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 Modellierung relationaler Daten in DynamoDB
Dieser Abschnitt erläutert bewährte Methoden für die Modellierung relationaler Daten in Amazon DynamoDB. Zunächst stellen wir traditionelle Konzepte der Datenmodellierung vor. Anschließend beschreiben wir die Vorteile der Verwendung von DynamoDB gegenüber herkömmlichen relationalen Datenbankmanagementsystemen — und wie dadurch Betriebsabläufe überflüssig werden und der Overhead reduziert wird. JOIN
Anschließend erläutern wir, wie Sie eine DynamoDB-Tabelle entwerfen, die effizient skaliert werden kann. Schließlich geben wir ein Beispiel für die Modellierung relationaler Daten in DynamoDB.
Themen
Traditionelle relationale Datenbankmodelle
Ein herkömmliches relationales Datenbankmanagementsystem (RDBMS) speichert Daten in einer normalisierten relationalen Struktur. Das Ziel des relationalen Datenmodells besteht darin, die Duplizierung von Daten (durch Normalisierung) zu reduzieren, um die referentielle Integrität zu unterstützen und Datenanomalien zu verringern.
Das folgende Schema ist ein Beispiel für ein relationales Datenmodell für eine generische Auftragserfassungsanwendung. Die Anwendung unterstützt ein Personalschema, das die betrieblichen und geschäftlichen Unterstützungssysteme eines imaginären Fertigungsunternehmens unterstützt.
Als nicht-relationaler Datenbankservice bietet DynamoDB viele Vorteile gegenüber herkömmlichen relationalen Datenbankmanagementsystemen.
Wie DynamoDB Betriebsabläufe überflüssig macht JOIN
An RDBMS verwendet eine Strukturabfragesprache (SQL), um Daten an die Anwendung zurückzugeben. Aufgrund der Normalisierung des Datenmodells erfordern solche Abfragen in der Regel die Verwendung des JOIN-Operators, um Daten aus einer oder mehreren Tabellen zu kombinieren.
Um beispielsweise eine Liste von Bestellartikeln zu generieren, sortiert nach der Menge, die in allen Lagern vorrätig ist, die jeden Artikel versenden können, könnten Sie die folgende SQL Abfrage für das vorherige Schema ausführen.
SELECT * FROM Orders
INNER JOIN Order_Items ON Orders.Order_ID = Order_Items.Order_ID
INNER JOIN Products ON Products.Product_ID = Order_Items.Product_ID
INNER JOIN Inventories ON Products.Product_ID = Inventories.Product_ID
ORDER BY Quantity_on_Hand DESCSQLAbfragen dieser Art können einen flexiblen Zugriff API auf Daten bieten, erfordern jedoch einen erheblichen Verarbeitungsaufwand. Jeder Join in der Abfrage erhöht die Laufzeitkomplexität der Abfrage, da die Daten für jede Tabelle zwischengespeichert und dann zusammengestellt werden müssen, um die Ergebnismenge zurückzugeben.
Weitere Faktoren, die sich auf die Dauer der Ausführung der Abfragen auswirken können, sind die Größe der Tabellen und die Frage, ob die zu verknüpfenden Spalten Indizes haben. Die vorangehende Abfrage initiiert komplexe Abfragen für mehrere Tabellen und sortiert anschließend die Ergebnismenge.
Die Eliminierung der Notwendigkeit von JOINs ist das Herzstück von No SQL Data Modeling. Aus diesem Grund haben wir DynamoDB zur Unterstützung von Amazon.com entwickelt und aus diesem Grund bietet DynamoDB in jeder Größenordnung konsistente Leistung. Angesichts der Komplexität von SQL Abfragen und JOINs zur Laufzeit ist die RBDMS Leistung bei Skalierung nicht konstant. Dies führt zu Leistungsproblemen, wenn Kundenanwendungen wachsen.
Durch die Normalisierung von Daten wird zwar die Menge der auf der Festplatte gespeicherten Daten reduziert, doch häufig sind CPU Zeit und Netzwerklatenz die am stärksten eingeschränkten Ressourcen, die sich auf die Leistung auswirken.
DynamoDB wurde entwickelt, um beide Einschränkungen zu minimieren, indem JOINs wegfallen (und die Denormalisierung von Daten gefördert wird) und die Datenbankarchitektur optimiert wird, um eine Anwendungsabfrage mit einer einzigen Anforderung an ein Element vollständig zu beantworten. Diese Eigenschaften ermöglichen es DynamoDB, in jeder Größenordnung eine Leistung im einstelligen Millisekundenbereich zu bieten. Dies liegt daran, dass die Laufzeitkomplexität für DynamoDB-Operationen unabhängig von der Datengröße bei häufigen Zugriffsmustern konstant ist.
So verringern DynamoDB-Transaktionen den Aufwand für den Schreibprozess
Ein weiterer Faktor, der die Geschwindigkeit verlangsamen kann, RDBMS ist die Verwendung von Transaktionen zum Schreiben in ein normalisiertes Schema. Wie im Beispiel gezeigt, müssen relationale Datenstrukturen, die von den meisten Anwendungen zur Online-Transaktionsverarbeitung (OLTP) verwendet werden, aufgeschlüsselt und auf mehrere logische Tabellen verteilt werden, wenn sie in einer gespeichert werden. RDBMS
Daher ist ein ACID -konformes Transaktionsframework erforderlich, um Wettbewerbsbedingungen und Datenintegritätsprobleme zu vermeiden, die auftreten könnten, wenn eine Anwendung versucht, ein Objekt zu lesen, das gerade geschrieben wird. Ein solches Transaktions-Framework kann in Verbindung mit einem relationalen Schema den Schreibprozess deutlich aufwendiger machen.
Die Implementierung von Transaktionen in DynamoDB verhindert häufige Skalierungsprobleme, die bei einem auftreten. RDBMS DynamoDB tut dies, indem es eine Transaktion als einen einzigen API Aufruf ausgibt und die Anzahl der Elemente begrenzt, auf die in dieser einzelnen Transaktion zugegriffen werden kann. Lang andauernde Transaktionen können zu Betriebsproblemen führen, da die Daten für lange Zeit oder dauerhaft gesperrt werden, weil die Transaktion nie abgeschlossen wird.
Um solche Probleme in DynamoDB zu vermeiden, wurden Transaktionen mit zwei unterschiedlichen API Vorgängen implementiert: TransactWriteItems und. TransactGetItems Diese API Operationen haben keine Anfangs- und Endsemantik, wie sie in einer üblich ist. RDBMS Darüber hinaus gilt in DynamoDB ein Zugriffslimit von 100 Elementen innerhalb einer Transaktion, ebenfalls um lang andauernde Transaktionen zu verhindern. Weitere Informationen zu DynamoDB-Transaktionen finden Sie unter Arbeiten mit Transaktionen.
Aus diesen Gründen ist es in der Regel technisch und wirtschaftlich sinnvoll, ein SQL No-System zu nutzen, wenn Ihr Unternehmen eine Antwort mit niedriger Latenz auf Anfragen mit hohem Datenaufkommen benötigt. Amazon DynamoDB hilft bei der Lösung von Problemen, die die Skalierbarkeit des relationalen Systems einschränken, indem sie diese vermeiden.
Die Leistung eines RDBMS lässt sich aus den folgenden Gründen in der Regel nicht gut skalieren:
-
Es verwendet kostspielige Joins, um die gewünschten Ansichten von Abfrageergebnissen neu zusammenzustellen.
-
Es standardisiert Daten und speichert sie in mehreren Tabellen, die mehrere Abfragen erfordern, bei denen Daten auf den Datenträger geschrieben werden.
-
Sie verursacht in der Regel die Leistungskosten eines ACID -konformen Transaktionssystems.
DynamoDB kann aus den folgenden Gründen gut skaliert werden:
-
Die Flexibilität des Schemas ermöglicht DynamoDB die Speicherung komplexer hierarchischer Daten innerhalb eines einzelnen Elements.
-
Das Design mit zusammengesetzten Schlüsseln ermöglicht das Speichern verwandter Elemente nahe beieinander in derselben Tabelle.
-
Transaktionen werden in einem einzigen Vorgang ausgeführt. Die Anzahl der Elemente, auf die zugegriffen werden kann, ist auf 100 begrenzt, um lange laufende Operationen zu vermeiden.
Abfragen des Datenspeichers werden sehr viel einfacher und können häufig im folgenden Format erfolgen:
SELECT * FROM Table_X WHERE Attribute_Y = "somevalue"
DynamoDB benötigt weit weniger Arbeit, um die angeforderten Daten zurückzugeben als RDBMS im vorherigen Beispiel.
