Ovidiu Hutuleac & Andreas Juffinger 14. Juni 2022

Lösungen für Zeitreihendaten neu denken

Der Zeitstempel ist ein wesentlicher Faktor bei der Verarbeitung von Daten. © Adobe: tadamichi / stock.adobe.com / 417046021 — © Adobe: tadamichi

Wie können wir heutzutage die Vielzahl an Zeitreihen effizient und skalierbar verarbeiten? Angesichts der zunehmenden Datenmenge und Datenfrequenz im Bereich Zeitreihen stehen etablierte Ansätze für den Umgang mit diesen Daten vor Herausforderungen in Bezug auf Betrieb, Skalierung und Leistung.

Für die Verarbeitung, Speicherung und Abfrage von Zeitreihendaten kommen relationale Datenbanken, aber auch speziell entwickelte Datenbanksysteme und NoSQL-Datenbanken in Frage. Bei der Entwicklung all dieser Datenbanksysteme wurden Kompromisse eingegangen, die im Kontext einer Lösung zu berücksichtigen sind. Um eine adäquate Auswahl zu treffen, sind die Abfrage- und Konsistenzanforderungen als wesentliche Merkmale zu betrachten. Darüber hinaus sind es aber die nicht-funktionalen oder Qualitätsanforderungen der Gesamtlösung an die Datenbank, die als Entscheidungskriterien herangezogen werden sollten.

Anwendungsszenarien

Der Zeitstempel ist ein wesentlicher Faktor bei der Verarbeitung von Daten. Jede Transaktion, jedes Ereignis, jeder Datensatz hat mehrere zeitliche Aspekte: Zeitpunkt der Erzeugung, Zeitpunkt jeder Veränderung oder auch Löschung sind relevante Informationen. In diesem Artikel betrachten wir sogenannte Zeitreihen, das sind grundsätzlich Folgen von diskreten Datenpunkten über einen Zeitraum, oft zeitlich sortiert – die Veränderung eines Wertes über einen bestimmten Zeitraum spielt hier eine zentrale Rolle.

Im Weiteren werden wir zwei Anwendungsszenarien betrachten, wobei der Fokus auf der Datenhaltung liegt. Da wie oben beschrieben aber der Kontext betrachtet werden muss, nehmen wir eine generische Lösungsarchitektur mit einer Ingest- und einer Query-Komponente jeweils mit Verarbeitungskapazität an.

Szenario 1: Telemetrie und Internet of Things (IoT)

Telemetrie ist definiert als die Übertragung von Messwerten auf drahtgebundenem oder drahtlosem Weg, dies ist eine der häufigsten Anwendungen im Bereich Internet of Things (IoT). Viele Firmen beschäftigen sich mit "Connected Devices" oder IoT, daher wird auch die Persistenz dieser Daten immer wichtiger. Vereinfacht nimmt in diesem Szenario ein Sensor Messwerte wie Temperatur, Luftfeuchtigkeit oder auch definierte Maschinenzustände auf und sendet diese Nachrichten an ein zentrales System. In unserer Lösungsarchitektur würden diese Nachrichten in der Ingest-Komponente verarbeitet. Hier ist die erste Entscheidung anhand der nicht-funktionale Anforderungen "Reaktionszeit" zu treffen.

Telemetrieszenarien mit extrem kurzer Reaktionszeit erfordern event-getriebene Architekturansätze. Das "Ablegen" der Daten in der Datenbank und regelmäßiges Abfragen (Polling) führt zu einer minimalen Reaktionszeit im Bereich des Pollingintervalls plus Abfragezeit – das kann Sekunden dauern und verursacht unnötig hohen Query Load auf der Datenbank. Ein event-getriebener Ansatz erlaubt es, Ereignisse zu erkennen und darauf zu reagieren, das erfordert jedoch ein Complex-Event-Processing-System (CEP) wofür sich Streaming-Plattformen wie Amazon Kinesis Data Analytics, Apache Flink und Apache Kafka eignen. Der Nachrichtenstrom wird dabei kontinuierlich analysiert und Vorfälle bei der Verarbeitung erkannt. Diese Ereignisse werden meist mittels Publish/Subscribe-Mechanismen verteilt und es kann sehr schnell darauf reagiert werden. Die Überwachung von Geschwindigkeit und Qualität einer Produktionsmaschine fällt zum Beispiel in diese Gruppe. Dazu werden bei event-getriebenen Architekturen die erkannten Ereignisse und die zugrunde liegenden Nachrichten für die Analyse persistiert.

