про NoSql

[109]

у Плахова вопрос - почему их так много, и чем не угодил тарый добрый sql?

http://plakhov.livejournal.com/165139.html?thread=3276307

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

но на самом деле только две системы сделали это правильно, по крайней мере концептуально - кассандра и sql azure. из этих двух - правильнее sql azure, но это не продукт, а сервис.

Comments

[http://users.livejournal.com/_foreseer/]

а что именно сделано в кассандре правильно?

[109.livejournal.com]

правильно - use of multiple replicas как при чтении, так и при записи, чтобы всегда соблюдались consistency guarantees. это как бы другой способ обойти CAP theorem, отличный от sql azure. ну не обойти на самом деле, а продемонстрировать ошибочность.

[aristovich.livejournal.com]

а можно поинтересоваться что произойдет, если в момент записи потеряется связь между нодами? и в каким боком там демонстрируется ошибочность CAP theorem?

[109.livejournal.com]

что такое "связь между нодами"? мы читаем сразу с нескольких нод, никакой связи между самими нодами нет. или о чём ты?

[aristovich.livejournal.com]

вот из их wiki:
...
Cassandra values Availability and Partitioning tolerance (AP). Tradeoffs between consistency and latency are tunable in Cassandra. You can get strong consistency with Cassandra (with an increased latency). But, you can't get row locking: that is a definite win for HBase.
...

т.е. если закрутим до предела C - то молучим коллосальную latency - т.к. будем ждать ACK с большого числа нодов. что там и где опровергается?

[109.livejournal.com]

если у нас redundancy level = 5, и мы читаем с трёх и commit quorum тоже равен трём, то двум из пяти нод всегда можно зафейлиться (или ответить слишком поздно, что в распределённой системе одно и то же) без ущерба как для записи, так и для чтения. то есть мы всегда ждём только трёх самых быстрых, а не "колоссальную latency". то есть для любых заранее заданных значений MTTF ноды и latency distribution можно всегда выбрать такое значение redundancy level, чтобы 99.99% (or whatever) ответов *с гарантированной консистентностью* приходили в указанные сроки. что явно противоречит постулатам CAP.

тут важно, что мы рассматриваем node failure events (network-connectivity-related, or otherwise) как независимые события. иначе, конечно, можно питание у топ-левел раутера выдернуть, и клиент может ждать результат до посинения. к CAP это имеет мало отношения.

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

[aristovich.livejournal.com]

а в чем противоречие? теорема говорит (в том виде как я понимаю) что C, A и P всегда связаны. будем увеличивать redundancy - пойдет вверх latency.

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

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


ну и да - "старый добрых SQL" традиционно не дает выбора. т.е. в нем ты всегда имеешь CAP на максимальном уровное, а latency получаешь такую, на какую денег хватило (хардвер, сеть, и прочее). :) а всякие NoSQL базки дают возможность выбора.

[109.livejournal.com]

> будем увеличивать redundancy - пойдет вверх latency.

эээ, если ты внимательно прочитал то, что я написал, то всё наоборот. чем больше redundancy, тем меньше latency. потому что больше нод, которых можно не ждать.

> т.е. на практике CAP теорема особых проблем не создает (если мы готовы уйти от жесткого ACID). но, формально говоря, я не вижу ее опровержения.

а формального опровержения быть и не может, поскольку у CAP нет формального доказательства - как, например, у теоремы пифагора. опровержение - в смысле того, как обычно понимается вывод из CAP - что мы не можем иметь одновременно consistency, availability и partition tolerance. а на примере как кассандры, так и sql azure мы видим что - нет, можем.

> ну и да - "старый добрых SQL" традиционно не дает выбора.

причём выбора, в первую очередь, в плане scalability. только scale up, никакого scale out.

[aristovich.livejournal.com]

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

[109.livejournal.com]

ушло мылом.

[wizzard]

> 99.99%

Вот, сразу видно человека с нормальным опытом работы, а не идеализирующих теоретиков :)

[109.livejournal.com]

так это как бы industry standard при разговоре о latency: 90% latency, 99% latency, etc.

[plumqqz.livejournal.com]

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

Ну как что - кровью блевать. Если не хватает денег, то нужны деньги.

Вообще а)одна "машина вообще" может потянуть просто невообразимое количество транзакций - была бы машина б) не вижу проблем поставить две машины. Или три.

[109.livejournal.com]

так ведь не ставится sql server на две или три машины. только на одну. и oracle rac тоже, в общем, не настоящая distributed database.

[plumqqz.livejournal.com]

Но ведь есть 2PC и очереди.

[109.livejournal.com]

2PC? это несерьёзно. даже комментировать не хочется. а очереди - это да, но с консистентностью проблемы.

[plumqqz.livejournal.com]

Почему несерьезно? Вся жабахрень на этом живет и ничего.

[plumqqz.livejournal.com]

Какие проблемы с консистентностью? Для денег хватает.

[109.livejournal.com]

проблемы с консистентностью именно в смысле "C" в "CAP" - после того, как система приняла апдейт "version m" -> "version n", клиенты не должны на свои запросы получать версию m.

вообще, я рекомендую прочитать оригинал, чтобы понять, о чём мы тут разговариваем. а то твои комменты очень уж random.

[plumqqz.livejournal.com]

проблемы с консистентностью именно в смысле "C" в "CAP" - после того, как система приняла апдейт "version m" -> "version n", клиенты не должны на свои запросы получать версию m.

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

Оригинал - это пост или "теорему"? Пост я читал, про "теорему" тоже. Кому как, конечно, но мне доказательство методом "мамой клянусь" не кажутся доказательствами.

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