Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Lesedauer 6 Min.

Time-Series-Datenbanken

Shooting-Star Prometheus versus Klassiker InfluxDB.
© dotnetpro
Spricht man von Datenbanken, denken viele an relationale Datenbanken, analytische spaltenorientierte Datenbanken oder NoSQL-Datenbanken. Zeitreihendatenbanken (Time-Series-Datenbanken) fristen ein Nischendasein. Grund genug, einen Blick auf sie zu werfen.Entwickler können ab einem gewissen Grad an Erfahrung Datenverarbeitungsmuster typischen Datenbanksystemen zuordnen. Banktransaktionen zum Beispiel: Hier denken wir an relationale Systeme und an Funktionalitäten, welche durch Akronyme wie ACID zusammengefasst werden. SQL-Abfragen für relationale Datenbanken zu schreiben gehört zum B­asis-Know-how eines Entwicklers. Wer in der Business-Intelligence-Welt (BI) Fuß gefasst hat, weiß, dass für statistische Auswertungen das, was in den Spalten steht, interessanter ist als das in den Reihen. CRUD-Operationen, für die relationale Datenbanken geschaffen wurden, sind hier sekundär. Gute analytische Datenbanken sind darauf optimiert, Daten spaltenweise auszulesen und zu aggregieren.Auch NoSQL-Datenbanken sind vermutlich den meisten vertraut. JSON-Daten lassen sich in Dokumentendatenbanken wie MongoDB ablegen, Schlüssel-Wert-Paare passen in spezielle Datenbanksysteme wie Redis. Graphen bilden Beziehungen ab und kommen in eine Graphdatenbank, und auch für Wide-Column-Szenarien fallen uns Lösungen ein.Welche Anwendungsmuster werden also durch Time-Series-Datenbanken gelöst?

Anwendungsfälle

Denken Sie an Sensordaten von Maschinen. Wärmesensoren liefern beispielsweise kontinuierlich Informationen über die Zeit. Um diese Daten zu sammeln, sind der Timestamp und die dem Timestamp zugeordneten Werte wesentlich, so lassen sich dann Graphen erstellen, die Veränderungen über die Zeit visualisieren.Als Entwickler denken wir auch an Systeminformationen aus unseren Rechnern und Servern. Es mag interessant sein, die CPU-Auslastung über die Zeit zu veranschaulichen. Streng genommen ist also jeder Taskmanager (Windows) oder Aktivitätenmanager (macOS), der Prozesse über die Zeit misst, eine Time-Series-Anwendung.

Time-Series-Datenbanken

Welche Lösungen gibt es also, um Messdaten über die Zeit festzuhalten? Ein Blick auf die Seite DB-Engines [1] zeigt, dass es scheinbar einen Marktführer gibt. Geht es nach DB-Engines, ist InfluxDB die mit Abstand beliebteste Time-Series-Datenbank (Bild 1). Weitere Artikel im Internet kommen zu ähnlichen Aussagen [2]. Kurz zusammengefasst werden in Artikeln oft die folgenden vier Datenbanken als Referenz für Time-Series-Datenbanken genannt: InfluxDB, Graphite, TimeScaleDB und OpenTDSB.
Rankingauf DB-Engines(Bild 1) © Autor
Wer aber auf Stackshare [3] und GitHub schaut, findet ein etwas anderes Ranking (Bild 2). Dort zeigt sich, dass es anscheinend einen neuen Herausforderer oder gar neuen Champion gibt: Prometheus [4]. Prometheus wird oft als Hybrid­ wahrgenommen. Es ist im Kern eine Time-Series-Datenbank, bietet daneben aber auch eine Monitoring-Plattform an.
Stackshare-Ranking(Bild 2) © Autor
Es ist wie so oft eine Frage der Betrachtungsweise. InfluxDB wird oft als „I“ in einen Technologiestack eingebunden, der als TICK-Stack (Telegraf, InfluxDB, Chronograf, Kapacitor) bezeichnet wird. Alle vier Komponenten dieses Stacks bilden ab, was Prometheus tut. Prometheus aus dem Ranking zu entfernen, nur weil es mehr kann, als lediglich Zeitreihendaten zu speichern, wäre demnach nicht sinnvoll.Auf der Webseite von Prometheus [4] werden die Time-Series-Plattformen ebenfalls verglichen. Das Fazit lautet dort:
  • InfluxDB ist besser geeignet für die Ereignisprotokollierung. Die kommerzielle Version bietet zudem Clustering für InfluxDB, was auch für die langfristige Datenspeicherung besser ist. Außerdem ist InfluxDB besser bei der Eventually Consistent View auf die Daten zwischen Replikaten.
  • Prometheus ist besser, wenn es hauptsächlich um Metriken geht. Es bietet die leistungsfähigere Abfragesprache, dazu Alarm- und Benachrichtigungsfunktionalitäten. Für Prometheus spricht zudem die höhere Verfügbarkeit und Betriebszeit für Grafiken und Alarme.
