Kein SQL Design für DynamoDB

Kein SQL Datenbanksystem wie Amazon DynamoDB verwendet alternative Modelle für das Datenmanagement, wie z. B. Schlüssel-Wert-Paare oder Dokumentenspeicher. Wenn Sie von einem relationalen Datenbankmanagementsystem zu einem System ohne SQL Datenbank wie DynamoDB wechseln, ist es wichtig, die wichtigsten Unterschiede und spezifischen Entwurfsansätze zu verstehen.

Unterschiede zwischen relationalem Datendesign und Nein SQL

Relationale Datenbanksysteme (RDBMS) und SQL No-Datenbanken haben unterschiedliche Stärken und Schwächen:

• In RDBMS können Daten flexibel abgefragt werden, Abfragen sind jedoch relativ teuer und lassen sich in Situationen mit hohem Datenaufkommen nicht gut skalieren (siehe). Erste Schritte für die Modellierung relationaler Daten in DynamoDB

• In einer SQL No-Datenbank wie DynamoDB können Daten auf eine begrenzte Anzahl von Arten effizient abgefragt werden. Andernfalls können Abfragen teuer und langsam sein.

Diese Unterschiede führen dazu, dass das Datenbankdesign der beiden Systeme verschieden ist:

• Bei der Entwicklung RDBMS achten Sie auf Flexibilität, ohne sich Gedanken über Implementierungsdetails oder Leistung machen zu müssen. Die Optimierung von Abfragen wirkt sich im Allgemeinen nicht auf das Schemadesign aus, eine Standardisierung ist jedoch wichtig.

• In DynamoDB entwerfen Sie das Schema im Hinblick darauf, die häufigsten und wichtigsten Abfragen so schnell und kostengünstig wie möglich ausführen zu können. Ihre Datenstrukturen sind an die spezifischen Anforderungen Ihrer geschäftlichen Anwendungsfälle angepasst.

Zwei Schlüsselkonzepte für No SQL Design

Kein SQL Design erfordert eine andere Denkweise als RDBMS Design. Zum einen RDBMS können Sie weitermachen und ein normalisiertes Datenmodell erstellen, ohne über Zugriffsmuster nachdenken zu müssen. Anschließend können Sie es erweitern, wenn neue Fragen und Abfrageanforderungen entstehen. Sie können jeden einzelnen Typ von Daten in einer eigenen Tabelle organisieren.

Wie Kein SQL Design ist anders

• Im Fall von DynamoDB sollten Sie nicht mit der Entwicklung des Schemas beginnen, bis Sie die Fragen kennen, die es beantworten soll. Es ist äußerst wichtig, die geschäftlichen Probleme und Anwendungsfälle vor der Entwicklung des Schemas zu kennen.

• Sie sollten in einer DynamoDB-Anwendung so wenig Tabellen wie möglich verwenden. Weniger Tabellen sorgen dafür, dass die Dinge besser skalierbar sind, weniger Berechtigungsmanagement erforderlich sind und der Overhead für Ihre DynamoDB-Anwendung reduziert wird. Dies kann auch dazu beitragen, die Backup-Kosten insgesamt niedrig zu halten.

Annäherung an kein SQL Design

Der erste Schritt beim Design der DynamoDB-Anwendung besteht in der Identifizierung der spezifischen Abfragemuster, die das System unterstützen muss.

Insbesondere ist es wichtig, drei Basiseigenschaften der Zugriffsmuster Ihrer Anwendung zu kennen, bevor Sie mit dem Design beginnen:

• Datenmenge: Wenn Sie wissen, wie viele Daten gleichzeitig gespeichert und angefordert werden, kann dies helfen, die effektivste Partitionierung der Daten zu ermitteln.

• Datenform: Anstatt Daten neu zu formen, wenn eine Abfrage verarbeitet wird (wie es bei einem RDBMS System der Fall ist), organisiert eine SQL No-Datenbank die Daten so, dass ihre Form in der Datenbank dem entspricht, was abgefragt wird. Dies ist ein entscheidender Faktor, um Geschwindigkeit und Skalierbarkeit zu verbessern.

