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 pool pour les graphes de propriétés étiquetés

Il existe trois approches différentes du modèle de pool pour LPGs Amazon Neptune :

Stratégie immobilière

Avec LPGs, les utilisateurs peuvent ajouter des propriétés de paire clé-valeur aux nœuds, ou sommets, et aux arêtes. Pour obtenir une séparation logique, la plupart des clients la modélisent intuitivement sous la forme d'une propriété unique sur chaque nœud et chaque périphérie avec une clé de propriété commune au locataire. La clé de propriété du locataire représente tous les locataires propriétaires du nœud. L'identifiant du locataire est une valeur unique qui identifie un locataire individuel.

Le schéma suivant montre ce modèle. Les deux sous-graphes déconnectés comportent différents nœuds et arêtes étiquetés, la clé de propriété du locataire étant représentée parTId. Chaque nœud et chaque arête d'un sous-graphe ont une TId valeur de1. Dans l'autre sous-graphe, chaque nœud et chaque arête ont une TId valeur de2.

Dans les graphes de propriétés étiquetés, il existe deux manières de gérer cela. Le langage de requête Gremlin propose la bibliothèque de PartitionStrategytraversée pour aider à gérer le partitionnement des données. Le code de l'exemple suivant s'attend à ce que chaque nœud et chaque arête aient une propriété appelée TId :

strategy1 = new PartitionStrategy(partitionKey: "TId", writePartition: "1", readPartitions: ["1"]) 
strategy2 = new PartitionStrategy(partitionKey: "TId", writePartition: "2", readPartitions: ["2"]) 

Lorsque de nouveaux nœuds ou arêtes sont écrits, la propriété "TId" est ajoutée avec une valeur de "1" ou"2", selon que strategy1 ou strategy2 a été sélectionné. Pour le client avec "TId" ou"1", vous utilisezstrategy1. L'exemple suivant montre comment écrire des données pour ce client :

g.withStrategies(strategy1).addV("Label1").property("Value", "123456").property(id, "Item_1") 

Pour les requêtes de lecture, un filtre pour "TId == '1'" ou "TId == '2'" est ajouté à chaque traversée de nœud ou de bord en utilisant strategy1 oustrategy2, respectivement. Ces stratégies de partition simplifient votre code, mais elles ne sont pas nécessaires. L'avantage de l'utilisation de cette stratégie est qu'elle peut être injectée au niveau d'autorisation et transmise au code de niveau inférieur qui forme la requête. Cela permet de séparer le code qui détermine l'identifiant du client (TId) de la logique de la requête.

L'exemple de code suivant montre une requête Gremlin pour lire des données :

g.withStrategies(strategy1).V().hasLabel("Label1")

Le code précédent est équivalent à l'exemple suivant :

g.V().hasLabel("Label1").has("TId", "1")

De même, lorsque vous écrivez des données à l'aide de Gremlin, vous pouvez utiliser la requête suivante :

g.withStrategies(strategy1).addV("Label1").property("Value").property(id, "Item_1")

Le code précédent est équivalent à l'exemple suivant, qui n'utilise pas la stratégie de partition et nécessite donc que la "TId" propriété soit écrite explicitement :

g.addV("Label1").property("TId", "1").property("Value").property(id, "Item_1")

Dans OpenCypher, ces bibliothèques n'existent pas. Vous êtes responsable de la rédaction et de la modification de vos requêtes pour ajouter l'identifiant du locataire en tant que propriété sur les nœuds et les arêtes. Par exemple :

CREATE (n:Item {`~id`: 'Item_1', Value: '123456', TId: '1'})
CREATE (n:Item {`~id`: 'Item_2', Value: '123456', TId: '2'})

Notez la similitude entre le code Gremlin sans la stratégie de partition. Vous pouvez ensuite lire le nœud écrit à partir de la première CREATE instruction en utilisant le code suivant :

MATCH (n:Item {TId: '1'})
RETURN n
--or
MATCH (n:Item)
WHERE n.TId == '1'
RETURN n

Vous pouvez choisir la stratégie de propriété lorsque vous souhaitez utiliser des constructions natives de TinkerPop Gremlin telles que. PartitionStrategy Cependant, ce modèle présente des inconvénients en termes de performances sur Amazon Neptune par rapport à la stratégie de préfixe-étiquette. Pour une discussion de ces inconvénients en termes de performances, voir la section Implications en termes de performances pour les modèles GPL.

