© saicle/Shutterstock.com
Datenmodellierung in nicht relationalen Datenbanken

Datenmodellierung in nicht relationalen Datenbanken


„Erstelle ein korrekt normalisiertes Datenbankschema!“ lautet eine beliebte Übungsaufgabe für angehende Informatiker. Das Erkennen und Beseitigen von Redundanzen geht irgendwann ins Blut über und wird alltägliches Handwerkszeug. Doch was ist zu beachten, wenn die Datenbank nicht relational ist, sondern aus dem Kanon der „neuen“, nicht relationalen Datenbanken à la MongoDB, CouchDB, Riak oder Redis stammt?

Längst sind nicht relationale Datenbanken, häufig etwas nichtssagend als „NoSQL“-(Not-only-SQL-)Datenbanken bezeichnet, im technologischen Mainstream und in Real-Life-Projekten angekommen. Systemarchitekten ersetzen das relationale Datenbanksystem komplett durch einen der Newcomer oder nehmen für Spezialaufgaben Vertreter dieser Spezies ins Architekturportfolio auf.

Für Entwickler bedeutet das ein Umdenken bei der Modellierung ihrer Persistenzschicht. Die Modellierung in relationalen Datenbanken beruht auf der Erstellung eines normalisierten Relationenmodells mit Tupeln und Relationen, die sich dann nahezu direkt in ein Tabellensystem umwandeln lassen. Im Vordergrund bei der Modellierung steht die Frage: „Wie sind meine Daten strukturiert und welche Antworten habe ich in meinen Daten?“ Beim Modellieren für NoSQL-Datenbanken steht typischerweise die Frage im Mittelpunkt: „Wie will ich auf die Daten zugreifen, welche Fragen an die Daten habe ich?“, verbunden mit: „Welche Möglichkeiten bietet die Datenbank, die Daten zu strukturieren und abzufragen?“

Schöne, bunte NoSQL-Welt

Bei relationalen Datenbanken erfolgt der Zugriff auf Daten über ein im Großen und Ganzen gemeinsames Datenmodell, das auf Tabellen mit Zeilen und strikt typisierten Spalten beruht. SQL ist als halbwegs standardisierte Abfragesprache und Zugriffsmöglichkeit etabliert.

Die NoSQL-Welt ist deutlich heterogener: Mittlerweile existieren etwa 150 NoSQL-Datenbanken am Markt [1], die die unterschiedlichsten Ansätze verfolgen: Einige fokussieren sich auf die horizontale Skalierbarkeit. Andere betonen die flexiblen Abfragemöglichkeiten. Wieder andere wollen jede Aufgabe als Graphenproblem betrachten und lösen.

NoSQL-Datenbanken speichern also ganz unterschiedliche Datenstrukturen: Key/Value, Dokumente, Graphen usw. Standardisierungsbemühungen im Bereich Abfragen, wie z. B. UnQL [2] oder JSONiq [3] als interoperable Abfragesprachen, waren bisher nicht erfolgreich bzw. stehen erst am Anfang. Das ist angesichts der heterogenen Ansätze auch nicht sonderlich erstaunlich.

NoSQL-Datenmodelle im Überblick

Die folgende Einteilung gibt einen ersten Überblick, welche Datenbankmodelle sich häufig in der NoSQL-Welt finden:

Simple Key-Value Stores stellen einen einfachen Datenbanktyp dar. Sie bilden Schlüssel (Keys) auf Werte (Values) ab. Die Schlüssel sind eindeutig und damit das Äquivalent zu einem Primary Key in einer relationalen Datenbank. Die Werte selbst sind für simple Key-Value Stores meist „opaque“: Sie werden als binäre Daten ohne Kenntnis der darin gegebenenfalls enthaltenen Strukturen abgespeichert.

Eine Abfrage der gespeicherten Werte ist in simplen Key-Value Stores nur über den jeweiligen Schlüssel möglich. Eine direkte Suche nach Werten ist nicht möglich, da der Key-Value Store die Werte nicht interpretieren kann. Häufig ist es auch nicht möglich, in einer vorhersagbaren Reihenfolge über alle Key-Value-Paare zu iterieren. Bereichsabfragen auf Schlüsseln (z. B. von Schlüssel „user-001“ bis „user-008“ oder „project-001-*“) werden somit oft nicht unterstützt. Die Unabhängigkeit der Schlüssel voneinander macht solche Key-Value Stores effizient und relativ simpel implementierbar. Allerdings ist die Abfragemöglichkeit für Entwickler auch sehr eingeschränkt und erfordert Disziplin bei der Vergabe der Schlüsselnamen. Memcached [4] ist ein Prototyp eines solchen simplen Key-Value Stores.

