Prise en charge des graphes Azure Cosmos DB for Gremlin et compatibilité avec les fonctionnalités TinkerPop

S’APPLIQUE À : Gremlin

Azure Cosmos DB prend en charge le langage de traversées de graphes Apache Tinkerpop, connu sous le nom de Gremlin. Vous pouvez utiliser le langage Gremlin pour créer des entités de graphes (sommets et arêtes), modifier les propriétés au sein de ces entités, exécuter des requêtes et traversées et supprimer des entités.

Le moteur Azure Cosmos DB Graph suit de près la spécification des étapes de traversée Apache TinkerPop, mais avec quelques différences au niveau de l’implémentation, spécifiques à Azure Cosmos DB. Dans cet article, nous fournissons une procédure pas à pas pour Gremlin, et nous énumérons les fonctionnalités de Gremlin prises en charge par l’API pour Gremlin.

Bibliothèques clientes compatibles

Le tableau suivant présente des pilotes Gremlin courants que vous pouvez utiliser sur Azure Cosmos DB :

Objets graphiques pris en charge

TinkerPop est une norme qui couvre un large éventail de technologies de graphes. Par conséquent, elle dispose de la terminologie standard utilisée pour décrire les fonctionnalités offertes par un fournisseur de graphes. Azure Cosmos DB fournit une base de données de graphes permanente, concurrentielle et accessible en écriture qui peut être partitionnée entre plusieurs serveurs ou clusters.

Le tableau suivant répertorie les fonctionnalités TinkerPop implémentées par Azure Cosmos DB :

Format de communication Gremlin

Azure Cosmos DB utilise le format JSON quand les résultats des opérations Gremlin sont retournés. Azure Cosmos DB prend actuellement en charge le format JSON. Par exemple, l’extrait de code suivant montre une représentation JSON d’un sommet retourné au client à partir d’Azure Cosmos DB :

  {
    "id": "a7111ba7-0ea1-43c9-b6b2-efc5e3aea4c0",
    "label": "person",
    "type": "vertex",
    "outE": {
      "knows": [
        {
          "id": "3ee53a60-c561-4c5e-9a9f-9c7924bc9aef",
          "inV": "04779300-1c8e-489d-9493-50fd1325a658"
        },
        {
          "id": "21984248-ee9e-43a8-a7f6-30642bc14609",
          "inV": "a8e3e741-2ef7-4c01-b7c8-199f8e43e3bc"
        }
      ]
    },
    "properties": {
      "firstName": [
        {
          "value": "Thomas"
        }
      ],
      "lastName": [
        {
          "value": "Andersen"
        }
      ],
      "age": [
        {
          "value": 45
        }
      ]
    }
  }

Les propriétés utilisées par le format JSON pour les sommets sont décrites ci-dessous :

Chaque propriété peut stocker plusieurs valeurs dans un tableau.

Et l’arête contient les informations suivantes pour faciliter la navigation vers d’autres parties du graphe.

Étapes de Gremlin

Nous allons maintenant examiner les étapes Gremlin prises en charge par Azure Cosmos DB. Pour des références complètes sur Gremlin, consultez Référence TinkerPop.

Le moteur optimisé pour l’écriture fourni par Azure Cosmos DB prend en charge l’indexation automatique de toutes les propriétés au sein des sommets et des arêtes par défaut. Par conséquent, les requêtes avec des filtres, les requêtes de plage, le tri ou les agrégations sur toutes les propriétés sont traités à partir de l’index et exécutés efficacement. Pour plus d’informations sur la façon dont fonctionne l’indexation dans Azure Cosmos DB, consultez notre article sur l’indexation indépendante du schéma.

Différences de comportement

• Le moteur de graphe Azure Cosmos DB fonctionne en largeur d’abord sur la traversée tandis que TinkerPop Gremlin fonctionne en profondeur d’abord. Ce comportement permet d’obtenir de meilleures performances dans un système horizontalement évolutif comme Azure Cosmos DB.

