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

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

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

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

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

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

драйвер mongodb-это драйвер raw, вы связываетесь непосредственно с mongodb. Мангуст-это слой абстракции. Вы получаете более легкий I / O к db пока ваша структура db просто достаточно.

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

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

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

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

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

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

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

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

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

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