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

[dotcom]

Однопоточный во всех неожиданных местах, глобальные локи повсюду, т.е. если оно решит записать что-то на диск большое, то все ждут когда закончит.

По поводу локов - это известная история, но не так это страшно, как пишут. Зависит от задачи, конечно. Если много писать с большого кол-ва клиентов напрямую в базу, то тогда да, все умрет. С MySQL тут даже сравнивать не стоит. Последний будет более надежный на одном инстансе. Mongo изначально было спроектировано быстро, чтобы работать с файлами напрямую. Не знаю, сделали ли они наконец collection level lock, но собирались. На наших тестах, в том числе и на тысячах конкурентных операциях и на чтение и на запись Mongo была быстрее Cassandra'ы. С одной тонкостью - у нас была своя очередь и кэш. То, что Cassandra имеет свои гарантии на скорость записи - это похвально. Но если бы она это еще делала быстро, то цены бы ей не было.
Про однопоточность и maintenance откуда дрова?

[valchkou]

То, что Cassandra имеет свои гарантии на скорость записи - это похвально. Но если бы она это еще делала быстро, то цены бы ей не было.

дайте пожалуйста циферки по касандре если есть
и что значит не быстро ?

[crypto5]

Однопоточный во всех неожиданных местах, глобальные локи повсюду, т.е. если оно решит записать что-то на диск большое, то все ждут когда закончит.

По поводу локов - это известная история, но не так это страшно, как пишут. Зависит от задачи, конечно. Если много писать с большого кол-ва клиентов напрямую в базу, то тогда да, все умрет. С MySQL тут даже сравнивать не стоит. Последний будет более надежный на одном инстансе. Mongo изначально было спроектировано быстро, чтобы работать с файлами напрямую. Не знаю, сделали ли они наконец collection level lock, но собирались. На наших тестах, в том числе и на тысячах конкурентных операциях и на чтение и на запись Mongo была быстрее Cassandra'ы. С одной тонкостью - у нас была своя очередь и кэш. То, что Cassandra имеет свои гарантии на скорость записи - это похвально. Но если бы она это еще делала быстро, то цены бы ей не было.

Я конечно не знаю какие именно бенчмарки вы делаете, везде в интернетах пишут что кассандра быстрее записывает, но как я уже написал монго живет неплохо пока у вас данные в памяти помещаются, а кассандра живет хорошо всегда. При этом у кассандры есть компрессия а у монго нету, т.е. кассандра намного больше в память может поместить. Ну и вот свеженькие бенчмарки от датастакса - ответов от монго гайс все еще нету: http://www.datastax.com/resources/white ... -databases

Про однопоточность и maintenance откуда дрова?

Однопоточность например у ихнего map reduction, мейнтененц по сравнению с кассандрой вполне присутствует, в кассандре операции добавления нодов, решардинга и т.д. намного проще, все ноды одинаковы и конфигурируются по p2p протоколу, а у монго нужно поднимать сервера с разными ролями(config server, mongos, mongod) при этом их нужно руками дуплицировать для fault tolerance.

[dotcom]

дайте пожалуйста циферки по касандре если есть
и что значит не быстро ?

Быстро - это когда разница в кол-ве операций на чтение были на порядок медленнее. Конкретных цифр нет на руках. Вот вам похожий benchmark, сделанный примерно в то же время:
http://amesar.wordpress.com/2011/10/19/ ... enchmarks/

[dotcom]

Я конечно не знаю какие именно бенчмарки вы делаете, везде в интернетах пишут что кассандра быстрее записывает, но как я уже написал монго живет неплохо пока у вас данные в памяти помещаются, а кассандра живет хорошо всегда.

Я с этим не спорил.

Однопоточность например у ихнего map reduction,

У Mongo вроде родно map-reduce'а нет? Или я что-то пропустил?

мейнтененц по сравнению с кассандрой вполне присутствует, в кассандре операции добавления нодов, решардинга и т.д.

Понял. Но это скорее проблема конфигурирования. Я, честно говоря, поднимал cassandra'у только один раз и игрушечную с одной нодой. Про конфигурирование и maintenance могу говорить только со слов других.=

[АццкоМото]

а у монго нужно поднимать сервера с разными ролями(config server, mongos, mongod) при этом их нужно руками дуплицировать для fault tolerance.

