Cookies
Diese Website verwendet Cookies und ähnliche Technologien für Analyse- und Marketingzwecke. Durch Auswahl von Akzeptieren stimmen Sie der Nutzung zu, alternativ können Sie die Nutzung auch ablehnen. Details zur Verwendung Ihrer Daten finden Sie in unseren Datenschutz­hinweisen, dort können Sie Ihre Einstellungen auch jederzeit anpassen.

Engineering

Not only SQL - ein Blick über den relationalen Tellerrand
Minuten Lesezeit
Blog Post - Not only SQL - ein Blick über den relationalen Tellerrand
Nicolas Dillmann

In den vergangenen Jahrzehnten beherrschten relationale Datenbankmanagementsysteme (RDBMS) den Teil einer IT-Anwendung, welcher sich um die Speicherung und Bereitstellung von Daten kümmert. Bei relationalen Datenbanken werden Datensätze normalisiert in Relationen (Tabellen) gespeichert, welche mit der Datenbanksprache SQL (Structured Query Language) abgefragt oder manipuliert werden können. Ein Ziel dieser relationalen Speicherung ist es, redundante Datensätze zu verhindern, indem durch Normalisierung diese in eigene Relationen ausgelagert werden und mittels Fremdschlüssel oder Join-Tabellen mit der eigentlichen Tabelle verbunden werden. Ergebnis ist meist ein Datenbankschema, welches durch eine Vielzahl von Relationen keine Redundanzen enthält und eine konsistente Sicht auf die Daten gibt.

Zahlreiche Herausforderungen für Datenbankmanagementsysteme

  • Das mittlerweile allgegenwärtige World Wide Web lässt die Lese/Schreib-Raten gerade bei den international bekannten Web-Anwendungen kontinuierlich wachsen. Die Menge an zu speichernden Daten steigt dementsprechend rapide. Nicht nur die Anzahl an zu speichernden Stammdaten einer Anwendung steigt, sowohl im Web, als auch im Enterprise-Umfeld, sondern auch jede Nutzerinteraktion wird mittlerweile gespeichert. Dadurch wird auch die Auswertung von großen Datenmengen ein immer wichtigerer Faktor.
  • Das Aufkommen des Social-Webs führt zu einer starken Vernetzung von Daten, sowohl im World Wide Web, als auch im Social Intranet größerer Unternehmen. Der Siegeszug des Mitmach-Webs mit seinem User-generated content produziert Unmengen an unstrukturierten Daten, welche abgespeichert und auswertbar gemacht werden müssen.
  • Zu guter Letzt ist Skalierbarkeit in Verbindung mit Verfügbarkeit in weltweit verteilten Architekturen ein geschäftskritischer Faktor in modernen Anwendungen geworden.

All diese Herausforderungen bringen traditionelle RDBMS an ihre Grenzen. Fixe Datenschemata, machen es schwer, Datensätze zur Laufzeit dynamisch zu erweitern. „Kostspielige“ Joins lassen sich häufig nur durch Denormalisierung vermeiden. Die Skalierung in verteilten Systemen ist durch den hohen Stellenwert der Konsistenz von Daten in RDBMS und den darauf resultierenden Protokollen, wie z.B. dem Zwei-Phasen-Commit-Protocol, eine große Herausforderung.

NoSQL = Not only SQL

Unter dem Begriff NoSQL versteht man eine Art von (Open-Source-(Bewegung des 21. Jahrhunderts, die alternative DBMS mit nicht relationalen, häufig schemalosen Ansätzen entwickeln und vorantreiben. Der Schwerpunkt dieser Systeme liegt meist darin, die oben genannten speziellen Anforderungen moderner (Web-(Anwendungen erfüllen zu können. Dabei ist der Begriff NoSQL nicht etwa als „No SQL“ (Kein SQL) zu verstehen, sonder vielmehr als „Not only SQL“ (oder besser: not only relational).

Die Mischung macht’s

Bedeutet dies, dass klassische relationale Datenbanken in Zukunft überflüssig sein werden und NoSQL-DBMS jedes Datenspeicherungsproblem lösen werden? Die Antwort ist, wie so häufig: Es kommt darauf an! Jede Technologie hat Ihren eigenen Anwendungsbereich, keine Technologie löst jedes Problem. Moderne IT-Anwendungen werden vielmehr in Zukunft aus einer großen Menge an hochspezialisierten Technologien ihren Technologiemix auswählen können um ihre Problemstellung optimal lösen zu können. Im Kontext von DBMS spricht man dabei von Polyglot Persistence: Innerhalb einer IT-Anwendung koexistieren mehrere DBMS, die jeweils genau ein Problem lösen. Dabei soll die verwendete Technologie optimal auf die Anforderungen der Datenhaltung passen. Diese Vorteile müssen den damit einhergehende Anstieg der Komplexität innerhalb des IT Systems überwiegen.

"The era of relational mono-culture is over. We now have to ask what is the right database for our needs?"

Um den richtigen Technologiemix für sein Projekt auswählen zu können, ist es wichtig zu wissen, dass NoSQL für Datenbanktechnologien unterschiedlichster Richtungen steht. Grob kann man NoSQL-Datenbanksysteme in folgende Kategorien und ihre Implementierungen aufteilen:

  • Key-Value Stores (z.B. Redis, Memcached),
  • dokumentenorientierte Datenbanken (wie z.B. CouchDB, MongoDB),
  • spaltenorientierte Datenbanken (z.B. Cassandra, HBase),
  • Graphendatenbanken (wie Neo4j oder FlockDB),
  • sowie das Hadoop-Ökosystem.

Jede Kategorie eignet sich dabei für bestimmte Anwendungsbereiche und hilft, deren Herausforderungen optimal zu lösen. In den kommenden Wochen werden wir eine Serie an Blogeinträgen veröffentlichen, in denen wir auf die unterschiedlichen Datenbanktypen eingehen werden. So werden wir einen Überblick schaffen, welche Datenbanktechnologie auf welchen Problemtyp am besten passt. Wir werden dabei Einblicke in unterschiedliche Konzepte (z.B. Verteilte Systeme, das CAP-Theorem, ACID, BASE oder auch Map Reduce) geben, welche für die Evaluierung und Auswahl von Datenbanktechnologien relevant sind, und Pro und Contra für den Einsatz solcher Technologien herausarbeiten.

Hier geht´s zum zweiten Teil der NoSQL-Serie.

Ihr sucht den richtigen Partner für eure digitalen Vorhaben?

Lasst uns reden.