Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Poolmodell für beschriftete Eigenschaftsdiagramme

Es gibt drei verschiedene Ansätze für das Poolmodell für LPGs auf Amazon Neptune:

Immobilienstrategie

Mit LPGs können Benutzer Schlüssel-Wert-Paar-Eigenschaften zu Knoten, Scheitelpunkten und Kanten hinzufügen. Um eine logische Trennung zu erreichen, modellieren die meisten Kunden dies intuitiv als eine einzigartige Eigenschaft an jedem Knoten und jeder Kante mit einem gemeinsamen Eigenschaftsschlüssel für den Mandanten. Der Eigenschaftsschlüssel des Mandanten steht für alle Mandanten, denen der Knoten gehört. Die Mandanten-ID ist ein eindeutiger Wert, der einen einzelnen Mandanten identifiziert.

Das folgende Diagramm zeigt dieses Modell. Die beiden getrennten Teilgraphen haben verschiedene beschriftete Knoten und Kanten, wobei der Eigenschaftsschlüssel des Mandanten durch dargestellt wird. TId Jeder Knoten und jede Kante eines Untergraphen hat den Wert. TId 1 Im anderen Untergraphen hat jeder Knoten und jede Kante den TId Wert. 2

In beschrifteten Eigenschaftsdiagrammen gibt es zwei Möglichkeiten, dies zu verwalten. Die Gremlin-Abfragesprache bietet die PartitionStrategyTraversal-Bibliothek, mit deren Hilfe die Datenpartitionierung der Daten verwaltet werden kann. Der Code im folgenden Beispiel geht davon aus, dass jeder Knoten und jede Kante eine Eigenschaft mit dem Namen hat: TId

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

Wenn neue Knoten oder Kanten geschrieben werden, "TId" wird der Eigenschaft der Wert "1" oder hinzugefügt"2", je nachdem, ob strategy1 oder ausgewählt strategy2 wurde. Für den Kunden mit "TId" of "1" verwenden Siestrategy1. Das folgende Beispiel zeigt, wie Daten für diesen Kunden geschrieben werden:

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

Bei Leseabfragen "TId == '2'" wird jedem Knoten "TId == '1'" oder jeder Kantendurchquerung ein Filter für oder hinzugefügtstrategy2, indem jeweils strategy1 oder verwendet wird. Diese Partitionsstrategien vereinfachen Ihren Code, sind aber nicht notwendig. Der Vorteil dieser Strategie besteht darin, dass sie auf einer Autorisierungsebene eingefügt und an den Code auf niedrigerer Ebene übergeben werden kann, der die Abfrage bildet. Dadurch wird der Code, der die Kunden-ID (TId) bestimmt, von der Logik der Abfrage getrennt.

Der folgende Beispielcode zeigt eine Gremlin-Abfrage zum Lesen von Daten:

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

Der vorherige Code entspricht dem folgenden Beispiel:

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

Ebenso können Sie beim Schreiben von Daten mithilfe von Gremlin die folgende Abfrage verwenden:

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

Der obige Code entspricht dem folgenden Beispiel, das die Partitionsstrategie nicht verwendet und daher erfordert, dass die "TId" Eigenschaft explizit geschrieben wird:

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

In OpenCypher existieren diese Bibliotheken nicht. Sie sind dafür verantwortlich, Ihre Abfragen zu schreiben und zu ändern, um die Mandanten-ID als Eigenschaft an Knoten und Kanten hinzuzufügen. Beispiel:

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

Beachten Sie die Ähnlichkeit zwischen dem Gremlin-Code ohne die Partitionsstrategie. Sie können dann den aus der ersten CREATE Anweisung geschriebenen Knoten lesen, indem Sie den folgenden Code verwenden:

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

Sie können die Eigenschaftsstrategie wählen, wenn Sie native TinkerPop Gremlin-Konstrukte wie verwenden möchten. PartitionStrategy Dieses Modell weist bei Amazon Neptune jedoch Leistungseinbußen im Vergleich zur Präfix-Label-Strategie auf. Eine Erläuterung dieser Leistungseinbußen finden Sie im Abschnitt Auswirkungen auf die Leistung der LPG-Modelle.

Wenn die folgenden Bedingungen zutreffen, sollten Sie erwägen, die Eigenschaftsstrategie nur an Knoten und nicht an Kanten zu modellieren:

Strategie mit Präfix-Bezeichnungen