Si les conditions suivantes s'appliquent, envisagez de modéliser la stratégie de propriété uniquement sur les nœuds, et non sur les arêtes :

Stratégie d'étiquetage par préfixe

Si la performance est une préoccupation majeure, nous vous recommandons vivement de privilégier la stratégie d'étiquette préfixe plutôt que la stratégie immobilière.

Dans la stratégie d'étiquette préfixe, vous étiquetez chaque nœud avec une combinaison d'identifiant de locataire et d'étiquette de nœud. Par exemple, si le locataire possède un identifiant de "1" et que l'étiquette du nœud est"Label1", vous spécifiez l'étiquette du nœud sous la forme"1-Label1". Le schéma suivant montre deux sous-graphes déconnectés qui utilisent ce modèle.

Lorsque vous écrivez des données dans Gremlin, vous pouvez ajouter un numéro d'identification à l'étiquette de n'importe quel nœud :

g.addV("1-Label1")
g.addV("2-Label6")

Lorsque vous interrogez ce graphe, vous pouvez vérifier l'existence de ce préfixe sur un nœud :

g.V().hasLabel("1-Label1")

Dans OpenCypher, vous pouvez écrire des données en utilisant une CREATE instruction :

CREATE (n:`1-Label1` {`~id`: 'Item_1', Value: 'XYZ123456'})

Pour interroger les données que vous avez écrites dans OpenCypher, utilisez le code suivant :

MATCH n= (:`1-Label1`)
RETURN n

La stratégie d'étiquette préfixe suppose que tous les nœuds sont affectés à un ou plusieurs locataires et que les autorisations ne sont pas attribuées à la périphérie. Évitez d'utiliser cette stratégie sur les étiquettes de bord, car cela provoquera un grand nombre de prédicats et aura un impact négatif sur les performances de Neptune.

L'approche de l'étiquette par préfixe présente deux inconvénients principaux. Tout d'abord, il est difficile d'exécuter des requêtes qui concernent tous les locataires. Par exemple, une requête qui compte tous les nœuds d'une étiquette donnée à des fins de reporting ou de surveillance. Si tel est votre cas d'utilisation, envisagez de combiner cette stratégie avec la stratégie à étiquettes multiples. Pour plus d'informations sur la combinaison de stratégies, consultez la section sur le modèle hybride.

Deuxièmement, la stratégie du préfixe-étiquette nécessite des contrôles qui garantissent l'application correcte du préfixe approprié à chaque requête afin d'éviter les fuites de données. Cependant, cette stratégie est l'option la plus efficace pour les charges de travail qui nécessitent des requêtes à faible latence, et nous la recommandons vivement. La section Implications en termes de performances pour les modèles GPL fournit des exemples expliquant pourquoi il s'agit de la stratégie la plus efficace.

Stratégie multilabel

La troisième option consiste à utiliser une stratégie à étiquettes multiples. Pour cette approche, vous ajoutez des étiquettes supplémentaires à chaque nœud du graphe. Par exemple, si vous devez filtrer toutes les données d'un locataire donné, ajoutez l'étiquette d'identification du locataire. Si vous devez filtrer toutes les données d'une étiquette donnée, quel que soit le locataire, ajoutez cette étiquette. Le schéma suivant montre la stratégie à étiquettes multiples appliquée en utilisant trois étiquettes pour chaque nœud.

Vous pouvez désormais accéder au graphique en utilisant trois modèles différents :

En LPGs effet, il existe deux manières de le mettre en œuvre.

Dans Gremlin, vous pouvez utiliser la stratégie de traversée appelée SubgraphStrategypour limiter la portée de toutes les requêtes aux seuls sommets portant une étiquette spécifique, tels que : "Label1"

g.withStrategies(
    new SubgraphStrategy(
        vertices=hasLabel("Label1")
    )
)

Contrairement à PartitionStrategy cela, SubgraphStrategy cela a un impact sur la lecture des données uniquement, et non sur leur écriture. Pour écrire les données, attribuez manuellement les libellés à chaque requête :

g.addV("Label1").property("Value","XYZ123456")
.addV("Label2").property("Value","XYZ123456")

Lors de la lecture des données, vous pouvez les utiliser SubgraphStrategy pour interroger tous les nœuds avec "Label1" :

