Есть ли какие-либо преимущества использования mongodb перед mysql, если указанные mongo db использовались без вложенных документов?

Question

Я использую php-фреймворк с адаптером mongodb, который в настоящее время не воспринимает внедренные документы как отношения Модель / Ассоциация. После нескольких дней чтения mongodb кажется, что вы должны использовать встроенные документы для объектов, которые чаще всего отображаются вместе. Это имеет большой смысл для меня. Во время одного разговора о схеме монго было сказано, что коллекция множества небольших документов может свести на нет некоторые преимущества монго по сравнению с СУБД.

При поиске в стеке и за его пределами я не вижу, какие преимущества существуют, если они есть, при развертывании mongodb в среде, в которой он реализован с достаточно нормализованной схемой, как в традиционной СУБД.

Есть ли еще преимущества использования MongoDB при использовании таким способом? Масштабирование? Производительность

Answer 1

Если под «разумно нормализованным» вы подразумеваете, что вам нужна информация из одной таблицы, чтобы отфильтровать информацию из другой таблицы (т. Е. Соединение), то Монго будет работать против вас.В базе данных SQL вы можете легко получить информацию из нескольких таблиц с помощью одного запроса.В монго вам понадобится несколько запросов для получения данных из нескольких коллекций.Любое преимущество в скорости, которое дает вам монго при извлечении из одной коллекции, будет быстро сведено на нет, если совершить несколько обращений к базе данных.

Answer 2

Вот некоторые преимущества, которые MongoDb может дать вам (в зависимости от вашего варианта использования):

• Схема : более гибкая, если структура документа изменяется позднее.
• Производительность : MongoDB очень хорошо использует доступную оперативную память, что делает ее очень производительной
• Простая репликация : Репликация проста в настройке
• Sharding / Clustering : MongoDB разработан с учетом необходимости использования шардинга. Он прост в настройке и не требует специалистов.
• Карта / Уменьшить : Если вам это нужно, есть встроенная поддержка.
• Javascript : Интуитивно понятный для использования, если вы уже знаете Javascript (а кто не знает в настоящее время :))

На веб-сайте MongoDB имеется хороший список примеров изучения производственных развертываний .

Answer 3

Сначала я разрабатывал свой университетский диссертационный проект на MySQL, а затем подумал, что нужно сделать попытку MongoDB улучшить производительность. Переписать код с Jongo было действительно легко и просто. Производство было действительно гладким.

К сожалению, производительность была ужасной. Я не очень хорошо разбираюсь в запросах MongoDB, но я думаю, что я провел довольно много исследований: я использовал картографическое сокращение, я использовал структуру агрегации, $ limit и все такое ... когда на том же этапе я получил сообщение : «Использование кучи запросов превысило 10% физической памяти» Я действительно отказался и поставил версию MySQL.

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

Надеюсь, мой комментарий не оскорбит фанатов MongoDB, но это мой опыт.

Answer 4

MongoDB имеет встроенную репликацию и разделение.

Это то, что можно сделать с MySQL.

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

Если бы это было для вас, это был бы интересный учебный проект.

Если это для более крупного проекта, вам придется взвесить нехватку программистов MongoDB и кривую обучения в сравнении с популярностью MySQL.