Duell der Datenbanken: In einem Shootout messen sich MySQL und PostgreSQL. Der Schwerpunkt vom ADMIN 06/2011 überprüft, wer schneller ist und gibt einen ... (mehr)

Datenbanken bewerten

Leider sind die Alternativen zu den relationalen Platzhirschen (Oracle, MySQL) viel zu wenig bekannt. Andere als relationale Modelle werden auch in Universitäten kaum gelehrt. Weiterhin gibt es kaum Richtlinien, wie man die beste Datenbank findet. In [1] wurde daher erstmals versucht, einen Leitfaden oder eine Checkliste zu erstellen, die dabei hilft, die beste Datenbank für den Einsatzzweck zu finden. Die wichtigsten Kernelemente sind daher funktionale und nicht-funktionale Anforderungen:

Datenanalyse: Jedes Projekt muss zunächst die Daten untersuchen. Es gibt eine Vielzahl von Datenarten wie Domain-, Log-, Event-, Message-, kritische, Business-, Meta-, temporäre, Session-, geographische Daten. Viele davon passen perfekt in relationale Datenbanken. Andere – wie Session- oder Logdaten – sind meist viel besser in NoSQL-Datenbanken aufgehoben. Meistens geht mit dieser Analyse die Frage nach dem besten Daten- und Speichermodell einher (relational, spalten-, dokumenten- graphen-, objektorientiert und so weiter). Hier sind Formate, Datentypen und Agilität wichtig. Aber auch solche Fragen: Wie wird in den Daten navigiert? Welche Datenmenge gilt es zu beherrschen? Wie komplex sind die Daten?

Transaktionsmodell: Durch die klassischen relationalen Systeme wird der Bereich der ACID Transaktionen seit Langem bestens abgedeckt. Wie vorher erläutert, gibt es aber viele Anwendungsfelder, bei denen ein BASE-Modell genauso gut funktioniert. Hier ist eventuell eine NoSQL Datenbank besser. Nicht die ACID-Anforderungen zu erfüllen, eröffnet (siehe CAP-Teil) andere Möglichkeiten. Aber natürlich kann es zwischen ACID und BASE auch andere Transaktionsmodelle geben, und eine eigene CAP-Abwägung ist immer wichtig.

Performance: Hier ist eine der ersten Entscheidungen, ob Scale-Up langfristig möglich oder ein Scale-Out wirklich nötig ist. Danach gilt es Datendurchsatz, Antwortverhalten und Latenzzeitanforderungen festzulegen.

Anfrageanforderungen: Die Anforderungen des Projektes geben Aufschluss darüber, wie intensiv und tief überhaupt in den Daten gesucht werden muss. Sind lediglich Schlüssel abzufragen, ist sicher eine Key/Value-Datenbank besser. Wird intensiv an Knoten entlang nach Elementen gesucht, ist gegebenenfalls eine Graphendatenbank besser. Für OLAP und Business-Analyse sind SQL oder LINQ unverzichtbar.

Und schließlich legt die Architektur der Anwendung auch schon einiges fest (mobil, Peer-to-Peer, lokal, verteilt und so weiter). Soll etwa auch mobil und offline gearbeitet werden können, dann ist beispielsweise CouchDB die erste Wahl. Oftmals gibt es Datenzugriffsmuster, wie zum Beispiel ein häufige Writes und nur wenig Read-Operationen. Auch diese weisen oftmals in die Richtung einer Datenbankklasse.

Daneben gibt es natürlich auch viele nicht-fachliche Kriterien:

  • Replikation
  • Refactoring Bedarf
  • Support / Bedienung
  • Entwickler-Qualifikation
  • Unternehmensvorgaben
  • Security
  • Vereinheitlichung der Software
  • Backup / Recovery / Crash Resistance
  • Lizenzkosten / Open Source / Community

Erfahrungen im NoSQL-Zeitalter

Die Praxiserfahrung zeigt, dass eine qualifizierte Analyse bei der Suche nach der besten Datenbank sehr selten stattfindet. Es herrschen meistens Unternehmensvorgaben oder noch häufiger Bauchentscheidungen vor. Leider kann dies Fehler zur Folge haben, die später viel Geld kosten.

Die hier konkret vorgestellten NoSQL-Datenbanken zeigen, dass NoSQL-Systeme in vielen Nischenbereichen ideal sind. Agile Daten, hohe Availability, Offline-Arbeit, Performance und Graphendaten sind nur einige wenige Beispiele, wo NoSQL-Datenbanken Vorteile bringen. Aber natürlich gilt es, immer die Gesamtheit der Anforderungen zu analysieren und abzuwägen.

Aus diesem Vorteil in Nischenbereichen folgt natürlich, dass NoSQL-Datenbanken relationale Datenbanken niemals ersetzen werden. Die Situation ist hier ähnlich wie bei Programmiersprachen. Genauso wie sich mit dem Web 2.0 der Raum der Anforderungen erweitert, erweitert sich auch die Zahl der verfügbaren Datenbanksysteme.

Eine direkte Migration von relationalen Systemen auf NoSQL-Systeme ist meistens nicht so leicht, da viel Anwendungslogik umgeschrieben werden muss. So müssen zum Beispiel eventuell Abfragen umgeschrieben werden, und die Transformation des Datenmodells ist generell mit Reibungsverlusten verbunden. Selbst Firmen wie Twitter haben den Umstellungsaufwand deshalb gescheut und die Migration nach NoSQL erst einmal nach hinten geschoben. Auf NoSQL zu setzen, lohnt daher oftmals eher bei neuen Projekten.

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2022