Что же происходит на рынке IT-труда в США?

[Леонид Ильич Брежнев]

Нужно еще про такой knob, как управляемая consistence, не забывать.
От ее полного отсуствия (eventual consistence) до ее полного присутсвует (consistent read).

[crypto5]

Это все бородатые урбан мифы про то что кассандра тормозит на чтении и у нее неправильная консистенци.

[Интеррапт]

Это все бородатые урбан мифы про то что кассандра тормозит на чтении и у нее неправильная консистенци.

А разве кто-то говорит, что Кассандра тормозит на чтении?

[crypto5]

Это все бородатые урбан мифы про то что кассандра тормозит на чтении и у нее неправильная консистенци.

А разве кто-то говорит, что Кассандра тормозит на чтении?

Ок, говорит что она супербыстрая на запись а скорость чтения не так уж и важна.

[Интеррапт]

Это все бородатые урбан мифы про то что кассандра тормозит на чтении и у нее неправильная консистенци.

А разве кто-то говорит, что Кассандра тормозит на чтении?

Ок, говорит что она супербыстрая на запись а скорость чтения не так уж и важна.

Ну да. Кассандру (из NoSQL решений) обычно выбирают по критериям скорости записи, а скорость чтения - уже вторичней.

[dotcom]

Это все бородатые урбан мифы про то что кассандра тормозит на чтении и у нее неправильная консистенци.

А разве кто-то говорит, что Кассандра тормозит на чтении?

Разница по скорости чтения с Mongo в наших тестах достигала одного порядка. Вверху была ссылка похожих тестов. Цифры одинаковые.

[Интеррапт]

Это все бородатые урбан мифы про то что кассандра тормозит на чтении и у нее неправильная консистенци.

А разве кто-то говорит, что Кассандра тормозит на чтении?

Разница по скорости чтения с Mongo в наших тестах достигала одного порядка. Вверху была ссылка похожих тестов. Цифры одинаковые.

Вот довольно свежие бенчмарки.

http://www.datastax.com/wp-content/uplo ... abases.pdf

[crypto5]

Это все бородатые урбан мифы про то что кассандра тормозит на чтении и у нее неправильная консистенци.

А разве кто-то говорит, что Кассандра тормозит на чтении?

Ок, говорит что она супербыстрая на запись а скорость чтения не так уж и важна.

Ну да. Кассандру (из NoSQL решений) обычно выбирают по критериям скорости записи, а скорость чтения - уже вторичней.

А как вы определили что "обычно"?

[Интеррапт]

А как вы определили что "обычно"?

Вот так вот взял и определил. Учитывая, что обычно слышу от людей (или читаю в блогах), что кассандра была выбрана среди других решений в освноном из-за high availability и write scalability.

[dotcom]

Вот довольно свежие бенчмарки.

http://www.datastax.com/wp-content/uplo ... abases.pdf

Ну да, только компания продает консалтинг вокруг Cassandra. Удивительно, чтобы у них benchmark'и были хуже для оной.

[Mic]

А там, на хабре, попадается что-нибудь стоящее? В принципе ресурс выглядит заманчиво для меня как некий аналог самиздата, но с упором в компьютерные технологии. Как правильно говорят,статью стоит написать хотя бы для того чтобы лучше самому понять тему. Но не менее важно получить профессиональные комментарии. Вот с этим как дела обстоят?

Если отсеивать откровенный шлак об "очередном безусловном флагмане среди мобильников" или типа того, то сайт, как новостной, очень хороший. Например там идет целая серия постов о Curiosity на Марсе, новинки в технологиях обсуждаются, технологические тренды.

[crypto5]

Вот довольно свежие бенчмарки.

http://www.datastax.com/wp-content/uplo ... abases.pdf

Ну да, только компания продает консалтинг вокруг Cassandra. Удивительно, чтобы у них benchmark'и были хуже для оной.

