Риск расширить ваш второй вопрос больше, чем нужно (я никогда не играл с BigTable, но я играл с MongoDB и CouchDB) ...
Самое важное отличие в том, чтоВ любом случае, насколько я понял, все СУБД используют хранилище на основе строк, тогда как движки NoSQL используют хранилище на основе столбцов.Плюсы и минусы в основном проистекают из этого.
http://en.wikipedia.org/wiki/Column-oriented_DBMS
Основное соображение, о котором я склоняюсь, это соответствие ACID: движок NoSQL - , в конечном итоге последовательный, а не всегда последовательный.Думайте об этом как о хранилище, которое ведет себя как кеш сайта: последнее обычно является действительным и непротиворечивым, но иногда немного устаревшим / непоследовательным.
Здесь нет правильного или неправильного: для некоторых вариантов использования (например, для поискадвижок, блог), слегка противоречивый вариант очень приемлемый;для других (например, банк, биллинговая система) это не так.(Я склонен работать над тем, что требует атомарности.)
Далее, существует множество соображений производительности, которые разбиваются на детали реализации.
Непосредственным следствием стремления к возможной согласованности является то, что целостностьпроверки и т. д. обычно выполняются в приложении, а не в хранилище данных (т. е. нет никаких триггеров или хранимых процедур, о которых можно было бы говорить).В вашем хранилище данных меньше работы, что приводит к очевидным выигрышам в производительности.
Хранилище на основе столбцов означает, что если вы обновляете один столбец из документа, вы только лишаете законной силы этот столбец.Хранилище на основе строк, напротив, делает недействительной всю строку.В зависимости от того, как вы обычно обновляете свои данные (т. Е. Всего несколько столбцов по сравнению с большинством из них), любой подход может сложиться.
Обратная сторона хранилища на основе столбцов заключается в том, что он делает соединения более хитрыми (източка зрения реализации).Говоря упрощенно, представьте себе, что в каждом столбце есть таблица EAV;это отлично работает для нескольких столов.Другое дело, если вам нужен большой отчет, требующий дюжины объединений по продажам или акциям (с которыми хорошая СУБД справится очень хорошо).
Надеемся, что более опытный пользователь включится в сегментирование и репликацию NoSQL.В связи с этим я чувствую себя достаточно комфортно, чтобы отметить, что Postgres имеет встроенные функции репликации с 9.0 и хорошо справляется с запросами, которые охватывают несколько разделов.
В любом случае ... Чтобы сократить очень долгоКороче говоря: если вы уже не знаете, что вам нужно будет мгновенно масштабировать до петабайтов и миллиардов запросов во множестве центров обработки данных в вашем следующем проекте, я думаю, что единственное соображение, которое вы должны иметь в виду при выборе реализации SQL или NoSQL, этодействительно ли вам нужно соответствие ACID или нет.
Наконец, если ваш основной интерес заключается в том, чтобы попробовать новую игрушку, попробуйте вместо этого использовать графо-ориентированную базу данных.Они потенциально сочетают в себе преимущества магазинов на основе строк - и .