Als Erweiterung des simplen Modells bieten einige Key-Value Stores an, den globalen Namensraum in verschiedene Keyspaces (auch Segmente oder Buckets genannt) aufzuteilen, die dann separat verwaltet und abgefragt werden können. Schlüsselnamen sind hierbei nicht mehr global eindeutig, sondern nur noch in Kombination mit dem jeweiligen Keyspace. Diese zweistufige Hierarchie erweitert die Abfragemöglichkeiten bereits deutlich.

Mittlerweile erlauben viele Key-Value Stores auch die Indizierung von Werten. Sie bieten damit neben dem herkömmlichen Zugriff per Schlüssel auch die Möglichkeit, gesuchte Werte schnell über Sekundär-Indizes abzufragen. Bei Verwendung sortierter Indizes sind damit auch Bereichsabfragen auf Werte möglich. Diese Möglichkeiten bestehen z. B. in Riak [5] und Amazons DynamoDB-Service [6]. Da der Store die zu indizierenden Teile von Werten mangels Kenntnis der internen Strukturen nicht ermitteln kann, muss der Entwickler der Datenbank den in den Index aufzunehmenden Wert selbst mitteilen.

Extended-Column Stores, oft auch Wide-Column oder Column-Family Stores genannt, basieren ebenfalls auf dem Konzept der Key-Value Stores. Die Daten werden grundsätzlich in einer mehrstufigen Schlüsselhierarchie abgelegt. Die in Keyspaces organisierten Schlüssel enthalten nun „Columns“ genannte Unterelemente. Diese Columns enthalten entweder direkt die eigentlichen Werte oder enthalten als „Supercolumns“ wiederum selbst Unter-Columns.

Der Begriff „Column“ entspricht hierbei nicht dem einer Spalte wie in relationalen Datenbanken. Die Ablage in Extended-Column Stores ähnelt eher einem verschachtelten assoziativen Array. Die oberen Ebenen der Hierarchie müssen meist vorab definiert werden und gelten für alle Datensätze. Die unteren Hierarchieelemente sind meist dynamisch und je Datensatz unterschiedlich definierbar, ohne dass dies wie in einer relationalen Datenbank zu Problemen führt.

Da alle Hierarchieelemente benannt und über ihre Namen ansprechbar sind, lassen sich hiermit Abfragen auf Elemente der untersten Ebene einfach und effizient ausführen. Bereichsabfragen sind möglich. Da die Werte in der Regel typenlos sind und vom Store nicht weiter interpretiert werden können, erfolgen die Bereichsabfragen allerdings nicht über Werte-, sondern über Schlüssel-Bereiche.

In der Praxis werden die Daten in Extended-Column Stores auf mehrere Server verteilt. Bereichsabfragen sind dann nur effizient, wenn zusammen abgefragte Daten auf demselben Server abgelegt werden. Dies erfordert oft Wissen über den Aufbau der Schlüsselhierarchie und bedingt die manuelle Definition der Verteilungslogik. Apache Cassandra [7] als bekannter Vertreter der Extended-Column Stores erlaubt beispielsweise eine solche durch Anwender konfigurierbare Partitionierung.

Dokumentendatenbanken speichern Daten in Form von Dokumenten, häufig nach außen als JSON repräsentiert. Dokumente sind Aggregate mit strukturierten, typisierten Attributen. Ein Dokument kann Listen enthalten und Unterdokumente einbetten, lässt damit also eine hierarchische Organisation von Daten zu. Dokumente aus derselben Domäne werden in der Regel in so genannten „Collections“ organisiert.

Dokumente sind wie in Key-Value Stores über eindeutige Schlüssel identifiziert und dementsprechend über ihre Schlüssel abfragbar. Da die Dokumentattribute typisiert sind, ermöglichen Dokumentendatenbanken darüber hinaus vielfältige weitere Abfragemöglichkeiten, z. B. die Suche nach Dokumenten mit bestimmten Attributen oder bestimmten Werten. Hier sind deutlich komplexere Abfragen möglich als in Stores, die die gespeicherten Daten nicht interpretieren können. Bekannte Dokumentendatenbanken sind MongoDB [8] und CouchDB [9].

Graphendatenbanken schließlich speichern einerseits Knoten und andererseits Kanten (Verbindungen) zwischen diesen Knoten. Die Gesamtheit der Knoten und Kanten wird als „Graph“ bezeichnet. Im Graph eines sozialen Netzwerks könnten die Knoten z. B. Personen u...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang