Где используются NOSQL базы данных

Базы данных NoSQL используются в основном в социальных сетях для хранения сообщений, которые пользователи отправляют друг другу.

Какие наиболее производительны? Не потестируете -- не узнаете. Facebook, например, сначала разработал Cassandra, а потом отказался от нее и развернул у себя HBase... А другие люди до сих пор пользуются Cassandra и не жалуются -- их она устраивает.. .

Насчет того, в каких задачах они более эффективны, чем Oracle, это немножко неправильный вопрос. Oracle денег стоит и аппаратуры желает соответствующей. А какую-нибудь Кассандру, MongoDB или HBase можно выгрузить бесплатно и развернуть на кластере, наспех сляпанном из нескольких сотен (или тысяч) дешевых линуксовых ящиков формата 1U.

Так или иначе, базы данных NoSQL наиболее эффективны в ситуациях, когда (1) отношение числа запросов на запись к числу запросов на чтение необычно высоко, (2) запросы на чтение редко повторяются (то есть кэширование не помогает) , (3) пользователей устравает eventual concurrency (т. е. , ситуация, когда данные, поступившие на один узел кластера, распространяются на другие узлы не моментально, а с некоторой задержкой, которая зависит от нагрузки на узлы) , и (4) потеря небольшой части данных -- это не конец света (что автоматически означает, что не стоит использовать NoSQL для хранения транзакционных данных) .

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

Теперь вообразите социальную сеть. 10 миллионов пользователей, каждый читает только то, что написали его друзья (то есть кэширование неэффективно -- слишком много разных записей востребуется одновременно) , оставляет комментарии, голосует в опросах и т. п. И все это бесплатно. Обработать такое количество запросов на запись экономично можно только согласившись на eventual concurrency -- стандартная репликация (а-ля MySQL) в такой ситуации просто задохнется (все обновления должны будут идти через мастер-сервер или небольшую группу мастер-серверов) , а решения, в которых множественные сервера хранят данные в SAN (типа Oracle RAC) будут не по-детски дороги. В NoSQL эта проблема решается неспешностью репликации: каждый сервер -- сам себе мастер, но данные на репликацию он не старается отдать немедленно любой ценой, а ждет, пока у него появится для этого свободное время.. . Та же вода с получением данных, которые отдали на репликацию другие сервера: есть свободные ресурсы памяти, процессора и ввода-вывода -- реплицируемся, нет -- ждем, пока они появятся.. . При этом каждый фрагмент данных хранится как минимум на трех узлах кластера, то есть это и не shared-nothing, как в MySQL, и не shared-everything, как в Oracle RAC. Но при этом всегда есть шанс, что какой-то узел (или процесс, работающий на узле) сдохнет, не успев отдать какие-то данные на репликацию. Причем чем сильнее узел загружен, тем больше шанс того, что он сдохнет, и тем больше количество данных, которые при этом потеряются. Отсюда нежелательность использования NoSQL для хранения транзакционных данных...