Fonctionnalités non prises en charge

• Gremlin Bytecode est une spécification pour les traversées de graphe indépendante du langage de programmation. Le graph Azure Cosmos DB ne la prend pas encore en charge. Utilisez GremlinClient.SubmitAsync() et passez la traversée en tant que chaîne de texte.

• La cardinalité des ensembles property(set, 'xyz', 1) n’est pas prise en charge. Utilisez property(list, 'xyz', 1) à la place. Pour plus d’informations, consultez Vertex properties with TinkerPop (Propriétés de vertex avec TinkerPop).

• L’étape match() n’est actuellement pas disponible. Cette étape fournit des fonctions d’interrogation déclarative.

• Les objets en tant que propriétés sur les sommets ou arêtes ne sont pas pris en charge. Les propriétés peuvent uniquement être des types primitifs ou des tableaux.

• Le tri par propriétés de tableau order().by(<array property>) n’est pas pris en charge. Seul est pris en charge le tri par types primitifs.

• Les types JSON non primitifs ne sont pas pris en charge. Utilisez les types string, number ou true/false. Les valeurs null ne sont pas prises en charge.

• Le sérialiseur GraphSONv3 n’est actuellement pas pris en charge. Utilisez les classes de sérialiseur, de lecteur et d’enregistreur GraphSONv2 dans la configuration de la connexion. Les résultats renvoyés par Azure Cosmos DB for Gremlin ne sont pas au format GraphSON.

• Les fonctions et les expressions lambda ne sont pas prises en charge actuellement. Cela comprend les fonctions .map{<expression>}, .by{<expression>} et .filter{<expression>}. Pour plus d’informations et pour découvrir comment les réécrire à l’aide d’étapes Gremlin, consultez A Note on Lambdas (Remarque sur les lambdas).

• Les transactions ne sont pas prises en charge en raison de la nature distribuée du système. Configurez un modèle d’accès concurrentiel optimiste approprié sur le compte Gremlin pour « lire vos propres écrits », et utilisez l’accès concurrentiel optimiste pour résoudre les conflits d’écritures.

Limitations connues

• Utilisation de l’index pour les requêtes Gremlin avec des étapes .V() mi-parcours : Actuellement, seul le premier appel .V() d’une traversée utilisera l’index pour résoudre les filtres ou prédicats qui lui sont associés. Les appels suivants ne consultent pas l’index, ce qui peut augmenter la latence et le coût de la requête.

Dans l’hypothèse de l’indexation par défaut, une requête Gremlin de lecture classique commençant par l’étape .V() utiliserait des paramètres dans les étapes de filtrage associées, tels que .has() ou .where(), pour optimiser le coût et les performances de la requête. Par exemple :

g.V().has('category', 'A')

Toutefois, lorsque plusieurs étapes .V() sont incluses dans la requête Gremlin, la résolution des données pour la requête peut ne pas être optimale. Utilisez la requête suivante en guise d’exemple :

g.V().has('category', 'A').as('a').V().has('category', 'B').as('b').select('a', 'b')

Cette requête retourne deux groupes de sommets en fonction de leur propriété appelée category. Dans ce cas, seul le premier appel, g.V().has('category', 'A') utilise l’index pour résoudre les sommets en fonction des valeurs de leurs propriétés.

Une solution de contournement pour cette requête consiste à utiliser des étapes de sous-parcours, telles que .map() et union(). En voici quelques exemples :

// Query workaround using .map()
g.V().has('category', 'A').as('a').map(__.V().has('category', 'B')).as('b').select('a','b')

// Query workaround using .union()
g.V().has('category', 'A').fold().union(unfold(), __.V().has('category', 'B'))

Vous pouvez examiner les performances des requêtes à l’aide de l’étape Gremlin executionProfile().

Étapes suivantes

• Commencez par créer une application de graphe à l’aide de nos kits SDK
• Découvrez plus en détail la prise en charge des graphiques dans Azure Cosmos DB.