Comment les instructions sont indexées dans 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.

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.

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 modèles de requêtes graphiques. Ces index concernent les quatre composants principaux d'une arête de graphe : sujet (sommet source dans LPG) ; prédicat (RDF) ou étiquette de propriété ou de bord (LPG) ; objet (sommet cible ou valeur de propriété dans LPG) ; et graphe (RDF) ou identifiant de bord (LPG). Il existe 16 (2^4) modèles d'accès possibles pour ces quatre positions de composants. Vous pouvez interroger efficacement les 16 modèles sans avoir à scanner ni à filtrer à l'aide de six index. Chaque index d'instruction de quadruplet utilise une clé composée des quatre valeurs de position concaténées dans un ordre différent. Voici une combinaison possible de quatre index d'instructions qui couvriraient les 16 chemins d'accès :

       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 :

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.

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

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.

 

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.