Alors que nous terminons la série "Building with Patterns", c'est l'occasion de récapituler les problèmes que les modèles abordés ont permis de résoudre et de mettre en évidence certains des avantages et des compromis de chaque modèle. La question la plus fréquente concernant les schémas de conception est la suivante : "Je conçois une application pour faire X, comment dois-je modéliser les données ?". Comme nous espérons que vous l'avez découvert au cours de cette série de blogs, il y a beaucoup d'éléments à prendre en considération pour répondre à cette question. Cependant, nous avons inclus un exemple de cas d'utilisation Charts que nous avons trouvé utile pour au moins fournir un guide initial sur les modèles de modélisation des données pour les cas d'utilisation génériques.
Exemples de cas d'utilisation
Le graphique ci-dessous est une indication de ce que nous avons constaté après des années d'expérience avec nos clients en ce qui concerne les modèles de conception de schéma utilisés dans une variété d'applications. Il ne s'agit pas d'une définition "gravée dans le marbre" de règles indiquant quel modèle de conception peut être utilisé pour un type d'application particulier. Veillez à examiner ceux qui sont fréquemment utilisés dans votre cas d'utilisation. Toutefois, n'écartez pas les autres, ils peuvent encore s'appliquer. La façon dont vous concevez le schéma de données de votre application dépend fortement de vos schémas d'accès aux données.
Résumés des modèles de conception
Approximation
Le Approximation Pattern est utile lorsque des calculs coûteux sont fréquemment effectués et que la précision de ces calculs n'est pas une priorité absolue.
Atouts
- Moins d'écritures dans la base de données.
- Maintenir des chiffres statistiquement valables.
Désavantages
- Les chiffres exacts ne sont pas représentés.
- La mise en œuvre doit être effectuée dans l'application.’
Attribut
Le Attribute est utile pour les problèmes liés à l'existence de documents volumineux comportant de nombreux champs similaires, mais un sous-ensemble de champs partageant des caractéristiques communes et sur lesquels on souhaite effectuer un tri ou une requête. Lorsque les champs à trier ne se trouvent que dans un petit sous-ensemble de documents. Ou lorsque ces deux conditions sont réunies dans les documents.
Atouts
- Moins d'index sont nécessaires.
- Les requêtes deviennent plus simples à écrire et sont généralement plus rapides.
Compartiment
Le Bucket Pattern est une excellente solution lorsqu'il s'agit de managed données en continu, comme dans les applications Time Series, Real-Time Analytics ou Internet of Things (IoT)).
Atouts
- Réduit le nombre total de documents dans une collection.
- Améliore les performances de index.
- Peut simplifier l'accès aux données en tirant parti de la préagrégation.
Calculé
Lorsqu'il existe des schémas d'accès aux données très intensifs en lecture et que ces données doivent être calculées de manière répétée par l'application, le Computed Pattern est une excellente option à explorer.
Atouts
- Réduction de la charge de travail de l'unité centrale pour les calculs fréquents.
- Les requêtes deviennent plus simples à écrire et sont généralement plus rapides.
Désavantages
- Il peut être difficile d'identifier le besoin de ce modèle.
- L'application ou l'utilisation excessive du modèle doit être évitée, sauf en cas de nécessité.
Version de document
Lorsque vous êtes confronté à la nécessité de conserver des versions antérieures de documents dans MongoDB, le Document Versioning Pattern est une solution possible.
Atouts
- Facile à mettre en œuvre, même sur des systèmes existants.
- Aucun impact sur les performances des requêtes sur la dernière révision.
Désavantages
- Double le nombre d'écritures.
- Les requêtes doivent cibler la bonne collection.
Référence étendue
Le Extended Reference Pattern est particulièrement utile lorsque votre application doit effectuer un grand nombre d'opérations JOIN pour rassembler des données fréquemment accessibles.
Atouts
- Améliore les performances lorsqu'il y a beaucoup d'opérations de JOIN.
- Des lectures plus rapides et une réduction du nombre total de JOINs.
Désavantages
- Duplication des données.
Aberration
Constatez-vous que certaines requêtes ou certains documents ne correspondent pas au reste de vos schémas de données habituels ? Ces exceptions sont-elles à l'origine de votre solution d'application ? Si c'est le cas, le modèle des valeurs aberrantes est une excellente solution à cette situation.
Atouts
- Empêche que quelques documents ou requêtes ne déterminent la solution d'une application.
- Les requêtes sont adaptées aux cas d'utilisation "typiques", mais les cas aberrants sont toujours pris en compte.
Désavantages
- Souvent adaptés à des requêtes spécifiques, les requêtes ad hoc risquent donc de ne pas donner de bons résultats.
- Une grande partie de ce modèle est réalisée avec le code de l'application.
Pré-allocation
Lorsque vous connaissez la structure de votre document et que votre application doit simplement la remplir de données, le Pre-Allocation Pattern est le bon choix.
Atouts
- Simplification de la conception lorsque la structure du document est connue à l'avance.
Désavantages
- Simplicité contre performance.
Polymorphe
Le Polymorphic Pattern est la solution lorsqu'il existe une variété de documents qui présentent plus de similitudes que de différences et que les documents doivent être conservés dans une collection unique.
Atouts
- Facile à mettre en œuvre.
- Les requêtes peuvent porter sur une seule collection.
Version de schéma
Pratiquement toutes les applications peuvent bénéficier du Schema Versioning Pattern, car des modifications du schéma de données interviennent fréquemment au cours de la durée de vie d'une application. Ce modèle permet aux versions précédentes et actuelles des documents de coexister dans une collection.
Atouts
- Aucun temps d'arrêt n'est nécessaire.
- Contrôle de la migration des schémas.
- Réduction de la dette technique future.
Désavantages
- Il se peut que deux index soient nécessaires pour le même champ lors de la migration.
Sous-ensemble
Le Subset Pattern résout le problème du dépassement de la capacité du site RAM par les documents volumineux dont une grande partie des données n'est pas utilisée par l'application.
Atouts
- Réduction de la taille globale de l'outil de travail.
- Temps d'accès au disque plus court pour les données les plus fréquemment utilisées.
Désavantages
- Nous devons managed le sous-ensemble.
- L'extraction de données supplémentaires nécessite des déplacements supplémentaires vers la base de données.
Arborescence
Lorsque les données ont une structure hiérarchique et qu'elles sont fréquemment interrogées, le Tree Pattern est le design à mettre en œuvre.
Atouts
- Amélioration des performances en évitant les opérations de JOIN multiples.
Désavantages
- Les mises à jour du graphique doivent être managed dans l'application.
Conclusion
Comme nous espérons que vous l'avez vu dans cette série, MongoDB document model offre une grande flexibilité dans la façon dont vous modélisez les données. Cette flexibilité est incroyablement puissante, mais elle doit être exploitée en fonction des schémas d'accès aux données de votre application. N'oubliez pas que la conception du schéma dans MongoDB a un impact considérable sur les performances de votre application. Nous avons constaté que les problèmes de performance sont souvent dus à une mauvaise conception du schéma.
Gardez à l'esprit que pour améliorer encore la puissance du site document model, ces modèles de conception de schémas peuvent être utilisés ensemble, si et quand cela s'avère judicieux. Par exemple, le schéma Versioning peut être utilisé en conjonction avec n'importe quel autre schéma au fur et à mesure que votre application évolue. Avec les douze modèles de conception de schémas abordés, vous disposez des outils et des connaissances nécessaires pour exploiter la puissance de la flexibilité du site document model.