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.

Beispiel für die Modellierung relationaler Daten in DynamoDB

In diesem Beispiel wird die Modellierung relationaler Daten in Amazon DynamoDB beschrieben. Das DynamoDB-Tabellendesign entspricht dem Schema für die Eingabe relationaler Bestellungen, das unter gezeigt wird. Relationale Modellierung Bei diesem Design werden mehrere spezialisierte Tabellen anstelle einer einzigen Adjazenzliste verwendet, wodurch klare betriebliche Grenzen geschaffen werden und gleichzeitig strategisch darauf geachtet wird, dass alle Zugriffsmuster effizient bedient GSIs werden.

Der Entwurfsansatz verwendet aggregationsorientierte Prinzipien, bei denen Daten auf der Grundlage von Zugriffsmustern und nicht anhand starrer Entitätsgrenzen gruppiert werden. Zu den wichtigsten Entwurfsentscheidungen gehören die Verwendung separater Tabellen für Entitäten mit geringer Zugriffskorrelation, das Einbetten verwandter Daten, wenn sie immer gemeinsam abgerufen werden, und die Verwendung von Elementsammlungen zur Identifizierung von Beziehungen.

Die folgenden Tabellen und die zugehörigen Indizes unterstützen das Schema der Eingabe in relationaler Reihenfolge:

Tabellendesign für Mitarbeiter

In der Tabelle „Employee“ werden Mitarbeiterinformationen in einer einzigen Einheit pro Element gespeichert. Sie ist für die direkte Suche nach Mitarbeitern optimiert und unterstützt mehrere Abfragemuster im strategischen GSIs Bereich. Diese Tabelle veranschaulicht das Prinzip, separate Tabellen für Entitäten mit unabhängigen betrieblichen Merkmalen und geringer objektübergreifender Zugriffskorrelation zu entwerfen.

Die Tabelle verwendet einen einfachen Partitionsschlüssel (employee_id) ohne Sortierschlüssel, da jeder Mitarbeiter eine eigene Entität ist. Vier GSIs ermöglichen effizientes Abfragen anhand verschiedener Attribute:

Tischdesign für Kunden

In der Kundentabelle werden Kundeninformationen mit strategischer Denormalisierung von account_rep_id gespeichert, um effiziente Abfragen von Kundenbetreuern zu ermöglichen. Bei dieser Entwurfswahl wird geringer Speicheraufwand gegen die Abfrageleistung abgewogen, sodass keine Verknüpfungen zwischen Kunden- und Kundenbetreuerdaten erforderlich sind.

Die Tabelle unterstützt mehrere Telefonnummern pro Kunde mithilfe eines Listenattributs, was die Schemaflexibilität von DynamoDB demonstriert. Die einheitliche GSI ermöglicht Workflows für Kundenbetreuer:

Tischdesign bestellen

Die Bestelltabelle verwendet eine vertikale Partitionierung mit separaten Elementen für Auftragskopfe und Auftragspositionen. Dieses Design ermöglicht effiziente produktbasierte Abfragen, wobei alle Bestellkomponenten für einen effizienten Zugriff innerhalb derselben Partition beibehalten werden. Jede Bestellung besteht aus mehreren Artikeln:

Die Tabelle beinhaltet die strategische Denormalisierung von account_rep_id (dupliziert aus der Kundentabelle), um direkte Anfragen von Kundenbetreuern zu ermöglichen, ohne dass Kundenanfragen erforderlich sind. Für Schreibszenarien mit hohem Durchsatz enthalten OPEN-Bestellungen Status- und Shard-Attribute, um Schreib-Sharding über mehrere Partitionen hinweg zu ermöglichen.

Vier GSIs unterstützen unterschiedliche Abfragemuster mit optimierten Prognosen:

Design von Produkttabellen

Die Produkttabelle verwendet das Artikelsammlungsmuster, um sowohl Produktmetadaten als auch Inventardaten in derselben Partition zu speichern. Dieses Design nutzt die identifizierende Beziehung zwischen Produkten und Inventar — Inventar kann ohne ein übergeordnetes Produkt nicht existieren. Durch die Verwendung von pk=Product_ID mit SK=Product_ID für Produktmetadaten und sk=Warehouse_ID für Inventarartikel entfällt die Notwendigkeit einer separaten Inventartabelle und eines globalen Index, wodurch die Kosten um etwa 50% gesenkt werden.

Dieses Muster ermöglicht effiziente Abfragen sowohl für den individuellen Lagerbestand (GetItem mit zusammengesetztem Schlüssel) als auch für den gesamten Lagerbestand eines Produkts (Abfrage nach Partitionsschlüssel). Das Attribut total_inventory im Produktmetadatenelement ermöglicht eine denormalisierte Aggregation für eine schnelle Suche nach dem Gesamtbestand.

Jede Tabelle ist mit spezifischen globalen sekundären Indizes (GSIs) ausgestattet, um die erforderlichen Zugriffsmuster effizient zu unterstützen. Das Design verwendet aggregationsorientierte Prinzipien mit strategischer Denormalisierung und spärlicher Indexierung, um sowohl die Leistung als auch die Kosten zu optimieren.

Zu den wichtigsten Designoptimierungen gehören:

Schließlich können Sie die Zugriffsmuster erneut aufrufen, die zuvor definiert wurden. Die folgende Tabelle zeigt, wie jedes Zugriffsmuster effizient unterstützt wird, wenn das Multi-Tabellen-Design mit Strategic verwendet wird. GSIs Jedes Muster verwendet entweder direkte Schlüsselabfragen oder einzelne GSI-Abfragen, wodurch teure Scans vermieden und eine konsistente Leistung in jeder Größenordnung gewährleistet wird.