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 des modèles pour créer des jointures. Voici un exemple :

aux aux aux aux Qu'est-ce que le quartier à deux sauts de Vertexv1?

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 unTinkerPopTraver(y compris les informations sur le chemin).

La première étape du traitement des requêtes Gremlin consiste à analyser la requête dans un TinkerPop Traversalobjet, composé d'une série de TinkerPop pas. Ces étapes, qui font partie de l'open sourceApache TinkerPop projet, sont à la fois les opérateurs logiques et physiques qui composent une traversée de 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 TinkerPop GraphStep.

Parce que ceux-ci off-the-shelf TinkerPop les étapes sont exécutables, telles que TinkerPop Traversal peut exécuter n'importe quelle requête Gremlin et produire la bonne réponse. Toutefois, lorsqu'il est exécuté sur un graphique 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 motifs, 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 toutes les exécutions de requêtes à partir de ce moment jusqu'à 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 sur la base d'une analyse statique et d'estimations 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 qui exécutent 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 de TinkerPopObjets traverseurs.

Sérialisation des résultats de requête

Amazon Neptune s'appuie actuellement sur TinkerPop des sérialiseurs de messages de réponse pour convertir les résultats des requêtes (TinkerPop Traverseurs) dans les données sérialisées à renvoyer par fil 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êtes Neptune doit effectuer une seule recherche 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. En outre, le TinkerPop les 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'GremlinprofileAPI 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.