Der Vergleich mit anderen Time-Series-­Datenbanken fällt relativ kurz aus. Teil­weise­ wird auch nur auf Implementierungs­details eingegangen wie etwa, dass Open­TDSB auf HBase aufbaut und deswegen ­einen Hadoop Cluster erfordert, um überhaupt lauffähig zu sein.Um den Vergleich abzuschließen, ist es sinnvoll, einen Blick auf GitHub zu werfen und sich die Aktivitäten zu den Produkten anzusehen (Bild 3). Es fällt auf, dass anscheinend an Prometheus mehr Entwickler arbeiten als an InfluxDB (Bild 4).
GitHubverzeichnet über 400 Mitwirkende zu Prometheus(Bild 3) © Autor
InfluxDBhat laut GitHub etwas weniger Mitwirkende als Prometheus(Bild 4) © Autor
Allzu weit liegen die Zahlen jedoch nicht auseinander. Bei einem Vergleich mit anderen Werkzeugen, wie etwa Open­TSDB, können diese Metriken allerdings durchaus das wesentliche Entscheidungsmerkmal sein. Wenn niemand ein Werkzeug mehr weiterentwickelt, ist man gezwungen, irgendwann umzusteigen.Auch die Aktivitätsanzeige auf GitHub [5] zeigt mehr Aktivitäten aufseiten von Prometheus (Bild 5) als bei anderen Time-Series-Datenbanken. Diese Information kann ebenfalls entscheidend sein.
Prometheuswird aktiv weiterentwickelt, wie die GitHub-Zahlen zeigen(Bild 5) © Autor

Der Prometheus-Weg

Um zu entscheiden, ob man auf althergebrachte Technologien setzt oder gleich mit Prometheus zu arbeiten beginnt, gilt es zu verstehen, was Prometheus speziell auszeichnet und von anderen Datenbanken unterscheidet.Wer mit InfluxDB arbeitet, stellt schnell fest, dass vieles ­einem Schema folgt, das man von Datenbanken gewohnt ist. Es ist möglich, Daten in diese Datenbank zu pushen und dann auch wieder auszulesen. Prometheus kommt mit einem neuen Konzept. Der Slogan bei Prometheus lautet: Pull statt Push. Anwendungen exponieren ihre Metadaten über ein API und Prometheus zieht die Daten an sich. Prometheus bietet APIs für Clients an, um Messdaten über diese Schnittstellen zu exponieren. Auf GitHub sind die Client-APIs zu finden. Darunter auch die APIs für Python [6] und Java [7].Der Standardweg ist also, Daten zu ziehen. Der Weg, Daten direkt in Prometheus zu pushen, ist nur für Sonderfälle gedacht, in denen es nicht möglich ist, die Daten zu exponieren. Als klassischen Referenzfall für einen Push-Algorithmus nennt die Webseite eine Anwendung, die nur Ergebnisse meldet.

Vier Metriken und ein Port

Prometheus stellt vier Metriken bereit: Counter, Gauge, Summary und Histogramm. Die folgende Referenzimplementierung zeigt, wie Code in Python instrumentiert wird, um Daten für Prometheus bereitzustellen. Konkret bedeutet das:
  • Es wird ein Port registriert, an welchem die Daten für Prometheus bereitgestellt werden.
  • Der Code wird so weit instrumentiert, dass die Daten an diesen Port geschickt werden.
Listing 1 zeigt die Python-Referenzimplementierung. Das Beispiel stammt von der Prometheus-Seite.
Listing 1: Python-Implementierung
<span class="hljs-keyword">from</span> prometheus_client <span class="hljs-keyword">import</span> \<br/>    start_http_server, Summary <br/><br/><span class="hljs-keyword">import</span> random <br/><span class="hljs-keyword">import</span> time <br/><br/># Create a metric to track time spent <br/># and requests made. <br/>REQUEST_TIME = Summary( \<br/>    <span class="hljs-string">'request_processing_seconds'</span>, \<br/>    <span class="hljs-string">'Time spent processing request'</span>) <br/><br/># Decorate function <span class="hljs-keyword">with</span> metric. <br/>@REQUEST_TIME.time() <br/>def process_request(t): <br/>    <span class="hljs-string">""</span><span class="hljs-string">"A dummy function that takes some time."</span><span class="hljs-string">""</span><br/>    time.sleep(t) <br/><br/><span class="hljs-keyword">if</span> __name__ == <span class="hljs-string">'__main__'</span>: <br/>    # Start up the server to expose the metrics. <br/>    start_http_server(<span class="hljs-number">8000</span>) <br/>    # Generate some requests. <br/>    while <span class="hljs-literal">True</span>: <br/>       process_request <br/>       (random.random())  

Daten abholen

Wesentlich ist, dass im Code alle Daten an Port 8000 exportiert werden. Mithilfe ­eines Werkzeugs wie beispielsweise cURL oder eines Browsers lässt sich dies verifizieren, indem man die Seite mit dem Port aufruft. Nachdem wir also die Daten über einen Port bereitstellen, wird es auch Zeit, diese abzuholen.Werfen Sie dazu einen Blick auf die Architektur (Bild 6). Die Daten sind bereitgestellt. Nun gilt es sie einzubinden. Das klappt am einfachsten, indem Prometheus in einem Docker-Container gestartet wird.
Die Architekturvon Prometheus(Bild 6) © Autor