Eigenschaften von Telemetrie- und Ereignisdaten lassen sich nun wie folgt zusammenfassen: Einzelne Nachrichten sind in der Regel sehr klein, aber vielfältig und die Struktur ist im Laufe der Zeit veränderbar. Ein neuer Sensor kann beispielsweise neben der Temperatur neuerdings auch die Feuchtigkeit feststellen oder ein Ereignis bekommt zusätzliche Attribute, da der Algorithmus zur Erkennung verbessert wurde. Telemetriedaten sind auch mit Metadaten versehen, welche Bezug auf das Gerät, den Einsatzort oder das Fahrzeug nehmen. Da sich der Inhalt einer Nachricht nicht mehr verändert, werden solche Daten gerne auch als "Append Only" bezeichnet. In der IoT-Praxis kommt es durchaus vor, dass Nachrichten bei der Übertragung dupliziert werden, daher sollten Telemetriesystem-Komponenten idempotent sein, das heißt, dass einfache oder mehrfache Verarbeitung derselben Nachricht zum selben Ergebnis führen sollten. Auch wenn das oft theoretisch angenommen wird, sind Nachrichten in der Praxis meist nicht äquidistant oder zeitlich sortiert, einzelne Nachrichten kommen manchmal erst Stunden oder Tage nach dem Aufzeichnen an.

Relationale Datenbanken (RDBMS) eignen sich nur bedingt für Daten mit veränderlichen Schemata, da hier ein fixes Schema vorausgesetzt wird. Viele unterschiedliche Messwertdatensätze führen darüberhinaus zu einer sehr fragmentierten Befüllung. Diese Fragmentierung von Tabellen stellt für die meisten RDBMS eine Herausforderung dar. ACID-Transaktionen sind für diesen "Append Only"-Workload unnötiger Overhead. Bei der Normalisierung der Metainformationen muss hier zusätzlich darauf geachtet werden, dass der Inhalt einer früher gespeicherten Nachricht nicht verändert wird. Sollte beispielsweise ein Sensor in einem Gerät getauscht werden, muss die Seriennummer des ursprünglichen Sensors bei den alten Daten erhalten bleiben, obwohl das bei einer naiven Umsetzung der dritten Normalform (3NF) nicht gewährleistet wäre. NoSQL-Datenbanken haben nun kein fixes Schema und können gut mit veränderlichen Datenstrukturen umgehen. Auch werden Daten in NoSQL-Datenbanken nicht normalisiert, das Datenmodell ergibt sich meist aus dem zugrundeliegenden NoSQL-Typ wie etwa Dokument-, Key-Value- oder Wide-Column-Datenbanken.

Relationale Modellierung optimiert Input/Output (I/O) und Speicherplatz. Speicher kostete sehr viel Geld und I/O war lange Zeit das Bottleneck – eine Situation, die eine Minimierung der Kosten erforderte, wohingegen höherer Rechenaufwand trotzdem zum Ergebnis führte. Speicherplatz ist heute kaum ein zentrales Qualitätskriterium, daher sind NoSQL-Datenbanken in Richtung Rechenaufwand/Geschwindigkeit optimiert und tolerieren höhere Redundanz. Für das Speichern der oben beschriebenen Telemetriedaten bieten sich nun Dokument- und Key-Value-Datenbanken an. Dokument-Datenbanken, wie Amazon DocumentDB, unterstützen dabei komplexe Dokumentstrukturen sowie Verschachtelungen. Dokumente werden hier als atomare Einheit betrachtet und mittels generiertem Identifier angesprochen. Der für Telemetrieanwendungen wesentliche Zeitstempel kann als Attribut mit Index modelliert werden. Key-Value-Datenbanken, wie Amazon DynamoDB, erlauben hingegen die Modellierung des primären Schlüssels als einzelnes oder zusammengesetztes Datenfeld. Bei Key-Value-Datenbanken ist eine Zeile die atomare Einheit und diese kann mittels Schlüssel abgerufen werden.

