Вышел CouchDB 1.0

> Это опциональное требование к реляционной БД, а не к БД вообще. Иначе при денормализации данных, которая происходит практически в каждом запросе sql появится неоднозначность.

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

С точки зрения теории NoSQL является подмножеством sql. Так что в вакууме ничего нового он дать не может. А в реальности за счет более простыхи продвинутых инструментов масштабирования - дает.

NoSQL это любой не SQL, включая объектные СУБД типа cache и прочее безобразие. Потому реляц. теория на NoSQL не распространяется ;)

> Вот, возьмём конкретно Twitter на Cassandra.

Cassandra не обеспечивает непротиворечивость

именно!!! цитата с их сайта:

«The CAP theorem (Brewer) states that you have to pick two of Consistency, Availability, Partition tolerance: You can't have the three at the same time and get an acceptable latency.

Cassandra values Availability and Partitioning tolerance (AP).»

Кассандра не обеспечивает Consistency, потому применение ее в системах требующих непротиворечивости данных невозможно.

не понимаю... это у вас триггер считает балланс?

map/reduce считает баланс. А база гарантирует, что на момент выборки, все записи будут обработаны.

а как же балланс меняется между нодами без транзакций?

То есть, нужна система, из нескольких нод, на любой узел которой приходит проводка, и при этом она гарантирует, что баланс, запрашиваемый с любого другого узла будет корректен? Или имелось нечто другое?

и как обеспечивается защита от «потерянных изменений»?

Биллинг «insert only», поэтому ни о каких потерянных изменениях не может быть и речи.

а насколько это капля в море? Может это использование скорее как исключение чем правило

Cassandra обеспечивает eventual consistency. То есть гарантируется, что данные через некоторое время, не превышающее т.н. «окно инконсистентности» придут в непротиворечивое состояние на всех нодах.

То есть консистентность там «достаточная».

>Если проводка их изменяет, значит они зависимые.

Игра слов они зависимы только при этой операции но они независимы по методу хранения и по их логической сути

Движения по всем счетам отражаются в одном документе, в том числе и fees/taxes/etc. Не вижу принципиальной разницы между этими движениями и основной проводкой.

месье а скажите сколько при таком подходе можно бизнес операций за раз сделать, и как можно в одном документе описать изменение в 40 таблицах причем эта же транзакция может менять не фиксированое количество значений полей в предполагаемых таблицах(может для задач билинга все это счастье и подходит на предмет структуры из 3х объектов , но это не массовый промышленый уровень это как секты при наличии массовых религий)

Да нишка у нескулевиков есть но она пока меленькая и скудненькая как по разработке так и по сопровождению(Недавно ради интереса поглядел Cashe был продукт на ней но даже там есть 3 вида доступа к данным и среди них SQL(и понятие транзакции там никто не отвергал потому как это мощный инструмент)),так что не надо брызгать слюной и доказывать что белое это черное...Коперников с вас не получится

>Еще один буратинистый пионеришко, попавший в БАНКу. То-то я смотрю, банк-клиент через жопу работает...

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

в этоге все прекрасно согласны что для таких частичных задач как билинг связаный с реальным временем эти системы могут применятся (задача узкоспециализированая), а что то посложнее скорее проще реализовать уже в SQL архитектуре DB, крупные игроки никогда свою основную Инфосистему не переведут на что то не SQL подобное, пока эти стандарты не созреют и не пройдут обкатку временем, пока это полигоны для нестандарртных задач и базовыми не расматриваются в принципе...

>> а как же балланс меняется между нодами без транзакций?

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

Да, именно это и имелось в виду.

и как обеспечивается защита от «потерянных изменений»?

Биллинг «insert only», поэтому ни о каких потерянных изменениях не может быть и речи.

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

> Cassandra обеспечивает eventual consistency. То есть гарантируется, что данные через некоторое время, не превышающее т.н. «окно инконсистентности» придут в непротиворечивое состояние на всех нодах.

вы забыли одно маленькое, но сильное условие - ПРИ ОТСУТСТВИИ НАГРУЗКИ на систему eventual consistency придет в непротиворечивое состояние. Поскольку нагрузка на insert/update/delete/select идет постоянно, но непротиворечивое состояние не достигается никогда.

Но вы, всё же, ответьте, Twitter - это крупный проект или так, мелочь пузатая? :)

крупный, но с ценой данных близкой к нулю, в отличии от цены данных в банковских системах. ;)

>крупный

