Подтвердить что ты не робот

Когда заменить RDBMS/ORM на NoSQL

Какие проекты выиграют от использования базы данных NoSQL вместо rdbms, обернутой ORM?

Примеры:

  • Аналогичные сайты Stackoverflow?
  • Социальные сообщества?
  • Форумы?
4b9b3361

Ответ 1

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

  • Хранилища с ключевыми значениями (Redis, Riak)
  • Triplestores (AllegroGraph)
  • Магазины колонок (Bigtable, Cassandra)
  • Документированные магазины (CouchDB, MongoDB)
  • Графические базы данных (Neo4j)

Проект может извлечь выгоду из использования базы данных документов в течение этапа разработки проекта, потому что вам не придется создавать сложные диаграммы сущности или писать сложные запросы на объединение. Я подробно описал другие применения баз данных документов в этом ответе.

Если вашему приложению необходимо обрабатывать очень большие объемы данных, фаза разработки, вероятно, будет больше, когда вы используете специализированное решение NoSQL, такое как Cassandra. Однако, когда ваше приложение переходит в production, оно значительно улучшит производительность и масштабируемость Cassandra.

В общем, если приложение имеет следующие требования:

  • масштаб горизонтально
  • работа с моделью данных X
  • выполнить операции Y

приложение получит выгоду от использования решения NoSQL, которое предназначено для хранения модели данных X и выполнения операций Y по данным. Если вам нужны более конкретные ответы относительно определенного типа базы данных NoSQL, вам нужно будет обновить свой вопрос.

  • Преимущества во время разработки (например, проще в использовании, чем SQL, без затрат на лицензирование)
  • Преимущества с точки зрения производительности (например, работает с адом с миллионами одновременно работающих пользователей)?
  • Какой тип базы данных NoSQL?

Update

Хранилища ключевого значения могут запрашиваться только ключом в большинстве случаев. Они полезны для хранения простых данных, таких как сеансы пользователя, простые данные профиля или предварительно вычисленные значения и вывод. Хотя можно хранить более сложные данные в парах "ключ-значение", это ложится на приложение с ответственностью за сохранение "ручных" индексов для выполнения более сложных запросов.

Triplestores предназначены для хранения Описание метаданных описания ресурсов. Я ничего не знаю об этих магазинах, кроме то, что Википедия говорит мне, поэтому вам придется провести некоторое исследование.

Хранилища семейства столбцов созданы для хранения и обработки очень больших объемов данных. Они используются поисковой системой Google и Facebook inbox search. Данные запрашиваются Функции MapReduce. Хотя функции MapReduce могут быть трудно понять в начале, концепция довольно проста. Здесь аналогия, которая (надеюсь) объясняет концепцию:

Представьте, что у вас есть несколько ящиков для обуви, заполненных квитанциями, и вы хотите рассчитать свои общие расходы. Вы приглашаете некоторых своих друзей и назначаете человека в каждую коробку для обуви. Каждый человек записывает общее количество каждой квитанции в коробке для обуви. Этот процесс выбора необходимых данных - это часть карты.

Когда человек записал итоговые (некоторые из) своих квитанций, он может суммировать эти итоги. Это часть уменьшения и может повторяться несколько раз, пока все квитанции не будут обработаны. В конце концов, все ваши друзья собираются вместе и суммируют свои общие суммы, предоставляя вам ваши общие расходы. Это окончательный шаг уменьшения.

Преимущество такого подхода заключается в том, что у вас может быть любое количество ящиков для обуви, и вы можете назначить любое количество людей в коробку для обуви и все равно в итоге получить тот же результат. Каждый ботинок можно рассматривать как сервер в сети базы данных. Каждый друг может показаться потоком на сервере. С помощью MapReduce вы можете распределять свои данные по многим серверам и каждый сервер обрабатывает часть запроса, оптимизируя производительность вашей базы данных.

Документированные магазины объясняются в этом вопросе, поэтому я не буду обсуждать их здесь.

Графические базы данныхпредназначены для хранения сетей высокосвязных объектов, например пользователей в социальной сети. Эти базы данных оптимизированы для операций с графами, например, поиск кратчайшего пути между двумя узлами или поиск всех узлов в пределах трех переходов от текущего node. Такие операции довольно дороги для систем РСУБД или других баз данных NoSQL, но очень дешевы в базах данных графов.

Ответ 2

NoSQL в смысле разных подходов к дизайну, а не только язык запросов. Он может иметь разные функции. Например. базы данных с колонками используются для большого объема хранилищ данных, которые могут использоваться для OLAP.

Как и мой question, вы найдете много ресурсов.