• Datengeschwindigkeit: DynamoDB wird durch die Erhöhung der Anzahl der physischen Partitionen skaliert, die für die Verarbeitung von Abfragen verfügbar sind, sowie durch die effiziente Verteilung von Daten über diese Partitionen. Wenn Sie im Voraus wissen, wie die Spitzenabfragelasten aussehen könnten, hilft Ihnen dies möglicherweise, die Daten so zu partitionieren, dass die I/O-Kapazität optimal genutzt wird.

Nach der Identifizierung spezifischer Abfrageanforderungen können Sie die Daten nach allgemeinen Grundsätzen organisieren, denen die Leistung unterliegt:

• Speichern Sie verwandte Daten zusammen.   Untersuchungen haben gezeigt, dass das Prinzip der „Referenzlokalität“, d. h. die Zusammenführung verwandter Daten an einem Ort, ein Schlüsselfaktor für die Verbesserung der Leistung und der Reaktionszeiten in SQL No-Systemen ist, genauso wie es sich vor vielen Jahren als wichtig für die Optimierung von Routingtabellen erwiesen hat.

  Allgemein sollten Sie in einer DynamoDB-Anwendung so wenig Tabellen wie möglich verwenden.

  Ausnahmen hiervon sind Fälle, in denen große Mengen von Zeitreihendaten oder Datensätze mit sehr unterschiedlichen Zugriffsmustern vorhanden sind. Eine einzelne Tabelle mit umgekehrten Indizes kann in der Regel einfache Abfragen unterstützen, um die komplexen hierarchischen Datenstrukturen zu erstellen und abzurufen, die Ihre Anwendung benötigt.

• Verwenden Sie eine Sortierreihenfolge.   Verwandte Elemente können zusammen gruppiert und effizient abgefragt werden, wenn ihr Schlüsseldesign dazu führt, dass sie gemeinsam sortiert werden. Dies ist eine wichtige Strategie ohne Design. SQL

• Verteilen Sie Abfragen.   Es ist auch wichtig, dass sich ein großes Volumen von Abfragen nicht auf einen Teil der Datenbank konzentriert, wo sie die I/O-Kapazität überschreiten könnten. Stattdessen sollten Sie Datenschlüssel so entwerfen, dass der Datenverkehr so gleichmäßig wie möglich auf die Partitionen verteilt wird, um Hotspots zu vermeiden.

• Verwenden Sie globale sekundäre Indizes.   Durch die Erstellung spezifischer globaler sekundärer Indizes können Sie eine größere Zahl unterschiedlicher Abfragen unterstützen, als Ihre Haupttabelle unterstützen kann. Gleichzeitig sind diese nach wie vor schnell und vergleichsweise kostengünstig.

Diese allgemeinen Grundsätze führen zu einigen häufigen Designmustern, die Sie verwenden können, um Daten in DynamoDB effizient zu modellieren.

Keine SQL Workbench für DynamoDB

Keine SQL Workbench für DynamoDBist eine plattformübergreifende, clientseitige GUI Anwendung, die Sie für die moderne Datenbankentwicklung und den Betrieb verwenden können. Sie ist für Windows, macOS und Linux verfügbar. No SQL Workbench ist ein visuelles Entwicklungstool, das Funktionen für Datenmodellierung, Datenvisualisierung, Beispieldatengenerierung und Abfrageentwicklung bietet, mit denen Sie DynamoDB-Tabellen entwerfen, erstellen, abfragen und verwalten können. Mit No SQL Workbench for DynamoDB können Sie neue Datenmodelle auf der Grundlage vorhandener Datenmodelle erstellen oder Modelle entwerfen, die den Datenzugriffsmustern Ihrer Anwendung entsprechen. Sie können das gestaltete Datenmodell am Ende des Prozesses auch importieren und exportieren. Weitere Informationen finden Sie unter Datenmodelle ohne SQL Workbench erstellen.