Wenn Leistung ein Hauptanliegen ist, empfehlen wir dringend, die Präfix-Label-Strategie der Immobilienstrategie vorzuziehen.

Bei der Präfix-Label-Strategie kennzeichnen Sie jeden Knoten mit einer Kombination aus Mandanten-ID und Knotenbezeichnung. Wenn der Mandant beispielsweise eine Kennung von hat "1" und die Knotenbezeichnung lautet"Label1", geben Sie die Knotenbezeichnung als an. "1-Label1" Das folgende Diagramm zeigt zwei getrennte Untergraphen, die dieses Modell verwenden.

Wenn Sie Daten in Gremlin schreiben, können Sie der Bezeichnung eines beliebigen Knotens eine Identifikationsnummer hinzufügen:

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

Wenn Sie dieses Diagramm abfragen, können Sie überprüfen, ob dieses Präfix auf einem Knoten existiert:

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

In OpenCypher können Sie Daten schreiben, indem Sie eine Anweisung verwenden: CREATE

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

Um die Daten abzufragen, die Sie in OpenCypher geschrieben haben, verwenden Sie den folgenden Code:

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

Die Präfix-Label-Strategie geht davon aus, dass alle Knoten einem oder mehreren Mandanten zugewiesen sind und dass im Edge-Bereich keine Berechtigungen zugewiesen werden. Vermeiden Sie es, diese Strategie bei Kantenbeschriftungen zu verwenden, da dies zu einer großen Anzahl von Prädikaten führt und sich negativ auf die Leistung von Neptune auswirkt.

Der Präfix-Label-Ansatz hat zwei Hauptnachteile. Erstens ist es schwierig, Abfragen auszuführen, die sich über mehrere Mandanten erstrecken. Ein Beispiel ist eine Abfrage, bei der alle Knoten eines bestimmten Labels für die Berichterstattung oder Überwachung gezählt werden. Wenn dies Ihr Anwendungsfall ist, sollten Sie erwägen, diese Strategie mit der Strategie für mehrere Labels zu kombinieren. Weitere Informationen zur Kombination von Strategien finden Sie im Abschnitt Hybridmodell.

Zweitens erfordert die Präfix-Label-Strategie Kontrollen, die die korrekte Anwendung des entsprechenden Präfixes auf jede Abfrage erzwingen, um Datenlecks zu verhindern. Diese Strategie ist jedoch die effizienteste Option für Workloads, die Abfragen mit niedriger Latenz erfordern, und wir empfehlen sie dringend. Der Abschnitt Auswirkungen auf die Leistung von LPG-Modellen enthält Beispiele dafür, warum diese Strategie die effizienteste ist.

Strategie mit mehreren Labels

Die dritte Option besteht darin, eine Strategie mit mehreren Bezeichnungen zu verwenden. Bei diesem Ansatz fügen Sie jedem Knoten im Diagramm zusätzliche Beschriftungen hinzu. Wenn Sie beispielsweise alle Daten für einen bestimmten Mandanten filtern müssen, fügen Sie das Mandanten-ID-Label hinzu. Wenn Sie alle Daten für ein bestimmtes Label unabhängig vom Mandanten filtern müssen, fügen Sie dieses Label hinzu. Das folgende Diagramm zeigt die Strategie mit mehreren Bezeichnungen, die angewendet wird, indem für jeden Knoten drei Labels verwendet werden.

Sie können jetzt mithilfe von drei verschiedenen Mustern auf das Diagramm zugreifen:

Denn LPGs es gibt zwei Möglichkeiten, dies zu implementieren.

In Gremlin können Sie die Traversal-Strategie verwenden, die aufgerufen wird, SubgraphStrategyum den Umfang aller Abfragen auf Scheitelpunkte mit einer bestimmten Bezeichnung zu beschränken, wie zum Beispiel: "Label1"

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

Im Gegensatz dazu SubgraphStrategy wirkt PartitionStrategy sich dies nur auf das Lesen von Daten aus, nicht auf das Schreiben von Daten. Um die Daten zu schreiben, weisen Sie die Beschriftungen in jeder Abfrage manuell zu:

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

Beim Lesen der Daten können Sie SubgraphStrategy alle Knoten abfragen mit"Label1":

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

Neptune gibt nur den ersten Datensatz zurück, der einen Wert von hat"Label1". "XYZ123456" Dies entspricht der folgenden Abfrage, die nicht verwendet: SubgraphStrategy

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

