Modèle de données de graphe de Neptune - Amazon Neptune
DictionnaireStratégie d'indexationModèle de données Gremlin

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.

Modèle de données de graphe de Neptune

L'unité de base des données d'un graphe Amazon Neptune est un élément à quatre positions (quadruplet), qui est comparable à un quadruplet RDF (Resource Description Framework). Voici les quatre positions d'un quadruplet Neptune :

  • subject    (S)

  • predicate  (P)

  • object     (O)

  • graph      (G)

Chaque quadruplet est une instruction qui effectue une assertion sur une ou plusieurs ressources. Une instruction peut déclarer l'existence d'une relation entre deux ressources, ou elle peut attacher une propriété (paire clé/valeur) à une ressource. Vous pouvez généralement considérer la valeur de prédicat de quadruplet comme le verbe de l'instruction. Elle décrit le type de relation ou la propriété qui est définie. L'objet est la cible de la relation ou la valeur de la propriété. Voici quelques exemples :

  • Une relation entre deux sommets peut être représentée en stockant l'identifiant du sommet source dans la position S, l'identifiant du sommet cible dans la position O et l'étiquette d'arc dans la position P.

  • Une propriété peut être représentée en stockant l'identifiant d'élément dans la position S, la clé de propriété dans la position P et la valeur de propriété dans la position O.

La position du graphe G est utilisée différemment dans les différentes piles. Pour les données RDF dans Neptune, la position G contient un identifiant de graphe nommé. Pour les graphes de propriétés dans Gremlin, elle sert à stocker la valeur d'ID d'arête dans le cas d'une arête. Dans tous les autres cas, la valeur par défaut est fixe.

Un graphe est constitué d'un ensemble de déclarations de quadruplet avec des identifiants de ressources partagées.

Dictionnaire des valeurs destinées à l'utilisateur

Neptune ne stocke pas la plupart des valeurs destinées aux utilisateurs directement dans les différents index qu'il gère. Il les stocke plutôt séparément dans un dictionnaire et les remplace dans les index par des identifiants à 8 octets.

  • Toutes les valeurs destinées à l'utilisateur qui figureraient dans les index S, P ou G sont stockées dans le dictionnaire de cette manière.

  • Dans l'index O, les valeurs numériques sont stockées directement (de manière intégrée). Cela inclut les valeurs date et datetime (représentées en millisecondes à partir de l'époque Unix).

  • Toutes les autres valeurs destinées à l'utilisateur qui figureraient dans l'index O sont stockées dans le dictionnaire et représentées dans l'index par des ID.

Le dictionnaire contient un mappage direct des valeurs destinées à l'utilisateur avec des ID de 8 octets dans un index value_to_id.

Il stocke le mappage inverse des ID de 8 octets avec les valeurs de l'un des deux index, en fonction de la taille de ces valeurs :

  • Un index id_to_value mappe les ID avec les valeurs destinées à l'utilisateur inférieures à 767 octets après l'encodage interne.

  • Un index id_to_blob mappe les ID avec à les valeurs supérieures destinées à l'utilisateur.

Comment les instructions sont indexées dans Neptune

Lorsque vous interrogez un graphe de quadruplets, vous pouvez ou non spécifier une contrainte de valeur pour chaque position de quadruplet. La requête renvoie tous les quadruplets qui correspondent aux contraintes de valeur que vous avez spécifiées.

Neptune utilise des index pour résoudre les requêtes. Dans leur article de 2005 intitulé Optimized Index Structures for Querying RDF from the Web, Andreas Harth et Stefan Decker ont observé qu'il existait 16 (24) modèles d'accès possibles pour les quatre positions de quadruplet. Vous pouvez interroger efficacement les 16 modèles sans avoir à analyser et filtrer à l'aide de six index d'instruction de quadruplet. Chaque index d'instruction de quadruplet utilise une clé composée des quatre valeurs de position concaténées dans un ordre différent.


       Access Pattern                                     Index key order
  ----------------------------------------------------    ---------------
   1.  ????  (No constraints; returns every quad)             SPOG
   2.  SPOG  (Every position is constrained)                  SPOG
   3.  SPO?  (S, P, and O are constrained; G is not)          SPOG
   4.  SP??  (S and P are constrained; O and G are not)       SPOG
   5.  S???  (S is constrained; P, O, and G are not)          SPOG
   6.  S??G  (S and G are constrained; P and O are not)       SPOG

   7.  ?POG  (P, O, and G are constrained; S is not)          POGS
   8.  ?PO?  (P and O are constrained; S and G are not)       POGS
   9.  ?P??  (P is constrained; S, O, and G are not)          POGS

  10.  ?P?G  (P and G are constrained; S and O are not)       GPSO
  11.  SP?G  (S, P, and G are constrained; O is not)          GPSO
  12.  ???G  (G is constrained; S, P, and O are not)          GPSO

  13.  S?OG  (S, O, and G are constrained; P is not)          OGSP
  14.  ??OG  (O and G are constrained; S and P are not)       OGSP
  15.  ??O?  (O is constrained; S, P, and G are not)          OGSP

  16.  S?O?  (S and O are constrained; P and G are not)       OSGP

