In diesem Beitrag möchte ich mir einmal die produktive Seite der Graphen-Datenbanken neo4j anschauen. Die Software hat mich technisch begeistert. Auf der Betriebs- und Kostenseite kommen nun Aspekte zum Vorschein, die aus dem Favoriten schnell ein Problem machen. Lest selbst und sagt mir Eure Meinung!
Das Szenario
Ich nehme als Beispiel-Applikation dieses Projekt: github-Reader. Der github-Reader nutzt eine neo4j, um ein Abbildung des Know-Hows innerhalb eines Unternehmens erstellen zu können. Technisch gesehen liest die Applikation Daten über die github-API aus und speichert diese in der Datenbank.
Technisch gesehen reicht für den aktuellen Stand der Entwicklung eine Standalone-Datenbank zusammen mit der Applikation (hier Spring Boot). Interessant wird es nun, wenn die Applikation nicht nur ein, sondern hunderte oder tausende Unternehmen abbilden soll. Für ein derartiges Szenario dürfte es recht eng werden in der Standalone-Datenbank. Ein Cluster wäre nett, um die Last verteilen und die Schreiboperation auf einem Knoten zu kapseln. Und natürlich wären regelmäßige Backups recht praktisch.
neo4j – Lösungsansatz
Die beiden Features lassen sich durch neo4j technisch lösen. Aber nun greift das Geschäftsmodell der neo4j: die genannten Features sind nicht mehr Teil der freien Community-Edition, die kommerziellen Lösungen werden nun relevant.
Wie schaut es nun aus bei der Enterprise-Edition (Vergleich der Editionen der neo4j)? Nun, auch neo4j möchte Geld verdienen. Zurecht! Leider wird das wichtigste Thema nicht auf den Seiten angesprochen: was kostet mich der Einsatz der Enterprise Edition?
Doch zunächst die guten Aspekte: für Startups mit weniger als 20 Mitarbeitern ist die Enterprise Edition frei. Darüber gibt es anscheinend spezielle Preismodelle (neo4j startup program). Alles andere kann offenbar mit dem Vertrieb in persönlicher Absprache geklärt werden.
Vorsicht: Migration
Die oben beschriebene Vorgehensweise enthält einige Aspekte, die Entwickler und Produktverantwortliche auf jeden Fall beachten sollten:
- die Community Edition ist ein Evaluierungsprodukt; der Produktiveinsatz scheint mir nur in Spezialfällen möglich; dies entspricht auch der Empfehlung von neo4j
- das Preisgefüge ist Verhandlungssache; über Themen des produktiven Einsatzes sollte daher früh nachgedacht werden (Skalierung, Backup, etc.)
- für den Fall, dass eine frühe Absprache nicht stattfand, können im Falle einer notwendigen Migration ungeplante Kosten und Zeiten entstehen:
- bei einer Migration zur Enterprise Edition muss der Fokus auf eine schnelle Einigung gelegt werden. Mehrere Verhandlungsrunden dürften sich dann als problematisch für das Produkt erweisen
- bei einer Migration zu einer Alternativlösung muss die Applikation umgebaut werden; auch hier können ggf. Lizenzkosten entstehen
- der Aufbau der Infrastruktur an sich benötigt Zeit
Alternativen
Ich denke, dass neo4j durchaus einiges an Mehrwert bringen dürfte. Eine Kosten-/Nutzen-Rechnung lohnt sich also in jedem Fall. Was ist aber, wenn neo4j nicht in Frage kommt? Welche Alternativen gibt es noch so auf dem Markt? Hier ist eine Liste von anderen Graphen-Datenbanken (kein Anspruch auf Vollständigkeit):
- Orient-DB (http://orientdb.com/orientdb/)
- Sparksee (http://sparsity-technologies.com/)
- ArangoDB (ArangoDB)
- Cayley (https://github.com/google/cayley)
Welche davon passt, hängt von ganz persönlichen Kriterien ab. Ich habe für mich die folgenden Aspekte aufgestellt, die ich prüfen möchte:
- handelt es sich um eine native Graphen-Datenbank oder um einen Aufsatz?
- Welche Treiber und Schnittstellen gibt es?
- Wie gestaltet sich die Sprache, in der die Datenbank bedient wird?
- Kosten?
- Unterstützung durch die Community
- Lizenz
Genau diesen Check werde ich in den nächsten Runden hier veröffentlichen. Wenn Ihr schon Erfahrungen gesammelt habt, lasst es mich gerne wissen.