Comment les requêtes Gremlin sont traitées dans Neptune - Amazon Neptune

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Comment les requêtes Gremlin sont traitées 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 qui peuvent être partagées entre les modèles afin de 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 trajectoire).

La première étape du traitement des requêtes par Gremlin consiste à analyser la requête en un objet TinkerPop Traversal, composé d'une série d' TinkerPop étapes. 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.

Comme ces off-the-shelf TinkerPop étapes sont exécutables, une telle TinkerPop traversée peut exécuter n'importe quelle requête Gremlin et produire la bonne réponse. Toutefois, lorsqu'elles sont exécutées sur un graphe de grande taille, TinkerPop les étapes peuvent parfois être très inefficaces et lentes. Au lieu de les utiliser, Neptune essaie de convertir la traversée en une 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 interrompt l'exécution native et reporte l'exécution de toutes les requêtes à partir de ce moment vers les TinkerPop étapes. Il n'essaie pas de jongler avec et sans l'exécution native.

Une fois les étapes traduites en un plan de requête logique, Neptune exécute une série d'optimiseurs de requêtes qui réécrivent le plan de requêtes en fonction d'une analyse statique et d'une estimation des cardinalités. 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é a été produit, Neptune crée un pipeline d'opérateurs physiques chargés d'exécuter 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 flux d'objets TinkerPop Traverser.

Sérialisation des résultats de la 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 Traverseurs) 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 queg.V().limit(1), le moteur de requête Neptune doit effectuer une recherche unique pour produire le résultat de la requête. 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'profileAPI Gremlin 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.