Fotolia

Pro und Contra: Native versus nicht-native Graphdatenbanken

Erfahrungswerte helfen, die richtige Datenbank zu finden. Für vernetzter Dinge besteht dabei oft die Frage: native oder nicht-native Graphdatenbank?

Dieser Artikel behandelt

Datenbanksysteme

ÄHNLICHE THEMEN

Die zunehmende Verbreitung von Graphdatenbanken zeigt, wie wichtig es für Unternehmen geworden ist, Beziehungen zwischen Daten effektiv zu nutzen.

Dabei greifen sie auf unterschiedliche Lösungen zurück. Geht es darum, Anwendungen zu entwickeln, die auf Basis von Echtzeit-Auswertungen Entscheidungsfindung und Prozesse vereinfachen, lauten die Schlüsselelemente für Graphdatenbanken Integrität, Performance, Effizienz und Skalierbarkeit.

Jedes Datenbank-Management-System (DBMS) verfolgt – ob gewollt oder nicht – ein anderes Designkonzept. Infolgedessen unterscheiden sich auch die erstellten Datenbanken. Welche Datenbank für die jeweiligen Anforderungen und Anwendungen die richtige ist, lässt sich nicht immer leicht bestimmen. In manchen Fällen müssen dabei Kompromisse beim Design in Kauf genommen werden.

Natives oder nicht-natives Design

Erfahrungswerte helfen dabei, die richtige Technologie zu finden. Eine grundlegende Entscheidung ist dabei die Wahl zwischen einem nativen und einem nicht-nativen Design des Datenbanksystems.

Wie der Name sagt, sind native Graphdatenbanken speziell auf die Bewältigung von Graph-Workloads, also stark vernetzten Daten, ausgelegt. Angefangen bei der Abfragesprache, der eigentlichen Datenbank, dem Dateisystem bis hin zu Clustering und Monitoring – native Graphdatenbanken verkörpern graphbasiertes Denken.

Das gilt auch für die native Graphdatenbank Neo4j: Hier sind die Softwarekomponenten auf allen Schichten durchgehend auf die Graphstruktur ausgerichtet. Wichtig ist, dass die Daten sicher sind und dass das gesamte System verlässlich arbeitet. Das ist nur möglich, wenn jede einzelne Komponente für Graphtechnologie optimiert ist und kein Teilbereich der Verarbeitung von andersartigen Komponenten übernommen wird.

Bei den nicht-nativen Datenbanken gibt es zwei Varianten: Die eine Variante setzt eine Graph-API auf ein vorhandenes Datenbanksystem auf. Die andere Variante verwendet eine Engine mit multimodaler Semantik auf einem darunterliegenden nativen Modell.

Zwischen der Architektur einer nativen und einer nicht-nativen Speicherung und Abfrage von Graphen gibt es einen gravierenden Unterschied. Native Technologien führen Abfragen schneller durch, lassen sich besser skalieren (ohne Einbußen bei der Abfragegeschwindigkeit und wachsender Datenmengen) und laufen auf weniger anspruchsvoller Hardware weitaus effizienter.

Umgekehrt führen nicht-native Graphdatenbanken eine Optimierung zugunsten von Workloads auf ihrem primären Datenmodell durch, was zulasten von Graphen geht. Oder sie kämpfen mit den Komplexitäten einer multimodalen Schicht und können oft nicht allen Aspekten ebenmäßig gerecht werden.

Natives Graphspeichersystem

Der Begriff Graphspeichersystem bezieht sich auf die zugrunde liegende Struktur der vernetzten Daten, die sich (oft, aber nicht immer) auf einem Massenspeicher befinden. Wenn dieses System speziell auf die Speicherung von Graphdaten ausgelegt ist, wird es als natives Graphspeichersystem bezeichnet.

Eine Datenbank, die konsequent zur Nutzung eines graphorientierten Dateisystems konzipiert ist, zeichnet sich bei der Verarbeitung von Graph-Workloads sowohl durch hohe Leistung als auch durch hohe Sicherheit aus. Eine Traversierung über eine Beziehung in Neo4j benötigt eine konstante Menge an Ressourcen – unabhängig von der Größe des Graphen aufgrund der direkten Abbildung von Verknüpfungen auf Hardwareadressen. Diese Anforderungen sind wegen des guten Zusammenspiels zwischen Software und Hardware niedrig.

