Каковы реальные варианты использования базы данных NoSQL Document Store? - PullRequest
5 голосов
/ 01 сентября 2010

За последние несколько дней я читал документацию и смотрел скринкасты, специфичные для Mongo DB, и я не понимаю, когда подобное решение будет лучше, чем типичная среда pg или mysql.

В частности, мой вопрос заключается в том, при каких обстоятельствах (с вариантом использования было бы неплохо) вы хотели бы пойти по маршруту nosql?

Спасибо!

Ответы [ 3 ]

9 голосов
/ 01 сентября 2010
  1. Многие разрозненные писатели.Особенно, когда авторы могут быть сегментированы из-за разъединений в сети, и позже потребуется повторная синхронизация данных, которые были записаны по обе стороны от бифуркации.Это нарушает ACID, и, хотя вы можете решить проблему с помощью явной бизнес-логики, теперь вы находитесь на территории NoSQL.Это очень часто встречается в военных ситуациях, но любая система, в которой каждый является плодовитым писателем, будет иметь некоторую блокировку конфликтов записи в системе ACID.

  2. Схемы Fluid.Изменение схемы в традиционной БД - это дорогостоящая операция, которая часто требует некоторого простоя сервера или других сложных процессов.С большинством систем NoSQL это тривиально.Таким образом, если у вас есть данные из множества разрозненных источников для слияния и / или возникли ситуации, когда вы захотите начать отслеживать новую информацию позднее, с системами NoSQL будет гораздо легче иметь дело.Хороший пример, который я могу привести, - объединение двух источников данных, чтобы они могли составлять диаграммы друг с другом.После того, как вы сломали ACID, у вас могут быть читатели и писатели на конечных узлах сетевого графа с частичными данными, которые не нуждаются в полных копиях базы данных.Это использует продукт моей собственной компании, командный пункт армии будущего.

  3. Совместимость данных.Большинство баз данных NoSQL позволяют вам анализировать данные, не зная заранее схемы, что упрощает соединения между разнородными системами.

  4. Массовое масштабирование.Это тот, который чаще всего обсуждается и чаще всего используется сторонниками NoSQL.Если это единственная причина, по которой вы выбираете NoSQL, начните с MySQL и масштабируйте позже.

7 голосов
/ 05 сентября 2010

Некоторые API REST возвращают данные JSON (например, многие из открытых API данных правительства ). Если вы хотите выгрузить данные REST в локальное хранилище данных (если вам нужно запустить анализ и т. Д.), Прием JSON-объекта с MongoDB - это тривиально. Нет необходимости определять схему таблицы. Более того, если объект JSON изменяется со временем (например, REST API возвращает дополнительные поля), вы все равно можете получить данные за один шаг. Попробуйте это с реляционной базой данных!

7 голосов
/ 01 сентября 2010

Вариант использования
Мы используем MongoDB для крупномасштабной чрезвычайно переходной структуры данных. По сути, он работает как трекер / менеджер заданий, и многие рабочие единицы обрабатываются каждую секунду. Рабочая единица не имеет определенной схемы (разные единицы изобретаются довольно часто), но мы должны иметь возможность запрашивать определенные поля или свойства без итерации по всей БД. Итак, резюмируем: высокопереходный, высокодоступный (не может позволить себе блокировать запрос) с рабочей нагрузкой около 600QPS для одной «обычной» машины, работающей в облаке.

В том-то и дело, что чрезвычайно сложно сделать то же самое на машине с SQL, сохраняя при этом те же затраты.

Другими популярными вариантами использования MongoDB (также и для нас) являются сбор статистики, он чрезвычайно эффективен при увеличении определенных свойств внутри документов, гораздо больше, чем в большинстве систем РСУБД.

Опять же, это не значит, что в MySQL это невозможно сделать, это просто дороже и требует больше времени (больше навыков), что для небольшой компании или среды быстрой разработки означает, что это невозможно.

...