NoSQL-Design für DynamoDB

• In RDBMS können Daten flexibel abgerufen werden, Abfragen sind jedoch vergleichsweise kostspielig und können bei einer großen Zahl von Zugriffen nicht gut skaliert werden (siehe Erste Schritte für die Modellierung relationaler Daten in DynamoDB).

• In einer NoSQL-Datenbank wie DynamoDB können Daten effizient mithilfe einer begrenzten Anzahl von Möglichkeiten abgerufen werden, die ansonsten möglicherweise kostspielig und langsam sind.

• In RDBMS entwerfen Sie das Design im Hinblick auf Flexibilität, ohne sich um Implementierungsdetails oder Leistung zu kümmern. 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.

Wie sich das NoSQL-Design unterscheidet

• 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.

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

• Datenform: Statt Daten neu zu gestalten, wenn eine Abfrage verarbeitet wird (wie im Fall von RDBMS-Systemen), organisieren NoSQL-Datenbanken Daten so, dass ihre Form in der Datenbank dem entspricht, was abgefragt werden 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.

• 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 NoSQL-Systemen ist, genauso wie es sich vor vielen Jahren als wichtig für die Optimierung von Routing-Tabellen 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 stellt eine wichtige Strategie für das NoSQL-Design dar.

• 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önnen. 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.