у Плахова вопрос - почему их так много, и чем не угодил тарый добрый sql?
http://plakhov.livejournal.com/165139.html?thread=3276307
sql не покрывает одну простую вещь. если нужно столько транзакций, что одна машина, даже очень большая, не справляется, то что делать? делать можно большим числом разных способов, каждый со своими трейдоффами, отсюда много реализаций.
но на самом деле только две системы сделали это правильно, по крайней мере концептуально - кассандра и sql azure. из этих двух - правильнее sql azure, но это не продукт, а сервис.
http://plakhov.livejournal.com/165139.html?thread=3276307
sql не покрывает одну простую вещь. если нужно столько транзакций, что одна машина, даже очень большая, не справляется, то что делать? делать можно большим числом разных способов, каждый со своими трейдоффами, отсюда много реализаций.
но на самом деле только две системы сделали это правильно, по крайней мере концептуально - кассандра и sql azure. из этих двух - правильнее sql azure, но это не продукт, а сервис.
(no subject)
Date: 2011-06-17 08:26 pm (UTC)эээ, если ты внимательно прочитал то, что я написал, то всё наоборот. чем больше redundancy, тем меньше latency. потому что больше нод, которых можно не ждать.
> т.е. на практике CAP теорема особых проблем не создает (если мы готовы уйти от жесткого ACID). но, формально говоря, я не вижу ее опровержения.
а формального опровержения быть и не может, поскольку у CAP нет формального доказательства - как, например, у теоремы пифагора. опровержение - в смысле того, как обычно понимается вывод из CAP - что мы не можем иметь одновременно consistency, availability и partition tolerance. а на примере как кассандры, так и sql azure мы видим что - нет, можем.
> ну и да - "старый добрых SQL" традиционно не дает выбора.
причём выбора, в первую очередь, в плане scalability. только scale up, никакого scale out.