про NoSql

[109]

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

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

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

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

Comments

[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.