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.
Erste Schritte für die Modellierung relationaler Daten in DynamoDB
Anmerkung
Das NoSQL-Design erfordert einen anderen Ansatz als das RDBMS-Design. Sie können ein standardisiertes Datenmodell für ein RDBMS entwickeln, ohne sich Gedanken über Zugriffsmuster machen zu müssen. Anschließend können Sie es erweitern, wenn neue Fragen und Abfrageanforderungen entstehen. Im Fall von Amazon DynamoDB sollten Sie jedoch nicht mit der Entwicklung Ihres Schemas beginnen, bis Sie die Fragen kennen, die es beantworten können muss. Es ist daher äußerst wichtig, die Business-Probleme und Anwendungsfälle vor der Entwicklung des Schemas zu kennen.
Um mit dem Entwerfen einer DynamoDB-Tabelle zu beginnen, die effizient skaliert werden kann, müssen Sie zunächst mehrere Schritte ausführen, um die Zugriffsmuster zu identifizieren, die von den Betriebs- und Geschäftsunterstützungssystemen (OSS/BSS) benötigt werden, die unterstützt werden müssen:
Im Fall neuer Anwendungen sollten Sie Berichte von Benutzern zu Aktivitäten und Zielen prüfen. Dokumentieren Sie die von Ihnen identifizierten Anwendungsfälle und analysieren Sie die von diesen benötigten Zugriffsmuster.
Analysieren Sie im Fall vorhandener Anwendungen die Abfrageprotokolle, um festzustellen, wie das System zurzeit verwendet wird und was die wichtigsten Zugriffsmuster sind.
Nach dem Abschluss dieses Vorgangs sollten Sie über eine Liste verfügen, die ungefähr wie die folgende aussieht.
| Muster # | Beschreibung des Zugriffsmusters |
|---|---|
| 1 | Suchen von Mitarbeiterdetails nach Mitarbeiter-ID |
| 2 | Mitarbeiterdetails nach Mitarbeiternamen abfragen |
| 3 | Finden Sie die Telefonnummer (n) eines Mitarbeiters |
| 4 | Finden Sie die Telefonnummer (n) eines Kunden |
| 5 | Bestellungen für Kunden innerhalb des Datumsbereichs abrufen |
| 6 | Alle offenen Bestellungen innerhalb des Datumsbereichs anzeigen |
| 7 | Alle kürzlich eingestellten Mitarbeiter anzeigen |
| 8 | Finden Sie alle Mitarbeiter im Warehouse |
| 9 | Holen Sie sich alle Artikel auf Bestellung für das Produkt |
| 10 | Besorgen Sie sich Inventare für das Produkt in allen Lagern |
| 11 | Holen Sie sich Kunden nach Kundenbetreuern |
| 12 | Bestellungen nach Kundenbetreuern abrufen |
| 13 | Holen Sie sich Mitarbeiter mit Berufsbezeichnung |
| 14 | Holen Sie sich den Lagerbestand nach Produkt und Lager |
| 15 | Holen Sie sich den gesamten Produktbestand |
In einer echten Anwendung könnte Ihre Liste sehr viel länger sein. Diese Liste ist jedoch beispielhaft für die Komplexität der Abfragemuster, denen Sie in einer Produktionsumgebung begegnen können.
Ein moderner Ansatz für das DynamoDB-Schemadesign verwendet aggregationsorientierte Prinzipien, bei denen Daten auf der Grundlage von Zugriffsmustern und nicht auf starren Entitätsgrenzen gruppiert werden. Bei diesem Ansatz werden mehrere Entwurfsmuster berücksichtigt:
Einzeltabellendesign — Verwendung zusammengesetzter Sortierschlüssel, überladener globaler Sekundärindizes und Adjazenzlistenmuster zum Speichern mehrerer Entitätstypen in einer Tabelle
Design mit mehreren Tabellen — Verwendung separater Tabellen für Entitäten mit unabhängigen Betriebsmerkmalen und geringer Zugriffskorrelation, strategisch wichtig für entitätsübergreifende Abfragen GSIs
Aggregiertes Design — Einbetten verwandter Daten, wenn sie immer gemeinsam abgerufen werden (Bestellung + OrderItems), oder Verwendung von Artikelsammlungen zur Identifizierung von Beziehungen (Produkt + Inventar)
Die Wahl zwischen diesen Ansätzen hängt von Ihren spezifischen Zugriffsmustern, Datenmerkmalen und betrieblichen Anforderungen ab. Sie können diese Elemente verwenden, um die Daten so zu strukturieren, dass eine Anwendung mittels einer einzigen Abfrage für eine Tabelle oder einen Index alle für ein bestimmtes Zugriffsmuster benötigten Informationen abrufen kann.
Anmerkung
Die Wahl zwischen Einzeltabellendesign und Mehrtabellendesign hängt von Ihren spezifischen Anforderungen ab. Das Design mit einer Tabelle eignet sich gut, wenn Entitäten eine hohe Zugriffskorrelation und ähnliche Betriebsmerkmale aufweisen. Das Design mit mehreren Tabellen wird bevorzugt, wenn Entitäten unabhängige betriebliche Anforderungen haben, unterschiedliche Zugriffsmuster haben oder wenn Sie klare betriebliche Grenzen benötigen. Das Beispiel in diesem Leitfaden veranschaulicht einen Ansatz mit mehreren Tabellen mit strategischer Aggregation und Denormalisierung.
Informationen zur Verwendung von NoSQL Workbench für DynamoDB zur Visualisierung Ihres Partitionsschlüsseldesigns finden Sie unter Erstellen von Datenmodellen mit NoSQL Workbench.