Ein Datenbankspeichersystem gilt als nicht graph-nativ, wenn es auf ein anderes Speichermodell optimiert ist, wie zum Beispiel ein relationales, ein spaltenorientiertes, ein dokumentenbasiertes oder ein Key-Value-Modell.

Sollen Daten in einem dieser Speichermodelle für einen Graphen genutzt werden, muss das Datenbanksystem aufwendige Transferarbeiten zwischen beiden Modellen vornehmen. Man kann zwar versuchen, diesen Aufwand durch radikale Denormalisierung zu senken. Dies geht jedoch auf Kosten von Latenzzeiten. Eine solche Denormalisierung verstärkt zudem die Risiken für die Datensicherheit.

Datensicherheit und neue Hardwarearchitekturen

Die Verarbeitung von Graphdaten mit nicht dafür vorgesehenen Speichersystemen ist auch unter den Gesichtspunkten Leistung und Skalierbarkeit problematisch. Datensicherheit wird nur dadurch erzielbar, dass das feingranulare Graphmodell mit Hilfe von Transaktionen (ACID, also atomare, konsistente, isolierte und dauerhaften Operationen) aktualisiert wird.

Die Aufrechterhaltung von konsistenten Beziehungen zwischen den Datensätzen ist unabdingbar und weit anspruchsvoller, als dies nichttransaktionale Modelle leisten können. Die Transaktionsmechanismen von nativen Graphdatenbanken gewährleisten, dass die Datensicherheit nicht durch Netzwerkstörungen, Serverausfälle oder Konflikte aufgrund konkurrierender Transaktionen oder Skalierungsentscheidungen gefährdet ist. Nicht-native Grapharchitekturen, insbesondere Varianten, die auf Eventual-Consistent-Ansätzen aufgebaut sind, lassen die Graphendaten inkonsistent werden.

Zudem ermöglicht ein natives Speichersystem eine Anpassung an künftige Hardwarearchitekturen. Mit der Weiterentwicklung der Speicher- und Festplattentechnologien wird sich auch die entsprechende Unterstützung der Graph-Workloads weiterentwickeln. Für Neo4j ist zum Beispiel zu erwarten, dass sich das native Speichermodell an neuartige Massenspeicher und Speicherarchitekturen anpassen wird, beispielsweise an nicht-flüchtigen RAM und Multi-Terabyte Speicher.

Native Graphabfragen

Graphabfragen – die Aspekte von Abfragedefinition, -planung und -optimierung – sind ein weiterer erheblicher Vorteil von Graphtechnologie. Bei einem nativen Graphsystem ist jede Ebene der Architektur auf das Speichern und Abrufen von Graphdaten optimiert: von der Klausel für Musterfindung in Cypher, der Abfragesprache von Neo4j, bis hin zu den Dateien auf dem Speichermedium.

Durch umfassende Denormalisierung versuchen einige nicht-native Graphdatenbanken, Nachteile zu vermeiden. Beispielsweise lässt sich ein nicht-natives Speichersystem für circa drei Ebenen von Traversierungen optimieren, indem Daten dupliziert oder neu angeordnet, oder zunehmend komplexe Indizes für jede Abfrage erstellt werden. Damit wird die Komplexität und Aufwand für Aktualisierungen in der Datenbank deutlich erhöht.

Je weiter die Abfragetiefe voranschreitet, umso drastischer verschlechtert sich die Abfrageleistung. Native Systeme hingegen weisen auf jeder Traversierungstiefe eine durchgängig hohe Performance auf. Bei nicht-nativen Systemen scheinen Abfragen zunächst schnell abgearbeitet zu werden. Ab einer bestimmten Schwelle steigen die Latenzzeiten jedoch steil an, ohne dass für den Endbenutzer der Grund erkennbar wird.

„Erfahrungswerte helfen dabei, die richtige Technologie zu finden. Eine grundlegende Entscheidung ist dabei die Wahl zwischen einem nativen und einem nicht-nativen Design des Datenbanksystems.“