Ну уж прямо так и руками. У нас вот клиенты мышкой водят (мышку - да, руками) в стиле next-next-finish и - voila - все само автоматом деплоится в железо (или в облако, если хочется извращений)

[crypto5]

Однопоточность например у ихнего map reduction,

У Mongo вроде родно map-reduce'а нет? Или я что-то пропустил?

Есть, на джава скрипте, это был один из selling points, пока народ не понял что ее использовать очень не просто.

мейнтененц по сравнению с кассандрой вполне присутствует, в кассандре операции добавления нодов, решардинга и т.д.

Понял. Но это скорее проблема конфигурирования. Я, честно говоря, поднимал cassandra'у только один раз и игрушечную с одной нодой. Про конфигурирование и maintenance могу говорить только со слов других.=[/quote]
Это и конфигурирование и поддержка и траблшутинг - больше движущихся частей.
К слову кассандра еще и гибче в плане инфраструктуры, например позволяет поднять два синхронизированных кластера, один для продакшн другой для аналитики, что бы друг другу не мешали. Или поднять два кластера и синхронизировать их в разных географических зонах. Монго насколько я знаю такого не умеет.

[vladich]

По поводу локов - это известная история, но не так это страшно, как пишут. Зависит от задачи, конечно. Если много писать с большого кол-ва клиентов напрямую в базу, то тогда да, все умрет. С MySQL тут даже сравнивать не стоит. Последний будет более надежный на одном инстансе. Mongo изначально было спроектировано быстро, чтобы работать с файлами напрямую. Не знаю, сделали ли они наконец collection level lock, но собирались. На наших тестах, в том числе и на тысячах конкурентных операциях и на чтение и на запись Mongo была быстрее Cassandra'ы. С одной тонкостью - у нас была своя очередь и кэш. То, что Cassandra имеет свои гарантии на скорость записи - это похвально. Но если бы она это еще делала быстро, то цены бы ей не было.

Нет там collection level lock. По крайней мере пока.

Я конечно не знаю какие именно бенчмарки вы делаете, везде в интернетах пишут что кассандра быстрее записывает, но как я уже написал монго живет неплохо пока у вас данные в памяти помещаются, а кассандра живет хорошо всегда. При этом у кассандры есть компрессия а у монго нету, т.е. кассандра намного больше в память может поместить. Ну и вот свеженькие бенчмарки от датастакса - ответов от монго гайс все еще нету: http://www.datastax.com/resources/white ... -databases

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

[crypto5]

а у монго нужно поднимать сервера с разными ролями(config server, mongos, mongod) при этом их нужно руками дуплицировать для fault tolerance.

Ну уж прямо так и руками. У нас вот клиенты мышкой водят (мышку - да, руками) в стиле next-next-finish и - voila - все само автоматом деплоится в железо (или в облако, если хочется извращений)

А какую они тулзу для этого юзают?

[crypto5]

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

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

[АццкоМото]

А какую они тулзу для этого юзают?

если юзеры - то ту, которую мы для них сделали, а есть ли какой-то 3rd party под этой тулзой, я не знаю, совсем не тем занимаюсь

[vladich]

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

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

Зато есть преимущества в уменьшении трафика между клиентом и сервером. И сложные записи можно сжимать частично, только то что нужно. Если нужно жать вообще все - это можно в конце концов делать на уровне файловой системы. Я не к тому, что сжатие на уровне сервера вообще не нужно - нужно, и у них это в ближайших планах есть, просто это не то, на что надо смотреть в первую очередь.

[crypto5]

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

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

Зато есть преимущества в уменьшении трафика между клиентом и сервером. И сложные записи можно сжимать частично, только то что нужно. Если нужно жать вообще все - это можно в конце концов делать на уровне файловой системы. Я не к тому, что сжатие на уровне сервера вообще не нужно - нужно, и у них это в ближайших планах есть, просто это не то, на что надо смотреть в первую очередь.

Кассандра использует thrift как протокол комуникации, и в нем уже встроена компрессия, что имхо правильно и не приносит никакой головной боли разработчикам.
По поводу файловой системы, то в линуксах, где все в основном это дело пускают, стабильной файловой системы с прозрачной компрессией к сожалению нет, иначе она действительно была бы не нужна на уровне БД.

[Mic]

Статья вообще ни о чем.

Статья о том, что рынок сильно повернулся к программерам передом и работодатели косят как в '99-ом. Там в начале ясно сказано - чисто личные наблюдения, без статистики, которые, кастати, были интересны тысячам.

