Mangouste vs Mongodb (modules / extensions nodejs), lequel de mieux? et pourquoi?
Je viens juste d'arriver sur Node.js et je vois qu'il y a beaucoup de bibliothèques à utiliser avec MongoDB, les plus populaires semblent être ces deux: (mangouste et mongodb). Puis-je avoir les avantages et les inconvénients de ces extensions? Existe-t-il de meilleures alternatives à ces deux là?
Edit: Nous avons trouvé une nouvelle bibliothèque qui semble également intéressante comme noeud-mongol et qui est "Mongolian DeadBeef est un pilote génial pour Mongo DB node.js qui tente de se rapprocher du shell mongodb." (readme.md)
https://github.com/marcello3d/node-mongolian
Ceci est juste pour ajouter plus de ressources aux nouvelles personnes qui le voient, donc fondamentalement mongol c'est comme un ODM ...
Mongoose est de niveau supérieur et utilise le pilote MongoDB (c'est une dépendance, vérifiez le package.json), vous l'utiliserez donc dans ces deux cas. La question que vous devriez vous poser est la suivante: "Est-ce que je veux utiliser le pilote brut ou ai-je besoin d'un outil de modélisation de document objet?" Si vous recherchez un outil de modélisation d'objet (ODM, équivalent des outils ORM du monde SQL) pour ignorer certains travaux de niveau inférieur, vous voulez Mongoose.
Si vous voulez un pilote, car vous avez l'intention de casser beaucoup de règles qu'un ODM pourrait appliquer, utilisez MongoDB. Si vous voulez un pilote rapide et que vous ayez quelques fonctionnalités manquantes, essayez Mongolian DeadBeef: https://github.com/marcello3d/node-mongolian
La mangouste est de loin la plus populaire. Je l'utilise et je n'ai pas utilisé les autres. Donc, je ne peux pas parler des autres, mais je peux vous raconter mes reproches avec Mongoose.
- Documentation difficile/médiocre
- Modèles sont utilisés. Et ils définissent la structure de vos documents. Pourtant, cela semble étrange pour Mongo où l'un de ses avantages est que vous pouvez ajouter une colonne (err, attribut?) Ou simplement ne pas en ajouter.
- Les modèles sont sensibles à la casse - moi-même et les autres développeurs avec lesquels je travaille ont eu des problèmes où la casse du nom de la collection avec laquelle le modèle est défini peut ne pas enregistrer quoi que ce soit, sans erreur. Nous avons constaté que l’utilisation de tous les noms en minuscules fonctionnait mieux. Par exemple. au lieu de faire quelque chose comme
mongooseInstace.model('MyCollection', { "_id": Number, "xyz": String }), il vaut mieux le faire (même si le nom de la collection est vraimentMyCollection):mongooseInstace.model('mycollection', { "_id": Number, "xyz": String })
Mais honnêtement, c'est vraiment utile. Le plus gros problème est la documentation. C'est là, mais c'est sec et difficile de trouver ce dont vous avez besoin. Il pourrait utiliser de meilleures explications et plus d'exemples. Mais une fois ces problèmes passés, cela fonctionne vraiment très bien.
Je construis une nouvelle application et en conçois maintenant la structure, voici quelques réflexions sur les raisons d'utiliser ou de ne pas utiliser de mangouste:
- Mongoose sera plus lent (pour les grandes applications)
- Mongoose est plus difficile avec des requêtes plus compliquées
- Il y aura des situations où vous voulez plus de vitesse et que vous choisirez de vous passer de la mangouste, alors vous aurez une demi-requête avec la mangouste et l'autre moitié. C'est une situation folle, avait une fois ..
- Mongoose vous fera coder plus rapidement avec des applications simples avec une structure simple de base de données
- Mongoose vous fera lire la documentation de mongodb ET la documentation de mangouste
- Avec la mangouste, votre pile dépendra d'une chose de plus et c'est une possibilité de plus de planter et de brûler en cendres.
le pilote mongodb est un pilote brut, vous communiquez directement avec mongodb. la mangouste est une couche d'abstraction. Vous obtenez plus facilement des E/S à la base de données alors que votre structure de base de données est assez simple.
L'abstraction apporte ses exigences et vous devez les respecter. Votre application sera plus lente, consommera plus RAM et sera plus compliquée, mais si vous savez l'utiliser, vous pouvez écrire plus rapidement des objets simples, enregistrez-les dans la base de données.
Sans mangouste, vous aurez une application plus rapide avec une connexion directe à mongodb. Personne ne dit que vous ne pouvez pas écrire vos propres modèles pour sauvegarder des fichiers dans la base de données. Vous pouvez. Et je pense que c'est plus facile. Vous écrivez du code, que vous utiliserez, vous savez ce dont vous avez besoin. Votre couche d'abstraction sera bien plus petite que celle de la mangouste.
Je viens du monde PHP, où nous avions SQL brut avec des fonctions mysql_ dépréciées, puis nous avons eu la couche d'abstraction orientée objet PDO pour communiquer avec SQL. Ou vous pouvez choisir un ORM lourd comme = Doctrine pour avoir des choses similaires à mangouste sur mongoDB. Objets avec la méthode setter/getters/save, etc. C'est bien, mais en ajoutant plus d'abstraction, vous ajoutez plus de fichiers, plus de logique, plus de documentation, plus de dépendances. J'aime garder les choses simples et avoir moins de dépendances dans ma pile. BTW, c’est pourquoi je suis passé de PHP à Javascript serveur-client en premier lieu ..
Avec la mangouste, je pense qu'il est bon d’écrire quelques applications simples, qui ont une structure de base de données similaire à celle de SQL. Quand vous commencez à avoir des sous-documents et que vous voulez faire toutes ces requêtes folles, j'ai trouvé cela très difficile avec mangouste. Vous devez consulter la documentation mongodb, puis la documentation mongoose pour savoir comment effectuer la requête souhaitée. Parfois, vous constaterez que X future de mongodb n’est pas en mangouste, vous devez donc lire le pilote mongodb brut et écrire des requêtes mongodb brutes dans un lieu ou à un autre. Sans la mangouste, vous consultez la documentation de mongodb et effectuez votre requête.
J'ai seulement utilisé mongodb. De mon point de vue personnel, je recommanderais de commencer par quelque chose de bas puis de monter. Sinon, vous pourriez vous retrouver avec les fonctionnalités avancées supplémentaires fournies par des pilotes de niveau supérieur, comme la mangouste, sans aucun avantage réel.
Le problème que j'ai eu avec mongodb, qui est endémique de node.js, est la mauvaise documentation. Il y a beaucoup de documentation, mais ce n'est pas toujours le plus utile. Comme je l’ai vu jusqu’à présent, il n’existe aucun exemple valable et complet d’utilisation du pilote en production. La documentation est remplie avec le même exemple d’ouverture d’une connexion, émettez une commande et fermez la connexion. Vous pouvez dire qu'il est copié et collé à partir d'un modèle, car chaque exemple inclut les éléments requis pour tout ce qui est nécessaire, plutôt que seulement ce qui est nécessaire pour chaque exemple.
Pour donner un exemple pris entièrement au hasard:
- raw {Boolean, default: false}, effectue des opérations à l'aide de buffers bson bruts.
Que fait exactement "effectuer des opérations en utilisant des tampons bson bruts"? Je n'arrive pas à le trouver expliqué nulle part et une recherche sur Google de cette phrase n'aide pas. Je pourrais peut-être approfondir la recherche sur Google, mais je n'aurais pas à le faire. L'information devrait être là. Existe-t-il des avantages en termes de performances, stabilité, intégrité, compatibilité, portabilité ou avantages fonctionnels pour activer/désactiver cette option? Je n'ai vraiment aucune idée sans plonger profondément dans le code et si vous êtes dans mon bateau, c'est un problème grave. J'ai un démon où la persistance parfaite n'est pas requise mais le programme doit être très stable au moment de l'exécution. Je peux supposer que cela signifie que j'attend de la désérialisation et de la sérialisation au format JSON, ou qu'il s'agit d'un problème de bas niveau, interne et transparent pour l'utilisateur, mais je peux me tromper. Bien que j'ai tendance à faire de bonnes hypothèses, je ne peux pas compter sur des hypothèses et des conjectures lorsque je crée des systèmes vitaux. Donc ici, je peux soit tester mon assertion avec du code, soit creuser plus profondément dans Google ou son code. Ce n'est pas si grave, mais je me retrouve souvent dans cette situation lorsque je lis leur documentation. La différence peut signifier des jours consacrés à une tâche par rapport à des heures. J'ai besoin d'une confirmation et la documentation me donne à peine une explication, sans parler d'une confirmation.
La documentation est précipitée. Il n'explique pas les événements, donne des détails vagues sur le moment où des erreurs sont générées ou sur la nature de ces erreurs, et il existe souvent plusieurs manières de réaliser la connectivité qui peuvent ne pas être claires. Vous pouvez vous en tirer et ce n'est pas complètement inutile, mais c'est très difficile sur les bords. Vous constaterez que certaines choses sont laissées à la conjecture et à l'expérimentation.