Construire avec des modèles : Un résumé

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 modèles 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 d’articles, il y a beaucoup d'éléments à prendre en considération pour répondre à cette question. Cependant, nous avons inclus un schéma d’exemples de cas d’utilisation 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 indique 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. Examinez ceux qui sont fréquemment utilisés dans votre cas d'utilisation. Mais, n'écartez pas les autres, ils peuvent tout de même s'appliquer. La façon dont vous concevez le schéma de données de votre application dépend fortement la manière dont vous accédez aux données.

Résumés des modèles de conception

Approximation

Le modèle Approximation 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.

Avantages

• Moins d'écritures dans la base de données.
• Maintenir des chiffres statistiquement valables.

Inconvénients

• Les chiffres exacts ne sont pas représentés.
• Doit être implémenté dans l'application.’

Attribut

Le modèle Attribut 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.

Avantages

• Moins d'index sont nécessaires.
• Les requêtes deviennent plus simples à écrire et sont généralement plus rapides.

Bucket

Le modèle Bucket est une excellente solution lorsqu'il s'agit de gérer un flux de données, comme dans les applications Time Series, Real-Time Analytics ou Internet of Things (IoT)).

Avantages

• 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.

Computed

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 modèle Calculé (Computed Pattern) est une excellente option à explorer.

Avantages

• Réduction de la charge du CPU pour les calculs fréquents.
• Les requêtes deviennent plus simples à écrire et sont généralement plus rapides.

Inconvénients

• 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é.

Document Versioning

Lorsque vous êtes confronté à la nécessité de conserver des versions antérieures de documents dans MongoDB, le modèle Document Versioning est une solution possible.

Avantages

• 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.

nconvénients

• Double le nombre d'écritures.
• Les requêtes doivent cibler la bonne collection.

Extended Reference

Le modèle Extended Reference est particulièrement utile lorsque votre application doit effectuer un grand nombre d'opérations de jointure pour regrouper des données accédées fréquemment ensemble.

Avantages

• Améliore les performances lorsqu'il y a beaucoup d'opérations de jointure.
• Des lectures plus rapides et une réduction du nombre total de jointures.

Inconvénients

• Duplication des données.

Outliner

Constatez-vous que certaines requêtes ou certains documents ne correspondent pas au modèles 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.

Avantages

• 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.

Inconvénients

• 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.

Pre-allocation

Lorsque vous connaissez la structure de votre document et que votre application doit simplement la remplir de données, le modèle Pre-Allocation est le bon choix.

Avantages

• Simplification de la conception lorsque la structure du document est connue à l'avance.

Inconvénients

• Simplicité contre performance.

Polymorphic

Le modèle Polymorphic 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.

Avantages

• Facile à mettre en œuvre.
• Les requêtes peuvent porter sur une seule collection.

Schema Versioning

Pratiquement toutes les applications peuvent bénéficier du Schema Versioning, 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.

Avantages

• Aucun temps d'arrêt n'est nécessaire.
• Contrôle de la migration des schémas.
• Réduction de la dette technique future.

Inconvénients

• Il se peut que deux index soient nécessaires pour le même champ lors de la migration.

Subset Pattern

Le modèle Subset résout le problème du dépassement de la capacité mémoire par les documents volumineux dont une grande partie des données n'est pas utilisée par l'application.

Avantages

• Réduction de la taille globale des données de travail.
• Temps d'accès au disque plus court pour les données les plus fréquemment utilisées.

Inconvénients

• Nous devons gérer le sous-ensemble.
• La récupération de données supplémentaires nécessite des accès supplémentaires à la base de données.

Tree

Lorsque les données ont une structure hiérarchique arborescente et qu'elles sont fréquemment interrogées, le modèle Tree est le schéma à suivre.

Avantages

• Amélioration des performances en évitant les opérations de jointure multiples.

Inconvénients

• Les mises à jour de l’arbre doivent être gérées dans l'application.

Conclusion

Comme nous espérons que vous l'avez vu dans cette série, le modèle document de MongoDB 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 manières d'accèder 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 modèle document, ces modèles de conception de schémas peuvent être utilisés ensemble, lorsque 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 modèle document.