Какой-то писатель судорожно пытается выйти из recovery mode на хабре.

Ну просветите, в каком еще mode вы можете еще запостить на хабр, после того как школьнеги засрали вам карму?

[Мальчик-Одуванчик]

Статья вообще ни о чем.

Статья о том, что рынок сильно повернулся к программерам передом и работодатели косят как в '99-ом. Там в начале ясно сказано - чисто личные наблюдения, без статистики, которые, кастати, были интересны тысячам.

Какой-то писатель судорожно пытается выйти из recovery mode на хабре.

Ну просветите, в каком еще mode вы можете еще запостить на хабр, после того как школьнеги засрали вам карму?

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

[АццкоМото]

А там, на хабре, попадается что-нибудь стоящее?

Попадается. Как бриллианты среди навоза - нечасто, но удивительно

[Мальчик-Одуванчик]

А там, на хабре, попадается что-нибудь стоящее?

Попадается. Как бриллианты среди навоза - нечасто, но удивительно

Так и представил что сейчас обьявится crypto5 и попросит,в качестве примера, продемонстрировать кусочек говна кода с удивительно-блестящими вкраплениями.
Мой интерес в другом - если не совсем просекаешь тему, к примеру незнаком с существенными нюансами, имеет ли смысл написать туда статейку с целью раскрутить аудиторию на обсуждение именно по теме? И будет ли толк с такого обсуждения? Вам, к примеру попадались статьи, после прочтения которых появлялось желание оставить комментарий по-существу?

[АццкоМото]

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

Попадались. Но глянув одним глазом, что в комменты уже нагадили, это хотение уничтожал. Привет - верх интеллектуальности, вежливости, отзывчивости и адекватности после Хабры.
Собственно, у меня там даже аккаунта нет по этим причинам.

[crypto5]

А там, на хабре, попадается что-нибудь стоящее?

Попадается. Как бриллианты среди навоза - нечасто, но удивительно

Так и представил что сейчас обьявится crypto5 и попросит,в качестве примера, продемонстрировать кусочек говна кода с удивительно-блестящими вкраплениями.
Мой интерес в другом - если не совсем просекаешь тему, к примеру незнаком с существенными нюансами, имеет ли смысл написать туда статейку с целью раскрутить аудиторию на обсуждение именно по теме? И будет ли толк с такого обсуждения? Вам, к примеру попадались статьи, после прочтения которых появлялось желание оставить комментарий по-существу?

Лучше писать на dzone или hacker news ))

[Мальчик-Одуванчик]

"Партр привстал и представил публике оплетенные соломой образцы блевотины. Настоящий успех выпал на долю самого красивого непереваренного яблока с красным вином"

[АццкоМото]

Партр, Рартр, Сартр, Тартр... Уууууартр
да, про яблоко - в... хммм... яблочко

[Easbayguy]

Однопоточный во всех неожиданных местах, глобальные локи повсюду, т.е. если оно решит записать что-то на диск большое, то все ждут когда закончит.

По поводу локов - это известная история, но не так это страшно, как пишут. Зависит от задачи, конечно. Если много писать с большого кол-ва клиентов напрямую в базу, то тогда да, все умрет. С MySQL тут даже сравнивать не стоит. Последний будет более надежный на одном инстансе. Mongo изначально было спроектировано быстро, чтобы работать с файлами напрямую. Не знаю, сделали ли они наконец collection level lock, но собирались. На наших тестах, в том числе и на тысячах конкурентных операциях и на чтение и на запись Mongo была быстрее Cassandra'ы. С одной тонкостью - у нас была своя очередь и кэш. То, что Cassandra имеет свои гарантии на скорость записи - это похвально. Но если бы она это еще делала быстро, то цены бы ей не было.
Про однопоточность и maintenance откуда дрова?

Вы похоже на Монго дб updates не делали или каждые две месяца slaves не перестраивали для исключения фрагментации.

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

А какие именно задачи эти "Big Data Engineers" решают?

Щеки широко надувают

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

Я конечно не знаю какие именно бенчмарки вы делаете, везде в интернетах пишут что кассандра быстрее записывает

Да, Cassandra на запись быстрее чем на чтение.

[Интеррапт]

Я конечно не знаю какие именно бенчмарки вы делаете, везде в интернетах пишут что кассандра быстрее записывает

Да, Cassandra на запись быстрее чем на чтение.

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