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.
Adjazenzlisten sind ein Entwurfsmuster, das für die Modellierung von many-to-many Beziehungen in Amazon DynamoDB nützlich ist. Allgemein ausgedrückt, stellen sie eine Möglichkeit für die Darstellung von Diagrammdaten (Knoten und Edges) in DynamoDB dar.
Adjazenzlisten-Designmuster
Wenn zwischen verschiedenen Entitäten einer Anwendung eine many-to-many Beziehung besteht, kann die Beziehung als Adjazenzliste modelliert werden. In diesem Muster werden alle Entitäten auf der obersten Ebene (synonym mit den Knoten im Diagrammmodell) mithilfe des Partitionsschlüssels dargestellt. Beziehungen mit anderen Entitäten (Edges in einem Diagramm) werden als Elemente innerhalb der Partition dargestellt, indem der Wert des Sortierschlüssels auf die ID der Zielentität (des Zielknotens) eingestellt wird.
Zu den Vorteilen dieses Musters gehören eine minimale Datenduplizierung und vereinfachte Abfragemuster, um alle Entitäten (Knoten) zu finden, die sich auf eine Zielentität beziehen (d. h., ein Edge zu einem Zielknoten besitzen).
Ein Beispiel aus der Praxis, für das dieses Muster nützlich ist, ist ein Rechnungssystem, bei dem Rechnungen mehrere Abrechnungen umfassen können. Eine Abrechnung kann zu mehreren Rechnungen gehören. Der Partitionsschlüssel in diesem Beispiel ist entweder eine InvoiceID oder eine BillID. BillID-Partitionen besitzen alle für Rechnungen spezifischen Attribute. InvoiceID-Partitionen enthalten ein Element zum Speichern rechnungsspezifischer Attribute und ein Element für jede BillID, die zu dieser Rechnung führt.
Das Schema sieht wie folgt aus.
Anhand des vorangehenden Schemas können Sie sehen, dass alle Abrechnungen für eine Rechnung mittels des primären Schlüssels für die Tabelle abgefragt werden können. Um alle Rechnungen nachzuschlagen, die einen Teil einer Abrechnung enthalten, erstellen Sie einen globalen sekundären Index für den Sortierschlüssel der Tabelle.
Die Projektionen für den globalen sekundären Index sehen wie folgt aus.
Materialisiertes Diagrammmuster
Viele Anwendungen werden auf der Basis der Kenntnis von Peer-Rangstufen, der allgemeinen Beziehungen zwischen Entitäten, des Status benachbarter Entitäten und anderer Arten von Diagramm-Workflows erstellt. Für diese Arten von Anwendungen sollten Sie die folgenden Schemadesignmuster berücksichtigen.
Das vorangehende Schema zeigt eine Diagrammdatenstruktur, die durch einen Satz von Datenpartitionen definiert wird, die die Elemente enthalten, welche die Edges und Knoten des Diagramms definieren. Die Edge-Elemente enthalten ein Target- und ein Type-Attribut. Diese Attribute werden als Teil eines zusammengesetzten Schlüsselnamens "TypeTarget" verwendet, um das Element in einer Partition in der Primärtabelle oder in einem zweiten globalen Sekundärindex zu identifizieren.
Der erste globale sekundäre Index basiert auf dem Attribut Data. Dieses Attribut verwendet Überladungen des globalen sekundären Index wie zuvor beschrieben, um verschiedene Attributtypen zu indizieren, d. h. Dates, Names, Places und Skills. Hier indiziert ein einziger globaler sekundärer Index effektiv vier verschiedene Attribute.
Wenn Sie in die Tabelle Elemente einfügen, können Sie eine intelligente Sharding-Strategie verwenden, um Elementsätze mit großen Aggregationen (Geburtsdaten, Qualifikationen) über so viele logische Partitionen in den globalen sekundären Indizes wie nötig zu verteilen, um Probleme mit Hot-Lese-/Schreibvorgängen zu vermeiden.
Das Ergebnis dieser Kombination von Designmustern ist ein robuster Datenspeicher für hoch effiziente Diagramm-Workflows, die in Echtzeit ausgeführt werden. Diese Workflows können hoch leistungsfähige Abfragen zum Status benachbarter Entitäten und zur Edge-Aggregation für Empfehlungsmodule, soziale Netzwerke, Knoteneinstufungen, Unterstrukturaggregationen und andere häufige Anwendungsfälle für Diagramme bereitstellen.
Wenn Ihr Anwendungsfall unempfindlich gegenüber der Konsistenz von Echtzeitdaten ist, können Sie einen geplanten Amazon-EMR-Prozess verwenden, um Edges mit relevanten Übersichtsaggregationen für Diagramme für Ihre Workflows aufzufüllen. Wenn Ihre Anwendung nicht sofort wissen muss, wenn dem Diagramm ein Edge hinzugefügt wird, können Sie einen geplanten Prozess verwenden, um die Ergebnisse zu aggregieren.
Um einen gewissen Grad an Konsistenz zu wahren, kann das Design Amazon DynamoDB Streams und AWS Lambda für die Verarbeitung von Edge-Aktualisierungen umfassen. Sie könnte auch einen Amazon-EMR-Auftrag verwenden, um die Ergebnisse in regelmäßigen Abständen zu validieren. Dieser Ansatz wird im folgenden Diagramm gezeigt. Er wird häufig für soziale Netzwerke verwendet, wenn die Kosten für Echtzeitabfragen hoch sind und die Notwendigkeit, einzelne Benutzerupdates sofort zu erkennen, gering ist.
IT-Servicemanagement (ITSM)- und Sicherheitsanwendungen müssen im Allgemeinen in Echtzeit auf Änderungen des Zustands von Entitäten reagieren, die aus komplexen Edge-Aggregationen bestehen. Diese Anwendungen benötigen ein System, das in Echtzeit Aggregationen mehrerer Knoten aus Beziehungen auf der zweiten und dritten Ebene oder komplexe Edge-Traversals unterstützen. Wenn Ihr Anwendungsfall diese Arten von Workflows für Diagrammabfragen in Echtzeit erfordert, empfehlen wir Ihnen, für die Verwaltung dieser Workflows die Verwendung von Amazon Neptune in Betracht zu ziehen.
Anmerkung
Wenn Sie stark vernetzte Datensätze abfragen oder Abfragen ausführen müssen, die mehrere Knoten (auch Multi-Hop-Abfragen genannt) mit Millisekunden-Latenz durchlaufen müssen, sollten Sie die Verwendung von Amazon Neptune in Betracht ziehen. Amazon Neptune ist eine speziell entwickelte, hochleistungsfähige Graphdatenbank-Engine, die für die Speicherung von Milliarden von Beziehungen und die Abfrage des Graphen bzw. des Diagramms mit einer Latenzzeit von Millisekunden optimiert ist.
