Ein Kommentar zur Datenbank-Mode Alles NoSQL oder was? Zur Zukunft der relationalen Datenbanken

Autor / Redakteur: Bruce Momjian / Ulrike Ostler

Bruce Momjian von EnterpriseDB wirft einen Blick auf den Erfolg von NoSQL-Datenbanken und bezieht Stellung zur Frage, ob diese das Ende der relationalen Datenbanken einläuten.

Firmen zum Thema

Bruce Momjian ist Senior Database Architect bei EnterpriseDB, einem Anbieter von professionellen PostgreSQL-Produkten/-Dienstleistungen und Kompatibilitätslösungen zur Oracle-Datenbank, und Mitbegründer der PostgreSQL Global Development Group.
Bruce Momjian ist Senior Database Architect bei EnterpriseDB, einem Anbieter von professionellen PostgreSQL-Produkten/-Dienstleistungen und Kompatibilitätslösungen zur Oracle-Datenbank, und Mitbegründer der PostgreSQL Global Development Group.
(Bild: EnterpriseDB)

NoSQL ist heute in aller Munde, und vielerorts wird über einen Wechsel zu NoSQL-Datenbanksystemen nachgedacht. Anwender von Datenbanken haben den Eindruck gewonnen, dass relationale Datenbanksysteme bereits Technologie von gestern sind und die Zukunft vor allem in NoSQL steckt.

Sie sehen natürlich die vielbesuchten Websites auf NoSQL-Basis und gehen daher davon aus, dass diese Unternehmen zu den Vorreitern einer neuen Anwenderwelle von einer neuen Technologie gehören. Diese Logik ist jedoch nicht ganz schlüssig.

Erstens handelt es sich bei NoSQL nicht um eine bestimmte Technologie – genauer gesagt, es handelt sich hier eigentlich um eine Gegentechnologie: Denn jede Datenbanktechnologie, die nicht die SQL-Abfragesprache verwendet, kann sich NoSQL nennen.

Welche NoSQL-Typen gibt es?

Moderne NoSQL-Datenbanken repräsentieren vier verschiedene Gruppen von Technologien: Key Value Stores (schlüsselorientierte Datenbanken), Document Databases (dokumentorientierte Datenbanken), Column Stores (spaltenorientierte Datenbanken) und Graph Databases (Graph-Datenbanken). Eine NoSQL-Technologie kann man nicht einfach aussuchen – man muss überlegen, welche NoSQL-Technologie eingesetzt werden soll.

Zweitens: Viele große Websites haben sich für NoSQL entschieden – kann man daraus also schließen, dass dies auch für alle die bessere Lösung ist? Nun, nicht unbedingt, denn Websites mit hohem Besucheraufkommen stellen ihre eigenen, atypischen Anforderungen an die Skalierung und sind daher auch bereit, stärker in die Softwareentwicklung zu investieren, um die Skalierung zu realisieren. Ist dies auch in Ihrem Unternehmen der Fall? Wahrscheinlich eher nicht.

Wie steht es mit SQL?

SQL wird seit 25 Jahren als Standard verwendet. Es genießt in der Branche eine starke Verbreitung, und es gibt ausgereifte Tools, um eine hohe Produktivität zu erzielen. SQL ist seit Jahrzehnten die Standardlösung der Datenbankwelt und bietet Unternehmen eine flexible, standardisierte Schnittstelle für den Zugriff auf ihre Daten. NoSQL-Technologien entstanden aus der Notwendigkeit heraus, eine Skalierung ohne den Overhead von SQL zu erreichen.

Jedoch darf aber nicht vergessen werden, dass man für eine solche Skalierung einen Preis zahlt – und oft einen sehr hohen. Häufig lassen NoSQL-Systeme nämlich die Flexibilität, einfache Administration und produktiven Entwicklungsmöglichkeiten von SQL-Systemen vermissen. Wenn Sie ein großes Unternehmen sind und eine sehr große Lösung benötigen, sind Sie vielleicht bereit, diese hohen Kosten dafür auch zu tragen, aber was ist mit den sogenannten „normalen“ Unternehmen?

Wollen Sie programmieren?