IoT-Anwendungen müssen in der Lage sein, die Daten von Millionen von Geräten wie beispielsweise smarten Stromzählern, Telemetrieinformationen von Autos oder Sensorendaten von Raffinerien zu verarbeiten. Es ist einerseits mit einem kontinuierlichen Strom einer hohen Zahl an Nachrichten pro Sekunde zu rechnen, andererseits muss die Lösung aber auch mit Lastspitzen im Datenstrom umgehen können. Die Abtastraten von Sensoren werden teilweise intelligent an die Veränderung der Werte angepasst, um Spitzen im Berufsverkehr oder Stromverbrauch am Abend mit höherer Genauigkeit zu erfassen – solche Veränderung führen schnell zu einer Verzehnfachung der Nachrichten pro Sekunde.

Bei Telemetrieanwendungen sind aktuelle Daten von höherem Wert und werden auch häufiger abgefragt. Daraus folgt eine Ungleichverteilung der abfragerelevanten Information. In manchen Anwendungsfällen werden ältere Rohdaten überhaupt nicht mehr gebraucht und nur aggregierte Daten gespeichert. In Telemetrielösungen beobachten wir folgende unterschiedliche Abfragemuster:

Laden von einzelnen oder vielen Zeitreihen innerhalb eines Zeitraums, zur Weiterverarbeitung, die sich gewisse Attribute wie z. B. Anlagennummer, Energiekunde oder Seriennummer teilen.
Analytische Auswertungen über einen Zeitraum, Aggregation der Durchschnittstemperatur, Fensterfunktionen wie Feuchtigkeitsverlauf und Klassifizierung des Energieverbrauchs pro Tag.
Zeitserienspezifische Berechnungen und Funktionen wie Interpolation von fehlenden Datenpunkten, Ableitungen zur Bestimmung des Veränderungsgradienten und auch Korrelationen zwischen Zeitserien.

Die funktionalen und qualitativen Anforderungen an eine Datenbank für dieses Telemetrie-Szenario lassen sich wie folgt zusammenfassen:

Skalierbarkeit der Verarbeitung und Speicherung von vielen Millionen Nachrichten
Elastizität in Bezug auf Spitzenlasten, Upscaling/Downscaling muss möglich sein
Schneller Zugriff auf aktuellere Daten, da diese häufiger benötigt werden, als historische Daten
Idempotenz im Umgang mit Nachrichtenduplikaten
Schneller Zugriff auf aktuelle Zeitreihen unabhängig von der aktuellen Schreiblast
Automatisierte Auslagerung von Rohdaten bis hin zur Löschung
Analytische Aggregations-, Fenster- und Gruppierungs-Funktionen
Zeitserienspezifische Berechnungen und mathematische Funktionen

Anforderungen 1-5 lassen sich mit den entsprechenden Modellierungsansätzen und geringem Implementierungsaufwand mit Amazon DynamoDB realisieren und automatisieren [1]. Das Staging wird mittels mehrerer Tabellen mit unterschiedlicher Lese-/Schreibkapazität kosteneffizient erreicht.

Mit Amazon DynamoDB kann auch transaktionales Verhalten, ähnlich wie mit relationalen Datenbanken, über mehrere Elemente hinweg umgesetzt werden. Effiziente Zugriffe auf aktuelle Zeitreihen auf Basis von verschiedenen Attributen lassen sich mit Global Secondary Indexes (GSI) realisieren und somit sind Abfragezeiten im Bereich von Millisekunden sichergestellt.