Всё. Таким образом утверждение, что крупные проекты не используют NoSQL опровергнуто.

но с ценой данных близкой к нулю

1. Про это в исходной постановке ничего не говорилось.

2. Тем не менее, цена данных у подобных систем, хотя и невелика, но весьма и весьма далека от нуля. Этот вопрос тоже обсуждался выше.

Да, именно это и имелось в виду.

В распределенных транзакциях, не силен. Какие БД, кроме оракла их поддерживают? Это же настоящий rocket-science. В моей системе баланс будет верным с точностью до репликационного лага.

а как синкать значения между узлами чтобы не произошло затирание изменений счета клиента другой нодой.

Когда я говорю «insert only», это именно то и значит, то есть «затирание изменений счета клиента» в принципе не может быть. Данные только добавляются, существующие документы не перезаписываются.

После репликации все значения будут верными. Думаю, вам тоже надо подучить матчасть на предмет b-tree индексов и как couchdb хранит отредьюсенные данные.

> вы забыли одно маленькое, но сильное условие - ПРИ ОТСУТСТВИИ НАГРУЗКИ на систему eventual consistency придет в непротиворечивое состояние. Поскольку нагрузка на insert/update/delete/select идет постоянно, но непротиворечивое состояние не достигается никогда.

Интересно, а на уровне одной ноды хотя бы оно умеет хоть как-то гарантировать целостность хранимого фрагмента БД после аварийного отключения? Некое подобие ACID compliance для одной ноды, дабы после поднятия этой ноды, данные могли успешно расшариться на другие ноды.

Или выигрыш (даже частичный) этих noSQL получается за счёт игнорирования ACID на всех уровнях?...

месье а скажите сколько при таком подходе можно бизнес операций за раз сделать, и как можно в одном документе описать изменение в 40 таблицах

Если данные можно держать в одном документе зачем их растаскивать по таблицам?

массовый промышленый уровень

Знаю я этот промышленный уровень: от схемы данных волосы на жопе шевелятся. Причем чем старее проект тем сильнее шевелятся. Самые махровые у опсосов, 1c и галактики.

так что не надо брызгать слюной и доказывать что белое это черное...Коперников с вас не получится

Вы меня с кем то путаете. Я и не говорил что SQL не нужен. Я просто показал как биллинг легко и непринужденно лег на couchdb. Вас, наверно, забрызгала СчастливаяБелочка.

>> Да, именно это и имелось в виду.

В распределенных транзакциях, не силен. Какие БД, кроме оракла их поддерживают? Это же настоящий rocket-science. В моей системе баланс будет верным с точностью до репликационного лага.

распределенные транзакции поддерживают все современные СУБД уровня предприятия. даже MySQL. но каждая со своими нюансами и способами работы. К примеру для Oracle требуется расшаренный массив куда пишут все ноды ибо принцип работы shared disk, а MySQL ndb - работает в share nothing им нужно только видеть друг-друга.

а как синкать значения между узлами чтобы не произошло затирание изменений счета клиента другой нодой.

После репликации все значения будут верными. Думаю, вам тоже надо подучить матчасть на предмет b-tree индексов и как couchdb хранит отредьюсенные данные.

мы не понимаем друг друга. есть много-много клиентов. у каждого свой балланс. Балланс каждого клиента уменьшается/увиличивается в зависимости от внешних действий (потребление трафика, проведение оплаты). Вы храните оставшийся балланс? если нет, то система будет рассчитывать баланс на каждый пук и станет жутким тормозом уже на 100Gb данных, что очень мало.

Если остаток балланса хранится (что чаще всего), то как происходит его обновление? и как гарантируется консистентность обновлений балланса между нодами, когда 2-3 или 10 нод в параллель ведут запись данных в трафик и уменьшение балланса ОДНОГО и того же клиента?

> Интересно, а на уровне одной ноды хотя бы оно умеет хоть как-то гарантировать целостность хранимого фрагмента БД после аварийного отключения? Некое подобие ACID compliance для одной ноды, дабы после поднятия этой ноды, данные могли успешно расшариться на другие ноды.

дело в том, что системы типа Cassandra или BigTable ведут резервирование данных, потому после аварийного отключения одной ноды ничего не происходит - система имеет полную копию всех данных ноды, но размазанную по другим нодам. У Cass есть характеристика при одновременном отключении скольки нод появляется вероятность, что данные пропали - система не успела провести синхронизацию и отзеркалировать данные находящиеся на упавших нодах.

