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

Question

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

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

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

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

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

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

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

• сырец {Boolean, по умолчанию: FALSE}, выполнять операции с использованием необработанных буферов BSON.

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

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

Answer 4

Я строй нового приложения и проектирование в настоящее время структуры этого, вот некоторые мысли о том, почему использовать или не использовать мангуст:

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

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

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

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

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

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