Datenbankdesign – die Qual der Wahl

Native oder nicht-native Graphdatenbank?

| Autor / Redakteur: Dr. Jim Webber * / Stephan Augsten

Datenverarbeitung in einer nativen Graphdatenbank.
Datenverarbeitung in einer nativen Graphdatenbank. (Bild: Neo4j)

Die Wahl des richtigen Datenbanksystems oder Datenbank-Management-Systems hängt immer von den jeweiligen Applikationsanforderungen ab. Grundlegend ist dabei die Frage nach dem Design – nativ oder nicht-nativ.

Generell sollte beim Design eines DBMS jene Datenstruktur gewählt werden, die sowohl das Datenmodell als auch Abfrage-Workloads bestmöglich unterstützt. Jede Datenstruktur ist für einen bestimmten Zweck ausgelegt und keine Datenstruktur ist universell einsetzbar. Vielmehr existieren unterschiedliche Strukturen für spaltenorientierte, relationale, dokumentbasierte oder eben auch graphbasierte Systeme. Eine entscheidende Frage lautet hier: Soll ein natives oder ein nicht-natives Design für das Datenbanksystem gewählt werden.

Native Graphdatenbanken sind beispielsweise bereits in der Entwicklung konsequent auf die sichere und effiziente Verarbeitung von Graphen ausgelegt. Das betrifft die Abfragesprache, die Datenbank-Management-Engine, die Repräsentation auf dem Dateisystem sowie Clustering, Backup und Monitoring. Sie sind speziell dafür konzipiert, Abfragen im Graphen durchzuführen (Affordance) und Graph-Workloads zu bewältigen.

Bei nicht-nativen Graphdatenbanken handelt es sich im Grunde nur um Erweiterungen eines bestehenden Systemdesigns, das soweit optimiert wird, bis sie für ein Graphdatenmodell die höchstmögliche Effizienz erreicht. Die resultierende Software ist zwar nativ – ausgelegt auf Spalten, Dokumente oder Tabellen – aber nicht nativ für Graphen. Es gibt zwei Varianten dieser Erweiterungen um Graph-Features: Die eine Variante verwendet eine Engine mit multimodaler Semantik auf einem darunterliegenden nativen Modell. Die andere Variante setzt eine Graph-API auf ein vorhandenes Datenbanksystem auf.

Die Unterschiede im Design einer Datenbank zeigen sich auch in der Praxis:

  • Generell führen native Technologien Graphabfragen schneller durch, lassen sich besser skalieren (ohne Einbußen bei der Abfragegeschwindigkeit und wachsender Datenmenge) und laufen auf leistungsschwacher Hardware weitaus effizienter.
  • Nicht-native Graphdatenbanken führen hingegen 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 gerecht werden.

Eigenschaften von Datenbanken im Vergleich

Um einen Vergleich zwischen nativen und nicht-nativen Graphdatenbanken zu ziehen, werden im Folgenden die Designs hinsichtlich drei wesentlicher Kriterien für Datenbanksysteme genauer untersucht: Speicherung, Abfrageverarbeitung und Performance.

Speicherung

Der Begriff „Graph-Speichersystem“ bezieht sich auf die zugrunde liegende Struktur der vernetzten Daten, die sich in der Regel auf einem Massenspeicher befinden. Nativ ist dieses System, wenn das Dateisystem konsequent auf die Verarbeitung von Graph-Workloads ausgelegt ist. Es ist daher für die Speicherung von Graphdaten besonders sicher.

Die Speicherformate ermöglichen dann eine indexfreie Nachbarschaft (Adjazenz) zur Unterstützung schneller Traversierungen auch bei langsamen Speichersystemen. Die gewählten Schreibstrategien sorgen zudem selbst bei Systemstörungen für Konsistenz.

Die weite Verbreitung von herkömmlichen, relationalen Datenbanken in Unternehmen verleitet dazu, Graphdaten zunächst mit solchen Systemen zu speichern und zu verarbeiten. Dabei zeigt sich jedoch sehr schnell, dass nicht-native Konzepte unweigerlich zu Problemen bei Performance, Konsistenz und Skalierbarkeit führen.

Der einzige empirisch belegte Weg, die Datensicherheit zu gewährleisten, ist die Aktualisierung des feingranularen Graphmodells mit Hilfe von Transaktionen (ACID = atomare, konsistente, isolierte und dauerhaften Operationen). Nichttransaktionale Modelle können die Aufrechterhaltung von konsistenten Beziehungen zwischen den Datensätzen jedoch nicht leisten.

Bei nicht-nativen Graphdatenbanken, die auf „eventual consistent“-Ansätzen aufgebaut sind, kann es zu Datenkorruption kommen – insbesondere wenn es sich um Datenbanken handelt, die um Graph-Features erweitert wurden. Anders bei nativen Graphdatenbanken: Hier gewährleisten die Transaktionsmechanismen, dass selbst bei Netzwerkstörungen, Serverausfällen oder Konflikten aufgrund konkurrierender Transaktionen oder Skalierungsentscheidungen Datensicherheit besteht.

Inhalt des Artikels:

Kommentare werden geladen....

Kommentar zu diesem Artikel

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45111312 / Datenbanken)