Вот есть бенчмарки старой версии от неконсультантов. http://www.networkworld.com/cgi-bin/mai ... 63595.html

[АццкоМото]

Да, в этом как-бы и основной поинт Кассандры, когда нужно супер-быстрая запись, а скорость чтения не так уж и важна.

Без всякого ехидства... а когда это нужно? Ну просто не могу представить себе такую ситуацию

[Интеррапт]

Да, в этом как-бы и основной поинт Кассандры, когда нужно супер-быстрая запись, а скорость чтения не так уж и важна.

Без всякого ехидства... а когда это нужно? Ну просто не могу представить себе такую ситуацию

Например, для аналитики, когда у тебя миллионы мобильных инсталляций пуляют данные с логами (тут юзер нажал на эту кнопочку, тут на эту) - ты все это собираешь в базу на сервере, а потом уже (переодически) запускает какой-нибудь MapReduce job для анализа этих данных (в моей компании счет идет на миллиарды записей).
Или для банков, когда ты записываешь в базу миллионы транзакций, а вот чтение этих транзакций происходит намного реже.

[АццкоМото]

Например, для аналитики, когда у тебя миллионы мобильных инсталляций пуляют данные с логами (тут юзер нажал на эту кнопочку, тут на эту) - ты все это собираешь в базу на сервере, а потом уже (переодически) запускает какой-нибудь MapReduce job для анализа этих данных.
Или для банков, когда ты записываешь в базу миллионы транзакций, а вот чтение этих транзакций происходит намного реже.

Но мне же скорость записи для аналитики вообще не важна, нет? Ну запулили данные, пролежали они до записи в очереди аж цельных 5 минут - кому от этого плохо-то? Я, может, анализ вообще послезавтра запущу

[Интеррапт]

Но мне же скорость записи для аналитики вообще не важна, нет? Ну запулили данные, пролежали они до записи в очереди аж цельных 5 минут - кому от этого плохо-то? Я, может, анализ вообще послезавтра запущу

Как это не важна, если к тебе каждую секунду приходит огромное кол-во записей?

[АццкоМото]

Как это не важна, если к тебе каждую секунду приходит огромное кол-во записей?

«Обычное утро в семье Евгения Гришковца…
— Пап, подай соль.
— Вот, возьми соль… Ну как — соль… Просто белые крупицы, которые когда на язык сыпешь, они солоноватый привкус оставляют. Или в детстве, когда мама…
Выходит мама:
— Ну, как мама, просто женщина, которая проводит с тобой большую часть времени, которая любит тебя до беспамятства…
— Да ну тебя нафиг, я лучше в школе поем!»

Ну вот как огромное и каждую секунду? Пусть у нас 100 млн пользователей. И каждый нажимает на 10 кнопок в день. (и то и другое - ооооочень дофига). 1 ярд нажатий. Пусть у нас есть всего жалких 10 серверов и каждый репорт занимает сто байт. 10 гигов оперативки нужно на каждый сервер чтобы закэшировать ДЕНЬ работы при вообще не записывающей ничего дазе банных

[crypto5]

Как это не важна, если к тебе каждую секунду приходит огромное кол-во записей?

«Обычное утро в семье Евгения Гришковца…
— Пап, подай соль.
— Вот, возьми соль… Ну как — соль… Просто белые крупицы, которые когда на язык сыпешь, они солоноватый привкус оставляют. Или в детстве, когда мама…
Выходит мама:
— Ну, как мама, просто женщина, которая проводит с тобой большую часть времени, которая любит тебя до беспамятства…
— Да ну тебя нафиг, я лучше в школе поем!»

Ну вот как огромное и каждую секунду? Пусть у нас 100 млн пользователей. И каждый нажимает на 10 кнопок в день. (и то и другое - ооооочень дофига). 1 ярд нажатий. Пусть у нас есть всего жалких 10 серверов и каждый репорт занимает сто байт. 10 гигов оперативки нужно на каждый сервер чтобы закэшировать ДЕНЬ работы при вообще не записывающей ничего дазе банных