In dieser einfachen Abfrage scheint die SubgraphStrategy Verwendung komplexer zu sein. Denken Sie daran, dass Ihre Bibliotheken eine Instanz von g mit der bereits definierten Strategie bereitstellen können. Entwickler müssen nicht sicherstellen, dass die richtigen Filter angewendet werden:

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

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

Die OpenCypher-Bibliotheken haben diese Konstrukte nicht, daher müssen Sie mehrere Labels für jeden Knoten erstellen:

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

Wenn Sie diese Labels verwenden, um nach einem Untergraphen zu filtern, können Sie Knoten zurückgeben, die das Kundenlabel haben, nach dem Sie suchen, oder die eine Beziehung zu einem anderen Knoten haben, der dieses Label trägt:

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

Die Strategie mit mehreren Labels bietet Ihnen die größte Flexibilität, um Knoten nach Typ (Label1) oder Mandant (1) abzufragen oder die effizientere Präfix-Label-Strategie zu verwenden, wenn die Leistung am wichtigsten ist (). 1-Label1

Der größte Nachteil dieser Strategie besteht darin, dass jedes Label ein zusätzliches Objekt ist, das in Ihrem Diagramm gespeichert ist. Ein Objekt ist ein Knoten, eine Kante oder eine Eigenschaft an einem Knoten oder einer Kante in LPGs. Die Aufnahmegeschwindigkeit wird anhand von Objekten pro Sekunde gemessen und festgelegt, und die Speicherkosten hängen von der Anzahl der verbrauchten Gigabyte ab. Das bedeutet, dass zusätzliche Objekte in großem Maßstab messbare Auswirkungen haben können.

Auswirkungen auf die Leistung der LPG-Modelle

Der AWS Skill Builder-Kurs Datenmodellierung für Amazon Neptune beschreibt ausführlich die internen Grundlagen des Neptun-Datenmodells und die Auswirkungen auf die Modellierung. Die wichtigen Überlegungen zu diesen Designs werden wir hier jedoch zusammenfassen. Erwägen Sie, drei Mandanten (T1, T2, T3) auf einem einzigen Neptun-Cluster zu haben. Diese Mandanten haben die folgenden Attribute:

Führen Sie mithilfe der Eigenschaftenstrategie eine Abfrage aus, mit der die Elemente für Mandant 3 abgerufen werden. Neptune untersucht die Statistiken für zwei Indexaufrufe:

Der Neptune-Abfrageoptimierer stellt fest, dass die letztere Abfrage am besten zuerst angewendet werden sollte (12 Millionen Ergebnisse), und überprüft dann jedes Element darauf. tenant property key=T3 Sie rufen 12 Millionen Elemente ab, um die 1 Million Ergebnisse zu finden.

Beachten Sie, dass sich diese Abfrage auf die Nebengeräusche auswirkt. Wenn Sie 100 Millionen Elementknoten pro Mandant hätten, hätte die erste Abfrage 300 Millionen Ergebnisse statt 12 Millionen (Dies ist zur Veranschaulichung zu stark vereinfacht. Der Neptune-Optimierer hat möglicherweise eine andere Reihenfolge der Operationen angewendet).

Betrachten Sie als Nächstes die Präfix-Label-Strategie. Führen Sie einen einzelnen Indexaufruf where durchlabel=T3-Item, der 1 Million Ergebnisse zurückgibt. Dadurch wird das gleiche Ergebnis wie mit der Property-Strategie erzielt, es werden jedoch 11 Millionen weniger Datensätze abgerufen. Außerdem haben Sie keine Probleme mehr mit lauter Nachbarschaft, da sich die Bezeichnung im Index nicht überschneidet.

Die Strategie mit mehreren Labels bietet keine direkte Verbesserung der Abfrageleistung im Vergleich zur Eigenschaftenstrategie. Das Filtern nach Eigenschaftswert ist mit dem Filtern nach Labelwert vergleichbar, wenn auch der Suchraum vergleichbar ist. Stattdessen unterstützt die Strategie mit mehreren Labels mehr Flexibilität.  Die Strategie mit mehreren Labels bietet eine Leistung, die der Präfix-Label-Strategie für oder das Etikett entspricht. label=T3 T3-Item Die Strategie mit mehreren Labels bietet eine Leistung, die der Immobilienstrategie für entspricht. label=Item Der Vorteil besteht darin, dass eine Vielzahl von Zugriffsmustern unterstützt wird.