Worin besteht der Unterschied zwischen NoSQL-Datenbanken und relationalen Datenbanken?
Im Allgemeinen zeichnen sich NoSQL-Datenbanken dadurch aus, dass sie sowohl horizontal skalierbar als auch nicht relational sind.
Horizontale und vertikale Skalierung
Die Größe von relationalen Datenbanken nimmt in der Regel zu, indem die Größe des virtuellen Computers oder der Compute-Instanz zunimmt, auf dem bzw. in der sie gehostet werden. NoSQL-Datenbanken werden durch Hinzufügen weiterer Server oder Knoten hochskaliert. Diese Knoten werden auch als physische Partitionen in Cosmos DB bezeichnet. Daten, die auf diesen physischen Partitionen gespeichert sind, müssen so organisiert werden, dass später effizient auf sie zugegriffen werden kann.
Daten werden mithilfe des Werts einer erforderlichen Eigenschaft für jedes Dokument vorhersagbar an verschiedene physische Partitionen weitergeleitet. Diese Eigenschaft wird als Partitionsschlüssel eines Containers bezeichnet. Dieser Partitionsschlüssel muss beim Erstellen des Containers angegeben werden. Die Übergabe des Partitionsschlüssels beim Schreiben oder Lesen von Daten aus einem Container stellt sicher, dass die Vorgänge effizient ablaufen.
Obwohl die Notwendigkeit eines Partitionsschlüssels als Einschränkung erscheinen mag, hat er enorme Vorteile. Normalerweise werden relationale Datenbanken höchstens auf weniger als 100 TB anwachsen. Eine NoSQL-Datenbank kann unbegrenzt wachsen, ohne dass sich dies auf die Antwortzeiten auswirkt, wenn sie auf Daten aus einer einzelnen Partition zugreift.
Außerdem wird mit dem Hinzufügen von Partitionen auch die Computeleistung erhöht, sodass der Umfang der von der Datenbank unterstützten Verarbeitung gleichzeitig zunimmt.
Nicht relationale Datenbanken im Vergleich zu relationalen Datenbanken
Das zweite kennzeichnende Merkmal einer NoSQL-Datenbank ist, dass keine Fremdschlüssel, Einschränkungen oder erzwungenen Beziehungen zwischen Daten vorhanden sind. Da Daten in einer NoSQL-Datenbank auf verschiedenen physischen Servern gespeichert werden, würde das Erzwingen von Einschränkungen oder Beziehungen bzw. das Sperren von Daten zu einer negativen oder unvorhersehbaren Leistung führen.
Dass es keine erzwungenen Beziehungen gibt, bedeutet jedoch nicht, dass Sie Entitäten, die Beziehungen aufweisen, in einer NoSQL-Datenbank nicht verwalten können, sondern nur, dass Sie dabei anders vorgehen müssen.
Warum unterscheiden sich diese Datenbanktypen so grundlegend?
Wenn Sie verstehen, wie sich die wirtschaftlichen Aspekte im Bereich Computing seit Einführung relationaler Datenbanken geändert haben, können Sie besser nachvollziehen, warum diese beiden Arten von Datenbanken so unterschiedlich angelegt sind.
Als die relationalen Datenbanken 1970 erfunden wurden, waren die Kosten für Speicher und Arbeitsspeicher im Verhältnis zur Computeleistung hoch. Das Ziel der Normalisierung eines Datenbankmodells war die Reduzierung doppelter Daten und somit der Kosten innerhalb einer Datenbank. Die Datenbank-Engine würde Sperren und Latches anwenden, um eine strenge ACID-Semantik (Unteilbarkeit, Konsistenz, Isolation, Dauerhaftigkeit) zu erzwingen, während sie Vorgänge an allen benötigten Daten zusammen durchführt. Die Datensperren sorgten für konsistente Daten, in Bezug auf Parallelität, Wartezeit und Verfügbarkeit mussten jedoch Kompromisse in Kauf genommen werden.
Heutzutage sind die Kosten für Speicher und Arbeitsspeicher im Vergleich zur Computeleistung relativ günstig, sodass wir nicht mehr im Hinblick auf die Speichereffizienz optimieren müssen, um kosteneffizient zu sein. Wenn Workloads immer höhere Maße an Parallelität und Verfügbarkeit sowie immer geringere Wartezeiten voraussetzen, wird auch ein neuer Datenbanktyp erforderlich, der optimal auf diese Anforderungen ausgelegt ist, sodass NoSQL-Datenbanken entstanden sind.
Aus diesen Gründen besteht eines der Ziele bei der Modellierung von Daten für eine NoSQL-Datenbank darin, das Lesen und Schreiben von Daten so zu gestalten, dass die Effizienz der Computeprozesse gewährleistet ist. Da es in NoSQL-Datenbanken keine relationalen Operatoren wie dokumentübergreifende Joins gibt, müssen die Daten so gespeichert werden, wie sie von der Anwendung verwendet werden, um die maximale Effizienz zu erreichen. Häufig müssen Daten denormalisiert, dupliziert oder auf eine andere Weise gespeichert werden, die viele der relationalen Normalisierungsregeln, die für die relationale Datenmodellierung verwendet werden, verletzt.
Kann NoSQL für relationale Workloads verwendet werden?
An diesem Punkt fragen Sie sich vielleicht, ob NoSQL-Datenbanken für relationale Workloads geeignet sind. Die Antwort lautet ja. NoSQL-Datenbanken können auf jeden Fall für Workloads verwendet werden, bei denen Beziehungen zwischen verschiedenen Entitäten vorhanden sind.
NoSQL-Datenbanken werden häufig dann eingesetzt, wenn eine relationale Datenbank die gewünschten Leistungs-, Skalierungs- oder Verfügbarkeitsanforderungen der Anwendung nicht erfüllen kann.
Die zum Entwerfen von NoSQL-Datenbanken verwendeten Techniken unterscheiden sich von der Modellierung von Daten für relationale Datenbanken. Diese Techniken sind auch für jemanden mit Hintergrundwissen zum relationalem Datenbankentwurf nicht intuitiv. Einige der bewährten Methoden, die Sie für das Erstellen relationaler Datenbanken kennenlernen, lassen sich nicht gut auf den Entwurf nicht relationaler Datenbanken übertragen. Diese bewährten Methoden für relationale Datenbanken sind beim Entwerfen von NoSQL-Datenbanken häufig ein Widerspruch.
Im weiteren Verlauf dieses Moduls und im Modul für die fortgeschrittene Modellierung werden wir Sie durch die Techniken führen, die verwendet werden, um Daten so zu modellieren, dass eine leistungsstarke NoSQL-Datenbank entsteht.