Abfragen in Amazon DynamoDB unterstützen jedoch keine analytischen oder mathematischen Funktionen, diese müssten in der Querykomponente programmiert werden. Amazon DynamoDB ist also eine gute Wahl, wenn extrem schneller Zugriff auf Zeitreihen ohne analytische und zeitserienspezifische Funktionen benötigt wird. Um nun diese analytischen Anforderungen erfüllen zu können, wäre eine nachgelagerte OLAP-Datenbank wie beispielsweise Amazon Redshift notwendig. Wenn die Daten mit Spark/Hadoop repliziert werden, sind in jedem Fall zusätzliche Komponenten notwendig [2].

Etliche unserer Kunden haben nun eine solche Lösung aufgebaut und betreiben diese in Produktion. Aufgrund hoher Komplexität haben diese Kunden den Wunsch nach einer integrierten Lösung an Amazon Web Services gestellt. Amazon Timestream unterstützt nun diese Kombination mit dynamischem Schema und analytischen Funktionen. Um die betrieblichen Herausforderungen gering zu halten, wurde Amazon Timestream als sogenannte Serverless-Datenbank aufgebaut. Als fully-managed Service übernimmt Amazon Web Services den Betrieb und der Kunde muss sich weder um Skalierung oder Verfügbarkeit in einer Region kümmern.

Wie hier in der Abbildung ersichtlich, besteht bei Amazon Timestream eine klare Trennung in drei unabhängig skalierbare Schichten. Die Trennung von Compute und Storage hat sich schon bei anderen Cloud-Native-Datenbanken wie Amazon Aurora bewährt, hier kommt noch hinzu, dass der Compute Layer in eine Datenaufnahme- und Abfrage-Schicht aufgeteilt wurde, um die besonderen Skalierungsanforderungen besser erfüllen zu können.

Die Spezialisierung auf Zeitseriendaten erlaubt es auch, Zeitreihen optimiert abzuspeichern, dadurch Speicherplatz zu sparen und gleichzeitig geringe Abfragezeiten zu gewährleisten.

Amazon Timestream vereinfacht das Lifecycle-Management der Daten mit einem In-Memory-Speicher für aktuelle Daten und einem Magnetspeicher für historische Daten. Der In-Memory-Speicher ist für schnelle Point-in-Time-Abfragen optimiert, der Magnetspeicher für schnelle analytische Abfragen.

Wenn Daten in Timestream geschrieben werden, kommen sie im In-Memory-Speicher an. Der Speicher erkennt doppelte Datenwerte, sortiert Daten und speichert die Daten dauerhaft. Dazu verarbeitet er auch neue Daten, sobald sie eintreffen. Timestream behält diese Daten im Arbeitsspeicher, solange der Zeitstempel der Daten innerhalb der Datenhaltefrist des In-Memory-Speichers liegt. Mit Timestream lässt sich ein Datenarchivierungsprozess konfigurieren, um Daten vom teureren In-Memory-Tier in den Magnetic-Tier zu verschieben. Wenn die Daten das konfigurierte Alter erreichen, verschiebt Timestream die Daten automatisch. Es ist auch möglich, die Haltedauer für den Magnetic-Tier festzulegen. Wenn Daten im Magnetspeicher ablaufen, werden sie automatisch gelöscht.

