mangosta vs mongodb (módulos / extensiones de nodejs), ¿cuál es mejor? ¿y por qué?


109

Acabo de llegar a Node.js y veo que hay muchas librerías para usar con MongoDB, las más populares parecen ser estas dos: (mangosta y mongodb). ¿Puedo obtener pros y contras de esas extensiones? ¿Existen mejores alternativas a estos dos?

Editar: Encontré una nueva biblioteca que también parece interesante node-mongolian y es "Mongolian DeadBeef es un increíble controlador node.js de Mongo DB que intenta aproximarse mucho al shell mongodb". (readme.md)

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

Esto es solo para agregar más recursos a las personas nuevas que ven esto, por lo que básicamente mongol es como un ODM ...


Por qué utilizar una capa de esquema para una base de datos sin esquema. Si desea una base de datos basada en esquemas, use algo más creado para ella. (Mongoose es solo una abstracción de esquema de mongodb)
Simon Dragsbæk

Respuestas:


123

Mongoose es de nivel superior y usa el controlador MongoDB (es una dependencia, verifique el package.json), por lo que lo usará de cualquier manera dadas esas opciones. La pregunta que debería hacerse es: "¿Quiero usar el controlador sin formato o necesito una herramienta de modelado de documentos y objetos?" Si está buscando una herramienta de modelado de objetos (ODM, una contraparte de los ORM del mundo SQL) para omitir algunos trabajos de nivel inferior, desea Mongoose.

Si desea un controlador, porque tiene la intención de romper muchas reglas que un ODM podría hacer cumplir, elija MongoDB. Si desea un controlador rápido y puede vivir con algunas funciones que faltan, pruebe Mongolian DeadBeef: https://github.com/marcello3d/node-mongolian


34

La mangosta es, con mucho, la más popular. Yo lo uso y no he usado otros. Así que no puedo hablar de los demás, pero puedo contarte mis quejas con Mongoose.

  • Documentación difícil / pobre
  • Se utilizan modelos . Y definen la estructura de sus documentos. Sin embargo, esto parece extraño para Mongo, donde una de sus ventajas es que puede agregar una columna (¿eh, atributo?) O simplemente no agregar una.
  • Los modelos distinguen entre mayúsculas y minúsculas: yo y otros desarrolladores con los que trabajo hemos tenido problemas en los que el caso del nombre de la colección con el que se define el modelo puede hacer que no se guarde nada, sin error. Hemos descubierto que usar todos los nombres en minúsculas funciona mejor. Por ejemplo, en lugar de hacer algo como mongooseInstace.model('MyCollection', { "_id": Number, "xyz": String })es mejor hacer (aunque el nombre de la colección sea realmente MyCollection):mongooseInstace.model('mycollection', { "_id": Number, "xyz": String })

Pero, sinceramente, es realmente útil. El mayor problema es la documentación. Está ahí, pero está seco y es difícil encontrar lo que necesita. Podría utilizar mejores explicaciones y más ejemplos. Pero una vez que superas estas cosas, funciona realmente bien.


11
Re: documentación. No podría estar mas de acuerdo. La documentación es mala y, para empeorar las cosas, es incorrecta en algunos lugares. A menudo me he encontrado descifrando el código (lo cual no es tan malo), pero debido a problemas de documentación.
JP Richardson

1
Los nombres de las colecciones AFAIK distinguen entre mayúsculas y minúsculas en Mongo, no en Mongoose.
Nick Campbell

34
En caso de que alguien se pregunte, la documentación es bastante buena ahora.
Kevin Beal

7
No estoy de acuerdo, la documentación aún está atrasada.
Steve K

5
También estaría de acuerdo en que aún falta documentación
Brendan Weinstein

25

Estoy construyendo una nueva aplicación y diseñando ahora su estructura, aquí hay algunas ideas sobre por qué usar o no la mangosta:

  1. Mongoose será más lento (para aplicaciones grandes)
  2. Mangosta es más difícil con consultas más complicadas
  3. Habrá situaciones en las que desee más velocidad y elegirá ir sin mangosta, entonces tendrá mitad consultas con mangosta y mitad sin mangosta. Esa es una situación loca, una vez tuve ...
  4. Mongoose te hará codificar más rápido con aplicaciones simples con una estructura de base de datos simple
  5. Mongoose te hará leer documentos de mongodb Y documentos de mongoose
  6. Con la mangosta, su pila obtendrá una cosa más de la que depender y es una posibilidad más de colapsar y reducirse a cenizas.

El controlador mongodb es un controlador sin formato, se comunica directamente con mongodb. la mangosta es la capa de abstracción. Obtiene E / S más fácil a la base de datos mientras que su estructura de base de datos es lo suficientemente simple.

La abstracción trae sus requisitos y tienes que seguirlos. Su aplicación será más lenta, consumirá más RAM y será más complicada, pero si sabe cómo usarla, puede escribir objetos simples más rápido y guardarlos en la base de datos.

