Open Source im professionellen Einsatz
Linux-Magazin 07/2015
© Pei Ling Hoo, 123RF

© Pei Ling Hoo, 123RF

Die Graphdatenbank Orient DB

Verknüpfte Welten

Die Orient DB eignet sich als flexibles Backend zum Speichern und Abfragen von Graphenstrukturen. Doch welche Vorteile sind damit verbunden? Was kann eine NoSQL-Graph-DB besser als eine relationale Datenbank? Zeit für einen Blick auf die Details.

1141

Lange Zeit galten relationale Datenbanken als Nonplusultra. Dafür musste deren Benutzer allerdings alle Datenmodelle in das Tabellenkonzept pressen. Das erwies sich in den letzten Jahren aber zunehmend als zu starr. Wo es zum Beispiel darum geht, die Beziehungen von Objekten untereinander zu speichern, ist mit Tabellen keine einfache und elegante Lösung möglich.

Datenbankkonzepte wie Dokument- und Graphdatenbanken etablierten sich als Alternative unter dem Schlagwort "Not Only SQL" (NoSQL). Ein Vertreter dieser Zunft ist die Orient DB, ein Datenbankserver, der sowohl als Dokument- wie als Graphdatenbank nutzbar ist.

Dieser Artikel demonstriert ein paar Möglichkeiten der Orient DB, die sich mit klassischen relationalen Datenbanken nicht umsetzen lassen. Das liegt an der vollkommen anderen Art und Weise, mit der die Datenbank ihre Daten ablegt. Abbildung 2 zeigt einen Vergleich: Relationale Datenbanken halten alle Daten in Tabellen, dort gibt es eine Spalte für jedes Attribut. Die Tabellen stellen zur Laufzeit ein starres Schema dar, zusätzliche Attribute erfordern entweder eine Anpassung der bestehenden Tabellen oder gar die Definition einer zusätzlichen Tabelle. Beides bringt einen Eingriff durch den Datenbankadministrator mit sich, gegebenenfalls sogar eine Migration der ganzen Datenbank.

Abbildung 2: Der Beispielgraph für die Abfragen bei drei Datenbankklassen.

Bei Dokumentdatenbanken liegen die Daten jedes Objekts in einem Dokument (XML, Json, …) vor. Jedes Dokument hat eine eindeutige ID, die die Datenbank benutzt, um es zu laden. Objektverknüpfungen stellen die Dokumente durch ID-Referenzen auf andere Dokumente dar. Zusätzliche Attribute lassen sich leicht in das Dokument einfügen.

Damit ist das Konzept zwar flexibler als die relationale Datenbank. Ein Nachteil ist allerdings, dass die Datenbank die Dokumente bei der Suche oder zur Verfolgung von Objektbeziehungen immer erst laden muss.

Graphdatenbanken beruhen auf zwei Basisobjekten: Den Knoten und den verbindenden Kanten. Beide können beliebige Attribute speichern, eine spezielle Deklaration ist meist nicht notwendig. Dadurch ergibt sich ein flexibles Datenmodell, das eine schnelle Traversierung über die Objekte möglich macht. Typische Anwendungsfälle sind alle Arten von sozialen Netzwerken (wer mit wem, wann und wo). Auch die Speicherung von Baugruppen-, Dokumenten- oder Projektstrukturen nutzt die flexible Abbildung von komplexen Abhängigkeiten und Querverweisen.

Die Orient DB implementiert zwei Konzepte: Die Basis bildet die Dokumentdatenbank, darüber ermöglicht ein Layer die Nutzung als Graphdatenbank.

Installation

Die Software steht auf der Webseite [1] fertig kompiliert als Tar-Archiv zur Verfügung. Nach dem Download entpackt der Admin das Archiv an einer beliebigen Stelle. Für die ersten Schritte lässt sich der Server ohne weitere Konfiguration mit dem Skript »bin/server.sh« starten. Beim ersten Hochfahren fragt die Datenbank nur ein Passwort für den Datenbank-Rootanwender ab.

Damit ist die Installation bereits abgeschlossen, für eine produktive Installation sollte der DBA die Datenbank allerdings mit SSL konfigurieren, da sonst die Daten und Passwörter im Klartext über das Netzwerk gehen.

Für die direkte Nutzung stehen eine Webanwendung sowie die etwas spröde, aber mächtige Konsole zur Verfügung. Der Anwender startet sie mit »bin/console.sh« . Danach kann er sich mit »connect remote:localhost root Passwort« an der Datenbank anmelden. Während andere NoSQL-Datenbanken sich bei der Abfragesprache von relationalen Datenbanken abgrenzen, setzt die Orient DB soweit möglich auf SQL. Der Anwender muss also keine neue Sprache lernen, nur für die zusätzlich hinzukommenden Fähigkeiten braucht es extra Kommandos. In der Konsole gibt der Help-Befehl einen Überblick über verfügbare Kommandos, eine umfangreichere Doku steht im Orient-DB-Wiki [2] zur Verfügung.

Erste Schritte

Das erste Beispiel basiert auf Figuren und Büchern der Scheibenwelt-Serie des in diese Jahr verstorbenen genialen Terry Pratchett (Abbildung 1). Es kennt zwei Knotentypen »Person« und »Buch« , die über die beiden Kanten »Beziehung« und »Auftritt« verbunden sind. Knoten und Kanten haben unterschiedliche Attribute, die direkt oder als Liste beziehungsweise Map verwendbar sind.

Abbildung 1: Diese Beispieldatenbank erläutert die Beziehungen von Figuren der Scheibenwelt-Serie.