docker <span class="hljs-keyword">run</span><span class="bash"> --name prometheus <span class="hljs-_">-d</span> -p 127.0.0.1:9090:9090 prom/prometheus </span>
 
Danach kann man eine Verbindung mit dem Container mit folgendem Befehl herstellen:

<span class="hljs-symbol">docker</span> exec -<span class="hljs-keyword">it </span>prometheus /<span class="hljs-keyword">bin/sh </span>
 
Im Container finden Sie die Datei prome­theus.yaml in der Hierarchie des Konfigura­tionsverzeichnisses etc. Dort können Sie die Server angeben, die „gescrapt“ werden sollen.

<span class="hljs-string">scrape_configs:</span> 
 - <span class="hljs-string">job_name:</span> <span class="hljs-string">'prometheus'</span> 

  <span class="hljs-string">static_configs:</span> 
   - <span class="hljs-string">targets:</span> 
      [<span class="hljs-string">'127.0.0.1:9090'</span>, 
        <span class="hljs-string">'127.0.0.1:9100'</span>] 
      <span class="hljs-string">labels:</span> 
        <span class="hljs-string">group:</span> <span class="hljs-string">'prometheus'</span> 
 
Werden die Anpassungen korrekt vorgenommen, kann man mehrere Targets definieren und auslesen. Bild 7 zeigt, dass mehrere Targets in Prometheus eingebunden worden sind.
Zwei Targetswurden eingebunden(Bild 7) © Autor

Der USP von Prometheus

An diesem Punkt angelangt, gilt es zu unterstreichen, was Prometheus so speziell macht. Es geht hier nicht in erster Linie darum, wie Daten im Detail in einer Datenbank gespeichert werden. Wesentlich ist vielmehr, dass mit der von Prometheus verwendeten Methode ein Standard geschaffen wird. Daten, die mit Prometheus-Clients exponiert werden, können auch von anderen Frameworks verarbeitet werden. Man könnte also beispielsweise auch einen Kafka-Producer schreiben, der die Daten vom Port abholt und in einem Kafka-Broker speichert. Außerdem können die in Prometheus abgelegten Daten jederzeit mithilfe von Grafana oder einem anderen Visualisierungswerkzeug darstellt werden.

Fazit

Ob Prometheus der neue Star am Himmel der Time-Series-Datenbanken ist oder nicht, darüber kann man debattieren. Wesentlich ist, dass Prometheus durch das Exponieren der APIs einen neuen Ansatz wählt, dank dem sich auch noch andere Werkzeuge in die Pipeline einbinden lassen. Aufgrund der hohen Beliebtheit von Prometheus ist es definitiv empfehlenswert, es bei der Suche nach einer Zeitreihendatenbank in die engere Wahl einzubeziehen.

Neueste Beiträge

DWX hakt nach: Wie stellt man Daten besonders lesbar dar?
Dass das Design von Websites maßgeblich für die Lesbarkeit der Inhalte verantwortlich ist, ist klar. Das gleiche gilt aber auch für die Aufbereitung von Daten für Berichte. Worauf besonders zu achten ist, erklären Dr. Ina Humpert und Dr. Julia Norget.
3 Minuten
27. Jun 2025
DWX hakt nach: Wie gestaltet man intuitive User Experiences?
DWX hakt nach: Wie gestaltet man intuitive User Experiences? Intuitive Bedienbarkeit klingt gut – doch wie gelingt sie in der Praxis? UX-Expertin Vicky Pirker verrät auf der Developer Week, worauf es wirklich ankommt. Hier gibt sie vorab einen Einblick in ihre Session.
4 Minuten
27. Jun 2025
„Sieh die KI als Juniorentwickler“
CTO Christian Weyer fühlt sich jung wie schon lange nicht mehr. Woran das liegt und warum er keine Angst um seinen Job hat, erzählt er im dotnetpro-Interview.
15 Minuten
27. Jun 2025
Miscellaneous

Das könnte Dich auch interessieren

UIs für Linux - Bedienoberflächen entwickeln mithilfe von C#, .NET und Avalonia
Es gibt viele UI-Frameworks für .NET, doch nur sehr wenige davon unterstützen Linux. Avalonia schafft als etabliertes Open-Source-Projekt Abhilfe.
16 Minuten
16. Jun 2025
Mythos Motivation - Teamentwicklung
Entwickler bringen Arbeitsfreude und Engagement meist schon von Haus aus mit. Diesen inneren Antrieb zu erhalten sollte für Führungskräfte im Fokus stehen.
13 Minuten
19. Jan 2017
Evolutionäres Prototyping von Business-Apps - Low Code/No Code und KI mit Power Apps
Microsoft baut Power Apps zunehmend mit Features aus, um die Low-Code-/No-Code-Welt mit der KI und der professionellen Programmierung zu verbinden.
19 Minuten
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige