Mongoose против Mongodb (модули / расширения nodejs), что лучше? и почему?

Question

Я только что прибыл в Node.js и увидел, что есть много библиотек, которые можно использовать с MongoDB, наиболее популярными из них являются: (mongoose и mongodb). Могу ли я получить плюсы и минусы этих расширений? Есть ли лучшие альтернативы этим двум?

Редактировать: Нашел новую библиотеку, которая также кажется интересной нод-монгольской и является "Mongolian DeadBeef - потрясающий драйвер Mongo DB для node.js, который пытается максимально приблизиться к оболочке mongodb". (Readme.md)

https://github.com/marcello3d/node-mongolian

Это просто для того, чтобы добавить больше ресурсов новым людям, которые это видят, поэтому в основном монгольский это как ODM ...

Answer 1

Mongoose более высокого уровня и использует драйвер MongoDB (это зависимость, проверьте package.json), так что вы будете использовать любой из этих параметров.Вопрос, который вы должны задать себе: «Хочу ли я использовать необработанный драйвер или мне нужен инструмент моделирования объектных документов?»Если вы ищете инструмент для моделирования объектов (ODM, аналог ORM из мира SQL), чтобы пропустить какую-то работу более низкого уровня, вам нужен Mongoose.

Если вам нужен драйвер, потому что вы намереваетесь сломатьмножество правил, которые может применять ODM, идут с MongoDB.Если вы хотите быстрый драйвер и можете использовать некоторые недостающие функции, попробуйте Mongolian DeadBeef: https://github.com/marcello3d/node-mongolian

Answer 2

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

• Сложная / плохая документация
• Используются модели . И они определяют структуру для ваших документов. Тем не менее, это кажется странным для Mongo, где одно из его преимуществ заключается в том, что вы можете добавить столбец (err, attribute?) Или просто не добавлять его.
• Модели чувствительны к регистру - у меня и других разработчиков, с которыми я работаю, были проблемы, когда регистр имени коллекции, с которым определена модель, может привести к тому, что она ничего не сохранит, без ошибок. Мы обнаружили, что использование всех строчных имен работает лучше всего. Например. вместо того, чтобы делать что-то вроде mongooseInstace.model('MyCollection', { "_id": Number, "xyz": String }), это лучше сделать (хотя имя коллекции действительно MyCollection): mongooseInstace.model('mycollection', { "_id": Number, "xyz": String })

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

Answer 3

Я создаю новое приложение и сейчас разрабатываю его структуру, вот несколько мыслей о том, зачем использовать или не использовать mongoose:

1. Mongoose будет медленнее (для больших приложений)
2. Мангуст сложнее с более сложными запросами
3. Будут ситуации, когда вам нужно больше скорости, и вы решите обходиться без мангуста, тогда у вас будет половина запросов с мангустой и половина без. Это безумная ситуация, однажды ..
4. Mongoose сделает ваш код быстрее с простыми приложениями с простой структурой БД
5. Mongoose заставит вас читать документы Mongodb И документы Mongoose
6. С mongoose ваш стек получит еще одну вещь, от которой зависит, и это еще одна возможность разбиться и сгореть дотла.

Драйвер mongodb является необработанным драйвером, вы напрямую общаетесь с mongodb. мангуст - это слой абстракции. Вы получаете более легкий ввод / вывод в БД, в то время как ваша структура БД достаточно проста.

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

Без mongoose у вас будет более быстрое приложение с прямым подключением к mongodb. Никто не говорит, что вы не можете написать свои собственные модели, чтобы сохранить материал в БД. Вы можете. И я думаю, что это проще. Вы пишете код, который будете использовать, вы знаете, что вам нужно. Слой абстракции будет намного меньше, чем у мангуста.

Я пришел из мира PHP, там у нас был сырой sql с устаревшими функциями mysql_, затем мы получили PDO - объектно-ориентированный уровень абстракции для взаимодействия с sql. Или вы можете выбрать какой-нибудь тяжелый ORM, например Doctrine, чтобы иметь такие же вещи, как mongoose на mongoDB. Объекты с помощью метода set / getters / save и так далее. Это хорошо, но добавляя больше абстракции, вы добавляете больше файлов, больше логики, больше документации, больше зависимостей. Мне нравится хранить вещи простыми и иметь меньше зависимостей в моем стеке. Кстати, именно поэтому я перешел с PHP на сервер-клиент Javascript в первую очередь ..

С mongoose я думаю, что было бы здорово написать несколько простых приложений, которые имеют простую структуру БД, похожую на sql . Когда у вас появились поддокументы и вы хотите делать все эти сумасшедшие запросы, мне было очень тяжело с мангустом. Вы должны посмотреть на документы mongodb, а затем посмотреть на документы mongoose, чтобы узнать, как сделать запрос, который вы хотите. Иногда вы обнаружите, что X будущее mongodb не в mongoose, поэтому вы переходите к необработанному драйверу mongodb и пишете необработанные запросы mongodb в том или ином месте. Без мангуста вы смотрите документы mongodb и выполняете запрос.

Answer 4

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

Проблема, с которой я столкнулся при работе с mongodb, которая свойственна node.js, - плохая документация. Есть документация, и ее много, но она не всегда самая полезная. Что я видел до сих пор нет хороших и подробных примеров производственного использования драйвера. Документация заполнена тем же шаблонным примером открытия соединения, подачи команды и закрытия соединения. Вы можете сказать, что он скопирован и вставлен из шаблона, потому что каждый пример включает в себя все, что может понадобиться, а не только то, что нужно для каждого примера.

Чтобы привести пример, взятый совершенно случайно:

• raw {Boolean, default: false}, выполнять операции с использованием необработанных буферов bson.

Что именно делает «выполнение операций с использованием необработанных буферов bson»? Я нигде не могу найти объяснения, и поиск Google по этой фразе не помогает. Возможно, я мог бы Google дальше, но я не должен был бы. Информация должна быть там. Есть ли какая-либо производительность, стабильность, целостность, совместимость, переносимость или функциональные преимущества для включения / отключения этой опции? Я действительно понятия не имею, не углубившись в код, и если вы находитесь в моей лодке, это серьезная проблема. У меня есть демон, в котором идеальное постоянство не требуется, но программа должна быть очень стабильной во время выполнения. Я могу предположить, что это означает, что он ожидает десериализации и сериализации в JSON или является чем-то низким, внутренним и прозрачным для пользователя, но я могу ошибаться. Хотя я склонен делать хорошие предположения, я не могу полагаться на предположения и догадки при создании жизненно важных систем. Так что здесь я могу либо проверить свое утверждение с помощью кода, либо углубиться в Google или их код. В целом это не так уж и плохо, но я часто сталкиваюсь с этой ситуацией, когда читаю их документацию. Разница может означать дни, потраченные на задачу, а не часы. Мне нужно подтверждение, и документация едва ли дает мне объяснение, не говоря уже о подтверждении.

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