Modélisation des données de graphes à l’aide d’Azure Cosmos DB for Apache Gremlin
S’APPLIQUE À : 
Gremlin
Cet article fournit des recommandations relatives à l’utilisation de modèles de données de graphes. Ces meilleures pratiques sont essentielles pour garantir la scalabilité et les performances d’un système de base de données de graphe au fur et à mesure de l’évolution des données. Un modèle de données efficace est particulièrement important pour les graphes à grande échelle.
Spécifications
Le processus décrit dans ce guide est basé sur les hypothèses suivantes :
- Les entités dans l’espace du problème sont identifiées. Ces entités sont destinées à être consommés atomiquement pour chaque demande. En d’autres termes, le système de base de données n’est pas conçu pour récupérer les données d’une entité unique dans plusieurs demandes de requête.
- Vous comprenez les exigences en lecture et en écriture pour le système de base de données. Ces exigences guident les optimisations nécessaires pour le modèle de données de graphes.
- Les principes du standard des graphes de propriétés Apache Tinkerpop sont bien compris.
Quand ai-je besoin d’une base de données de graphe ?
Une solution de base de données de graphe peut être utilisée de façon optimale si les entités et les relations dans un domaine de données ont l’une des caractéristiques suivantes :
- Les entités sont fortement connectées via des relations descriptives. L’avantage dans ce scénario est que les relations sont conservées dans le stockage.
- Il existe des relations cycliques ou des entités auto-référencées. Ce modèle représente souvent un certain défi lors de l’utilisation de bases de données relationnelles ou de documents.
- Il existe des relations évoluant dynamiquement entre les entités. Ce modèle s’applique en particulier à des données structurées en arborescence ou de façon hiérarchique avec de nombreux niveaux.
- Il existe des relations plusieurs-à-plusieurs entre les entités.
- Il existe des exigences d’écriture et de lecture sur les entités et les relations.
Si les critères ci-dessus sont remplis, il est probable qu’une approche de base de données de graphe fournisse des avantages pour la complexité des requêtes, la scalabilité du modèle de données et les performances des requêtes.
L’étape suivante consiste à déterminer si le graphe va être utilisé à des fins analytiques ou transactionnelles. Si le graphe est destiné à être utilisé pour des calculs intensifs et des charges de travail importantes de traitement des données, il est utile d’explorer le connecteur Spark Cosmos DB et la bibliothèque GraphX.
Comment utiliser des objets de graphe
La norme des graphes de propriétés Apache TinkerPop définit deux types d’objets : les sommets et les arêtes.
Voici les bonnes pratiques pour les propriétés dans les objets de graphe :
| Object | Propriété | Type | Notes |
|---|---|---|---|
| Sommet | id | String | Appliqué de façon unique par partition. Si une valeur n’est pas fournie lors de l’insertion, un GUID généré automatiquement est stocké. |
| Sommet | Étiquette | String | Cette propriété est utilisée pour définir le type d’entité que représente le sommet. Si une valeur n’est pas fournie, la valeur par défaut vertex (sommet) est utilisée. |
| Sommet | Propriétés | Chaîne, booléen, numérique | Une liste de propriétés distinctes stockées sous forme de paires clé-valeur dans chaque sommet. |
| Sommet | Clé de partition | Chaîne, booléen, numérique | Cette propriété définit où le sommet et ses arêtes sortantes sont stockés. Pour plus d’informations, consultez partitionnement de graphe. |
| Edge | id | String | Appliqué de façon unique par partition. Généré automatiquement par défaut. Les arêtes n’ont généralement pas besoin d’être récupérées de façon univoque via un ID. |
| Edge | Étiquette | String | Cette propriété est utilisée pour définir le type de relation entre deux sommets. |
| Edge | Propriétés | Chaîne, booléen, numérique | Une liste de propriétés distinctes stockées sous forme de paires clé-valeur dans chaque arête. |
Notes
Les arêtes ne nécessitent pas une valeur de clé de partition, car la valeur est affectée automatiquement en fonction de leur sommet source. Pour plus d’informations, consultez l’article Utilisation d’un graphe partitionné dans Azure Cosmos DB.
Instructions pour la modélisation des entités et des relations
Les recommandations ci-dessous vous aident à aborder la modélisation des données pour une base de données de graphes Azure Cosmos DB for Apache Gremlin. Ces instructions supposent qu’il existe une définition d’un domaine de données et des requêtes pour celui-ci.
Notes
Les étapes ci-dessous sont présentées en tant que recommandations. Vous devez évaluer et tester le modèle final avant de le considérer comme prêt pour la production. De plus, les recommandations sont spécifiques à l’implémentation de l’API Gremlin d’Azure Cosmos DB.
Modélisation des sommets et des propriétés
La première étape pour un modèle de données de graphe consiste à mapper chaque entité identifiée à un objet sommet. Un mappage un-à-un de toutes les entités aux sommets doit être une étape initiale et est sujet à modification.
Un piège courant est de mapper les propriétés d’une même entité en tant que sommet distinct. Prenons l’exemple ci-dessous, où la même entité est représentée de deux manières différentes :
Propriétés basées sur les sommets : Dans cette approche, l’entité utilise trois sommets distincts et deux arêtes pour décrire ses propriétés. Bien que cette approche puisse réduire la redondance, elle accroît la complexité du modèle. Un accroissement de la complexité du modèle peut entraîner une augmentation des temps de latence, de la complexité des requêtes et du temps de calcul. Ce modèle peut également présenter des problèmes liés au partitionnement.
Sommet avec des propriétés incorporées : Cette approche tire parti de la liste de paires clé-valeur pour représenter toutes les propriétés de l’entité à l’intérieur d’un sommet. Cette approche diminue la complexité du modèle, ce qui permet des requêtes plus simples et des traversées moins consommatrices de ressources.
Notes
Les diagrammes précédents montrent un modèle de graphe simplifié qui compare uniquement les deux façons de diviser les propriétés d’entité.
Le modèle de sommet avec propriétés incorporées fournit généralement une approche plus performante et plus évolutive. L’approche par défaut pour un nouveau modèle de données de graphe doit se faire autour de ce modèle.
Il existe cependant des scénarios où faire référence à une propriété peut offrir des avantages. Par exemple, si la propriété référencée est fréquemment mise à jour. Utilisez un sommet distinct pour représenter une propriété qui est constamment modifiée pour minimiser la quantité d’opérations d’écriture que la mise à jour nécessite.
Modélisation des relations avec les sens des arêtes
Une fois les sommets modélisés, les arêtes peuvent être ajoutées pour indiquer les relations entre ceux-ci. Le premier aspect qui doit être évalué est le sens de la relation.
Les objets arête ont un sens par défaut qui est suivi par une traversée lors de l’utilisation de la fonction out() ou outE(). L’utilisation de cette direction naturelle aboutit à un fonctionnement efficace, car tous les sommets sont stockés avec leurs arêtes sortantes.
Cependant, traverser dans le sens opposé d’une arête, en utilisant la fonction in(), aboutit toujours à une requête dans plusieurs partitions. Explorez plus en détail le partitionnement de graphe. S’il est nécessaire de traverser constamment en utilisant la fonction in(), il est recommandé d’ajouter des arêtes dans les deux sens.
Vous pouvez déterminer le sens de l’arête en utilisant le prédicat .to() ou .from() avec l’étape .addE() de Gremlin. Vous pouvez aussi utiliser la bibliothèque BulkExecutor pour l’API Gremlin.
Notes
Les objets arête ont un sens par défaut.
Étiquettes de relations
L’utilisation d’étiquettes de relation descriptives peut améliorer l’efficacité des opérations de résolution des arêtes. Vous pouvez appliquer ce modèle de ces différentes façons :
- Utilisez des termes non génériques pour étiqueter une relation.
- Associez l’étiquette du sommet source à l’étiquette du sommet cible avec le nom de la relation.
Plus l’étiquette utilisée par la traversée pour filtrer les arêtes est spécifique, meilleur est le résultat. Cette décision peut également avoir un effet important sur le coût des requêtes. Vous pouvez évaluer le coût des requêtes à tout moment en utilisant l’étape executionProfile.
Étapes suivantes
- Consultez la liste des étapes Gremlin prises en charge.
- Découvrez plus d’informations sur le partitionnement des bases de données de graphe pour gérer les graphes à grande échelle.
- Évaluez vos requêtes Gremlin en utilisant l’étape de profil d’exécution.
- Modèle de données de conception de graphe de tiers.