Sin mangosta, tendrá una aplicación más rápida con conexión directa a mongodb. Nadie dice que no puede escribir sus propios modelos para guardar cosas en db. Usted puede. Y creo que es más fácil. Escribes código, que usarás, sabes lo que necesitas. Tu capa de abstracción será mucho más pequeña que la de la mangosta.

Vengo del mundo PHP, allí teníamos sql sin procesar con funciones mysql_ depreciadas, luego obtuvimos PDO - capa de abstracción orientada a objetos para comunicarnos con sql. O puede elegir un ORM pesado como Doctrine para tener cosas similares a mongoose en mongoDB. Objetos con método setter / getters / save y así sucesivamente. Eso está bien, pero al agregar más abstracción, está agregando más archivos, más lógica, más documentación, más dependencias. Me gusta mantener las cosas simples y tener menos dependencias en mi pila. Por cierto, esa fue la razón por la que pasé de PHP a Javascript servidor-cliente en primer lugar.

Con mangosta, creo que es genial escribir algunas aplicaciones simples, que tienen una estructura de base de datos simple similar a SQL . Cuando empiezas a tener subdocumentos y quieres hacer todas esas consultas locas, me resulta muy difícil con la mangosta. Tienes que mirar los documentos de mongodb, luego mirar los documentos de mongoose para saber cómo hacer la consulta que deseas. A veces encontrará que X future of mongodb no está en mongoose, por lo que baja al controlador mongodb sin procesar y escribe consultas mongodb sin procesar en uno u otro lugar. Sin mangosta, miras los documentos de mongodb y haces tu consulta.


3
También creo que mongodb es mejor que mongoose porque es rápido y posible realizar consultas complejas. Es mejor para aplicaciones grandes y debe usar un controlador mongodb sin procesar. Estoy muy de acuerdo con usted.
Abdul Alim Shakir

Estoy totalmente de acuerdo contigo incluso si no estás haciendo una gran aplicación. Las consultas complejas son mucho más fáciles en mongo driver en comparación con hacerlas en mongoose
Juan

14

Solo he usado mongodb. En mi opinión personal, recomendaría comenzar con algo de bajo nivel y luego avanzar. De lo contrario, puede encontrarse utilizando las funciones avanzadas adicionales proporcionadas por controladores de nivel superior como mangosta sin ningún beneficio real.

El problema que he tenido con mongodb, que es endémico de node.js, es la mala documentación. Hay documentación y mucha, pero no siempre es la más útil. Que he visto hasta ahora, no hay ejemplos buenos y completos del uso de producción del controlador. La documentación contiene el mismo ejemplo en plantilla de abrir una conexión, emitir un comando y cerrar la conexión. Puede saber si está copiada y pegada de una plantilla porque cada ejemplo incluye lo necesario para todo lo que podría ser necesario en lugar de solo lo que se necesita para cada ejemplo.

Para dar un ejemplo tomado completamente al azar:

  • raw {booleano, predeterminado: falso}, realiza operaciones utilizando búferes bson sin procesar.

¿Qué hace exactamente "realizar operaciones utilizando búferes bson sin procesar"? No puedo encontrarlo explicado en ninguna parte y una búsqueda en Google de esa frase no ayuda. Quizás podría buscar más en Google, pero no debería tener que hacerlo. La información debería estar ahí. ¿Existe alguna ventaja de rendimiento, estabilidad, integridad, compatibilidad, portabilidad o funcional para habilitar / deshabilitar esta opción? Realmente no tengo idea sin profundizar en el código y si estás en mi barco, eso es un problema grave. Tengo un demonio en el que no se requiere una persistencia perfecta, pero el programa debe ser muy estable en tiempo de ejecución. Podría suponer que esto significa que espera que deserialice y serialice a JSON o es algo de bajo nivel, interno y transparente para el usuario, pero podría estar equivocado. Aunque tiendo a hacer buenas suposiciones, no puedo confiar en suposiciones y conjeturas al hacer sistemas vitales. Así que aquí puedo probar mi afirmación con código o profundizar mucho más en Google o su código. Como único, esto no es tan malo, pero me encuentro en esta situación muchas veces cuando leo su documentación. La diferencia puede significar días dedicados a una tarea frente a horas. Necesito confirmación y la documentación apenas me da una explicación, mucho menos una confirmación.

La documentación se apresura. No explica los eventos, brinda detalles vagos sobre cuándo se producen los errores o la naturaleza de esos errores y, a menudo, hay varias formas de lograr la conectividad que pueden no estar claras. Puedes pasar y no es completamente inútil, pero es muy áspero en los bordes. Descubrirás que algunas cosas se dejan conjeturas y experimentación.


Con una excelente documentación viene un excelente software. Es una de las partes más importantes.
Lukas Liesis
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.