Ассоциативно работает как RAID-5, RAID-Z когда отключение одного винта не приводит к потере данных в системе.

Потому системы уровня Cassandra / Hbase / BigTable в некотором смысле обладают гарантией целостности.

> Или выигрыш (даже частичный) этих noSQL получается за счёт игнорирования ACID на всех уровнях?...

РСУБД обладают транзакциями и соответствующими гарантиями. платой за это явялется невозможность линейной масштабируемости - слишком большие накладные расходы. Получается, что на некотором числе нод скорость ухудшается, т.к. прибавка скорости от добавления новой меньше чем расходы на координацию транзакций между всеми нодами.

Чтобы получить масштабирование на множество нод (10-50, а может и тысячи) приходится отказываться от ACID и изобретать более мягкие требования, такие как Partition Tolerance и Eventual Consistency.

Смягченные требования подходят далеко не всем проектам. Но к примеру соц.сети и другая соц-хрень вполне может применять NoSQL-системы хранения данных.

> дело в том, что системы типа Cassandra или BigTable ведут резервирование данных, потому после аварийного отключения одной ноды ничего не происходит - система имеет полную копию всех данных ноды, но размазанную по другим нодам. У Cass есть характеристика при одновременном отключении скольки нод появляется вероятность, что данные пропали - система не успела провести синхронизацию и отзеркалировать данные находящиеся на упавших нодах.

Вот меня заинтересовало, что же произойдет, если нода не успела передать данные соседям и упала. При большой нагрузке это вполне реально, иначе бы не было «почти линейной масштабируемости». Или все-таки есть какой то «ACID хотя бы на N>=2 нод изначально»?

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

мы не понимаем друг друга

Тут одностороннее непонимание. Я вас прекрасно, а вы меня нет.

Я даже не знаю, как бы попроще объяснить.

Для каждого нового/измененного документа выполняется map/reduce, например, map кидает пару (id-счета, сумма операции), а reduce суммирует эти значения. На основе этого couchdb строит b-tree индекс, в узлах которого (id-счета) хранится баланс. Ненужность транзакций основывается на двух фактах:

1) За целостность индекса отвечает couchdb. То есть, при любом стечении обстоятельств, в каком бы порядке не пришли документы, как часто, параллельно или нет, но значение баланса в узле индекса будет точно соответствовать замэпредьюсенным документам.

2) couchdb гарантирует, что на момент выбора значений из этого индекса, все новые или измененные документы будут замэмредьюсены.

В совокупности с master-master репликацией это решает проблемы с синхронизаций нод — как только прошла реплика, следующее обращение к балансу даст корректный результат.

Вот тут уже вижу, что настраивается величина, сколько реплик «Кворум :)» должны подтвердить запись, прежде чем она считается успешной.

http://www.slideshare.net/benjaminblack/introduction-to-cassandra-replication...

На целостность самих нод при такой архитектуре похоже забили. Ибо кворум всё решит.

когда 2-3 или 10 нод в параллель ведут запись данных в трафик и уменьшение балланса ОДНОГО и того же клиента?

Тут, кстати, можно сделать consistent hashing по id клиента на чтение/запись баланса/операций с нод. Тогда даже репликационный лаг не помеха.

>Знаю я этот промышленный уровень: от схемы данных волосы на жопе шевелятся. Причем чем старее проект тем сильнее шевелятся. Самые махровые у опсосов, 1c и галактики.

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

>Ассоциативно работает как RAID-5, RAID-Z когда отключение одного винта не приводит к потере данных в системе.

но при этом для RAID-5 и производных от него падает производительность при выборочном чтении записи(хотя и последовательное тоже), тут также по анологии тоже наступают жудкие тормоза?

> но при этом для RAID-5 и производных от него падает производительность при выборочном чтении записи(хотя и последовательное тоже), тут также по анологии тоже наступают жудкие тормоза?

Судя по описанию выше, надо собрать кворум, т.е > 50% нод прочитать. По сути должны быть те же тормоза. Но в социалках на это просто забьют «кворум = 1». Пофигу, если некоторое время у кого-то будет отображаться, например, старая версия статьи.

Кажется мне, при повышении требований к надежности, это будет копия MySQL кластер с другой формой представления данных.

> Вот меня заинтересовало, что же произойдет, если нода не успела передать данные соседям и упала. При большой нагрузке это вполне реально, иначе бы не было «почти линейной масштабируемости». Или все-таки есть какой то «ACID хотя бы на N>=2 нод изначально»?

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

