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

Ответ 1

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

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

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

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

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

Ответ 4

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

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

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

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

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

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