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 von Kollegen, 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 Personen Beziehungen zu anderen Personen, besitzen Fähigkeiten, leben an Orten und haben zugehörige Daten (z. B. Geburtsdaten). Jede Person ist ein Knoten in der Grafik. Die Verbindungen zwischen Menschen, wie beispielsweise Freundschaften, sind Kanten. Die Assoziationen zwischen Menschen und ihren Eigenschaften (Fähigkeiten, Orte, Daten) sind ebenfalls Kanten.
Mit dem materialisierten Diagrammmuster können Sie sowohl Knoten als auch Kanten in einer einzigen DynamoDB-Tabelle speichern und Beziehungen effizient durchqueren. Die folgenden Diagramme zeigen, wie dieses Diagramm für soziale Netzwerke modelliert wird. Das erste Diagramm zeigt die primäre Tabellenstruktur. Die nachfolgenden Diagramme zeigen die globalen Prognosen für den sekundären Index.
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 Node-Elemente 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. Beispielsweise erzeugt ", wenn" mit Person-2 "befreundet Person-1 ist Type=FriendTarget=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 Indexes 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ärindex verwenden, um alle Personen abzufragen, die an einem bestimmten Datum geboren wurden, alle Personen an einem Ort oder alle Personen mit einer bestimmten Fähigkeit.
Der zweite globale sekundäre Index wird TypeTarget als Partitionsschlüssel für Reverse-Lookups verwendet. Beispielsweise können Sie alle Personen finden, die sich Person-2 als Freund registrieren, indem Sie nach abfragen. TypeTarget=Friend-Person-2
Beim Einfügen von Elementen in die Tabelle können Sie mithilfe einer intelligenten Sharding-Strategie Elementgruppen mit großen Aggregationen (Geburtsdatum, Qualifikation) auf so viele logische Partitionen in den globalen Sekundärindizes verteilen, wie nötig sind, um aktuelle 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 es verwenden, um 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 Grafiken zu 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 miteinander verbundene Datensätze abfragen oder mehrere Knoten (Multi-Hop-Abfragen) mit einer Latenz von Millisekunden durchlaufen müssen, sollten Sie Amazon Neptune in Betracht ziehen. https://docs.aws.amazon.com/neptune/latest/userguide/ Amazon Neptune ist eine speziell entwickelte, leistungsstarke Graphdatenbank-Engine. Sie ist für das Speichern von Milliarden von Beziehungen und das Abfragen des Graphen mit einer Latenz von Millisekunden optimiert.