ArangoDB

Kurzfassung

  • URL: https://www.arangodb.com/
  • Document-Datenbank
  • Code-Basis: C/C++
  • Interaktive Shell auf Javascript-Basis
  • ArangoDB query language (AQL)
  • erste produktive Version: 1.0 im Frühjahr 2012
  • Apache 2.0 license. Use free for non-commercial and commercial us

Recht junges Projekt aus Deutschland, das eine Dokument-DB aufgesetzt hat. Diese DB wird durch Aufsätze angereichert und kann u.a. auch als Graphen-Datenbank genutzt werden. Positiv herausgestellt sei, dass die Software an sich keinerlei Kosten verursacht, da sie unter einer Apache Lizenz freigegeben wurde. Skeptisch bin ich ein wenig beim Einsatz als Graphen-Datenbank, da diese stark an die darunterliegende Dokumentenstruktur gebunden ist.

Wer steht hinter ArangoDB

  • die ArangoDB GmbH, gegründet 2014, Firmensitz in Köln
  • die Firma verdient Geld über Support, Training und Consulting-Dienstleistungen

Graphen-Abbildung

  • Basiert auf Document Mapsjeweils für Knoten und Kanten (Vertices and Edges)
  • Abbildung von Graphen durch eine Bibliothek (org/arangodb/general-graph)

Funktionsumfang

  • Dokumenten-DB
  • Aufsätze und Bibliotheken auf Basis von V8
  • Unterstützung von Graphen- und Key-/Value-Pair- und Dokument-Systemen
  • interaktive Shell
  • Authentication: basic (username, password)
  • Unterstützung von ACID
  • lauffähig auf 32- und 64-bit-Systemen von Linux, Windows und MacOS
  • Schnittstellen: REST/json, AQL, http://localhost:8529/_admin, Gremlin/Blueprints
  • Clusterfähig über Foxx und einer Coordinator-Applikation
  • Basis-Treiber für diverse Systeme

Meine Kriterien

1. handelt es sich um eine native Graphen-Datenbank oder um einen Aufsatz?

Die Verwaltung von Graphen ist ein Zusatzmodul.

2. Welche Treiber und Schnittstellen gibt es?Wie gestaltet sich die Sprache, in der die Datenbank bedient wird?

