Datenbanken: Wer die Wahl hat...
Datenbanken sind in der IT allgegenwärtig, doch nicht jede Datenbank eignet sich für jede Aufgabe. Gleichzeitig gibt es immer mehr Datenbankarten, aus denen Administratoren für neue Setups wählen können. Relationale Datenbanken, Zeitreihendatenbanken, NoSQL-Systeme, verteilte DBs – es ist nicht schwierig, dabei den Überblick zu verlieren. Wir verraten, welche DBs existieren und was Admins im Hinterkopf haben sollten. Im ersten Teil werfen wir einen Blick auf den Klassiker relationale Datenbanken.
Eine der klarsten Entwicklungen der vergangenen 20 Jahre besteht hinsichtlich der IT darin, dass Technik sich in den Alltag von immer mehr Menschen hineinentwickelt hat. Wo früher eine statische HTML-Website per FTP hochgeladen wurde, werkelt heute ein kompliziertes Content Management System wie WordPress oder Joomla. Der Vorteil: Auch Nicht-Profis haben die Möglichkeit, Inhalte ins Netz zu stellen, weil die Backends von Drupal & Co. einen intuitiv zu nutzenden Texteditor anbieten und die Einstiegshürde damit deutlich senken.
Implizit hat das sogenannte Web 2.0, in dem jeder irgendwie mitmachen kann, den Aufstieg von Datenbanken massiv gefördert. Endanwendersoftware wie ein CMS ist ohne Datenbank im Hintergrund praktisch nicht sinnvoll zu betreiben. Denn irgendwo müssen die Inhalte, die Gäste auf einer Website sehen, ja herkommen. Die Dynamik und Flexibilität, die etwa ein CMS für den (komfortablen) Betrieb einer Website erzwingen, wären ohne Datenbank praktisch nicht zu erreichen. Und nicht nur hier spielen Datenbanken eine wichtige Rolle. Fast jede moderne IT-Anwendung muss auf irgendeine Weise ihre eigenen Nutzdaten verwalten. Vor allem deshalb wirkt es heute so, als seien MariaDB, PostgreSQL & Co. allgegenwärtig.
Zahlreiche Datenbanktypen am Start
Gerade die jüngere Vergangenheit hat beim Thema Datenbanken allerdings zu einer deutlichen Diversität geführt. Zu den relationalen Datenbanken haben sich längst andere Datenbanktypen gesellt: Zeitreihendatenbanken, NoSQL-Implementierungen, Key-Value-Speicher und etliche weitere Werkzeuge streiten heute um die Gunst der Nutzer.
Aus Sicht eines Administrators wie aus Sicht eines Nutzers und sogar aus der eines Entwicklers besteht dabei eine zentrale Gefahr: Fällt für eine bestimmte Aufgabe die Wahl auf die falsche Datenbank, führt das oft zu miserabler Performance oder funktioniert überhaupt nicht. Die Flut an Datenbanktypen der vergangenen Jahre hat gleichzeitig aber dazu geführt, dass viele heute gar keinen genauen Überblick mehr über die Situation am Markt haben. Deshalb listen wir im Anschluss die gängigsten Datenbanktypen auf und erklären, für welche Art von Daten diese sich gut eignen und wo der Admin lieber Alternativen ins Auge fassen sollte.
Relationale Datenbanken: Der Klassiker
Zwar sind relationale Datenbanken zweifelsohne der Klassiker im DB-Universum, gerade deshalb ist es an dieser Stelle aber sinnvoll, auch auf sie im Detail einzugehen. Mit einer relationalen Datenbank – oft auch als RDBMS bezeichnet – dürfte beinahe jeder Anwender und jeder Administrator bereits zu tun gehabt haben. Denn bei diesen Datenbanken handelt es sich um die klassischen Vertreter, die meist gemeint sind, wenn von Datenbanken ohne eine weitere Einschränkung die Rede ist. Kurzum also: MariaDB, MySQL, PostgreSQL, MS SQL und dergleichen viele mehr.
Relationale Datenbanken heißen so, weil sie unter der Haube auf ein so genanntes relationales Datenmodell setzen, das nach einer bestimmten Hierarchie organisiert ist. Es geht zurück auf E.F. Codd und erschien als Konzept erstmals in den Jahren 1970 bis 1972. Codd war Mathematiker, entwickelte aber auch das relationale Datenmodell, das später die Grundlage für alle heute etablierten, großen Datenbanksysteme wurde.
Relational ist das System, weil es verschiedene Entitäten definiert und diese per Attribut in eine Beziehung zueinander setzt. Klingt in der Theorie total kompliziert, ist eigentlich aber recht leicht, denn die Entitäten sind in modernen relationalen Datenbanken nichts anderes als die Reihen in Datenbanken. Diese sind in Spalten eingeteilt, die Spalte fungiert also wie ein Attribut für eine Reihe. Reihe und Spalte zusammen ergeben eine Beziehung, im Alltag meist einfach "Tabelle" genannt.
Relationale Datenbanken kommen mit einem riesigen Vorteil daher: sie sind in der Lage, die Garantien der ACID-Regeln (Atomicity, Consistency, Isolation, Durability) problemlos zu erfüllen, haben lange Entwicklungszeiten hinter sich und gelten als entsprechend stabil und robust. Obendrein sind die allermeisten RDBMS heute nicht mehr kompliziert aufzusetzen. MariaDB, PostgreSQL & Co. liegen jeder modernen Linux-Distribution bei, sind schnell installiert und bereit für den Einsatz.
Hinzu kommt, dass RDBMS-Systeme aufgrund ihrer internen Struktur einen guten Kompromiss zwischen der verfügbaren Performance einerseits und der Sicherheit der Daten andererseits darstellen. Aus einer MariaDB oder PostgreSQL-Datenbank geht noch am ehesten dann etwas unfreiwillig verloren, wenn der Admin oder der Nutzer es aus Unachtsamkeit selbst löscht. Dass hingegen die großen Vertreter der RDBMS-Kategorie hart crashen und Daten eigenständig vernichten, kommt heute nur noch selten vor.
Verteilte Datenbanken für skalierbare Systeme
Relationale Datenbanken sind zuverlässig, performant und stabil – aber die allermeisten gängigen Implementierungen skalieren nicht zuverlässig in die Breite. Für die normale Website mit CMS im Hintergrund ist das zwar auch nicht nötig. Riesige Webshops jedoch, die abertausende Anfragen pro Sekunde abarbeiten müssen, werden eine einzelne Datenbank mit einiger Sicherheit an die Grenzen ihrer Leistungsfähigkeit bringen.
Ansätze zur Lösung des Problems gibt es einige, etwa Master-Slave-Szenarien, in denen zumindest etliche Backends für das Lesen von Daten zur Verfügung stehen. Früher waren die allermeisten Anwendungen im Unternehmensumfeld stark leselastig. Das ist heute zwar noch immer grundsätzlich so, jedoch verschiebt sich das Verhältnis langsam zugunsten von Schreibzugriffen. Nicht zuletzt daher hat es sich eingebürgert, echte Multi-Master-Setups zu bauen. Darunter versteht man verteilte Datenbanken, bei denen jeder einzelne Knoten sowohl den lesenden als auch den schreibenden Zugriff ermöglicht.
Nota bene: Verteilte Datenbanken können jede interne Struktur anwenden –neben verteilten RDBMS-Systemen sind auch verteilte Zeitreihendatenbanken denkbar. Aufgrund ihrer internen Struktur stellen verteilte RDBMS-Systeme aber technisch mit die höchste Hürde dar, die aus Sicht einer Datenbank denkbar ist. Denn zur Einhaltung der ACID-Regeln kommt hier neben den lokalen Herausforderungen die Aufgabe hinzu, die Transaktionen über die Grenzen einzelner Knoten und die Netzwerkgrenzen zwischen den Systemen hinweg sicher durchzuführen.
Verteilte Datenbanken kommen in der Regel nur dann zum Einsatz, wenn zuvor ein tatsächlicher Bedarf erhoben wurde. Denn der Betrieb einer solchen Lösung ist technisch nicht einfach und trivial. Wer einen realen Einsatzzweck hat, steht vor der Qual der Wahl: Für MariaDB sowie MySQL ist Galera die verbreitetste Lösung. Bei PostgreSQL buhlen mehrere Ansätze um die Gunst der Nutzer, etwa Yugabyte oder CitusDB. Jeder dieser Ansätze hat allerdings eigene, spezifische Nachteile.
No-SQL-Datenbanken
RDBMS-Systeme nutzen als Abfragesprache (Query Language) einen Nachfolger der ebenfalls von E.F. Codd entwickelten Sprache "SEQUEL". SQL steht heute für "Structured Query Language" und beschreibt die Art und Weise, wie Anwender Daten in MySQL schreiben oder Daten aus der Datenbank auslesen. Praktisch jedes RDBMS-System der Gegenwart spricht einen SQL-Dialekt, wobei diese nicht unbedingt kompatibel miteinander sein müssen.
Basale Befehle etwa funktionieren auf MariaDB und PostgreSQL gleich oder zumindest ähnlich, bei komplexen Schritten sind aber oft völlig andere Kommandos nötig. Trotzdem: Weil RDBMS-Systeme lange den Markt komplett dominierten, wurde es irgendwann üblich, alle anderen Systeme unter dem Begriff "No-SQL-Datenbanken" zu subsummieren. Die Krux: Alleine anhand des Begriffes ist kein Rückschluss darauf möglich, um welche Art von Datenbank es sich handelt oder was deren spezifischen Fähigkeiten sind.
Eine Sonderform der No-SQL-Datenbanken stellt übrigens SQLite dar. Zwar kommt in SQLite eine Syntaxsprache zur Anwendung, die einen klassischen SQL-Dialekt darstellt. Die ganze Idee hinter SQLite besteht aber ja bekanntlich darin, keine echte Datenbank zu sein. SQLite-Datenbanken sind stattdessen in der Regel einzelne Textdateien auf der Festplatte, auf die der Zugriff durch ein spezielles Interface – etwa eine Bibliothek – erfolgt. Das ist zwar weder sonderlich performant noch skaliert es gut, gerade viele kleinere Programme sind so aber in der Lage, ihre eigenen Metadaten abzuspeichern. Und das ganz ohne Zwang für den Admin, eine separate Datenbank aufzusetzen.
Manchem werden viele Datenbanken eher unter ihrem Produktnamen begegnet sein als unter der Art, zu der das jeweilige Produkt gehört. MongoDB etwa erfreut sich seit einigen Jahren großer Beliebtheit und gehört zur Gruppe der No-SQL-Datenbanken. Es ist dokumentenorientiert, sodass Einträge etwa JSON- oder XML-Strukturen haben können. Mittlerweile steht MongoDB nicht mehr unter einer Open-Source-Lizenz, nach wie vor handelt es sich jedoch um die am weitesten verbreitete No-SQL-Datenbank überhaupt.
Zeitreihendatenbanken
Time Series Databases, zu Deutsch etwas ungelenk Zeitreihendatenbanken, gibt es wie RDBMS-Systeme bereits eine ganze Weile. Bis zum Aufkommen großer skalierbarer Plattformen spielten sie im IT-Alltag allerdings keine sonderlich große Rolle. Das ist heute definitiv anders. Zeitreihendatenbanken unterscheiden sich von ihren RDBMS-Gegenstücken vor allem durch die interne Struktur.
Während bei MariaDB beispielsweise Reihen und Spalten zu einer Tabelle zusammengefasst werden, ist das zentrale Bezugselement einer Zeitreihendatenbank stattdessen ein Zeitstrahl. Auf diesem lassen sich an beliebigen Stellen Datensätze ablegen und abfragen. Besonders hilfreich ist das natürlich bei Informationen, die chronologisch zu speichern sind. Was etwas abstrakt klingt, wird anhand eines Beispiels schnell deutlich.
Gegeben sei also eine private Cloudumgebung auf Basis von Proxmox, die aus insgesamt 30 Systemen besteht. Der Administrator will seinen Job gut machen und beispielsweise Ausfälle von Hardware sofort erkennen. Er geht aber noch einen Schritt weiter: volllaufende SSDs und übervollen RAM will er so früh erkennen, dass er kontrolliert gegensteuern kann, statt auf Notfallmaßnahmen zurückzugreifen. Wie das technisch geht, ist klar: Trending. Trending heißt nichts anderes, als Metrikdaten von allen Zielsystemen in regelmäßigen Abständen einzusammeln, zu speichern und dann etwa dadurch zu verarbeiten, indem sie der Admin grafisch darstellt. Manche Trending-Systeme wie Prometheus – übrigens selbst im Kern eine Zeitreihendatenbank – sind zudem in der Lage, Alarme auszulösen, wenn Werte einen festgelegten Bereich für die jeweilige Metrik verlassen.
Schon beim Abspeichern käme ein RDBMS-System hier gut ins Schwitzen. Bei angenommenen 150 Messwerten pro System und einer Abfrage pro System alle 20 Sekunden würde ein Monitoringwerkzeug pro Minute 9000 neue Zeilen in einer Datenbank anlegen, fast 13 Millionen Einträge pro Tag. Noch brenzliger wird die Situation, wenn die in der Datenbank schlummernden Daten ausgelesen werden sollen, um grafisch dargestellt zu werden. In der Regel wird der Administrator nicht den gesamten Inhalt aller historischer Daten bis zum Anbeginn des Setups sehen wollen, sondern seine Suchanfrage entsprechend einschränken. Die relationale Datenbank müsste dann jede einzelne ihrer Zeilen durchgehen, prüfen, ob der Filter passt, die Zeile gegebenenfalls in die Antwort übertragen und diese schließlich ausgeben.
Ganz gleich, welche Tuningmaßnahmen der Administrator an einem RDBMS vollzieht und wie potent die Hardware ist, auf dem die Datenbank läuft: schon nach kurzer Zeit wird das Setup kaum mehr sinnvoll zu benutzen sein. Der beschriebene Vorgang der Transponierung von einem Datenbankformat (Reihe/Spalte) in ein anderes (Zeitstempel) frisst einfach zu viele Ressourcen.
Hier haben Zeitreihendatenbanken ihren großen Auftritt: gerade weil ihr Wurzelelement der Zeitstrahl ist, ersparen sie sich die komplette Transponierung. Sie lesen anhand des vom Admin bei der Abfrage festgelegten Zeitraums einfach den entsprechenden Teil des Zeitstrahls aus und geben ihn wieder – fertig.
Zeitreihendatenbanken existieren am Markt mittlerweile mannigfaltig. Die gängigsten Vertreter sind InfluxDB, Prometheus, OpenTSDB oder RRDTool. Vorsicht ist geboten, was die Konsistenzen von Zeitreihendatenbanken angeht: Anders als die meisten RDBMS bieten sie etwa keine Konsistenzgarantien nach dem ACID-Prinzip an. Was nicht etwa an mangelnder Qualität der Zeitreihendatenbanken gilt, sondern daran, dass bei diesen Performance im Mittelpunkt steht und es üblicherweise als vernachlässigbar gilt, wenn die Metrikdaten zu einem einzelnen Zeit- und Messpunkt verlorengehen.
Key-Value-Speicher: Möglichst simpel
Nicht fehlen darf in dieser Liste gegenwärtiger Datenbanken schließlich der – oft verteilt auftretende – Key-Value-Speicher. Key-Value-Speicher heißt wörtlich übersetzt "Schlüssel-Wert-Speicher", und das beschreibt die interne Struktur dieses Datenbanktypus ganz gut: sie speichert nämlich einfach Pärchen aus einer Namen ("Key") und dem dazu gehörenden Wert.
Abfragen sind denkbar einfach: Wer den Wert zu einem bestimmten Key will, fragt diesen Schlüssel explizit ab und erhält die gewünschte Information. Die im Vergleich mit RDBMS- und selbst Zeitreihendatenbanken relativ geringe Komplexität sorgt dafür, dass Key-Value-Speicher meist ordentlich Dampf unter der Haube haben. Wer lediglich Daten in einem denkbar einfachen Schema abspeichern möchte, ist mit einem Key-Value-Store oft noch am besten bedient.
Die größte Komplexität von Key-Value-Speichern geht regelmäßig von der Notwendigkeit aus, diese in verteilten Systemen selbst verteilt zu konfigurieren. Derselbe Datensatz soll dann, wie etwa auch bei Galera für MariaDB, durchaus mehrfach im Netz vorhanden und an verschiedenen Stellen abfragbar sein. Hier existieren mehrere etablierte Produkte, von denen Etcd und Consul zu den einfachen gehören und Redis am anderen Ende der Komplexitätsskala steht. Letzteres lässt sich etwa auch als In-Memory-Cache nutzen, wenn die Quellapplikation darauf ausgelegt ist. Dies wäre ebenfalls ein recht typischer Anwendungsfall für einen schnellen Key-Value-Speicher.
Fazit
Die beschriebenen Beispiele belegen deutlich: Es prüfe, wer sich an eine spezifische Datenbank bindet. Ist eine Applikation erstmal entwickelt und auf den Betrieb mit einer speziellen Datenbank hin angepasst, ist ein nachträglicher Umstieg in aller Regel unmöglich. Jedenfalls wäre er extrem aufwendig. Hier ist Vorsicht besser als Nachsicht, zumal das vermeintliche Chaos in Sachen Datenbanken insgesamt recht gut zu durchdringen ist, wenn ein paar Grundbegriffe klar sind.
Autor: Martin Loschwitz