Traitement des requêtes Gremlin dans Neptune

Dans Amazon Neptune, les traversées plus complexes peuvent être représentées par une série de modèles qui créent une relation basée sur la définition de variables nommées pouvant être partagées entre des modèles pour créer des jointures. Voici un exemple :

Question : Quel est le voisinage à deux sauts du sommet v1 ?

  Gremlin code:      g.V(‘v1’).out('knows').out('knows').path()
  Pattern:           (?1=<v1>, <knows>, ?2, ?) X Pattern(?2, <knows>, ?3, ?)

  The pattern produces a three-column relation (?1, ?2, ?3) like this:
                     ?1     ?2     ?3
                     ================
                     v1     v2     v3
                     v1     v2     v4
                     v1     v5     v6

En partageant la variable ?2 entre les deux modèles (à la position O dans le premier modèle et à la position S dans le second modèle), vous créez une jointure entre les voisins à un premier saut et les voisins à deux sauts. Chaque solution Neptune possède des liaisons pour les trois variables nommées, qui peuvent être utilisées pour recréer un TinkerPopTraverser (y compris les informations de chemin).

La première étape du traitement d'une requête G705 consiste à analyser la requête pour en faire un objet TinkerPop Traversal, composé d'une série d'étapes. TinkerPop Ces étapes, qui font partie du TinkerPop projet open source Apache, sont à la fois les opérateurs logiques et physiques qui composent une traversée Gremlin dans l'implémentation de référence. Elles sont toutes deux utilisées pour représenter le modèle de la requête. Il s'agit d'opérateurs exécutables qui peuvent produire des solutions en fonction de la sémantique de l'opérateur qu'ils représentent. Par exemple, .V() est à la fois représenté et exécuté par le TinkerPop GraphStep.

Ces off-the-shelf TinkerPop étapes étant exécutables, un tel TinkerPop Traversal peut exécuter n'importe quelle requête Gkremlin et produire la bonne réponse. Cependant, lorsqu'elles sont exécutées sur un graphique de grande taille, TinkerPop les étapes peuvent parfois être très inefficaces et lentes. Au lieu de les utiliser, Neptune essaie alors de convertir la traversée en forme déclarative composée de groupes de modèles, comme décrit précédemment.

Neptune ne prend actuellement pas en charge tous les opérateurs Gremlin (étapes) dans son moteur de requête natif. Il essaie donc de réduire autant d'étapes que possible en une seule étape NeptuneGraphQueryStep, qui contient le plan de requête logique déclaratif pour toutes les étapes qui ont été converties. Idéalement, toutes les étapes sont converties. Mais lorsqu'une étape ne peut pas être convertie, Neptune sort de l'exécution native et reporte toute exécution de requête à partir de ce point jusqu'aux étapes. TinkerPop Il n'essaie pas de jongler avec et sans l'exécution native.

Une fois que les étapes sont converties en plan de requête logique, Neptune exécute une série d'optimiseurs de requête qui réécrivent le plan de requête en fonction de l'analyse statique et des cardinalités estimées. Ces optimiseurs effectuent des opérations telles que la réorganisation des opérateurs en fonction du nombre de plages, la suppression des opérateurs superflus ou redondants, la réorganisation des filtres, le transfert des opérateurs dans différents groupes, etc.

Une fois qu'un plan de requête optimisé est généré, Neptune crée un pipeline d'opérateurs physiques qui effectuent le travail d'exécution de la requête. Cela inclut la lecture des données à partir des index d'instruction, l'exécution de jointures de différents types, le filtrage, l'organisation, etc. Le pipeline produit un flux de solution qui est ensuite reconverti en un flux d'objets TinkerPop Traverser.

Sérialisation des résultats de requête

Amazon Neptune s'appuie actuellement sur les sérialiseurs de messages de TinkerPop réponse pour convertir les résultats des requêtes (TinkerPop Traversers) en données sérialisées à renvoyer par câble au client. Ces formats de sérialisation ont tendance à être assez verbeux.

Par exemple, pour sérialiser le résultat d'une requête de sommet telle que g.V().limit(1), le moteur de requête Neptune doit effectuer une seule recherche pour générer le résultat. Toutefois, le sérialiseur GraphSON effectue un grand nombre de recherches supplémentaires pour empaqueter le sommet dans le format de sérialisation. Il doit effectuer une recherche pour obtenir l'étiquette, une recherche pour obtenir les clés de propriété et une recherche par clé de propriété pour que le sommet puisse obtenir toutes les valeurs de chaque clé.

Certains formats de sérialisation sont plus efficaces, mais tous nécessitent des recherches supplémentaires. De plus, les TinkerPop sérialiseurs n'essaient pas d'éviter les recherches dupliquées, ce qui entraîne souvent la répétition inutile de nombreuses recherches.

Il est donc très important d'écrire vos requêtes afin qu'elles demandent spécifiquement les informations dont elles ont besoin. Par exemple, g.V().limit(1).id() renvoie uniquement l'ID de sommet et élimine toutes les recherches de sérialiseur supplémentaires. L'API Gremlin profile dans Neptune vous permet de voir combien d'appels de recherche sont effectués pendant l'exécution de la requête et pendant la sérialisation.