Я кассандру юзал для всякого machine learning-a, например есть набор текстов, скажем википедия, нужно вытащить из нее слова наиболее часто встречающиеся в одном документе и скорее всего как то связанные по смыслу, для этого для каждого документа нужно сделать все возможные пары слов(или их подмножество) и заинкрементить каунтер в БД для каждой пары, получается пару миллионов апдейтов на документ.

[АццкоМото]

Я кассандру юзал для всякого machine learning-a, например есть набор текстов, скажем википедия, нужно вытащить из нее слова наиболее часто встречающиеся в одном документе и скорее всего как то связанные по смыслу, для этого для каждого документа нужно сделать все возможные пары слов(или их подмножество) и заинкрементить каунтер в БД для каждой пары, получается пару миллионов апдейтов на документ.

Ммм... и почему скорость записи была важна? Ну и пусть себе пишутся апдейты три часа. Солдат спит, машин лёрнинг идет. Красота.

[crypto5]

Я кассандру юзал для всякого machine learning-a, например есть набор текстов, скажем википедия, нужно вытащить из нее слова наиболее часто встречающиеся в одном документе и скорее всего как то связанные по смыслу, для этого для каждого документа нужно сделать все возможные пары слов(или их подмножество) и заинкрементить каунтер в БД для каждой пары, получается пару миллионов апдейтов на документ.

Ммм... и почему скорость записи была важна? Ну и пусть себе пишутся апдейты три часа. Солдат спит, машин лёрнинг идет. Красота.

Я например обрабатывал только 10% пар, и у меня процесс занимал неделю, т.е. если уменьшить throughput в 3 раза, то процесс займет 3 недели.
А еще мне очень хотелось бы заиметь кластер побольше и обрабатывать все пары.
Таких задач много например в поиске, таргетировании рекламы и некоторых других областях.

[АццкоМото]

Я например обрабатывал только 10% пар, и у меня процесс занимал неделю, т.е. если уменьшить throughput в 3 раза, то процесс займет 3 недели.
А еще мне очень хотелось бы заиметь кластер побольше и обрабатывать все пары.
Таких задач много например в поиске, таргетировании рекламы и некоторых других областях.

Ок, спасибо. Более-менее понятно, что смысл в этом есть. Хотя детали не вполне ясны, ну да и доверимся

[Интеррапт]

Ну вот как огромное и каждую секунду? Пусть у нас 100 млн пользователей. И каждый нажимает на 10 кнопок в день. (и то и другое - ооооочень дофига). 1 ярд нажатий. Пусть у нас есть всего жалких 10 серверов и каждый репорт занимает сто байт. 10 гигов оперативки нужно на каждый сервер чтобы закэшировать ДЕНЬ работы при вообще не записывающей ничего дазе банных

Да и никак это не будет по 10 гиг, а гораздо больше (кеш все-таки это не просто какие-то данные, а еще и сопутствующие метаданные для поддержания работы кеша).
И то и другое - нифига не дофига ("Пусть у нас 100 млн пользователей. И каждый нажимает на 10 кнопок в день.") Возьмем Angry Birds (и это настоящий пример). Там никак не будет 10 нажатий в день, а очень даже больше, особенно в "час пик", когда выйдет новая версия. Тут тебе и энвайронмент зарепортить нужно и перескоки между уровнями и нажатиями кнопок на меню да и вообще много чего. А еще при этом на этих же серверах обрабатываем эвенты от парочки виджетов, предустановленных на большинстве T-Mobile телефонов. И еще с десяток клиентов/приложений с активной userbase. А что делать будем, если сервер вдруг грохнется - терять все эти закешированные десятки гигабайт данных? Ладно еще если это события аналитики, это будет очень неприятно, но несмертельно (хотя после нескольких потерь данных - клиенты начнут разбегаться). А если это финансовые транзакции? Да и не важно - кешируешь ты или нет, в какой-то момент все-равно из кешей нужно начинать скидывать в базу и желательно делать это быстрее, чем заполняется кеш.