Wie oben kurz beschrieben, ist Timestream so konzipiert, dass es über eine vollständig entkoppelte Datenaufnahme-, Speicher- und Abfragearchitektur verfügt. Jede Komponente kann unabhängig von anderen Komponenten skaliert werden, womit eine Skalierung für unterschiedliche Situationen möglich ist. Das bedeutet, dass Timestream nicht "umkippt", wenn die Anwendungen Hunderte von Terabyte an Daten pro Tag senden oder Millionen von Abfragen ausführen, die kleine oder große Datenmengen verarbeiten. Diese Architektur gewährleistet auch nahezu gleichbleibende Abfragelatenz bis in den Petabytebereich. Dies liegt daran, dass die Abfragearchitektur von Timestream massive Mengen an Parallelität nutzen kann, die Daten für solche Anwendungen optimal abgelegt sind und somit sehr gut skalieren. Timestream-Abfragen werden in einer SQL-Grammatik ausgedrückt, die Erweiterungen für zeitreihenspezifische Unterstützung (zeitreihenspezifische Datentypen und Funktionen) enthält, sodass die Lernkurve für Entwickler, die bereits mit SQL vertraut sind, flach ist.

Wenn wir uns den IoT-Zeitreihen-Anwendungsfall noch einmal ansehen, sind die Anforderungen (1. Skalierbarkeit, 2. Elastizität, 3. Tiering von Daten, 4. Idempotenz und 5. Entkopplung Datenaufnahme und Abfrage) durch Amazon Timestream per Design gewährleistet. Darüber hinaus werden die verschiedenen Speicher- und Aufnahmekomponenten dank der zellularen Architektur des Dienstes bei Bedarf automatisch skaliert. Die Unterstützung von 6. Lifecycle der Daten wurde schon beschrieben. Bleiben also noch die Anforderungen 7. analytische Funktionen und 8. zeitserienspezifische Berechnungen.

Timestream unterstützt etwa vierzig Aggregatfunktionen wie SUM, AVG, MIN, MAX bis hin zu statistischen Funktionen wie CORR, SKEWNESS, APPROX_PERCENTILE[3]. Analytische Funktionen wie in SQL2003 beschrieben werden mittels RANGE und OVER auch unterstützt [4]. Diese Funktionen decken die meisten analytischen Anforderungen ab und werden kontinuierlich erweitert.

Zur Erleichterung des Umgangs mit zeitreihenspezifischen mathematischen Funktionen wie Interpolation, Integral- und Differenzial-Rechnung wurde ein spezielles TIMESERIES-Datenmodell-Konstrukt eingeführt. Das Zeitreihenmodell ist ein Abfragezeitkonstrukt und stellt die Daten als geordnete Folge von Zeit- und Messwertpaaren für eine Reihe von Dimensionen dar. Dieses Datenformat wird benötigt, um effizient die in Timestream integrierten Zeitreihenfunktionen zu nutzen. Somit lassen sich fehlenden Werte durch Interpolation ergänzen und die Änderungsrate (Ableitungen), sowie Korrelation zwischen zwei Zeitreihen mittels Abfragen aus den Daten in der Datenbank berechnen.

Um Daten von einem flachen Modell in ein Zeitreihenmodell umzuwandeln, enthält Timestream die integrierte Funktion CREATE_TIME_SERIES(time, value), die zwei Eingabespalten (time und measure) akzeptiert und eben diesen Zeitreihen-Datentyp als eine Folge von Zeitstempeln zurückgibt. Mittels UNNEST(timeseries) ist es möglich, wieder zur normalen tabellarischen Form zurück zu wandeln.

Sehen wir uns anhand der standardmäßigen IoT-Beispieldatenbank von der Amazon-Timestream-Seite in der AWS-Konsole das Format und die Art der Transformation an, die wir ausführen können. Wir können die Beispieldatenbank mit SQL-Grammatik wie in der folgenden Anweisung abfragen:

SELECT time, truck_id, ... , measure_name, measure_value::double, ...
  FROM "<DATENBANK>"."<TABELLE>"
 WHERE time between ago(7d) and now()
 ORDER BY time DESC
 LIMIT 10

Auf ähnliche Weise können wir jetzt die umfangreichen Analysefunktionen von Timestream einsetzen, um Abfragen wie beispielsweise den letzten Kraftstoffstand für jeden LKW in den letzten 24 Stunden zu finden.

