mongoose vs mongodb (модулі / розширення nodejs), що краще? і чому?


109

Щойно я приїхав до Node.js і бачу, що з MongoDB можна використовувати багато ліб, найпопулярнішими, здається, є ці два: (мангуст і монгдб). Чи можу я отримати плюси і мінуси цих розширень? Чи є кращі альтернативи цим двом?

Редагувати: Знайдено нову бібліотеку, яка здається також цікавою монгольською вузлом і є "Mongolian DeadBeef - дивовижний драйвер DBD node.js, який намагається наблизити оболонку mongodb". (readme.md)

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

Це просто для того, щоб додати більше ресурсів для нових людей, які переглядають це, так що в основному монгольська це як ODM ...


Навіщо використовувати рівень схеми для бази даних без схем. Якщо ви хочете базуватись на базі схем, використовуйте щось інше, створене для неї. (Мангуст - це просто абстракція монгоба)
Саймон Драгсбек

Відповіді:


123

Mongoose вищого рівня і використовує драйвер MongoDB (це залежність, перевірте package.json), тож ви будете використовувати будь-який спосіб, враховуючи ці параметри. Питання, яке ви повинні задати собі, таке: "Чи хочу я використовувати сировинний драйвер чи мені потрібен інструмент моделювання об'єктних документів?" Якщо ви шукаєте інструмент моделювання об'єктів (ODM, аналог ORM з світу SQL), щоб пропустити деякі роботи нижчого рівня, вам потрібно мангусту.

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


34

Мангуст, безумовно, найпопулярніший. Я ним користуюся, а інших не використовував. Тож я не можу говорити про інших, але я можу розповісти вам про свої захоплення з Мангустом.

  • Важка / погана документація
  • Використовуються моделі . І вони визначають структуру ваших документів. І все-таки це здається дивним для Монго, де однією з його переваг є те, що ви можете кинути стовпчик (помилка, атрибут?) Або просто не додати його.
  • Моделі залежать від регістру - у мене та інших розробників, з якими я працюю, виникли проблеми, коли випадок імені колекції, з яким визначена модель, може призвести до того, що вона нічого не економить, без помилки. Ми з’ясували, що використання всіх малих імен працює найкраще. Наприклад, замість того, щоб робити щось подібне mongooseInstace.model('MyCollection', { "_id": Number, "xyz": String }), краще це зробити (навіть якщо назва колекції є насправді MyCollection):mongooseInstace.model('mycollection', { "_id": Number, "xyz": String })

Але чесно кажучи, це дійсно корисно. Найбільше питання - це документація. Він є, але сухий і важко знайти те, що потрібно. Це може використовувати кращі пояснення та більше прикладів. Але як тільки ти пройдеш повз ці речі, це працює дуже добре.


11
Re: документація. Я не міг більше погодитися. Документація погана і занадто погіршує справи, місцями вона неправильна. Я часто виявляв, що зламає код (що не так вже й погано), але через проблеми з документацією.
JP Richardson

1
Назви колекцій AFAIK чутливі до регістру в Монго, а не в Мангусті.
Нік Кемпбелл

34
У випадку, якщо хтось цікавився, документація зараз дуже гарна.
Кевін Біл

7
Я не згоден, Документація все ще запізніла.
Стів К

5
Погодьтесь, документації ще бракує
Брендан Вайнштейн

25

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

  1. Мангуст буде повільніше (для великих додатків)
  2. Мангусту важче із складнішими запитами
  3. Будуть ситуації, коли вам потрібно більше швидкості, і ви вирішите їхати без мангуста, тоді у вас буде половина запитів з мангустом і половина без огляду. Це шалена ситуація, колись ..
  4. Mongoose зробить вас швидшим кодом за допомогою простих програм із простою структурою db
  5. Мангуст змусить вас читати документи mongodb І документи мангусти
  6. З мангустом ваш стек отримає ще одну річ, від якої можна залежати, і ще одна можливість розбитися і спалити до попелу.