Neptune crée et gère uniquement trois de ces six index par défaut :

  • SPOG –   Utilise une clé composée de Subject + Predicate + Object + Graph.

  • POGS –   Utilise une clé composée de Predicate + Object + Graph + Subject.

  • GPSO –   Utilise une clé composée de Graph + Predicate + Subject + Object.

Ces trois index gèrent la plupart des modèles d'accès les plus courants. Le fait de conserver seulement trois index d'instruction complets au lieu de six a pour effet de limiter grandement les ressources dont vous avez besoin pour prendre en charge l'accès rapide sans analyse et filtrage. Par exemple, l'index SPOG permet une recherche efficace chaque fois qu'un préfixe des positions, comme le sommet ou l'identifiant de sommet et de propriété, est lié. L'index POGS permet un accès efficace lorsque seule l'étiquette d'arête ou de propriété stockée à la position P est liée.

L'API de bas niveau permettant de trouver des instructions utilise un modèle d'instruction dans lequel certaines positions sont connues et les autres doivent être découvertes à l'aide d'une recherche d'index. En constituant les positions connues dans un préfixe de clé en fonction de l'ordre de la clé d'index pour l'un des index d'instruction, Neptune exécute une analyse de plage pour récupérer toutes les instructions correspondant aux positions connues.

Cependant, un des index d'instruction que Neptune ne crée pas par défaut est un index OSGP de traversée inverse, qui peut collecter des prédicats dans les objets et les sujets. Au lieu de cela, Neptune effectue par défaut le suivi des différents prédicats dans un index distinct qu'il utilise pour effectuer une analyse d'union de {all P x POGS}. Lorsque vous utilisez Gremlin, un prédicat correspond à une propriété ou à une étiquette d'arête.

Si le nombre de prédicats distincts dans un graphe devient important, la stratégie d'accès Neptune par défaut peut devenir inefficace. Dans Gremlin, par exemple, une étape in() dans laquelle aucune étiquette d'arc n'est donnée, ou toute étape qui utilise in() en interne, comme both() ou drop(), peut devenir plutôt inefficace.

Activation de la création d'index OSGP en mode Lab

Si votre modèle de données crée un grand nombre de prédicats distincts, vous pouvez être confronté à des performances réduites et des coûts opérationnels plus élevés qui peuvent être considérablement améliorés en utilisant le mode laboratoire pour activer l'index OSGP, en plus des trois index qui sont gérés par défaut par Neptune.

Note

Cette fonctionnalité est disponible à partir de la version 1.0.1.0.200463.0 du moteur Neptune.

L'activation de l'index OSGP peut présenter quelques inconvénients :

  • Le taux d'insertion peut être ralenti de jusqu'à 23 %.

  • Le stockage augmente jusqu'à 20 %.

  • Les requêtes de lecture qui touchent tous les index de manière égale (ce qui est plutôt rare) peuvent avoir des latences accrues.

En général, cependant, cela vaut la peine d'activer l'index OSGP pour les clusters de bases de données avec un grand nombre de prédicats distincts. Les recherches basées sur des objets deviennent extrêmement efficaces (par exemple, trouver toutes les arêtes entrantes vers un sommet ou tous les sujets connectés à un objet donné). De ce fait, la suppression des sommets devient aussi beaucoup plus efficace.

Important

Vous ne pouvez activer l'index OSGP que dans un cluster de bases de données vide, avant d'y charger des données.

 

Déclarations Gremlin dans le modèle de données Neptune

Les données du graphe de propriétés Gremlin sont exprimées dans le modèle SPOG à l'aide de trois classes de déclarations, à savoir :

Pour en savoir plus sur leur utilisation dans les requêtes Gremlin, consultez Présentation du fonctionnement des requêtes Gremlin dans Neptune.