Jim Webber, Neo4j

Neo4j kennt die Probleme aus eigener Erfahrung. Bei frühen Implementierungen (in den Jahren 2000 bis 2003) war die Neo4j Graphdatenbank ein nicht-natives System, das mit einer Graph-API arbeitete, die auf einer relationalen Datenbank aufsetzte. Wenn Abfragen mit einer Traversierungsstiefe von etwa drei Ebenen oder mehr anfielen, brach die Leistung extrem ein. Zudem ist es bei der nicht-nativen Verarbeitung von Graphen in einem relationalen Datenbank-Management-System äußerst schwierig, die Richtung einer Traversierung umzukehren. Hierzu musste man entweder einen aufwendigen Reverse-Lookup-Index für jeden Anwendungsfall erstellen oder eine detaillierte Suche (Scan) im Originalindex machen. Beide Ansätze sind auf Dauer – gemessen an Leistung und Aufwand – nicht vertretbar.

Vorteile einer nativen Grapharchitektur

Eine native Grapharchitektur bietet einige Vorteile:

  1. Millisekunden statt Minuten: Native Graphdatenbanken verarbeiten verbundene Datenabfragen schneller als nicht-native Graphdatenbanken. Auch auf leistungsschwacher Hardware können native Graphdatenbanken problemlos mehrere Millionen Traversierungen pro Sekunde zwischen Knoten in einem Graphen und viele Tausend Schreibtransaktionen pro Sekunde auf einer einzigen Maschine verarbeiten.
  2. Datenintegrität für Graphen: Wenn bei nativen, transaktionalen Graphdatenbanken eine Transaktion abgeschlossen ist, heißt das, dass die Daten konsistent und dauerhaft sicher sind, auch wenn der Vorgang auf mehreren Servern stattfindet. Zudem stehen Transaktionen aufgrund der Transaktionsinfrastruktur nicht im Konflikt. Derartige Transaktionen werden automatisch erkannt und zurückgesetzt. Im Fehlerfall bleiben keine inkonsistenten Datensätze zurück.
  3. Effizienz: Im Unterschied zu nicht-nativen Graphmodellen können native Graphdatenbanken Traversierungen in konstanter Zeit mit Hilfe von Adjazenzstrukturen (index-frei) ohne komplexe Schemakonstruktionen und Abfrageoptimierungen erzeugen. Dieses intuitive Graphmodell erübrigt eine zusätzliche und oft unnötig komplexe Anwendungslogik zur Verarbeitung von Verbindungen.

Warum native Architekturen?

Noch immer herrscht die Überzeugung, nicht-native Graphtechnologie sei gut genug, um die nötigen Anforderungen zu erfüllen. Doch Datensätze wachsen beständig, sind zunehmend frei strukturiert und haben mehr Beziehungen untereinander als je zu vor. Der eigentliche Wert der Daten liegt oftmals in diesen Verknüpfungen. Ein nicht-natives Design konzentriert sich aber nicht darauf. Daher ist eine native Graphdatenbank auf lange Sicht für Unternehmen die bessere Wahl und setzt zudem keine komplexe Hardwareinfrastruktur voraus.

Über den Autor:
Jim Webber ist Chief Scientist bei Neo4j und entwickelt Lösungen der nächsten Generation für die massive Skalierung von Graphdaten. Vor seinem Eintritt bei Neo4j war Webber Professional Services Director bei ThoughtWorks, wo er an Großrechnersystemen für die Finanz- und Telekommunikationsbranche arbeitete. Er besitzt einen Doktortitel in Computing Science (Informatik) der Newcastle Universität, England.

Folgen Sie SearchEnterpriseSoftware.de auch auf Twitter, Google+, Xing und Facebook!

Nächste Schritte

Graphdatenbanken festigen Beziehungen zwischen Datenelementen.

Graphdatenbanken: Behörden entdecken den Wert von Datenbeziehungen.

Panama Papers mit Graphdatenbank und Visualisierungssoftware enthüllt.

Artikel wurde zuletzt im September 2017 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Datenbanksysteme

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchStorage.de

SearchNetworking.de

SearchDataCenter.de

Close