Stock - где что почем?

[crypto5]

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

С моей точки зрения, NoSQL хорош для хранения временных/нестурктурированных данных которые не требуют backup и не предполагают ананлитической обработки внутри базы. Которому не нужен контроль транзакций и как вы о своем приложении, перезаписывается каждые 5 дней, веб логи и так далее.

Все таки какие ваши предпочтения для решения вашей задачи?
Для НоСкл применений много, та же real time аналитика (i.e. google analytics), где хочется смотреть сложную аналитику с sub-second latency, а для этого нужно считать много разных каунтеров, делать денормализации в real-time, или к примеру search engines, или вебмейл, или social network какой, анализ логов все таки делается без nosql, легче на hdfs писать и потом map reduce делать.
Транзакции тоже научились делать, например с помощью локов zookeeper: https://zookeeper.apache.org/doc/r3.1.2 ... haredLocks или copmare and swap в кассандре: http://www.datastax.com/dev/blog/lightw ... sandra-2-0 a некоторые проприетарные решения делают все это из коробки: http://research.google.com/pubs/pub38125.html ))

А в вашем кейсе (когда много tombstones in sstables, и много данных на ноде), стоит посмотреть на leveled compaction - она призвана помогать именно в таких ситуациях: http://www.datastax.com/dev/blog/levele ... -cassandra

[dotcom]

С моей точки зрения, NoSQL хорош для хранения временных/нестурктурированных данных которые не требуют backup и не предполагают ананлитической обработки внутри базы. Которому не нужен контроль транзакций и как вы о своем приложении, перезаписывается каждые 5 дней, веб логи и так далее.

По поводу backup'а вы погорячились. У носкля много достоинств (как и недостатков), но главное, что они позволяют хранить что угодно без оглядки на структуру и реляционную целостность (что вы правильно заметили), а значит облегчают задачу миграции и фрагментации данных в том числе и в реальном времени, где в случае с РБД миграция и фрагментация всегда нетривиальна.

[crypto5]

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

[dotcom]

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

Никто не спорит.

[Ljolja]

В кассандре нету аналитических запросов, я так понимаю стандартный способ это прикручивать к ней хадуп, и на нем сложную аналитику считать. Любит/не любит понятно зависит от конкретных кейсов.

hadoop к аналитике тоже имеет весма далекое отношение. А для каких задач ваша кассандра подойдет?

[crypto5]

В кассандре нету аналитических запросов, я так понимаю стандартный способ это прикручивать к ней хадуп, и на нем сложную аналитику считать. Любит/не любит понятно зависит от конкретных кейсов.

hadoop к аналитике тоже имеет весма далекое отношение.

Да неужели?

А для каких задач ваша кассандра подойдет?

Я выше привел примеров.

[Ljolja]

А для каких задач ваша кассандра подойдет?

Я выше привел примеров.

Вы имеете ввиду

ну и где вы предлагаете хранить данные если не в кассандре?

или НоСкл = kассандра ?

[crypto5]

А для каких задач ваша кассандра подойдет?

Я выше привел примеров.

Вы имеете ввиду

ну и где вы предлагаете хранить данные если не в кассандре?

или НоСкл = kассандра ?

да

[Zorkus]

