Когда заменить RDBMS / ORM на NoSQL [закрыто]

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

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

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

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

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

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

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

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

Обновление

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

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

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

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

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

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

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

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