[АццкоМото]

Да и никак это не будет по 10 гиг, а гораздо больше (кеш все-таки это не просто какие-то данные, а еще и сопутствующие метаданные для поддержания работы кеша).

Да ну. Какие там метаданные? Ойпишнег, с которого пришли данные (4 байта), да тамстемп (8 байт). Все остальное может лежать до обработки в том виде, в котором пришло.

И то и другое - нифига не дофига ("Пусть у нас 100 млн пользователей. И каждый нажимает на 10 кнопок в день.") Возьмем Angry Birds (и это настоящий пример).

Ну давай возьмем. Плей говорит - от 10 до 50 миллионов инсталляций для Star Wars. А там посчитан и я - который скачал, посмотрел, сказал "фигня" и снес нафиг. Уверен, я не уникум.

Там никак не будет 10 нажатий в день, а очень даже больше, особенно в "час пик", когда выйдет новая версия. Тут тебе и энвайронмент зарепортить нужно и перескоки между уровнями и нажатиями кнопок на меню да и вообще много чего.

ну это все на девайсе надо аггрегировать, а не тупо постить на сервер каждый пук пользователя. и упаковывать нормально, а не выдавать высеры типа {"event":"button_pressed", "which_button":"this big red button which is next to proceed to next level button"}

А еще при этом на этих же серверах обрабатываем эвенты от парочки виджетов, предустановленных на большинстве T-Mobile телефонов. И еще с десяток клиентов/приложений с активной userbase.

Ну блин! А если на этих серверах мы еще и считаем число Пи с рекордной точностью и ищем внеземной разум?

А что делать будем, если сервер вдруг грохнется - терять все эти закешированные десятки гигабайт данных? Ладно еще если это события аналитики, это будет очень неприятно, но несмертельно (хотя после нескольких потерь данных - клиенты начнут разбегаться).

Ой, велика ценность. И так от Rovio "клиенты" (лоботрясы на самом-то деле) разбегаются, просто потому что нельзя птичками-свинками кормить безнаказанно общественность 15 лет. Потеря статистики по нажатым кнопочкам аж за целый день аж на одном из нескольких серверов не повлияет ни на что и вообще никак

[Интеррапт]

Ладно, убедил, не нужны базы данных, все нужно в кешах хранить. А мы то идиоты мучаемся.

Потеря статистики по нажатым кнопочкам аж за целый день аж на одном из нескольких серверов не повлияет ни на что и вообще никак

Никак, кроме того, что клиенты могут выкатывать претензии или просто уходить к конкурентам.
А какие возражения по финансовым транзакциям буду - тоже ерунда?

А если на этих серверах мы еще и считаем число Пи с рекордной точностью и ищем внеземной разум?

А это здесь при чем? Это одна и та же задача и данные приходят одного и того же мобильного SDK. Просто клиенты разные.

ну это все на девайсе надо аггрегировать, а не тупо постить на сервер каждый пук пользователя. и упаковывать нормально, а не выдавать высеры типа

{"event":"button_pressed", "which_button":"this big red button which is next to proceed to next level button"}

клиенты иной раз хотят schemaless данные.

[Интеррапт]

И то и другое - нифига не дофига ("Пусть у нас 100 млн пользователей. И каждый нажимает на 10 кнопок в день.") Возьмем Angry Birds (и это настоящий пример).

Ну давай возьмем. Плей говорит - от 10 до 50 миллионов инсталляций для Star Wars. А там посчитан и я - который скачал, посмотрел, сказал "фигня" и снес нафиг. Уверен, я не уникум.

https://play.google.com/store/apps/deta ... irds&hl=en

От 100 до 500 млн (а там еще есть разные версии).
Это не считая iOS девайсов.
Но не в этом суть.