[Просто изначально был наезд на java программистов от альберта

Да это не наезд, просто ответ Крысе на слова что база и SQL - это все жутко просто

Для джава девелопера который работает с хибернейтом и пищет другого рода SQL запросы на выборку, вставку и проч - не должно быть ничего сложного. Достаточно знать об индексах, batch, пуле и иже с ним это все замечательно делается в самой Java (кроме индексов) - тот же голый JDBC который нынче уже не в моде ну просто и batch замутит, и пул коннекшенов можно там же организовать и транзакции, д и т п. Если требуют намного больше - пусть наймут еще одного человека, специалиста по базе - не знаю уж кого, админа, девелопера, архитектора, и он пуская посматривает и советы дает. Я так понимаю.

Я года 4 довольно активно с ораклом работал, у нас такого не было в целом, чему я рад.

От серверсайдщиков, кто с более-менее крупными базами работали (хотя бы десятки миллионов записей в таблицах), ожидались и само собой разумелось что они конечно не на уровне хорошего админа оракла, но на некотором приличном уровне знают SQL/PL/SQL, внутренности оракла и умеют оптимизировать более-менее.

[Zorkus]

Ну например кассандра отлично ест обсуждаемые 10k inserts/updates даже если все не помещается в памяти, в силу своих архитектурных решений, то же самое hbase например.
А монго это странная база, я ее защищать не берусь

Да ест первые 10K insert/updates, а на 3ем терабайте начинаются затыки с compact/repair, колличество записей в табличке приходится смотреть в статистике, потому что "select count" сваливается на timeout. Записи которые часто изменяются ставят в затык саму табличку, которую потом невозможно не пофиксит/не пересоздать и приходится удалять физически файлы/директории на всех нодах и перестартовывать. Там много веселого, когда начинаешь сопровождать.

Ну если держать по 3 террабайта на одном ноде, то наверное да, так и будет

Ну давайте посмотрим: 10k inserts/sec x 3600*24 = 864,000,000 records per day, average size 500bytes.
Для простоты 400ГБ в день. 5 node cluster, 3 replicas. Итого 240ГБ на машину в день, 3 ТБ через 10 дней. Если предположить что ночью народ не работает, то через 20 дней.
То есть вы либо должны не хранить такие данные в кассандре, либо удалять их раз в месяц.

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

В HDFS

[crypto5]

Да ест первые 10K insert/updates, а на 3ем терабайте начинаются затыки с compact/repair, колличество записей в табличке приходится смотреть в статистике, потому что "select count" сваливается на timeout. Записи которые часто изменяются ставят в затык саму табличку, которую потом невозможно не пофиксит/не пересоздать и приходится удалять физически файлы/директории на всех нодах и перестартовывать. Там много веселого, когда начинаешь сопровождать.

Ну если держать по 3 террабайта на одном ноде, то наверное да, так и будет

Ну давайте посмотрим: 10k inserts/sec x 3600*24 = 864,000,000 records per day, average size 500bytes.
Для простоты 400ГБ в день. 5 node cluster, 3 replicas. Итого 240ГБ на машину в день, 3 ТБ через 10 дней. Если предположить что ночью народ не работает, то через 20 дней.
То есть вы либо должны не хранить такие данные в кассандре, либо удалять их раз в месяц.

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

В HDFS

ХДФС я уже предлагал, если выбрали кассандру, наверное им нужно как то более оперативно читать отдельные записи.

[Krys-Krys]

Я года 4 довольно активно с ораклом работал, у нас такого не было в целом, чему я рад.

От серверсайдщиков, кто с более-менее крупными базами работали (хотя бы десятки миллионов записей в таблицах), ожидались и само собой разумелось что они конечно не на уровне хорошего админа оракла, но на некотором приличном уровне знают SQL/PL/SQL, внутренности оракла и умеют оптимизировать более-менее.

Я как-то на проекте работала, лет так 6-7 назад. Так он начался "за здравие", а закончился "за упокой", вроде все шло хорошо по началу, и все 4 джава девелопера писали исключительно на джаве, а потом вдруг джава закончилась и все стали писать на PL/SQL. Ну, научились. Это я так просто вспомнила - на сон грядущий. Я тогда очень хорошо знала PL/SQL но с тех пор конечно же забыла.

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

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

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

Все верно, только хрюкающего забыли.

[crypto5]

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

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

Все верно, только хрюкающего забыли.

Ну там уже вариантов масса может быть.

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

Ну если держать по 3 террабайта на одном ноде, то наверное да, так и будет

Ну давайте посмотрим: 10k inserts/sec x 3600*24 = 864,000,000 records per day, average size 500bytes.
Для простоты 400ГБ в день. 5 node cluster, 3 replicas. Итого 240ГБ на машину в день, 3 ТБ через 10 дней. Если предположить что ночью народ не работает, то через 20 дней.
То есть вы либо должны не хранить такие данные в кассандре, либо удалять их раз в месяц.

Как-то маловато нодов-то. Бэкапные опять-таки не плохо бы учесть.

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

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

SDB/Dynamo - пиши что хочешь.

[Easbayguy]

Как-то маловато нодов-то. Бэкапные опять-таки не плохо бы учесть.

Может я что то пропустил, а какие бэкапные ноды в кассандре? Мы по старинке со снапшотами.

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

Как-то маловато нодов-то. Бэкапные опять-таки не плохо бы учесть.

Может я что то пропустил, а какие бэкапные ноды в кассандре? Мы по старинке со снапшотами.

Да не, знаете наверняка. Это NetworkTopologyStrategy, когда кластер deployed across multiple data centers. При этом можно оговорить какой DC используется для read/write, a какой DC по сути backup.

[crypto5]

Как-то маловато нодов-то. Бэкапные опять-таки не плохо бы учесть.

Может я что то пропустил, а какие бэкапные ноды в кассандре? Мы по старинке со снапшотами.

Да не, знаете наверняка. Это NetworkTopologyStrategy, когда кластер deployed across multiple data centers. При этом можно оговорить какой DC используется для read/write, a какой DC по сути backup.

Это не бекап, он не спасает от ситуации когда скажем в результате програмной ошибки получились битые данные, потому что они будут и на рабочем кластере и на hot stand by.

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

Это софистика. Да не спасает. Но реализует real-time recovery model, и/или ситуацию network partitioning.

[Easbayguy]

Это не наша модель, хотя мы будем использовать NetworkTopologyStrategy чтобы плавно переехать из дата центра в Бай Арии
в Неваду.

[Сабина]

С моей точки зрения, NoSQL хорош для хранения временных/нестурктурированных данных которые не требуют backup и не предполагают ананлитической обработки внутри базы. Которому не нужен контроль транзакций и как вы о своем приложении, перезаписывается каждые 5 дней, веб логи и так далее.

По поводу backup'а вы погорячились. У носкля много достоинств (как и недостатков), но главное, что они позволяют хранить что угодно без оглядки на структуру и реляционную целостность (что вы правильно заметили), а значит облегчают задачу миграции и фрагментации данных в том числе и в реальном времени, где в случае с РБД миграция и фрагментация всегда нетривиальна.

Если там и аривация данных поставлена лучше чем в RDB то точно стоит ознакoмится .
Вот как бы не ругали тут Oracle мне например в нем много нравится, а именно:
- мошная аналитика
- parallel processing ( не хуже ...)
- partitionining
- архивация ( а она таки есть и неплохая несмотря на)

online/nearline хранить на самом деле не так уж много надо. Кого волнуют данные 5 летней давности. Но если у заволнуют то пусть они будут partitioned например.

[Zorkus]

Я года 4 довольно активно с ораклом работал, у нас такого не было в целом, чему я рад.

От серверсайдщиков, кто с более-менее крупными базами работали (хотя бы десятки миллионов записей в таблицах), ожидались и само собой разумелось что они конечно не на уровне хорошего админа оракла, но на некотором приличном уровне знают SQL/PL/SQL, внутренности оракла и умеют оптимизировать более-менее.

Я как-то на проекте работала, лет так 6-7 назад. Так он начался "за здравие", а закончился "за упокой", вроде все шло хорошо по началу, и все 4 джава девелопера писали исключительно на джаве, а потом вдруг джава закончилась и все стали писать на PL/SQL. Ну, научились. Это я так просто вспомнила - на сон грядущий. Я тогда очень хорошо знала PL/SQL но с тех пор конечно же забыла.

Ну почему "за упокой"? В Ынтерпрайз-приложениях есть логика, которую естественным образом удобнее описывать в реляционных, а не объектных терминах, и которые гораздо эффективнее исполнять внутри СУБД, а не стрелять запросами из джавы.

[crypto5]

Я года 4 довольно активно с ораклом работал, у нас такого не было в целом, чему я рад.

От серверсайдщиков, кто с более-менее крупными базами работали (хотя бы десятки миллионов записей в таблицах), ожидались и само собой разумелось что они конечно не на уровне хорошего админа оракла, но на некотором приличном уровне знают SQL/PL/SQL, внутренности оракла и умеют оптимизировать более-менее.

Я как-то на проекте работала, лет так 6-7 назад. Так он начался "за здравие", а закончился "за упокой", вроде все шло хорошо по началу, и все 4 джава девелопера писали исключительно на джаве, а потом вдруг джава закончилась и все стали писать на PL/SQL. Ну, научились. Это я так просто вспомнила - на сон грядущий. Я тогда очень хорошо знала PL/SQL но с тех пор конечно же забыла.

Ну почему "за упокой"? В Ынтерпрайз-приложениях есть логика, которую естественным образом удобнее описывать в реляционных, а не объектных терминах, и которые гораздо эффективнее исполнять внутри СУБД, а не стрелять запросами из джавы.

Тем не менее куча народа использует костыли вроде ejb и hibernate превращающиe реляционки в обьектные базы

[crypto5]

Это софистика. Да не спасает. Но реализует real-time recovery model, и/или ситуацию network partitioning.

Да, только это ортогонально бекапам,и решает совсем другие задачи