von Redaktion IT-A…
Lesezeit
3 Minuten
Datenbanken im Überblick (3)
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 dritten Teil widmen wir uns noch Zeitreihendatenbanken und Key-Value-Speichern.
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.
ln/Martin Loschwitz
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.
Bild 2: Mit einer Zeitreihendatenbank im Rücken lassen sich Metrikdaten problemlos optisch aufbereiten – dieselbe Aktion auf Basis eines RDBMS würde sehr, sehr lange dauern.
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.
Bild 3: Prometheus ist eine Zeitreihendatenbank und kommt heute üblicherweise zum Einsatz, um skalierbare Umgebungen zu überwachen.
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.
Im ersten Teil
des Artikels werfen wir einen Blick auf den Klassiker relationale Datenbanken. In der zweiten Folge geht es um verteilte Datenbanken und No-SQL-Systeme. Im dritten Teil des Workshops widmen wir uns Zeitreihendatenbanken und Key-Value-Speichern.
ln/Martin Loschwitz