драйвер mongodb - це сирий водій, ви спілкуєтесь безпосередньо з mongodb. мангуст - це абстракційний шар. Ви отримуєте простіший введення / вивід db, тоді як ваша структура db досить проста.

Абстракція пред'являє свої вимоги, і ви повинні слідувати цим. Ваш додаток буде повільніше, їсти більше оперативної пам’яті та буде складніше, але якщо ви знаєте, як ним користуватися, ви зможете швидше писати прості об’єкти, зберігаючи їх у базі даних.

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

Я родом із світу PHP, там у нас був необроблений sql з знеціненими функціями mysql_, тоді ми отримали PDO - об'єктно-орієнтований шар абстракції для спілкування з sql. Або ви можете вибрати якийсь важкий ORM, наприклад, доктрина, щоб мати подібні речі до мангуста на mongoDB. Об'єкти із сеттером / getters / методом збереження тощо. Це добре, але додаючи більше абстракцій, ви додаєте більше файлів, більше логіки, більше документації, більше залежностей. Мені подобається просто зберігати речі і менше залежностей у моїй стеці. BTW, тому я перейшов з PHP до Javascript-сервера-клієнта в першу чергу ..

З мангустом я думаю, що чудово писати кілька простих додатків, які мають просту структуру db, схожу на sql . Коли ви починаєте мати піддокументи і хочете зробити всі ці божевільні запити, мені було важко з мангустом. Ви повинні переглянути документи mongodb, а потім переглянути документи-мангусти, щоб дізнатись, як зробити запит, який потрібно. Іноді ви виявите, що X майбутнє mongodb не в мангусті, тому ви переходите до сирого драйвера mongodb і пишете необроблені запити mongodb в тому чи іншому місці. Без мангуста ви дивитеся на документи mongodb і виконуєте свій запит.


3
Я також вважаю, що mongodb краще, ніж мангуст, тому що це швидко і можливо зробити складний запит. Це краще для великих додатків, і ви повинні використовувати сирий драйвер mongodb. Я сильно з вами згоден.
Абдул Алім Шакір

Я повністю згоден з вами, навіть якщо ви не робите великого додатку. Складні запити у водія монго набагато простіше порівняно з виконанням їх у мангуста
Хуан

14

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

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

Щоб навести приклад, взятий повністю навмання:

  • raw {Boolean, типово: false}, виконайте операції, використовуючи буфери bson.

Що саме робить "виконання операцій із використанням сирих бузонів bson"? Я не можу знайти його десь поясненим, і пошук Google за цією фразою не допомагає. Можливо, я міг би продовжити Google, але мені не варто. Інформація повинна бути там. Чи є якісь продуктивність, стабільність, цілісність, сумісність, портативність або функціональні переваги для включення / відключення цієї опції? Я справді не маю уявлення, не заглиблюючись у кодекс, і якщо ти в моєму човні, це серйозна проблема. У мене демон, де не потрібна ідеальна наполегливість, але програма повинна бути дуже стабільною під час виконання. Я можу припустити, що це означає, що він очікує від мене десеріалізації та серіалізації до JSON або це щось низьке, внутрішнє та прозоре для користувача, але я можу помилитися. Хоча я схильний робити хороші припущення, я не можу покластися на припущення та здогадки при створенні життєво важливих систем. Тож тут я можу або перевірити своє твердження з кодом, або заглибитися набагато глибше в Google або їх код. Як один, це не так вже й погано, але я знаходжу себе в цій ситуації багато разів, читаючи їх документацію. Різниця може означати дні, витрачені на виконання завдання, а не години. Мені потрібно підтвердження, і документація ледве дає мені пояснення, не кажучи вже про підтвердження.

Документація поспішає. Це не пояснює події, дає розпливчасті деталі про те, коли викидаються помилки чи характер цих помилок, і часто існує кілька способів налагодити зв’язок, який може бути незрозумілим. Можна обійтись і зовсім не марним, але він дуже шорсткий по краях. Ви знайдете, що деякі речі залишаються для здогадок та експериментів.


З великою документацією поставляється чудове програмне забезпечення. Це одна з найважливіших частин.
Лукас Лейсіс
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.