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.
Bewährte Methoden für die Verwaltung von n:m-Beziehungen in DynamoDB-Tabellen
Adjazenzlisten stellen nützliche Designmuster für die Modellierung von Many-to-Many-Beziehungen in Amazon DynamoDB dar. Allgemein ausgedrückt, stellen sie eine Möglichkeit für die Darstellung von Diagrammdaten (Knoten und Edges) in DynamoDB dar.
Adjazenzlisten-Designmuster
Wenn es zwischen verschiedenen Entitäten in einer Anwendung Many-to-Many-Beziehungen gibt, 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 müssen die Rangfolge der Peers, die Beziehungen zwischen Entitäten und den Status der benachbarten Entitäten verstehen. Wenn Ihre Anwendung diese Arten von Workflows im Grafikstil verwendet, sollten Sie das folgende Schemaentwurfsmuster berücksichtigen.
Stellen Sie sich als Beispiel aus der Praxis eine Anwendung für soziale Netzwerke vor. In dieser Anwendung haben Menschen Beziehungen zu anderen Menschen, verfügen über Fähigkeiten, leben an Orten und haben zugehörige Daten (z. B. Geburtsdaten). Jede Person ist ein Knoten im Diagramm. Die Verbindungen zwischen Menschen, wie zum Beispiel Freundschaften, sind Kanten. Die Assoziationen zwischen Menschen und ihren Eigenschaften (Fähigkeiten, Orte, Daten) sind ebenfalls Kanten.
Mit dem materialisierten Grafikmuster können Sie sowohl Knoten als auch Kanten in einer einzigen DynamoDB-Tabelle speichern und Beziehungen effizient durchqueren. Die folgenden Diagramme zeigen, wie dieser Graph für soziale Netzwerke modelliert wird. Das erste Diagramm zeigt die primäre Tabellenstruktur. Die nachfolgenden Diagramme zeigen die globalen sekundären Indexprognosen.
Die Tabelle verwendet die folgende Schlüsselstruktur:
-
Partitionsschlüssel — Die Entitäts-ID (z. B.
Person-1,Person-2). Jede Partition enthält ein Knotenelement und mehrere Edge-Elemente. -
Sortierschlüssel — Für Knotenelemente die eigene ID der Entität. Bei Kantenelementen eine Kombination aus Kantentyp und Ziel (z. B.
Friend-Person-2oderSkill-DynamoDB).
Die Edge-Elemente enthalten ein Target- und ein Type-Attribut. Diese bilden den zusammengesetzten Schlüssel TypeTarget "", der Elemente in der Primärtabelle und im zweiten globalen Sekundärindex identifiziert. Zum Beispiel erzeugt "Person-1 ist mit Person-2" befreundetType=Friend,Target=Person-2, undTypeTarget=Friend-Person-2.
Der erste globale sekundäre Index basiert auf dem Attribut Data. Dieses Attribut verwendet die globale Überladung des sekundären Indexes, um mehrere Attributtypen innerhalb desselben Index zu indizieren:
-
Dates— Geburtsdaten, Beitrittsdaten (zum Beispiel)1971-12-21 -
Names— Namen anzeigen (zum BeispielAna Carolina Silva) -
Places— Standorte (zum BeispielSeattle) -
Skills— Kompetenzen (zum BeispielDynamoDB)
Sie können diesen einzigen globalen sekundären Index verwenden, um nach allen Personen abzufragen, die an einem bestimmten Datum geboren wurden, nach allen Personen an einem Ort oder nach allen Personen mit einer bestimmten Fähigkeit.
Der zweite globale sekundäre Index verwendet TypeTarget als Partitionsschlüssel für umgekehrte Suchvorgänge. Sie können beispielsweise alle Personen finden, die Person-2 als Freund gelistet sind, indem Sie nach suchen. TypeTarget=Friend-Person-2
Beim Einfügen von Elementen in die Tabelle können Sie eine intelligente Sharding-Strategie verwenden, um Elementgruppen mit großen Aggregationen (Geburtsdatum, Fähigkeit) auf so viele logische Partitionen in den globalen Sekundärindizes zu verteilen, wie nötig sind, um schwerwiegende Probleme zu vermeiden. read/write
Mit dieser Kombination von Entwurfsmustern erhalten Sie einen soliden Datenspeicher für hocheffiziente Grafik-Workflows in Echtzeit. Sie können damit leistungsstarke Abfragen zur Status- und Edge-Aggregation von Nachbarentitäten für Empfehlungsmaschinen, Anwendungen für soziale Netzwerke, Knotenrankings, Unterbaumaggregationen und andere gängige Anwendungsfälle für Graphen erstellen.
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 verbundene Datensätze abfragen oder mehrere Knoten (Multi-Hop-Abfragen) mit einer Latenz von Millisekunden durchqueren müssen, sollten Sie Amazon Neptune in Betracht ziehen. Amazon Neptune ist eine speziell entwickelte, leistungsstarke Graphdatenbank-Engine. Sie ist für das Speichern von Milliarden von Beziehungen und das Abfragen des Diagramms mit einer Latenz von Millisekunden optimiert.