g.withStrategies(
new SubgraphStrategy(vertices=.hasLabel("Label1"))
).
V().has("Value","XYZ123456")

Neptune renvoie uniquement le premier enregistrement, dont la valeur est "Label1" égale à. "XYZ123456" C'est équivalent à la requête suivante, qui n'utilise pas SubgraphStrategy :

g.V().hasLabel("Label1").hasValue("XYZ123456")

Dans cette requête de base, il apparaît que SubgraphStrategy son utilisation est plus complexe. N'oubliez pas que vos bibliothèques peuvent fournir une instance g de la stratégie déjà définie. Les développeurs n'ont pas à s'assurer que les filtres appropriés sont appliqués :

def getGraphTraversal():
return g.withStrategies(new SubgraphStrategy(vertices=.hasLabel("Label1"))

getGraphTraversal().has("Value","XYZ123456")

Les bibliothèques OpenCypher n'ont pas ces structures, vous devez donc créer plusieurs étiquettes pour chaque nœud :

CREATE (n:`1`:`Label1`:`1-Label1` {`~id`: 'Item_1', Value: '12345'})

Lorsque vous utilisez ces étiquettes pour filtrer un sous-graphe, vous pouvez renvoyer des nœuds qui possèdent l'étiquette client que vous recherchez ou qui partagent une relation avec un autre nœud portant cette étiquette :

MATCH n=(:Label1:`1`)
// or
MATCH n=(:`1-Label1`)

La stratégie à étiquettes multiples vous donne la plus grande flexibilité pour interroger les nœuds par type (Label1) ou par locataire (1), ou pour utiliser la stratégie d'étiquette de préfixe la plus efficace lorsque les performances sont primordiales (). 1-Label1

Le principal inconvénient de cette stratégie est que chaque étiquette est un objet supplémentaire stocké dans votre graphique. Un objet est un nœud, une arête ou une propriété d'un nœud ou d'une arête LPGs. La vitesse d'ingestion est mesurée et limitée par le nombre d'objets par seconde, et les coûts de stockage dépendent du nombre de gigaoctets consommés. Cela signifie que des objets supplémentaires peuvent avoir un impact mesurable à grande échelle.

Implications en termes de performances pour les modèles GPL

Le cours Data Modeling for Amazon Neptune de AWS Skill Builder décrit en détail les aspects internes du modèle de données Neptune et ses implications en termes de modélisation, mais nous allons résumer ici les considérations importantes relatives à ces conceptions. Envisagez d'avoir trois locataires (T1, T2, T3) sur un seul cluster Neptune. Ces locataires possèdent les attributs suivants :

Exécutez une requête qui récupérera les objets pour Tenant 3 en utilisant la stratégie immobilière. Neptune inspecte les statistiques de deux appels d'index :

L'optimiseur de requêtes Neptune détermine qu'il est préférable d'appliquer cette dernière requête en premier (12 millions de résultats), puis inspecte chaque élément. tenant property key=T3 Vous récupérez 12 millions d'éléments pour trouver le million de résultats.

Notez l'impact bruyant de cette requête sur les voisins. Si vous aviez 100 millions de nœuds Item par locataire, la première requête aurait 300 millions de résultats au lieu de 12 millions (cela est trop simplifié à des fins d'illustration). L'optimiseur Neptune a peut-être appliqué un ordre d'opérations différent).

Ensuite, considérez la stratégie du préfixe-étiquette. Effectuez un seul appel d'index wherelabel=T3-Item, qui renvoie 1 million de résultats. Cela donne le même résultat que la stratégie immobilière, mais permet de récupérer 11 millions d'enregistrements de moins. De plus, vous n'avez plus à vous soucier des voisins bruyants, car l'étiquette ne se chevauche pas dans l'index.

La stratégie à étiquettes multiples n'améliore pas directement les performances des requêtes par rapport à la stratégie immobilière. Le filtrage par valeur de propriété est comparable au filtrage par valeur d'étiquette lorsque l'espace de recherche est également comparable. Au contraire, la stratégie à étiquettes multiples favorise une plus grande flexibilité.  La stratégie à étiquettes multiples fournit des performances équivalentes à la stratégie d'étiquette préfixe pour ou pour l'étiquette. label=T3 T3-Item La stratégie à labels multiples fournit des performances équivalentes à celles de la stratégie immobilière pour. label=Item L'avantage est de prendre en charge une variété de modèles d'accès.