зависит от системы. HBase делает ретурн вызывающему методу когда данные уже разошлись по репликам. Таким образом псевдо-транзакции как бы есть ;)

ACID нет, есть «Partition Tolerance и Eventual Consistency».

Для многих систем данные появляются на ноде когда они ушли в кластер, а не до того. Плюс некоторые системы имеют режим восстановления - в MySQL ndb есть что-то такое.

Но в больших системах типа NoSQL вся надежда на соседей. На себя не надеются ибо Partition Tolerance - защита данных от падения ноды.

ну а теперь ответьте сможете вы реализовать весь этот функционал в режиме NoSQL

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

И опять таки, я не говорил что собрался всех переводить на couchdb. Где вы все это вычитываете?

> Для каждого нового/измененного документа выполняется map/reduce, например, map кидает пару (id-счета, сумма операции), а reduce суммирует эти значения. На основе этого couchdb строит b-tree индекс, в узлах которого (id-счета) хранится баланс. Ненужность транзакций основывается на двух фактах:

Ага, пасибо ))) теперь дошло )))

фактически документ в couchdb и есть транзакция. А MapReduce навешанные на документ - триггера на изменения в «таблицах» в терминах РСУБД.

Единственный косяк - «триггеры» MapReduce это триггеры after - вы не можете проверить балланс ДО проведения транзакции, т.к. реплика изменения могла еще не придти.

Нужно проверять балланс клиента и не дать ему потратить больше чем у нега на счете (дебетовая карта) Клиент: балланс 10rub Ноде1: клиент купил на 8rub, балланс 10, остаток балланса 2rub - проводка подтверждена. Ноде2: клиент купил на 4rub, балланс 10, остаток балланса 6rub - проводка подтверждена. Ноде2: пришла реплика с Ноде1, балланс клиента -2rub. Ноде1: пришла реплика с Ноде2, балланс клиента -2rub.

В РСУБД триггер поймает и откатит транзакцию в триггере before update.

> Судя по описанию выше, надо собрать кворум, т.е > 50% нод прочитать. По сути должны быть те же тормоза. Но в социалках на это просто забьют «кворум = 1». Пофигу, если некоторое время у кого-то будет отображаться, например, старая версия статьи.

тормозов не будет ;) кворум это ноды до которых должен проходит пинг. и все. кворум это защита от «Brain Splitting», других накладных расходов нет.

Нет MySQL кластер это совсем другой подход ;)

> тормозов не будет ;) кворум это ноды до которых должен проходит пинг. и все. кворум это защита от «Brain Splitting», других накладных расходов нет.

Разве нет? Просто кворум в Cassandra регулируемый, например N/2+1, то есть более половины реплик. В MySQL cluster - все реплики должны подтвердить коммит. Не тут ли кроется разница в производительности?

Защита от Brain Splitting в системе с _Eventual_ Consistency это наверное весело :) Сплита то не будет, а вот что с данными...

Хотя при трёх репликах в NoSQL при кворуме 2 и 1й невалидной записи в реплике, при отпадании одной валидной как раз и получится сплит-брейн. Некрасиво. Зато термин Eventual Consistency мне теперь ясен.

Нужно проверять балланс клиента и не дать ему потратить больше чем у нега на счете

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

> Разве нет? Просто кворум в Cassandra регулируемый, например N/2+1, то есть более половины реплик. В MySQL cluster - все реплики должны подтвердить коммит. Не тут ли кроется разница в производительности?

кроется ;) только кворум Cassandra и подтверждение коммита от разных node groups в MySQL - принципиально разные вещи ;)

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

> кроется ;) только кворум Cassandra и подтверждение коммита от разных node groups в MySQL - принципиально разные вещи ;)

А можно поподробней? В чём разница, если сделать кворум=ALL в Cassandra например и будет то же самое ожидание подтверждения записи «коммита» от всех реплик? Интересно было бы почитать об этом. Пока что принципиальных отличий от shared-nothing MySQL cluster я не вижу.

То, что скорость записи в БД они ускоряют, введя понятия quorum и позволив его уменьшать - ясно. Надежность от этого меняется в прямо противоположную сторону, это тоже очевидно. На странице 9 по этой линке видно:

http://www.slideshare.net/benjaminblack/introduction-to-cassandra-replication...

Пощупал тут MongoDB. Фшоке :)

=== cut ===

Миллион простых записей вставляется в 10(!) раз быстрее, чем в MyISAM.

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

