Когда мы должны использовать MongoDB?

MongoDB - это база данных NoSQL, которую я нашел довольно простой в использовании. Недавно мне пришлось разработать простое приложение, которое должно было собирать некоторые данные с использованием HTTP-запросов и сохранять некоторые результаты после обработки данных, и я попытался использовать MongoDB.

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

Тем не менее, иногда я не уверен, когда мне следует использовать MongoDB вместо традиционной реляционной базы данных, такой как SQL Server или MySQL.

В таком случае, когда мы можем использовать MongoDB вместо реляционных баз данных? Есть ли какое-то большое предостережение относительно MongoDB, которое делает его неподходящим для некоторых ситуаций?

В принципе:

• Если вы можете представить свои данные в виде пакета документов, MongoDB может быть хорошим выбором.

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

Вот два примера, которые я считаю иллюстративными:

• Несколько лет назад я создал блог-движок. Его целью является размещение статей блога, а для каждой статьи - хранение разных версий, метаданных, статистики посещений и т. Д.

  Это может быть сохранено в виде набора таблиц, но при попытке построить модель она очень быстро увеличивается до десятка таблиц, если не больше. Некоторые SQL-запросы могут выглядеть ужасно с большим количеством joins, и ... ну, вы поняли картину.

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

• Теперь представьте себе совершенно другой проект. Есть некоторые пользователи, которые могут писать вещи и делиться вещами, написанными другими пользователями. На странице пользователя вы ожидаете найти и то, что написал этот пользователь, и то, что он опубликовал. Есть одно ограничение: когда кто-то редактирует то, что он написал в прошлом, это изменение появляется везде, где был опубликован исходный текст.

  При основанном на документе подходе трудно найти то, что было бы документом. Пользователь может быть? Ну, это хорошее начало. Пользовательский документ будет содержать все, что написал этот пользователь. Но как насчет вещей, которыми она поделилась?

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

  Альтернативой может быть сохранение в пользовательском документе только списка записей, которыми поделился этот пользователь (с идентификатором упомянутого пользователя и записью). Но теперь может возникнуть другая проблема: если пользователь поделится тысячами записей от тысяч пользователей, ему потребуется открыть тысячи документов, чтобы получить эти записи.

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

  Сколько таблиц вам понадобится, если вы используете реляционную базу данных? Хорошо, три. Это было бы просто моделировать, а также просто использовать.

У каждой технологии есть свои преимущества.

Преимущества реляционных баз данных в том, что СУБД делает для вас кое-что, например:

• Обеспечение ссылочной целостности (не допускается вставка детали счета, если счет, к которому она принадлежит, не существует)
• Избегайте избыточности: вещи хранятся только один раз.
• Сложные запросы можно выполнять с помощью декларативного языка (SQL), который является зрелым, проверенным временем и широко распространенным.

Все это сводится к тому, что вам приходится писать меньше кода, потому что СУБД навязывает вам все.

Кроме того, независимость данных: часто, если вы используете стандартные структуры SQL, а не специфичные для поставщика, вы можете перенести свои данные из одной RDBMS в другую с минимальными трудностями, тогда как базы данных NOSQL вообще не стандартизированы.

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

Для вашего конкретного случая MongoDB звучит как хороший выбор, но существует множество сценариев (вероятно, большинство из них), где он не будет лучшим выбором.

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

MongoDB не подходит для сценариев, которые требуют:

1. Сильные гарантии ACID: MongoDB позволяет хранить дублирующиеся данные, несовместимые чтения и даже потерю данных. Эти вещи хороши в некоторых приложениях, но не в большинстве.
2. Многофункциональные транзакции: MongoDB поддерживает транзакции ACID, но только для одного объекта / документа. Это просто не повлияет на более сложные операции, такие как банковские переводы, бронирование и т. Д.
3. Традиционный BI: существует множество инструментов BI, которые хорошо работают только с традиционным SQL.
4. SQL: MongoDB имеет очень специфический язык запросов, в то время как SQL очень хорошо известен многим (возможно, это важный аспект), он может делать много сложных вещей (тогда как с MongoDB у вас могут возникнуть проблемы с выполнением простого присоединиться) и может передаваться через множество реализаций.

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

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

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

Как только я сказал это, я полностью не согласен с текущей тенденцией, которая мне кажется, которая подразумевает, что MongoDB является своего рода постом и превосходным решением для СУБД, и noSQL должен быть вашим решением по умолчанию. Все это абсурдно. MongoDB - это нишевая база данных, и 90% проектов являются реляционными и нуждаются в параметре RDBMS, потому что вам нужно мощное решение для запросов, такое как SQL, для генерации отчетов и поиска разрозненных данных: «объединения» - это «за», а не «против». Кроме того, современные СУБД поддерживают коллекции BSON и геопространственную интеграцию, так что, возможно, ниша для noSQL теперь еще уже.

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

В таком контексте MongoDB очень быстрый и надежный. Но никогда не забывайте, что в вашей базе данных нет реляционной информации. Это означает, что если вы что-то измените в структуре вашей веб-страницы, вы не сможете заполнить дыры в уже сохраненных страницах, потому что у вас нет данных, необходимых для этого. Подробнее об этом здесь: http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/