Worin besteht der Unterschied zwischen NoSQL-Datenbanken und relationalen Datenbanken?
Azure Cosmos DB ist sowohl nicht relational als auch horizontal skalierbar.
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 wie Azure Cosmos DB werden skaliert, indem zusätzliche Server oder Knoten hinzugefügt werden. Dies wird als horizontale Skalierung bezeichnet. 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 an verschiedene physische Partitionen weitergeleitet. Diese Eigenschaft wird als Partitionsschlüssel eines Containers bezeichnet. Dieser Partitionsschlüssel muss beim Erstellen des Containers angegeben werden. Durch das Übergeben des Partitionsschlüssels beim Schreiben oder Lesen von Daten in einem Container wird sichergestellt, dass Vorgänge effizient sind und Anforderungen nur an die Partitionen weitergeleitet werden, in denen sie gespeichert werden.
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. Dies bedeutet, dass sie auch mehrere gleichzeitige Benutzer unterstützen kann. Dies hat keine Auswirkungen auf die Leistung.
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 bewährte Methoden, die Sie sich zum Erstellen relationaler Datenbanken aneignen, gelten oftmals nicht für die Entwicklung im Bereich von NoSQL-Datenbanken.
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.