Das Listing 1 enthält auszugsweise die Konsolen-Kommandos, die der Anwender braucht, um den Graphen zu erstellen. In den ersten beiden Zeilen konnektiert er zunächst die Konsole mit dem Server und legt anschließend eine neue Datenbank mit dem Namen »discworld« an. Nach dem Anlegen verbindet sich die Konsole ganz automatisch mit der neuen Datenbank.

Listing 1

Datenbank anlegen

01 connect remote:localhost root password
02 create database remote:localhost/discworld root password plocal
03
04 create class Person extends V;
05 create property Person.geburtstag date;
06
07 create class Buch extends V;
08 create property Buch.uebersetzung embeddedmap;
09
10 create class Beziehung extends E;
11 create property Beziehung.von date;
12
13 create class Auftritt extends E;
14 create property Auftritt.kapitel embeddedlist integer
15
16 insert into Person (nachname, vorname, geburtstag) values ('Vimes', 'Samuel', '1962-04-03');
17 insert into Person (nachname, vorname, geburtstag) values ('Sybil', 'Ramkin', '1969-09-06');
18
19 insert into Buch (name, uebersetzung) values ('Guards ! Guards !', {'de':'Wachen ! Wachen !', 'fr' : 'Au Guet !'} );
20
21 create edge Beziehung from #11:0 to #11:1 set typ='Verheiratet', von='1993-01-01';
22
23 create edge Auftritt from #11:0 to #13:0 set kapitel={1,2,3,4,5,6};

Graphdatenbanken enthalten die Basistypen V (Knoten) und E (Kante). Auf ihrer Grundlage definiert das Listing die hier genutzten Typen. Ab Zeile 4 legt es die Klassen »Person« und »Buch« als Erweiterung des Basisknotens an und bestimmt ihre Attribute. In der Orient DB stehen die üblichen Primitive wie Integer, String oder Date zur Verfügung, es lassen sich wie ab Zeile 8 auch Listen, Sets oder Maps verwenden. Das Attribut »uebersetzung« in der Buch-Klasse enthält die Map »Sprache : Titel« , das Attribut »kapitel« nimmt die Kapitel auf, in denen eine Person auftritt. Relationale Datenbanken müssten hierfür eine zusätzliche Tabellen definieren.

Die Kantenklassen »Beziehung« und »Auftritt« definieren sich ähnlich wie Knotenklassen, nur ist die Basisklasse jetzt »E« statt »V« . Anders als bei relationalen Datenbanken muss man bei den Kanten nicht unterscheiden, ob sie eine 1:1-, 1:n- oder m:n-Beziehung repräsentieren. Jede Kante stellt eine 1:1-Beziehung zwischen zwei Knoten dar. Dafür darf es aber beliebig viele Kanten geben, die von einem Knoten ausgehen oder auf einen Knoten verweisen.

Die Knotenerzeugung nutzt das klassische Insert-Statement, bei dem die Zielklasse und die Attributwerte anzugeben sind. Dass bei der Definition der »Person« die Attribute »nachname« und »vorname« nicht angegeben wurden, bestraft die Datenbank an dieser Stelle nicht mit einer Fehlermeldung, sie legt diese Attribute beim Einfügen dynamisch an.

Um Listen, Sets oder Maps zu füllen, akzeptiert die Orient DB eine Json-ähnliche Schreibweise (Zeile 18). Orient DB vergibt für jeden Knoten eine eindeutige Objekt-ID (zum Beispiel #11:3), die sich später zur Suche beziehungsweise zum Erzeugen der Kanten nutzen lässt.

Kanten sind mit dem neuen »create edge« -Statement zu erzeugen. Neben der ID des Start- und Zielobjekts können Kanten wie die Knoten beliebige Attribute tragen.

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 5 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

  • Graphdatenbanken

    Sie erkennen mit klarem Blick die wirklich relevanten Beziehungen im Social Web, verstehen die Sprache, finden zielstrebig die kürzesten Wege und optimieren Besucherströme. Das sind die Aufgaben, die Graphdatenbanken mit Bravour erledigen. Dieser Artikel vergleicht fünf blaublütige Open-Source-Vertreter.

  • Perl-Snapshot

    Die Graphdatenbank Neo4j eignet sich viel besser als relationale Datenbanken, um Knoten und deren Beziehungen zueinander zu speichern und gezielt abzufragen. Wessen Freundeskreis nicht verworren genug ist, um als Graph-basierter Anwendungsfall durchzugehen, inventarisiert eben sein LAN damit.

  • Linuxtag 2011: Die Simpsons in der Graphdatenbank

    Wozu braucht man eine Graphdatenbank? Daniel Kirstenpfad von der Sones GmbH erläuterte das in seinem Linuxtag-Vortrag anhand der hauseigenen Software.

  • Schnellgericht

    Aufgießen, umrühren - fertig. Lange vermissten Umsteiger von Microsofts Büropaket auf Star Office oder Open Office eine Instant-Datenbank à la Access. Mit der Open-Office-Version 2 integriert das Büropaket nun erstmals eine solche Komponente, die in Minuten einsatzbereit ist und die Lücke füllen könnte.

  • Objekte statt Tabellen

    In objektorientiertem Programmcode wirken SQL-Abfragen wie Fremdkörper. Zudem unterscheiden sich die SQL-Dialekte verschiedener Datenbanken. Die Lösung: Der Objekt-Relational-Mapper SQL Object stellt ein einheitliches objektorientiertes Interface zur Verfügung.

comments powered by Disqus

Ausgabe 11/2017

Digitale Ausgabe: Preis € 6,40
(inkl. 19% MwSt.)

Stellenmarkt

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.