MongoDB - Une collection utilisant des index

Question

Ok, donc le développement de plus en plus dans Mongodb commence à m'interroger sur le besoin de plusieurs collections plutôt que d'avoir une grande collection avec des index (puisque les colonnes et les champs peuvent être différents pour chaque document). Si j'essaie de développer de la manière la plus efficace possible (ce qui signifie moins de code et de code réutilisable), puis-je utiliser une collection pour tous les documents et simplement indexer sur un champ. En ayant tous les documents dans une collection avec des index alors je peux réutiliser tout mon code de traitement de formulaire et tout autre code puisque tout sera inséré dans la même collection.

Par exemple:

Disons que je développe un gestionnaire de contacts et j'ai deux types de contacts « individus » et « entreprises ». Ma pensée originale était de créer une collection appelée individus et une deuxième collection appelée entreprises. Mais c'était parce que je l'habitude de développer en sql où oui ce serait approprié puisque les colonnes seraient différentes pour chaque table. Plus je commençais à réfléchir à la flexibilité du document dbs, plus je commençais à penser: «Ai-je vraiment besoin de deux collections pour cela? Si je viens d'ajouter un champ à chaque document appelé "type de contact" et index sur cela, ai-je vraiment besoin de deux collections? Puisque les champs/colonnes de chaque document n'ont pas à être identiques pour tous (comme dans sql) alors chaque document peut avoir ses propres champs tant que j'ai un champ "type de document" et un index sur ce champ. Alors j'ai pris ce concept et j'ai commencé à penser, si je n'ai besoin que d'une collection pour "particuliers" et "entreprises", puis j'ai besoin d'une collection séparée pour "Utilisateurs" ou "Historique des contacts" ou d'autres données. . En théorie, je ne pourrais pas construire la solution entière dans une collection et avoir juste un champ dans chaque document qui spécifie le "type" et l'index dessus comme "Utilisateurs", "Contact individuel", "Contacts d'affaires", "Historique des contacts ", etc, et s'il s'agit d'un document lié à un autre document, je peux indexer sur le champ" parent/foreign "Id ...

Ceci me permettrait de coder le frontal de façon dynamique puisque le code de traitement de formulaire tous sont identiques (insertion dans la même collection). Cela permettrait d'économiser beaucoup de codage, mais je veux m'assurer qu'en utilisant des index et des index secondaires, la base de données fonctionnerait toujours rapidement et ne causerait pas de problèmes futurs au fur et à mesure que la collection grandirait. Comme vous pouvez l'imaginer, si tout se trouvait dans une collection, il pourrait y avoir des centaines de milliers voire des millions de documents dans cette collection au fur et à mesure que la base d'utilisateurs grandirait, mais elle aurait des index et index secondaires pour optimiser les performances.

Ma question est la suivante: est-ce une méthode courante que les développeurs de mongodb utilisent? Pourquoi ou pourquoi pas? Quelles sont les chutes, le cas échéant? S'il s'agit d'une méthode couramment utilisée, veuillez aussi donner des points positifs à l'utilisation de cette méthode. Je vous remercie.

Answer 1

MongoDB, et NoSQL en général, concerne la dénormalisation des données et la réduction des jointures. Cela va à l'encontre de la pensée SQL normale.

Dans votre cas, je ne vois aucune raison pour laquelle vous voudriez avoir des collections séparées car cela introduit une complexité inutile et une surcharge de performance. Considérez, par exemple, si vous voulez avoir un écran qui affiche tous les contacts, dans l'ordre alphabétique. Si vous avez une collection unique pour les contacts, alors c'est vraiment facile, mais si vous avez deux collections, cela devient une proposition plus compliquée.

Où j'aurais plusieurs collections est si votre application avait plusieurs utilisateurs qui stockent des contacts. J'aurais alors une collection pour chaque utilisateur. Cela rend si facile d'extraire les contacts des utilisateurs.

Answer 2

Ceci est un très gros point dans Mongo et la réponse est un peu plus d'un art que de la science. Avoir une collection pleine de documents gigantesques est définitivement un anti-pattern, car il fonctionne contre de nombreuses fonctionnalités de Mongo.Par exemple, lors de la récupération de documents, vous pouvez uniquement extraire un document entier d'une collection (pas tout à fait vrai, mais surtout). Donc, si vous avez d'énormes documents, vous récupérez des documents énormes à chaque fois. De plus, le fait d'avoir des documents volumineux rend le découpage moins flexible puisque seuls les documents de premier niveau sont indexés (et donc partagés) dans chaque collection. Vous pouvez indexer des valeurs en profondeur dans un document, mais la valeur d'index est associée au document de niveau supérieur. Dans le même temps, aller purement relationnel est également un anti-pattern car vous avez perdu beaucoup de l'intégrité référentielle en allant à Mongo en premier lieu. En outre, toutes les jointures sont effectuées dans la mémoire de l'application, de sorte que chacune nécessite un aller-retour complet (lent).

Donc la réponse est de faire quelque chose entre les deux. Je pense que vous voudrez probablement une collection pour les particuliers et une collection différente pour les entreprises dans ce cas. Je dis cela parce qu'il semble que les entreprises aient assez de méta-données pour pouvoir augmenter beaucoup. (De plus, la relation individu-entreprise semble être une relation plusieurs-à-plusieurs). Toutefois, un individu peut avoir un objet Name (avec les propriétés first et last). Ce serait une mauvaise idée de faire Name dans une collection séparée.

Certaines informations du 10gen sur la conception du schéma: http://www.mongodb.org/display/DOCS/Schema+Design

EDIT

En outre, un soutien limité a Mongo pour les transactions - sous la forme d'agrégats atomiques. Lorsque vous insérez un objet dans mongo, l'objet entier est inséré ou n'est pas inséré. Donc, votre domaine d'application nécessite la cohérence entre certains objets, vous voulez probablement les conserver dans le même document/collection.

Par exemple, considérons une application qui exige qu'un User a toujours un objet Name (contenant FirstName, LastName et MiddleInitial). Si un User était inséré d'une manière ou d'une autre sans Name correspondant, les données seraient considérées comme corrompues. Dans un SGBDR, vous devez envelopper une transaction autour des opérations pour insérer User et Name. Dans Mongo, nous nous assurons que Name est dans le même document (agrégé) que User pour obtenir le même effet.

Votre exemple est un peu moins clair, car je ne comprends pas les analyses de rentabilisation. Une chose qui vient à l'esprit est que Mongo a un excellent soutien pour l'héritage. Il peut être judicieux de placer tous les utilisateurs, individus et potentiellement les entreprises dans la même collection (en fonction de la façon dont l'application est modélisée). Si une personne a de nombreux contacts, vous voulez probablement que les individus aient un tableau d'identification. Si votre application nécessite que vous obteniez un aperçu rapide des contacts, vous pouvez envisager de dupliquer une partie d'un individu et de stocker un tableau d'objets contact.

Si vous êtes habitué à la réflexion sur les SGBDR, vous pensez probablement que toutes vos données doivent toujours être cohérentes. La vérité est que ce n'est probablement pas entièrement vrai. Ce concept d'application des agrégats atomiques au domaine a été prêché récemment par la communauté DDD. Lorsque vous analysez votre domaine en profondeur, comme le font les utilisateurs professionnels, les limites de cohérence doivent être distinctes.