Когда использовать базу данных nosql, такую ​​как mongodb, вместо mysql?

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

Как мне привести пример запроса к чему-то простому: «найти все комментарии, опубликованные этим пользователем», «найти все фотографии, принадлежащие объекту альбома» и т. Д.

Уходят ли системы nosql от статической реляционной модели данных, но все же позволяют отслеживать такие ссылки, есть ли что-то аналогичное внешним ключам, которое вы можете использовать в запросах?

Общее использование

• Если у вас есть структуры данных, которые не были четко определены во время создания системы. Например, я склонен хранить пользовательские настройки в nosql. Другим примером была система, в которой пользователи должны были иметь возможность добавлять поля во время выполнения - очень болезненно в СУБД и бризом в NoSQL.

• Если ваша модель модели в основном сосредоточена вокруг одного или нескольких объектов модели, и большинство отношений на самом деле являются дочерними объектами основных объектов модели. В этом случае вы обнаружите, что у вас практически не будет необходимости в реальных соединениях. Я обнаружил, что система управления контактами может быть очень хорошо реализована, например, в nosql. Человек может иметь несколько адресов, телефонов и адресов электронной почты. Вместо того, чтобы помещать их каждый в отдельную таблицу, все они становятся частью одной модели, и у вас есть один объект человека.

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

• Кэширование. Даже если вы хотите использовать СУБД в качестве основной базы данных, может быть полезно использовать базу данных NoSQL для кэширования результатов запросов или хранения данных, таких как счетчики.

• Хранение документов. Если вы хотите хранить связные документы, в базе данных некоторые из баз данных NoSQL (например, MongoDB) фактически специализируются на их хранении.

А как насчет присоединений?

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

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

К счастью, большинство драйверов могут сделать соединение за вас, если вы правильно настроили свою схему.

Для дальнейшего чтения я действительно рекомендую Мартина Фаулера .

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

В некоторых случаях вам не понадобятся внешние ключи. Например:

Найти все комментарии этого пользователя

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

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