Ein Beispiel: Je nach gewählter NoSQL-Datenbank erhalten Sie vielleicht eine bessere Leistung, eine bessere Skalierung der Schreibzugriffe oder eine Datenbanksprache, die sich besser mit der Sprache Ihrer Applikation verträgt. Andererseits kann es aber sein, dass die Datenbanksprache weniger Ausdrucksmöglichkeiten oder Flexibilität bietet oder dass die NoSQL-Datenbank weniger gleichzeitige Zugriffe erlaubt oder dass ihre Dauerhaftigkeit („Durability“) nicht garantiert ist.

Wären Sie bereit, ein Programm („Concurrency“) zu schreiben, um einen Report aus Ihrer Datenbank abzurufen? Könnten Sie damit leben, nur ein begrenztes Sprachangebot für den Zugriff auf Ihre Daten nutzen zu können?

Viele NoSQL-Datenbanken bieten keine ACID-Garantien im Hinblick auf Leistung und Skalierung. Dies kann für Ihre spezifische Aufgabe in Ordnung sein, muss es aber nicht. Und falls dies nicht der Fall ist, müssten Sie die benötigten Concurrency- und Durability-Merkmale per Software in ihre Applikation oder Middleware integrieren. Eine solche Implementierung kann jedoch eine komplexe und schwierig zu testende Angelegenheit sein.

Gestatten? Ein Blick zurück

Es ist nicht neu, dass die Vorherrschaft der SQL-Datenbank in Frage gestellt wird. In den 90er Jahren wurden Objektdatenbanken als Möglichkeit propagiert, Daten in einem Format zu speichern, das besser zu objektorientierten Sprachen passte. Leider waren aber die Objektdatenbanken zu eng mit bestimmten objektorientierten Sprachen gekoppelt und erschwerten daher einen flexiblen Datenzugriff. Objektdatenbanken verloren bald die Gunst der Anwender, und objektrelationale Abbildungslösungen (Object-relational Mappers, ORM) gewannen an Beliebtheit.

Ein Jahrzehnt später kamen dann XML-Datenbanken in Mode, die eine flexible Speicherung für XML-basierte Applikationen erlaubten. Relationale Systeme führten bald ebenfalls die XML-Speicherung ein, und reine XML-Datenbanken verschwanden ebenfalls wieder von der Bildfläche.

NoSQL-Datenbanken werden nie völlig verschwinden, ebenso wie es immer noch Objektdatenbanken und XML-Datenbanken gibt. Jedoch werden sich die SQL-Datenbanken entsprechend weiterentwickeln. SQL-Datenbanklösungen lernen aus der Unzufriedenheit der Anwender mit den Einschränkungen von SQL und führen Merkmale ein, mit denen sie die Lücke füllen, welche die Anwender zum Wechsel zu NoSQL bewegt hat.

Kennen Sie Postgres?

In Postgres wurden zahlreiche NoSQL-typischen Funktionsmerkmale realisiert, die eine weitergehende Skalierung, nicht-dauerhafte Datenhaltung und die Bearbeitung von JSON-Daten unterstützen – hierdurch gelangen die Anwender in den Genuss von NoSQL-Features, während gleichzeitig die Vorteile der relationalen SQL-Systeme erhalten bleiben.

Wenn Sie also NoSQL in Betracht ziehen, können Sie wählen: NoSQL verwenden und seine Beschränkungen akzeptieren oder SQL behalten und zusätzliche NoSQL-Features mit modernen SQL-Datenbanken wie Postgres nutzen.

Der Autor:

Bruce Momjian, Mitarbeiter von EnterpriseDB, ist Mitbegründer der PostgreSQL Global Development Group. Er arbeitet bereits seit 1996 an PostgreSQL mit und ist auch Autor des Buches „PostgreSQL: Introduction and Concepts“ (erschienen bei Addison-Wesley).

Vor seiner Tätigkeit für EnterpriseDB war er bei SRA Japan und Great Bridge LLC, beides Anbieter von PostgreSQL-Supportleistungen, tätig. Bruce Momjian hält regelmäßig Vorträge auf internationalen Open-Source-Konferenzen.

Vor seiner PostgreSQL-Zeit arbeitete er als Berater und entwickelte kundenspezifische Datenbank-Applikationen für einige der weltgrößten Anwaltskanzleien. Während seiner akademischen Laufbahn war Momjian fünf Jahre lang als Informatiklehrer an High Schools tätig. Er besitzt einen Masters-Abschluss in Erziehungswissenschaft und ist derzeit Gastprofessor an der Drexel University.

Artikelfiles und Artikellinks

(ID:42367421)