Hauptunterschiede und Gestaltungsprinzipien des NoSQL-Designs

NoSQL-Datenbanksysteme wie Amazon Keyspaces verwenden alternative Modelle für das Datenmanagement, z. B. Schlüssel-Wert-Paare oder die Speicherung von Dokumenten. Wenn Sie von einem relationalen Datenbankmanagementsystem zu einem NoSQL-Datenbanksystem wie Amazon Keyspaces wechseln, ist es wichtig, die wichtigsten Unterschiede und spezifischen Entwurfsansätze zu verstehen.

Unterschiede zwischen einem relationalen Datendesign und NoSQL

Relationale Datenbankmanagementsysteme (RDBMS) und nNoSQL-Datenbanken besitzen unterschiedliche Vor- und Nachteile:

• 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 Bewährte Methoden zur Datenmodellierung: Empfehlungen für den Entwurf von Datenmodellen).

• In einer NoSQL-Datenbank wie Amazon Keyspaces 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:

• 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 Amazon Keyspaces entwerfen Sie Ihr Schema speziell, um die häufigsten und wichtigsten Abfragen so schnell und kostengünstig wie möglich zu gestalten. Ihre Datenstrukturen sind an die spezifischen Anforderungen Ihrer geschäftlichen Anwendungsfälle angepasst.

Zwei Schlüsselkonzepte für das NoSQL-Design

Das NoSQL-Design erfordert einen anderen Ansatz als das RDBMS-Design. Sie können für ein RDBMS ein standardisiertes Datenmodell entwickeln, ohne sich Gedanken über Zugriffsmuster machen 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 sich das NoSQL-Design unterscheidet

• Im Gegensatz dazu sollten Sie nicht mit dem Entwerfen Ihres Schemas für Amazon Keyspaces beginnen, bis Sie wissen, welche Fragen es beantworten muss. Es ist äußerst wichtig, die geschäftlichen Probleme und Anwendungsfälle vor der Entwicklung des Schemas zu kennen.

• Sie sollten so wenige Tabellen wie möglich in einer Amazon Keyspaces-Anwendung verwalten. Weniger Tabellen sorgen für mehr Skalierbarkeit, erfordern weniger Rechteverwaltung und reduzieren den Overhead für Ihre Amazon Keyspaces-Anwendung. Dies kann auch dazu beitragen, die Backup-Kosten insgesamt niedrig zu halten.

Ansatz für ein NoSQL-Design

Der erste Schritt beim Entwerfen Ihrer Amazon Keyspaces-Anwendung besteht darin, die spezifischen Abfragemuster zu identifizieren, die das System erfüllen muss.

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

• Datengröße: Wenn Sie wissen, wie viele Daten gleichzeitig gespeichert und angefordert werden, können Sie ermitteln, wie die Daten am effektivsten partitioniert werden können.

• 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: Amazon Keyspaces skaliert, indem es die Anzahl der physischen Partitionen erhöht, die für die Verarbeitung von Abfragen verfügbar sind, und indem Daten effizient auf diese Partitionen verteilt werden. 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.   Studien zur Optimierung von Routing-Tabellen, die vor 20 Jahren durchgeführt wurden, hatten zum Ergebnis, dass der "Referenzspeicherort" den wichtigsten Faktor für die Verkürzung der Reaktionszeit darstellt: Daten sollten daher zentral gespeichert werden. Das gilt auch heute für NoSQL-Systeme: Wenn verwandte Daten nahe beieinander gespeichert werden, hat dies große Auswirkungen auf Kosten und Leistung. Statt verwandte Datenelemente über mehrere Tabellen zu verteilen, sollten Sie verwandte Elemente in Ihrem NoSQL-System so nahe beieinander wie möglich speichern.

  In der Regel sollten Sie in einer Amazon Keyspaces-Anwendung so wenige Tabellen wie möglich verwalten.

  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 außerdem wichtig, zu vermeiden, eine große Zahl von Abfragen auf einen einzigen Teil der Datenbank auszurichten, da dies die E/A-Kapazität überschreiten könnte. Sie sollten stattdessen Datenschlüssel entwerfen, um die Zugriffe so gleichmäßig wie möglich über die Partitionen zu verteilen und Konzentrationspunkte zu vermeiden.

Diese allgemeinen Prinzipien lassen sich in einigen gängigen Entwurfsmustern umsetzen, die Sie verwenden können, um Daten in Amazon Keyspaces effizient zu modellieren.