WITH latest_recorded_time AS (
  SELECT truck_id,
         max(time) as latest_time
    FROM "<DATENBANK>"."<TABELLE>"
   WHERE measure_name = 'fuel-reading'
     AND time >= ago(24h)
   GROUP BY truck_id
)
SELECT b.truck_id, b.fleet, ... , b.time,
       b.measure_value::double as last_reported_fuel_reading
  FROM latest_recorded_time a 
 INNER JOIN "<DATENBANK"."<TABELLE>" b
    ON a.truck_id = b.truck_id AND b.time = a.latest_time
 WHERE b.measure_name = 'fuel-reading'
   AND b.time > ago(24h)
 ORDER BY b.truck_id

Es lassen sich aber auch Minima und Maxima der Füllstandsveränderung mittels erster Ableitung durch Abfragen realisieren, wobei beispielsweise vorher noch fehlende Werte durch lineare Interpolation ergänzt werden können. Alle zeitreihenspezifischen Funktionen im Timestream sind in [5] beschrieben.

Telemetrie-Messwerte sollten grundsätzlich nicht von vornherein als Zeit-Äquidistante angenommen werden, das kann bei analytischen Auswertungen und Aggregationen zu unerwarteten Verfälschungen führen. Solche Effekte treten auf, wenn Sensorfunktionen als Hintergrundprozesse laufen und nicht in Echtzeit mit einer exakten Frequenz Nachrichten erzeugt und gesendet werden. Es ist daher bei der Verarbeitung von IoT-Daten auch darauf zu achten, dass die Messwerte auch auf der Zeitachse normalisiert werden. In Timestream könnte eine Normalisierung auf ein 1-Minuten-Intervall wie folgt umgesetzt werden.

SELECT bin(time, 1m) as time, truck_id, measure_name, 
       avg(measure_value::double) as measure_value
  FROM "<DATENBANK>"."<TABELLE>"
 WHERE time between ago(7d) and now()
 GROUP BY bin(time, 1m), truck_id , measure_name
 ORDER BY time DESC
 LIMIT 10

Amazon Timestream erfüllt also alle acht oben angeführten Anforderungen.

Szenario 2: Spielerverhalten und Anomalieerkennung

Ein anders gelagertes Szenario, bei dem der Faktor Zeit ebenso eine wesentliche Rolle spielt, ist die Analyse von Spielern in einem Onlinespiel. Hier werden beispielsweise die Spielereignisse und Aktionen jedes Spielers gesammelt und anhand eines LevelUp-Ereignisses wird die Summe der Aktionen über die Zeit betrachtet, um die Anzahl der Punkte zu ermitteln. Auch in diesem Szenario sind die einzelnen Datensätze sehr klein, veränderlich oder aktionsabhängig und kommen in unregelmäßigen Abständen als "Append Only"-Nachrichtenstrom in einem zentralen System an. Auch hier empfiehlt es sich, etwaige verzögerungssensible Aktionen ereignisgesteuert mittels CEP zu verarbeiten. Dass bei Onlinespielen Skalierbarkeit und Elastizität eine zentrale Anforderung sind, sollte klar sein, jedoch unterscheiden sich hier die Abfragemuster wesentlich vom vorherigen Telemetrieszenario.

Laden einzelner Zeitreihen, um diese weiter zu verarbeiten – es werden keine Aggregationen durchgeführt.
Abfragen müssen innerhalb von wenigen Millisekunden die Zeitreihe für einen Spieler liefern.
Es müssen alle Aktionen einer Zeitreihe, die teilweise auch lange Zeit zurückliegen, geladen und analysiert werden.

Daraus leiten sich nun in diesem Szenario folgende zentralen funktionalen und qualitativen Anforderungen an eine Datenbank ab:

Skalierbarkeit der Verarbeitung und Speicherung von vielen Millionen Nachrichten
Elastizität in Bezug auf Spitzenlasten, Upscaling/Downscaling muss möglich sein
Aktionen können mehrfach innerhalb einer Sekunde vorkommen
Zeitserien werden immer als Gesamtes betrachtet und müssen extrem schnell bereitgestellt werden
ACID-Transaktionen werden benötigt, um garantiert konsistente Abfragen zu gewährleisten

