Graphdatenbank ist nicht gleich Graphdatenbank
Wollen Entwickler Graphprojekte erfolgreich umsetzen, sind vor allem Integrität, Performance, Effizienz und Skalierbarkeit gefragt. Um dabei aus vernetzten Daten maximalen Nutzen zu ziehen, bieten native Datenbankdesigns Vorteile gegenüber nicht-nativen.
![Terraform in der Praxis: LAMP-Stack in der Cloud](https://heise.cloudimg.io/width/610/q85.png-lossy-85.webp-lossy-85.foil1/_www-heise-de_/imgs/18/2/3/7/4/8/7/2/admin-7a8cb4fafe93c0da.jpeg)
- Jim Webber
NoSQL-Datenbanken haben sich in den letzten Jahren als vielversprechende Alternative zu relationalen Datenbanken etabliert. Darunter fallen auch Graphdatenbanken, die laut DB-Engines zu den am schnellsten wachsenden Datenbanktypen zählen. Bei der Auswahl der passenden Technologie für ein Projekt stehen Entwickler aber regelmäßig vor der entscheidenden Frage, welche Datenbank für die jeweiligen Anforderungen und Anwendungen am besten geeignet ist.
Auch wenn die grundlegende Entscheidung zugunsten von Graphdatenbanken ausfällt, gilt es, die projektrelevanten Faktoren für die Auswahl im Zusammenhang mit Graphdaten im Unternehmenskontext zu berücksichtigen – denn auch Graphdatenbanken unterscheiden sich in Aufbau und Ausprägung. Entwickler stehen hier vor der Wahl zwischen einem nativen und einem nicht-nativen Design des Datenbanksystems. Erstere wurden bereits bei der Entwicklung auf Graphen ausgerichtet, die nicht-nativen Systeme dafür angepasst.
Dieser Artikel geht zunächst auf einige grundlegende Aspekte der Informatik und des Systemdesigns ein, die beim Aufbau eines Datenbank-Management-Systems (DBMS) eine Rolle spielen. Dabei wird der Frage nachgegangen, wie unterschiedliche DBMS-Designs ihre primären oder nativen Modelle unterstützen und wo die Risiken liegen, wenn native Modelle auf andere nicht-native Modelle ausgeweitet werden sollen.