mongoose vs mongodb (модули / расширения nodejs), что лучше? и почему?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы привести пример, взятый полностью наугад:

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

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

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