Die Anforderungen 1. und 2. überschneiden sich mit denen von oben und passen sehr gut zu einer Zeitreihendatenbank. Da Idempotenz bei zu ungenauer Zeitgranularität (wie Sekunden) der Nachrichten mehrfache Aktionen als eine betrachten würde, ist in diesem Szenario sicherzustellen, die Zeit zumindest mit einer Genauigkeit von Millisekunden zu erfassen. Amazon Timestream kann mit der Genauigkeit im Milli-, Micro- und Nano-Sekunden arbeiten, somit würde Punkt 3. erfüllbar sein. Die Anforderung 4. steht nun etwas im Widerspruch zu analytischen Eigenschaften, im Speziellen sind einstellige Latenzen für Zeitreihen die über den In-Memory-Tier hinausragen, bei Amazon Timestream nicht gewährleistet. Extrem niedrige Latenz und die ACID-Anforderung werden aber von Amazon DynamoDB unterstützt und da keine analytischen Abfragen gemacht werden, ist in diesem Szenario eine Key-Value-Datenbank die bessere Wahl.

NoSQL- und zweckgerichtete Zeitreihendatenbanken werden im Hinblick auf Skalierbarkeit und Flexibilität entwickelt und gehen ihrerseits Kompromisse in anderen Bereichen ein, um die versprochene Leistung zu erbringen. Zum Beispiel werden Limitierungen in Bezug auf die Datensatzgröße in Kauf genommen. In DynamoDB können Elemente bis zu einer maximalen Größe von 400 KB gespeichert werden. In Timestream beträgt die maximale Gesamtgröße eines Datensatzes einschließlich Dimensionen und Kennzahlen 4 KB. Die maximale Datengröße für ein Abfrageergebnis in DynamoDB ist mit 16 MB limitiert, wobei Timestream bis zu 5 GB Daten zurückgeben kann [6].

Fazit

In diesem Artikel haben wir beschrieben, wie im Zusammenhang mit Zeitreihen verschiedene Technologien abgewogen werden können. Für sehr kurze Reaktionszeiten sind Streaming-Plattformen und ein ereignisgesteuerter Architekturansatz im Vorteil. In Szenarien, in denen sehr geringe Antwortzeiten auf einfache Abfragen über einen größeren Zeitraum gefordert sind, kann eine NoSQL-Datenbank wie Amazon DynamoDB die beste Wahl sein. Hoch skalierbare Zeitreihendatenbanken wie Amazon Timestream verfügen dahingegen über umfassende Analysefunktionen, mathematische Zeitserienfunktionen und automatisiertes Lifecycle-Management und bieten sich daher primär für analytische Anwendungen an. Bei zweckgerichteten Datenbanken gilt es abzuwägen und sicherzustellen, dass die Applikation die Datenbank auch für den entsprechenden Zweck nutzt.

Da der Betrieb von Datenbanken nicht trivial ist und spezielle Kenntnisse erforderlich sind, sollten bei der Wahl auch betriebliche Aspekte eine Rolle spielen. Ein professioneller Betrieb bindet signifikante Ressourcen. Damit Entwicklungsteams sich auf wertschöpfende und differenzierende Funktionalitäten konzentrieren können, übernimmt bei Amazon Timestream und Amazon DynamoDB, AWS die gesamte Komplexität des Betriebes. Abschließend bleibt zu sagen, dass bei der Wahl eines Datenbanksystems immer Abfrageanforderungen und nicht-funktionale Anforderungen die zentrale Rolle spielen sollten und dann erst Dateneigenschaften – es empfiehlt sich also ein "Working Backwards"-Ansatz, in dem Sinne, dass man zuerst die Workload-Anforderungen verstehen und darauf basierend eine zweckgerichtete Lösung entwickeln sollte.

Quellen