Neo4J sieht nach einer interessanten Lösung für Datensätze aus, die starke Verknüpfungen untereinander aufweisen. Wenn man beispielsweise komplexere Strukturen in Datenbanken speichern möchte, hätte man in der relationalen Welt eine riesige Sammlung aus Verbindungen in den Tabellen. Das würde mit vielen JOINs zu langsamen Antworten führen. Mit graphenbasierten Datenbanken werden aber intern andere Trade-Offs gefahren, womit hochgradig verbundene Datensätze besser verwaltbar werden. Dabei wird aber nie auf die Garantien hinter ACID verzichtet, was diesen graphenorientierten Weg äußerst spannend macht.
Diese Ansätze könnten für eine Idee die ich derzeit verfolge spannend werden. Statt alles in Datenreihen zu speichern oder sich mühevoll eine eigene Repräsentation zu basteln, die das alles persistiert, könnte ich auf diese bereits bestehende Infrastruktur aufbauen und um die Ergebnisse eigene Engines basteln, die diese Daten direkt konsumieren. In lese also komplexe Daten, führe Pattern Matching und Normalisierungs-Algorithmen darauf aus, speichere alles in die Datenbank und gehe zum nächsten Datensatz. Am Ende kann die Datenbank dann das erste Glied zum Auslesen der Daten werden, die dann über eine Client-Anwendung wieder transformiert und präsentiert werden.
Generell kann man mit derartigen Ansätzen also auf die eine allmächtige Datenbank die alle Daten in der aktuellsten Version ohne Redundanzen in der n+1ten Normalform speichert vergessen. Stattdessen bastelt man sich Applikationen mit Flows, die über Zeit die Daten/Änderungen in die letzten Ecken des Stacks propagieren. Bei manchen Anwendungen (Suchen und großen Indices) sollte das auch kein zu großes Problem darstellen.
Zusammenfassend bin ich also schon jetzt neugierig, wie ich diese „Neuerungen“ in meine zukünftigen Entwicklungen einbauen kann und ob ich das alles gebrauchen kann. Der typische Ratschlag von „No matter what, go relational and do fancy things later!“ kann bei solchen Paradigmenwechseln glaube ich auch mal ignoriert werden. Und wenn Speicherplatz eh billig ist, kann man auch alle Daten einfach parallel in eine relationale und eine graphenbasierte Datenbank schreiben, damit im Falle eines Ausfalls die relationale Datenbank als absoluter Safespace einspringen kann und den Rest des Stacks wieder befüllt. Vermutlich gibt es massenhaft Nachteile die man erst bei der Benutzung erfährt (unvorhersehbare Query-Performance, RAM Vorraussetzungen, …), aber Offenheit zu einer kombinierten Nutzung von z.B. PostgreSQL und Neo4J könnte am Ende zu einem Vorteil führen bei Anfragen, die zu dem jeweiligen System passen.
Vielleicht kann so etwas ja einer Leserin oder einem Leser helfen! 🙂
LG,
Max
