Cloud Serie: Google Spanner Graph - Ein "must read" für Software-Entwickler und Daten-Analysten

Für jedes Problem sollte das optimale Werkzeug verwendet werden. Wer nur einen Hammer hat, für den sieht bekanntlich jedes Problem wie ein Nagel aus. So sieht die heile Welt aus. In der Realität gilt es abzuwägen, ob sich der Aufwand tatsächlich lohnt. Jedes Werkzeug muss evaluiert, eingeführt, geschult und gewartet werden. Im schlimmsten Fall verkompliziert die Einführung eines neuen Werkzeuges den ganzen IT-Stack und der erhoffte Nutzen und kehrt sich insgesamt in einem Mehraufwand um.

Graphendatenbanken bieten hervorragende Eigenschaften in der Datenanalyse. Natürlich kann man die Graphen-Theorie auch auf relationale oder Dokumenten basierte (NoSQL-) Datenbanken "ummünzen". Die effizienten Algorithmen der Graphen-Theorie kann man jedoch nicht anwenden, wenn man einen "Graphen" via SQL-Abfrage implementierten muss, weil die Daten in einer relationalen Datenbank gespeichert sind.

Bislang gab es beim Einsatz von Graphendatenbanken jedoch zwei grosse Hindernisse:

1. Bis vor kurzem gab es keine standardisierte Abfragesprache wie ISO SQL. Damit wird man stark Anbieter abhängig und die Verbreitung einer spezifischen, teilweise sogar proprietären Sprache, ist entsprechend gering. Das erschwert auch die Suche nach Entwicklern, welche die Sprache beherrschen. Das Problem besteht im Übrigen auch bei NoSQL-Datenbanken. Dieses Problem wurde diesen Frühling mit der Veröffentlichung vom ISO-Standard:  ISO/IEC 39075:2024 Information Technology – Database languages – GQL behoben. Link. Klar, gibt es jetzt nicht automatisch schon eine Menge Experten dieser Sprache, aber die Voraussetzung ist geschaffen.
2. Das eigentlich noch grössere Problem ist, dass Graphendatenbanken eigene, also separate, Datenbanken sind. In der Regel hat man die transaktionalen Daten in einer relationalen Datenbank oder allenfalls Dokument basierten Datenbank gespeichert. Die ganze Business-Logik baut auf einer oder beiden Datenbanken auf. Wenn nun für spezifische Analysen eine Graphendatenbank sinnvoll wäre, stellt sich die Fragen, ob sich der Aufwand lohnt eine solche zu betreiben, mit all dem Aufwand des Betriebs und der Datendublizierung aus den anderen Datenbanken etc. Anders sieht es natürlich aus, wenn der Hauptzweck, wie bspw. bei einer Fahrplan-Applikation, aus Graphen besteht. Das trifft für viele Unternehmens-Applikationen in der Regel aber nicht zu.

Diese zwei Gründe sind meines Erachtens verantwortlich, dass Graphendatenbanken heute eine sehr geringe Verbreitung haben. Für viele Anwendungsfälle lohnt sich der Aufwand insgesamt einfach nicht.

Umso erfreuter war ich von der Publikation von Google, dass die relationale Datenbank Spanner mit Graphen-Funktionen erweitert wurde. Genau gesagt ist Spanner nun GQL-kompatibel.

Das Beste aus beiden Welten! Das erste Problem wurde durch den ISO-Standard behoben und das zweite nun von Google für GCP-Kunden.

Ich glaube, dass vielen Entwicklern und Datenanalysten noch nicht klar ist, welche Möglichkeiten sich damit eröffnen. Plötzlich lohnt es sich, auch für eigentlich kleine Anwendungsfälle die Daten auf Grundlage der Graphentheorie mittels GQL zu nutzen.

Google adressiert genau die bisherigen Probleme und liefert eine passende Lösung dazu. Da hat jemand einen super Job gemacht!

Bei aller Euphorie, seien hier noch folgende Informationen gegeben:

• Die Funktion ist derzeit in Preview, das heisst, noch nicht definitiv öffentlich verfügbar mit SLA.
• Die Funktion ist nur in den Spanner Editions Enterprise und Enterprise Plus verfügbar (die neuen Editionen gibt es ab dem 24.09.2024).
• Mit den neuen Editionen ändert auch das Preismodell von Spanner. Wie ich gesehen habe, kostet die günstigste Konfiguration mit GQL-Funktionalität um die CHF 1'000 p.M. Also eher ungeeignet um klein anzufangen und nur etwas auszuprobieren.

Die Ankündigung von Google findet ihr hier.

Ich empfehle allen Backend-Entwicklern und Datenanalysten, sich GQL und die diesbezüglichen Funktionen von Spanner einmal anzusehen.