На пробу запустил конвертацию БД форума. Правда, места жрёт... У!... Раза в три больше, чем в случае MyISAM. И это ещё без индексов. Хотя радует скорость создания индексов. Секунды (на целочисленных) там, где раньше уходили десятки минут.

И вдобавок ко всему, оно ещё и масштабируется.

Правда, говорят, плохо переносит повреждения. Ну, это мы ещё проверим.

...

Ещё фигею от скорости поблочной выборки в конце интервала: «1,700,001-1,700,100 of 1,804,368» извлекается секунд за 10. MySQL на таком вешался очень надолго...

БД форума с тремя целочисленными индексами заняла 10,4Гбайт против 4,9Гбайт на MyISAM и против 8,8Гбайт на InnoDB. При чём преобразование в последний занимало около 40 минут, а тут - минут 5 на всё. Продолжаю удивляться :)

=== cut ===

>уточни что ты под этим подразумеваешь , на кой дублить одно и тоже , из того что я видел не вся бугалтерия юзается на базах с SQL(вот там где его нет приходится заниматся костылями)

Ты просто не знаешь бухгалтерию, от того такие глупости говоришь. Принцип т.н. «двойной записи» — основа современного бухучета — был изобретен флорентийскими ростовщиками лет эдак полтыщи тому назад. За это время ничего лучше не придумали. Учи матчасть.

>Пощупал тут MongoDB. Фшоке :)

=== cut ===

эээ... А вот поясни, ты это сам тестил, или скопипастил откуда-то?

c:started use

>ты это сам тестил, или скопипастил откуда-то?

Сам тестил. Скопипастил от себя с http://balancer.ru/tech/forum/2010/07/t70507--mongodb-kto-to-uzhe-proboval.98...

c:started use

не понял

Сам тестил

Отличненько

не понял

гадание на капче )

небольшая цитата от Adam D'Angelo, бывшего CTO Facebook

1. Если разбивать данные по разным серверам на уровне приложения, то масштабируемость MySQL не такая уж и большая проблема. На 2008 год, в Facebook [1] у нас было 1800 MySQL серверов для которых требовалось всего два администратора. Конечно, вы не сможете сделать JOIN с данными с разных серверов, но NoSQL-базы вам тоже этого не позволят. Нет никаких данных о том, что в Facebook используют Cassandr'у как основное хранилище, и, кажется, что единственное, для чего она там нужна — это поиск по входящим сообщениям. [2]

2. В действительности, распределенные базы данных вроде Cassandra, MongoDB и CouchDB [3] не очень-то масштабируемы или стабильны. Например, парни из Твиттера пытаются перейти с MySQL'а на Cassandr'у целый год. Конечно, если кто-то расскажет про то, как он использовал любую из этих БД как основное хранилище на 1000 машин в течении года, то я изменю свое мнение.

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

4. В действительности, можно очень далеко уйти на одном MySQL совсем не заботясь о разбиение данных на уровне приложения. Можно легко «отмасштабировать» сервер на кучу ядер и тонны оперативки, ну и не надо забывать про репликацию. К тому же, если перед сервером стоит слой из memchached (который просто масштабируется), то единственное, что делает ваша БД это пишет новые данные. А для хранения больших объектов можно использовать S3 или любую другую распределенную хеш-таблицу. По этому пока вы уверены, что сможете масштабировать базу по мере роста, не нужно взваливать на себя ношу сделать БД масштабируемой еще на порядок больше, чем это действительно нужно.

5. Большинство проблем возникает в том случае, когда вы пытаетесь разбить данные по большому числу серверов самостоятельно. Но можно использовать промежуточный слой между базой, который отвечает за такого рода разбиение, что, собственно, и сделали во FriendFeed. [4]

6. Я верю, что реляционная модель это правильный способ структурирования данных в большинстве приложений, контент в которых создают пользователи. Схемы позволяют содержать данные в определенном виде по мере разработки новых версий сервиса, они же служат документацией и позволяют избежать кучи ошибок. Еще SQL позволяет обработать данные по необходимости, а не получать тонны сырой информации, которую потом еще нужно дополнительно обрабатывать в приложении. Я думаю, что вся шумиха вокруг «NoSQL» сразу закончится, как кто-то наконец разработает распределнную реляционную базу со свободной семантикой.

(c) http://sylvio.habrahabr.ru/blog/99884/

жесть...

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

Угу. Бухучет например. Идеально структурируется, главное — костылей не жалеть.

6. Я верю,

А я не верю.