Es gibt Treiber für Java, Javascript, Perl, Python, Scala, PHP, Clojure und andere (https://www.arangodb.com/download/). Keine direkte Unterstützung durch Spring Data, es gibt jedoch auch einen Treiber für Blueprints/Gremlin, für die es bereits Spring-Data-Treiber gibt (dies habe ich nicht getestet!).

Die interne Sprache ist AQL (ArangoDB query language), die auch für Graphen-Funktionen genutzt wird (Original Doc: AQL – GraphFunctions)

3. Kosten?

ArangoDB is published under the Apache 2.0 license. This means essentially that you can use it free for non-commercial and commercial use. Kommerzieller Support wird durch die Firma angeboten (siehe oben).

4. Unterstützung durch die Community

Das Projekt ist auf github einsehbar (https://github.com/arangodb/arangodb). Es gibt anscheinend 7 Entwickler, die regelmäßig am Code arbeiten. Es scheint auch Beiträge aus der Community zu geben (43), die aber immer nur kurz am Code beteiligt sind.

5. Lizenz

Apache 2.0 license für den gesamten Code.

Spannende Seiten zu diesem Thema

DB-Engines – ArangoDB

 

The stage is yours…

Alles hier stellt nur meine Meinung dar, ich bin gespannt auf Hinweise, Feedback und sonstiges. Traut Euch, schreibt mir 😉

Neo4j in Produktion

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.

Hierarchische Daten in einer Graph-Datenbank

Einleitung

Im Beitrag „Hierarchische Daten in einer relationalen Datenbank“ habe ich geprüft, ob ich hierarchische Daten in eine relationale Datenbank zu klopfen. Das hat nur bedingt gut geklappt.

Dieses Mal probiere ich es mit Graphen-Datenbank.  Hier ist zunächst das Modell:

hierarchie-politischegebiete-150x150

Ich baue ein hierarchisches Modell auf Basis der politischen Ebenen des Landes Bayern auf. Ich möchte mit der Graphen-Datenbank dieselben Fragen klären, die ich im relationalen Modell klären wollte:

  • Ausgabe aller Bezirke von Bayern (RDBMS: leicht)
  • Alle Gemeinden des Landkreises Traunstein (RDBMS: leicht)
  • Gibt es eine politische Einheit mit dem Namen „Tutzing“? Wenn ja, wo in der Hierarchie befindet sich diese? (RDBMS: schwer)

Projekt-Setup

Für Tests habe ich eine Datenbank aufgebaut, mit der man die oben genannten Fragen live klären kann:

https://github.com/ollihoo/geographicalHierarchyGraph

Das Projekt hat im README eine Anleitung, wie man die Neo4j-Datenbank aufsetzt.

Aufbau der Datenbank

Die Datenbank nutzt Knoten, die die Hierarchie abbilden: (:Country), (:State), (:District), (:RuralDistrict), (:City), (:Community). Die zugehörigen Zuordnungen zur nächsthöhren Ebene werden durch :BELONGS_TO-Beziehungen abgebildet.

Zur Abfrage der Datenbank wird die Sprache Cypher benutzt, die in der Konsole des neo4j-Browsers angeboten wird.

Auswertung

Mit dieser Sprache lassen sich nun leicht die oben genannten Fragen beantworten:

Ausgabe aller Bezirke von Bayern

MATCH (d:Districts)-[:BELONGS_TO]->(s:State{name:"Bayern"}) return d.name

Als Ergebnis werden wie erwartet alle sieben Regierungsbezirke zurückgegeben.

Alle Gemeinden des Landkreises Traunstein

MATCH (c:Community)-[:BELONGS_TO]->(:RuralDistrict{name:"Traunstein"}) RETURN c.name

Es sollten 37 Gemeinden zurückgegeben werden.

Gibt es eine politische Einheit mit dem Namen „Tutzing“?

MATCH (n)-[:BELONGS_TO*1..]->(:State{name:"Bayern"}) 
WHERE n.name = "Tutzing"
RETURN n

Als Ergebnis sollte ein Community-Knoten zurück gegeben werden. Das heisst, es gibt eine Gemeinde namens „Tutzing“.

Wo in der Hierarchie befindet sich „Tutzing“?

Die Frage wurde bereits beantwortet (Tutzing ist eine Gemeinde), ich werde die Frage daher dahingehend erweitern, wie die einzelnen Hierarchie-Stufen aussehen:

MATCH path=(n)-[:BELONGS_TO*1..]->(:State{name:"Bayern"}) 
WHERE n.name = "Tutzing"
RETURN extract(node in nodes(path) | node.name)

Als Ergebnis wird ein Array zurück gegeben, das die einzelnen Hierarchie-Ebenen zurückgibt: [Tutzing, Starnberg, Oberbayern, Bayern]

Ergebnis und Ausblick

Im Vergleich zu einer relationalen Datenbank lassen sich die oben genannten Fragestellungen ohne größere Probleme lösen. Die expressive Sprache Cypher erlaubt eine eingängige Beschreibung der Knoten/Relationship-Muster und ermöglicht so, auch komplexere Fragen gut abbilden zu können.

Hier zunächst ein Vergleich der Elemente zwischen den beiden Modellen:

Element Relationales Modell Graphen-Modell
Entity/Dateneinheit Eine Zeile der Tabelle Knoten (z.B. (…) )
Typ der Dateneinheit Definiert durch Tabellen-Name Definiert durch die Label der Knoten (z.B. :State)
Eigenschaften der Entity Eine Tabellen-Zelle Eine property des Knotens (z.B. {name:“Bayern“})
Beziehung Kombination von Eigen- und Fremdschlüsseln, referenziert in Tabellen-Zellen Ein eigenes Relationship-element mit eigenem Label (z.B. -[:BELONGS_TO]-> )

Wie die Tabelle zeigt, arbeitet das Relationen-Modell sehr Tabellen-zentriert. Demgegenüber bietet das Graphen-Modell sehr viel mehr Modellierungs-Möglichkeiten an, die so komplexere Sachverhalte greifbarer machen.

Ausblick: in Hinblick auf den Abbildungsreichtum der Graphen-Datenbank stellt sich die Frage, warum relationale Datenbanken ein so zentrale Bedeutung bei zahlreichen Anwendungen haben. Eine Antwort ist, dass letztere sehr flexibel eingesetzt werden können und schnell und leicht zu erlernen sind.

Dies führt auch dazu, dass Entwickler sich daran gewöhnt haben, relational zu denken. Modelle werden lieber „platt geklopft“ als sie „anders“ abzubilden. Für viele Fälle ist das auch sicherlich der kostengünstigere Weg.

Dennoch lohnt sich gerade bei Graphen-Datenbanken der Blick über den Tellerrand. Vielleicht schaffen wir es ja, dieses Modell ebenso flexibel einzusetzen wie das der relationalen Datenbank.

Links:

Hierarchische Daten in einer relationalen Datenbank

Einführung

Egal, ob wir Excel oder MySQL oder Oracle DB nutzen, das Prinzip dieser Tools ist dasselbe: wir reduzieren ein Objekt auf seine wesentlichen Eigenschaften, setzen diese Objekte zueinander in Beziehung und beantworten dann bestimmte Fragestellungen auf dieses Konstrukt.

Technisch gesehen sind Objekte („entities“) in einer Tabelle zusammen gefasst, die Eigenschaften sind die Spalten dieser Tabelle.  Die Beziehungen („relationships“) werden über Referenzen als weitere Spalte abgebildet. Bei komplexeren Beziehungen werden auch weitere Hilfstabellen aufgebaut. Um die Referenzierung zu erleichtern, werden oftmals eindeutige Schlüssel („primary key“) definiert, die wiederum als Fremdschlüssel („foreign key“) genutzt werden. Wer weitere Grundlagen benötigt, möge sich die Links zu den Relationalen Datenbanken (siehe unten) anschauen.

Aufbauend auf diesem Modell soll nun eine Hierarchie abgebildet werden. Als Beispiel dient mir hier die politische Aufteilung des  Bundeslandes Bayern.

Ich beschreibe zuerst, wie ich das Modell aufbaue und diskutiere dann Vor- und Nachteile bei der Implementierung bestimmter Fragestellungen. Ich möchte zeigen, dass relationale Datenbanken nur sehr bedingt für hierarchische Systeme geeignet sind. Dies und mögliche Alternativen diskutiere ich zum Schluss dieses Blogs.

Das Modell

Hier ist ein Beispiel: die folgende Tabelle zeigt eine Tabelle mit Bundesländern und deren Bezirken. Die Beziehung („relation“) habe ich dadurch eingebaut, dass die Spalte „Teil_von“ aussagt, zu welchem Bundesland die entsprechenden Bezirke gehören. Die Verknüpfung habe ich durch einen eindeutigen Identifier (ID) hergestellt.

ID Name Typ Teil_von
1 Bayern Bundesland
2 Oberbayern Bezirk 1
3 Niederbayern Bezirk 1
4 Oberpfalz Bezirk 1
5 Oberfranken Bezirk 1
6 Unterfranken Bezirk 1
7 Mittelfranken Bezirk 1
8 Schwaben Bezirk 1

Das Beispiel zeigt bereits das Problem dieser Art der relationalen Abbildung: irgendwie passen diese Elemente nicht so recht zusammen. In der Regel werden daher mehrere Tabellen angelegt, die diese Darstellung vereinfachen (z.B. Bundeslaender, Bezirke). Diesen Vorgang nennt man „Normalisierung“.

Was passiert nun, wenn wir eine weitere Ebene einziehen wollen? Im Beispiel wären dies Kreisstädte und Landkreise. Dafür könnte man zwei weitere Tabellen angelegt werden.

Dieses Spiel lässt sich beliebig oft wiederholen, indem man zum Beispiel noch Stadtteile und Gemeinden abbildet.

An dieser Stelle haben wir nun eine Hierarchie von politischen Gebieten, das wie folgt aussieht:

hierarchie-politischegebiete-150x150

Zur Erläuterung: Kreisstädte haben entweder keinen Landkreis oder sind der Verwaltungssitz eines Landkreises.

Diskussion

Die Sinnhaftigkeit dieses Modells möchte ich nun dahingehend prüfen, ob es möglich ist, bestimmte Fragestellungen zu beantworten. Das Ziel sollte sein, möglichst einfache Algorithmen definieren zu können. Die Wartbarkeit oder Anpassungsfähigkeit sollte dabei nicht eingeschränkt werden. Im einfachsten Fall sollte die Datenbank die Fragestellung mit Bordmitteln abbilden und somit beantworten können.

Vorteile des relationen Modells

  • eindeutige Tabellen, denen wir je nach Anwendungszweck auch noch weitere Eigenschaften zuordnen können
  • einfache Beziehungen: jeder spezifischere Element (z.B. eine Gemeinde) ist genau einem allgemeinerem Element (z.B. genau einem Landkreis) zugeordnet
  • Abfragen wie „Alle Bezirke von Bayern“ oder „Alle Gemeinden im Landkreis Traunstein“ sind ohne großen Aufwand möglich

Nachteile des relationalen Modells

Komplexität entsteht in diesem Modell, wenn man über die Hierarchie suchen muss. Hier sind ein paar Beispiele:

  • die Suche eines beliebigen Elements der Hierarchie nach seinem Namen (z.B. „Tutzing“).
  • Die Hierarchie dieses Elements soll ausgegeben werden können.

Im konkreten Fall könnte man am einfachsten jede einzelne Tabelle abfragen. Dies wären sechs Abfragen.

Über den Fundort des Ergebnisses, wäre es dann wiederum möglich, die Hierarchie abzubilden. Dies bedeutet bei Ergebnissen auf Gemeinde- oder Stadtteil-Ebene eine Verknüpfung mit drei weiteren Tabellen.

Dies sind nun die Nachteile:

  • mehrere Requests, die programmatisch ausgewertet werden müssen
  • Aufbau von (teuren) Verknüpfungen über mehrere Tabellen
  • kontext-abhängige Abfragen

Für das o.g. Beispiel „Tutzing“ wäre die Hierarchie wie folgt: „Gemeinde Tutzing“, „Landkreis Starnberg“, „Bezirk Oberbayern“, „Bundesland Bayern“

Ergebnis und Ausblick

  • die Abbildung von hierarchischen Strukturen in Tabellen ist möglich
  • einfache Anfragen auf einer oder zwei Ebenen sind einfach zu realisieren
  • Suchen auf einer Ebene und damit auf einer Tabelle sind einfach
  • Suchen entlang der Hierarchie sind komplex und schwer abzubilden
  • die Abbildung komplexerer Fragestellungen stößt schnell an die Grenzen der Sprachmittel von relationalen Datenbanken

Zur Abbildung von hierarchischen Datenstrukturen ist das relationale Datenmodell somit nur bedingt geeignet.

Ausblick: eine gute Alternative bieten hier Graphen-Datenbanken. Es lohnt sich ein Blick auf Datenbanken wie Neo4j oder OrientDB.

Links