Sind Graphdatenbanken besser?
Datenbanken haben eine zentrale Bedeutung in der Softwareentwicklung. Nach wie vor dominieren die relationalen Datenbanken. Allerdings finden wir vermehrt auch andere Typen von Datenbanken. Dazu gehören Graphdatenbanken. Wie der Name schon suggeriert stehen hier Beziehungen im Vordergrund.
Relationale Datenbanken
Die klassischen relationalen Datenbanken wurden schon in den 1970ern erdacht und dann entwickelt. Die Tabelle ist dabei die führende Datenstruktur. Da sich relationale Datenbanken recht einfach implementieren lassen, haben sie jahrzehntelang die EDV dominiert. Performante Abfragen sind nur mit passenden Indizes möglich.
Auch wenn relationale Datenbanken sich bewährt haben, so haben sie mehrere Schwächen. Zum einen sind sie relativ starr: Wenn der Schema erst einmal steht, dann lässt er sich nicht so ohne weiteres ändern. Oder besser gesagt, Änderungen erfordern ein diszipliniertes Änderungsmanagement, um unerwartete Auswirkungen zu vermeiden.
Wie bereits erwähnt, sind Abfragen nur mit entsprechenden Indizes performant. Dieses Problem war früher noch schärfer, moderne Datenbanken sind recht gut darin, den Datenbankadministrator zu unterstützen. Dennoch können die Indizes schnell groß werden und die Abfragen unübersichtlich.
Die Erkenntnis, dass Daten wertvoll sind, führt zu immer größeren Datenbanken – Big Data! Auch die gespeicherten Daten werden immer komplexer. Diese Treiber fordern neue Ansätze.
Graphdatenbanken
Im Gegensatz dazu steht bei Graphdatenbanken die Beziehung im Mittelpunkt. Das spiegelt die Erkenntnis wider, dass der Wert der Daten zum großen Teil in den Beziehungen zwischen den Daten liegt, nicht nur in den Daten selbst.
Graphdatenbanken gehören zu der Klasse der NoSQL-Datenbanken. Damit sind alle nicht-relationale Datenbanken gemeint. Insofern ist diese Bezeichnung meiner Meinung nach nicht sonderlich aussagekräftig.
Literaturempfehlung: Graph Databases (Robinson, Webber & Eifrem) gibt’s umsonst von neo4j
Echt oder simuliert
Weiterhin ist es ein leichtes, durch eine Abstraktion eine relationale in eine Graphdatenbank umzuwandeln. Das macht die Arbeit für die Entwickler möglicherweise einfacher. Allerdings bleiben dabei mögliche Performancevorteile auf der Strecke, da die zugrundeliegende Engine nicht für Graphen optimiert wurde. Dennoch kann dieser Ansatz sinnvoll sein, um zum Beispiel auf einer bestehenden Legacy-Datenbank mit Graphkonzepten aufzusetzen.
Eine „echte“ Graphendatenbank hingegen ist für den Umgang mit komplexen Graphen optimiert und skaliert in der Regel wesentlich besser. Das liegt unter anderem daran, dass sich Abfragen am Graph „entlanghangeln“. Dadurch gibt es viele Arten von Abfragen, bei der nicht der komplette Graph in Betracht gezogen werden muss. Das Indizieren von Daten fällt weg, zumindest in dem Maße, wie es bei relationalen Datenbanken notwendig wäre.
Verschiedene Graphen
Die wichtigsten in Graphdatenbanken umgesetzten Modelle sind:
- Propertygraph – Dieser besteht aus Knoten und gerichteten Kanten. Sowohl Knoten als auch Kanten können Eigenschaften (Properties) haben.
- Hypergraph – Hier verbindet eine Relation eine beliebige Anzahl von Knoten. Hypergraphen sind da nütlich, wo es viele n:m-Beziehungen gibt. Beim Propertygraph müsste eine größere Anzahl von Kanten herhalten.
- Triples – Ein Triple besteht aus drei Elementen in der Form Knoten-Kante-Knoten. Diese intuitive und flexible Datenstruktur ist die Basis für viele Anwendungen des semantischen Webs. Dabei ist RDF eine Kerntechnologie, die sich inzwischen durchgesetzt hat.
Fazit
Sind Graphdatenbanken besser? Diese Frage muss wie so oft mit: „Kommt drauf an“ beantwortet werden. Graphdatenbanken sind besser, wenn die zu verarbeitenden Daten aus komplexen Graphen bestehen. Graphendatenbanken skalieren in bestimmten Situationen auch besser als klassische relationale Datenbanken.
