Häufig gestellte Fragen zu Amazon Timestream

Zeitreihendaten sind eine Abfolge von Datenpunkten – wie Aktienkurse, Temperatur und CPU-Auslastung einer Amazon EC2-Instance –, die im Laufe der Zeit aufgezeichnet werden. Bei Zeitreihendaten besteht jeder Datenpunkt aus einem Zeitstempel, einem oder mehreren Attributen und dem Ereignis, das sich im Laufe der Zeit ändert. Diese Daten werden verwendet, um Einblicke in die Leistung und den Zustand einer Anwendung abzuleiten, Anomalien zu erkennen und Optimierungsmöglichkeiten zu identifizieren.

Beispielsweise möchten DevOps-Ingenieure möglicherweise Daten anzeigen, die Änderungen der Infrastrukturleistungskennzahlen messen, Hersteller möchten möglicherweise IoT-Sensordaten verfolgen, die Temperaturänderungen bei Geräten in einer Einrichtung messen, und Online-Vermarkter möchten möglicherweise Clickstream-Daten analysieren, die erfassen, wie ein Benutzer im Laufe der Zeit auf einer Website navigiert. Da Zeitreihendaten aus mehreren Quellen in extrem hohen Mengen generiert werden, müssen sie kostengünstig gespeichert und nahezu in Echtzeit analysiert werden, um wichtige Geschäftserkenntnisse abzuleiten.

Amazon Timestream bietet vollständig verwaltetes InfluxDB, eine der beliebtesten Open-Source-Zeitreihendatenbanken auf dem Markt, und LiveAnalytics, eine Serverless-Zeitreihendatenbank, die skalierbar ist.

Ja, Sie können einen Database Savings Plan für Ihre Nutzung von Amazon Timestream erwerben und Ihre Kosten um bis zu 20 % reduzieren, wenn Sie sich zu einer gleichbleibenden Nutzung über einen Zeitraum von 1 Jahr verpflichten. Weitere Informationen zur berechtigten Nutzung finden Sie auf der Preisseite der Database Savings Plans.

Sie können mit Timestream beginnen, indem Sie die AWS-Managementkonsole, die AWS Command Line Interface (AWS CLI) oder die SDKs verwenden. Weitere Informationen, einschließlich Tutorials und anderer Inhalte für den Einstieg, finden Sie im Entwicklerhandbuch.

Amazon Timestream für InfluxDB sollte für Anwendungsfälle verwendet werden, die Zeitreihenabfragen nahezu in Echtzeit erfordern und wenn Sie InfluxDB-Features oder Open-Source-APIs benötigen. Die bestehende Timestream-Engine, Amazon Timestream für LiveAnalytics, sollte verwendet werden, wenn Sie mehr als 10 Gigabyte an Zeitreihendaten pro Minute aufnehmen und innerhalb von Sekunden SQL-Abfragen für Terabyte von Zeitreihendaten ausführen müssen.

Ja. Die beiden Engines ergänzen sich für die Erfassung von Zeitreihendaten mit niedriger Latenz und großem Umfang. Sie können Daten in Timestream für InfluxDB erfassen und ein Telegraf-Plugin verwenden, um Daten zur Analyse historischer Daten über SQL-Abfragen an Timestream zu senden.

Wenn Sie sich entscheiden, Ihre Timestream-für-InfluxDB-Daten in Timestream für LiveAnalytics zu migrieren, fallen für die Nutzung dieses Services öffentliche Abrechnungsgebühren an, einschließlich Erfassung, Speicherung und Abfrage. Es ist optional, Timestream für LiveAnalytics mit Timestream für InfluxDB zu verwenden.

Timestream für InfluxDB kann separat oder zusammen mit Ihren Timestream-für-LiveAnalytics-Workloads verwendet werden. Timestream für InfluxDB ist für Anwendungen nahezu in Echtzeit mit einstelligen Millisekunden-Reaktionszeiten vorgesehen. Timestream für LiveAnalytics adressiert Anwendungsfälle, bei denen Gigabyte an Daten innerhalb von Minuten aufgenommen und Terabyte an Daten in Sekunden abgefragt werden müssen. Sie können Timestream für InfluxDB und Timestream für LiveAnalytics in Ihren Anwendungen oder Dashboards kombinieren.

Nein. Timestream erstellt dynamisch das Schema einer Tabelle auf der Grundlage einer Reihe von dimensionalen Attributen und Kennzahlen. Dies bietet eine flexible und inkrementelle Schemadefinition, die jederzeit angepasst werden kann, ohne die Verfügbarkeit zu beeinträchtigen.

Sobald Ihre Datenbanken erstellt wurden und verfügbar sind, können Sie Endpunktinformationen von der Timestream-Konsole abrufen. Alternativ können Sie auch die Describe-API verwenden, um Endpunktinformationen abzurufen (DescribeDatabase, wenn Sie Timestream für LiveAnalytics verwenden, und DescribeDBInstances, wenn Sie Timestream für InfluxDB verwenden).

Mit Grafana, einem plattformübergreifenden Open-Source-Analyse- und interaktiven Visualisierungstool, können Sie Ihre Timestream-Zeitreihendaten visualisieren und Benachrichtigungen erstellen. Weitere Informationen und Beispielanwendungen finden Sie in der Dokumentation.

Sie können AWS-Lambda-Funktionen erstellen, die mit Timestream interagieren. Weitere Informationen finden Sie in der Dokumentation.

Sie können Zeitreihendaten, die mit Open-Source-Telegraf erfasst wurden, mithilfe des Telegraf-Connectors direkt an Timestream senden. Weitere Informationen finden Sie in der Dokumentation.

Sie können von Ihrer Amazon Virtual Private Cloud (Amazon VPC) über VPC-Endpunkte auf Timestream zugreifen. Amazon-VPC-Endpunkte sind einfach zu konfigurieren und bieten zuverlässige Konnektivität zu Timestream-APIs, ohne dass ein Internet-Gateway oder eine NAT-Instance erforderlich ist.

AWS CloudFormation vereinfacht die Bereitstellung und Verwaltung durch CloudFormation-Vorlagen für eine schnelle und zuverlässige Bereitstellung der Services oder Anwendungen. CloudFormation bietet umfassende Unterstützung für Timestream, indem Vorlagen zum Erstellen von Datenbanken bereitgestellt werden (sowohl für Timestream für LiveAnalytics als auch Timestream für InfluxDB). Die Vorlagen sind mit der letzten Ankündigung von Timestream für InfluxDB auf dem neuesten Stand und bieten Timestream-Kunden Flexibilität und Benutzerfreundlichkeit.

Amazon Timestream für LiveAnalytics ist eine schnelle, skalierbare Serverless-Zeitreihendatenbank, die für umfangreiche Workloads konzipiert wurde. Es ist Serverless und skaliert automatisch hoch oder herunter, um Kapazität und Leistung anzupassen, sodass Sie die zugrunde liegende Infrastruktur nicht verwalten müssen. Dank der vollständig entkoppelten Architektur können Sie Billionen von Datenpunkten aufnehmen und Millionen von Abfragen pro Tag ausführen.

Mit der adaptiven Abfrage-Engine von Timestream für LiveAnalytics können Sie gemeinsam auf aktuelle und historische Daten zugreifen und diese analysieren, ohne deren Standort angeben zu müssen. Es verfügt über integrierte Funktionen für die Zeitreihenanalyse, mit denen Sie Trends und Muster in Ihren Daten nahezu in Echtzeit erkennen können.

Timestream für LiveAnalytics wurde entwickelt, um Zeitreihendaten zu sammeln, zu speichern und zu verarbeiten. Die Serverless-Architektur unterstützt vollständig entkoppelte Services zur Datenerfassung, Speicherung und Abfrageverarbeitung, die unabhängig voneinander skaliert werden können und eine praktisch unendliche Skalierung für die Anforderungen Ihrer Anwendung ermöglichen. Anstatt das Schema bei der Tabellenerstellung vorzudefinieren, wird das Schema einer Timestream-Tabelle dynamisch auf der Grundlage der Attribute der eingehenden Zeitreihendaten erstellt, was eine flexible und inkrementelle Schemadefinition ermöglicht.

Für die Datenspeicherung partitioniert Timestream für LiveAnalytics die Daten nach Zeit und Attributen und beschleunigt so den Datenzugriff mithilfe eines speziell entwickelten Indexes. Attribute Ihrer Daten wie der Name der Kennzahl oder der gewählte Partitionierungsschlüssel spielen eine entscheidende Rolle bei der effektiven Partitionierung und beim performanten Abrufen Ihrer Daten. Darüber hinaus automatisiert Timestream für LiveAnalytics das Datenlebenszyklusmanagement, indem es einen In-Memory-Speicher für aktuelle Daten und einen Magnetspeicher für historische Daten bietet und konfigurierbare Regeln unterstützt, um Daten automatisch vom Speicher in den Magnetspeicher zu verschieben, wenn sie ein bestimmtes Alter erreichen.

Timestream für LiveAnalytics vereinfacht auch den Datenzugriff durch seine speziell entwickelte adaptive Abfrage-Engine, die nahtlos auf Daten aus verschiedenen Speicherebenen zugreifen und diese kombinieren kann, ohne den Datenstandort angeben zu müssen, sodass Sie mithilfe von SQL schnell und einfach Erkenntnisse aus Ihren Daten ableiten können. Schließlich arbeitet Timestream nahtlos mit Ihren bevorzugten Datenerfassungs-, Visualisierungs-, Analyse- und Machine Learning (ML)-Services zusammen, sodass Sie Timestream problemlos in Ihre Zeitreihenlösungen integrieren können.

Timestream für LiveAnalytics bietet eine Verfügbarkeit von 99,99 %. Weitere Informationen finden Sie im Service Level Agreement (SLA).

Mit Timestream für LiveAnalytics zahlen Sie nur für die tatsächliche Nutzung. Schreibvorgänge, gespeicherte Daten und von Abfragen gescannte Daten werden Ihnen separat in Rechnung gestellt. Timestream skaliert automatisch Ihre Schreib-, Speicher- und Abfragekapazität je nach Nutzung. Sie können die Datenaufbewahrungsrichtlinie für jede Tabelle festlegen und wählen, ob die Daten in einem In-Memory- oder Magnetspeicher gespeichert werden sollen. Detaillierte Preise finden Sie auf der Seite mit den Preisen.

Ja, Timestream für LiveAnalytics bietet eine 1-monatige kostenlose Testversion für alle neuen Konten. Die Nutzung der kostenlosen Testversion ist auf 50 GB Datenerfassung, 100 GB Magnetspeicher, 750 GB-Stunden Speicherplatz und 750 GB gescannter Daten begrenzt.

Für die Nutzung, die über den Umfang der kostenlosen Testversion hinausgeht, werden Ihnen die Standardpreise von Timestream für LiveAnalytics in Rechnung gestellt. Weitere Informationen finden Sie auf der Preisseite.

Die aktuelle Verfügbarkeit in der Region finden Sie auf der Preisseite.

Timestream für LiveAnalytics bietet Latenzen nahezu in Echtzeit für die Datenerfassung. Der integrierte Arbeitsspeicher von Amazon Timestream ist für schnelle Point-in-Time-Abfragen optimiert, und der Magnetspeicher ist für die Unterstützung schneller analytischer Abfragen optimiert. Mit Timestream für LiveAnalytics können Sie Abfragen ausführen, die Dutzende von Gigabyte an Zeitreihendaten aus dem Speicher innerhalb von Millisekunden analysieren, und analytische Abfragen, die Terabyte an Zeitreihendaten aus dem Magnetspeicher innerhalb von Sekunden analysieren. Geplante Abfragen verbessern die Abfrageleistung weiter, indem Aggregate, Rollups und andere Echtzeitanalysen berechnet und gespeichert werden, die für häufig aufgerufene betriebliche Dashboards, Geschäftsberichte, Anwendungen und Systeme zur Geräteüberwachung verwendet werden.

Sie können Exabyte an Daten in einer einzigen Tabelle speichern. Da Ihre Daten im Laufe der Zeit wachsen, nutzt Timestream für LiveAnalytics seine verteilte Architektur und die enorme Parallelität, um größere Datenmengen zu verarbeiten und dabei die Abfragelatenzen nahezu unverändert zu halten.

Die Serverless-Timestream-Architektur unterstützt vollständig entkoppelte Systeme zur Datenerfassung, Speicherung und Abfrageverarbeitung, die unabhängig voneinander skaliert werden können. Timestream für LiveAnalytics überwacht kontinuierlich Ihre Anwendungsanforderungen in Bezug auf Erfassung, Speicherung und Abfragerate, sodass eine sofortige Skalierung ohne Ausfallzeiten für die Anwendung möglich ist.

Aktuelle Limits und Kontingente finden Sie in der Dokumentation.

Sie können Zeitreihendaten von verbundenen Geräten, IT-Systemen und Industrieanlagen sammeln und in Timestream für LiveAnalytics schreiben. Sie können Daten entweder direkt aus Ihrer Anwendung mithilfe der AWS SDKs oder aus Datenerfassungs-Services wie AWS IoT Core, Amazon Managed Service für Apache Flink oder Telegraf an Timestream für LiveAnalytics senden. Weitere Informationen finden Sie in der Dokumentation.

Als verspätete Daten gelten Daten, deren Zeitstempel in der Vergangenheit liegt und die außerhalb des Aufbewahrungsbereichs des Speichers liegen. Zukunftsdaten sind Daten, die einen Zeitstempel in der Zukunft haben. Mit Timestream können Sie beide Arten speichern und darauf zugreifen.

Um verspätete Daten zu speichern, schreiben Sie die Daten einfach in Timestream für LiveAnalytics, und der Service ermittelt anhand des Zeitstempels der Daten und der konfigurierten Datenaufbewahrungsdauer für den Speicher und die Magnetspeicher automatisch, ob sie in den Speicher oder in den Magnetspeicher geschrieben werden. Um Daten zu speichern, die länger als 15 Minuten in der Zukunft liegen, modellieren Sie Ihre Daten als Datensatz mit mehreren Kennzahlen und stellen Sie den zukünftigen Zeitstempel als Kennzahl innerhalb des Datensatzes dar.

Mithilfe des Batch-Ladevorgangs können Sie CSV-Dateien, die in Amazon Simple Storage Service (Amazon S3) gespeichert sind, in Timestream für LiveAnalytics aufnehmen. Sie können den Batch-Ladevorgang verwenden, um Daten aufzufüllen, die nicht sofort für die Analyse benötigt werden. Sie können Batch-Ladeaufgaben mithilfe der AWS-Managementkonsole, der AWS CLI und der AWS SDKs erstellen. Weitere Informationen finden Sie in der Dokumentation.

Sie können Daten von Ihren IoT-Geräten sammeln und diese Daten mithilfe von AWS-IoT-Core-Regelaktionen in Timestream für LiveAnalytics speichern. Weitere Informationen finden Sie in der Dokumentation.

Sie können Apache Flink verwenden, um Ihre Zeitreihendaten von Amazon Kinesis direkt in Timestream für LiveAnalytics zu übertragen. Weitere Informationen finden Sie in der Dokumentation.

Sie können Apache Flink verwenden, um Ihre Zeitreihendaten von Amazon Managed Streaming für Apache Kafka (Amazon MSK) direkt an Timestream für LiveAnalytics zu senden. Weitere Informationen finden Sie in der Dokumentation.

Timestream organisiert und speichert Zeitreihendaten in Partitionen. Die Partitionierung der Daten wird vom Service anhand der Attribute der Daten bestimmt. Attribute wie timestamp und measure_name oder kundendefinierte Partitionsschlüssel spielen eine wichtige Rolle bei der Entscheidung über die Partitionen. Weitere Informationen finden Sie im Blog von Werner Vogel. Wenn Sie Ihre Abfrageleistung optimieren möchten, um Ihren spezifischen Anforderungen besser gerecht zu werden, empfehlen wir die Verwendung kundendefinierter Partitionsschlüssel. Mit Timestream können Sie das Datenlebenszyklusmanagement automatisieren, indem Sie einfach Datenaufbewahrungsrichtlinien konfigurieren, um Daten automatisch vom Speicher in den Magnetspeicher zu verschieben, wenn sie das konfigurierte Alter erreichen.

Der Arbeitsspeicher von Timestream für LiveAnalytics ist ein schreiboptimierter Speicher, der die eingehenden Zeitreihendaten akzeptiert und dedupliziert. Der Arbeitsspeicher ist auch für latenzempfindliche Point-in-Time-Abfragen optimiert.

Der Magnetspeicher von Timestream für LiveAnalytics ist ein leseoptimierter Speicher, der für die Ausführung schneller Analyseabfragen entwickelt wurde, mit denen Hunderte von Terabyte an Daten gescannt werden können. Der Magnetspeicher ist auch für schnelle analytische Abfragen optimiert, bei denen Hunderte von Terabyte an Daten gescannt werden.

Sie können die Aufbewahrungsdauer sowohl für den Arbeitsspeicher als auch für den Magnetspeicher festlegen. Die Standarddauer sind 12 Stunden bzw. 10 Jahre. Wenn das Alter der Daten, bestimmt durch den Zeitstempel im Datensatz, die konfigurierte Aufbewahrungsdauer des Arbeitsspeichers überschreitet, ordnet Timestream für LiveAnalytics die Daten automatisch dem Magnetspeicher zu. Ebenso löscht der Service die Daten automatisch, wenn das Alter der Daten die konfigurierte Aufbewahrungsdauer des Magnetspeichers überschreitet.

Timestream für LiveAnalytics gewährleistet die Haltbarkeit Ihrer Daten, indem Ihre Speicher- und Magnetspeicherdaten automatisch über verschiedene Availability Zones innerhalb einer einzigen Region hinweg repliziert werden. Alle Ihre Daten werden auf die Festplatte geschrieben, bevor Ihre Schreibanforderung als abgeschlossen bestätigt wird.

Sie können SQL verwenden, um Ihre in Timestream gespeicherten Zeitreihendaten abzufragen. Sie können auch Zeitreihenanalysefunktionen für Interpolation, Regression und Glättung mithilfe von SQL verwenden. Weitere Informationen finden Sie in der Dokumentation. Die adaptive Abfrage-Engine von Timestream ermöglicht Ihnen den Zugriff auf die Daten über Speicherebenen hinweg mit einer einzigen SQL-Anweisung. Sie greift transparent auf Daten aus verschiedenen Speicherebenen zu und kombiniert sie, ohne dass Sie den Datenspeicherort angeben müssen. 

Die geplanten Abfragen von Timestream für LiveAnalytics bieten eine vollständig verwaltete und skalierbare Serverless-Lösung für die Berechnung und Speicherung von Aggregaten, Rollups und anderen Echtzeitanalysen, die für häufig aufgerufene betriebliche Dashboards, Geschäftsberichte, Anwendungen und Geräteüberwachungssysteme verwendet werden.

Bei geplanten Abfragen definieren Sie einfach die Echtzeitanalyseabfragen, die Aggregate, Rollups und andere Echtzeitanalysen für Ihre eingehenden Daten berechnen. Timestream führt diese Abfragen regelmäßig und automatisch aus und schreibt die Abfrageergebnisse zuverlässig in eine separate Tabelle. Sie können dann Ihre Dashboards, Berichte, Anwendungen und Überwachungssysteme so einrichten, dass sie einfach die Zieltabellen abfragen, anstatt die wesentlich größeren Quelltabellen abzufragen, die die eingehenden Zeitreihendaten enthalten. Dies führt zu Leistungs- und Kostensenkungen um eine Größenordnung, da die Zieltabellen viel weniger Daten enthalten als die Quelltabellen, wodurch der Datenzugriff und die Speicherung schneller und kostengünstiger sind.

Sie können JDBC- und ODBC-Treiber verwenden, um Timestream für LiveAnalytics mit Ihren bevorzugten Business-Intelligence-Tools und anderen Anwendungen zu verbinden. Weitere Informationen finden Sie in der JDBC- und ODBC-Dokumentation.

Mit Amazon QuickSight und Grafana können Sie Zeitreihendaten in Timestream für LiveAnalytics visualisieren und analysieren. Sie können QuickSight auch für Ihre ML-Anforderungen verwenden.

Mit QuickSight können Sie umfangreiche und interaktive Dashboards für Ihre Zeitreihendaten erstellen. Weitere Informationen finden Sie in der Dokumentation.

Sie können Amazon-SageMaker-Notebooks verwenden, um Ihre ML-Modelle in Timestream für LiveAnalytics zu integrieren. Weitere Informationen finden Sie in der Dokumentation.

Daten werden immer verschlüsselt, egal ob im Ruhezustand oder während der Übertragung. Mit Timestream für LiveAnalytics können Sie einen kundenverwalteten AWS Key Management Service (AWS KMS)-Schlüssel für die Verschlüsselung von Daten im Magnetspeicher einrichten.

Timestream für LiveAnalytics ist kompatibel mit ISO (9001, 27001, 27017 und 27018), PCI DSS, FedRAMP (Moderate) und Health Information Trust (HITRUST) Alliance Common Security Framework (CSF). Es ist auch HIPAA-fähig und im Geltungsbereich der AWS-SOC-1-, SOC-2- und SOC-3-Berichte.

Für Ihre Timestream-Ressourcen stehen Ihnen zwei Backup-Optionen zur Verfügung: On-Demand-Backups und geplante Backups. On-Demand-Backups sind einmalige Backups, die entweder über die Timestream-Konsole oder AWS Backup initiiert werden können. On-Demand-Backups sind nützlich, wenn Sie ein Backup erstellen möchten, bevor Sie eine Änderung an Ihrer Tabelle vornehmen, bei der Sie die Änderungen möglicherweise rückgängig machen müssen. Geplante Backups sind wiederkehrende Backups, die Sie mithilfe der AWS-Backup-Richtlinien in den gewünschten Intervallen (z. B. 12 Stunden, 1 Tag, 1 Woche usw.) konfigurieren können. Geplante Backups sind nützlich, wenn Sie fortlaufende Backups erstellen möchten, um Ihre Datenschutzziele zu erreichen.

Die erste Sicherung der Tabelle, entweder On-Demand oder nach Zeitplan, ist eine vollständige Sicherung, und jede nachfolgende Sicherung derselben Tabelle erfolgt inkrementell, wobei nur die Daten kopiert werden, die sich seit der letzten Sicherung geändert haben. 

Backups und Wiederherstellungen werden auf der Grundlage der Backup-Speichergröße der ausgewählten Tabelle berechnet, gemessen auf einer GB-Monatsbasis. Die Gebühren werden in Ihrer AWS-Rechnung unter „Backup“ ausgewiesen und beinhalten die Kosten für Backup-Speicher, Datenübertragungen, Wiederherstellungen und vorzeitiges Löschen. Da die Backups inkrementeller Natur sind, entspricht die Speichergröße der nachfolgenden Sicherung der Tabelle der Größe der seit der letzten Sicherung geänderten Datenmenge. Weitere Informationen finden Sie in den AWS-Backup-Preisen.

Zunächst müssen Sie AWS Backup aktivieren, um Ihre Timestream-für-LiveAnalytics-Ressourcen zu schützen (dies ist eine einmalige Aktion). Navigieren Sie nach der Aktivierung zur AWS-Managementkonsole oder verwenden Sie die CLI oder das SDK von AWS Backup, um On-Demand-Backups oder geplante Backups Ihrer Daten zu erstellen und diese Backups zwischen Konten und Regionen zu kopieren. Sie können Ihr Backup-Lebenszyklusmanagement auf der Grundlage Ihrer Datenschutzanforderungen konfigurieren. Weitere Informationen finden Sie in der Dokumentation zum Erstellen eines Backups. 

Sie können Ihre Timestream-für-LiveAnalytics-Tabellen über die AWS-Managementkonsole oder das AWS Backup CLI oder SDK wiederherstellen. Wählen Sie die Wiederherstellungspunkt-ID für die Ressource aus, die Sie wiederherstellen möchten, und geben Sie die erforderlichen Eingaben wie den Namen der Zieldatenbank, den neuen Tabellennamen und die Aufbewahrungseigenschaften ein, um den Wiederherstellungsvorgang zu starten. Nach erfolgreicher Wiederherstellung können Sie auf die Daten zugreifen. Wenn Sie versuchen, die letzte inkrementelle Sicherung Ihrer Tabelle wiederherzustellen, werden die gesamten Tabellendaten wiederhergestellt. In der Dokumentation finden Sie weitere Informationen.

Amazon Timestream für InfluxDB ist eine neue Zeitreihendatenbank-Engine, die es Anwendungsentwicklern und DevOps-Teams erleichtert, InfluxDB-Datenbanken in AWS für Echtzeit-Zeitreihenanwendungen mithilfe von Open-Source-APIs auszuführen. Mit Timestream für InfluxDB ist es einfach, Zeitreihen-Workloads einzurichten, zu betreiben und zu skalieren, die Abfragen mit einstelligen Millisekunden-Abfrageantworten beantworten können.

Timestream für InfluxDB unterstützt die Open-Source-Version 2.7 von InfluxDB. 

Sie sollten Timestream für InfluxDB verwenden, wenn Sie InfluxDB selbst verwalten, Open-Source-Zeitreihen-APIs verwenden möchten oder Zeitreihenanwendungen in Echtzeit erstellen, für die einstellige Millisekunden-Abfrageantworten erforderlich sind. Mit Timestream für InfluxDB profitieren Sie von Open-Source-APIs und einer Vielzahl von Open-Source-Telegraf-Agenten zum Sammeln von Zeitreihendaten. Sie müssen keine komplexen und zeitaufwändigen Aufgaben wie InfluxDB-Installation, Upgrades, Speicherung, Replikation für hohe Verfügbarkeit und Backups verwalten.

Timestream für InfluxDB bietet ein SLA von 99,9 % Verfügbarkeit, wenn es mit einer Multi-AZ-Konfiguration bereitgestellt wird, und 99,5 % Verfügbarkeit für eine Single-AZ-Konfiguration.

Timestream für InfluxDB wurde für Zeitreihen-Anwendungsfälle nahezu in Echtzeit entwickelt. Abhängig von den Instance-Konfigurationen und den Merkmalen der Workloads können Sie mit einer Schreib- und Leselatenz von etwa 1 Sekunde bei einer Abfragelatenz von einstelligen Millisekunden rechnen.

Um von einer selbstverwalteten InfluxDB-Instance zu Timestream für InfluxDB zu migrieren, können Sie einfach ein Backup aus einer vorhandenen InfluxDB-Datenbank in eine Timestream-für-InfluxDB-Instance mit ein paar Minuten Ausfallzeit wiederherstellen. Sie können Ihre Datenerfassungsagenten, wie beispielsweise Open-Source-Telegraf-Agenten, neu konfigurieren, um auf den von Timestream für InfluxDB verwalteten InfluxDB-Endpunkt abzuzielen. Dashboard-Technologien wie InfluxDB UI, selbst gehostetes Grafana oder Amazon Managed Grafana funktionieren weiterhin, indem sie so konfiguriert werden, dass sie den Timestream-für-InfluxDB-Endpunkt ohne weitere Codeänderungen verwenden.

Um von Timestream für LiveAnalytics zu Timestream für InfluxDB zu migrieren, können Sie Ihre Daten von Timestream für LiveAnalytics nach Amazon S3 exportieren, alle erforderlichen Änderungen an den exportierten CSV-Dateien vornehmen und sie in Timestream für InfluxDB laden.

Man kann sich eine DB-Instance als eine Datenbank-Umgebung in der Cloud vorstellen, die über die vom Benutzer festgelegten Rechen- und Speicherressourcen verfügt. Mithilfe der AWS-Managementkonsole, Timestream-für-InfluxDB-APIs und der AWS CLI können Sie DB-Instances erstellen und löschen, Infrastrukturattribute Ihrer DB-Instances definieren und verfeinern und Zugriff und Sicherheit kontrollieren. Sie können eine oder mehrere DB-Instances ausführen und jede DB-Instance kann je nach Workload-Merkmalen und Instance-Konfiguration eine oder mehrere Datenbanken (Buckets) oder Organisationen unterstützen.

DB-Instances sind einfach zu erstellen, undzwar mit der AWS-Managementkonsole, mit Timestream-für-InfluxDB-APIs oder der AWS CLI. Um eine DB-Instance mithilfe der AWS-Managementkonsole zu starten, wählen Sie InfluxDB-Datenbanken und dann im Dashboard die Schaltfläche „InfluxDB-Datenbank erstellen“. Von dort aus können Sie die Parameter für Ihre DB-Instance angeben, darunter Instance-Typ, Speichertyp und -menge, primäre Benutzer-Anmeldeinformationen und mehr.

Alternativ können Sie Ihre DB-Instance auch mithilfe der API CreateDBInstance oder über den Befehl "create-db-instance" erstellen.

Sobald Ihre DB-Instance verfügbar ist, können Sie ihren Endpunkt über die DB-Instance-Beschreibung in der AWS-Managementkonsole, in der GetDBInstance-API oder im Befehl „get-db-instance“ abrufen. Mit diesem Endpunkt und Ihrem Zugriffs-Token können Sie InfluxDB-APIs verwenden, um Schreib - und Leseanforderungen zu senden und die Engine mit Ihrem bevorzugten Datenbank-Tool oder Ihrer bevorzugten Programmiersprache zu verwalten. Mit demselben Endpunkt können Sie auch von Ihrem Browser aus auf die InfluxDB-Benutzeroberfläche zugreifen. Um für Ihre ausgeführte DB-Instance Netzwerkanfragen zu ermöglichen, müssen Sie den Zugriff autorisieren oder den öffentlichen IP-Zugriff aktivieren.

Standardmäßig dürfen Sie insgesamt bis zu 40 Timestream-für-InfluxDB-Instances haben.

Sie zahlen nur für das, was Sie tatsächlich nutzen. Es gibt keine Mindest- oder Einrichtungsgebühren. Die Abrechnung erfolgt auf folgender Grundlage:

• DB-Instance-Stunden: Basierend auf der Klasse (z. B. db.influx.large und db.influx.4xlarge) der genutzten DB-Instance. Teilweise verbrauchte DB-Instance-Stunden werden in 1-Sekunden-Schritten abgerechnet, mit einer Mindestgebühr von 10 Minuten nach einer abrechenbaren Statusänderung, wie z. B. dem Erstellen, Starten oder Ändern der DB-Instance-Klasse.
• Speicher (pro GB-Monat): Speicherkapazität, die Sie für Ihre DB-Instance bereitgestellt haben. Wenn Sie Ihre bereitgestellte Speicherkapazität innerhalb des Monats skalieren, wird Ihre Rechnung anteilig berechnet.
• Datenübertragung: Ein- und ausgehende Internet-Datenübertragung Ihrer DB-Instance.

Preisinformationen zu Timestream für InfluxDB finden Sie auf der Preisseite.

Die Fakturierung einer DB-Instance beginnt zu dem Zeitpunkt, ab dem die DB-Instance verfügbar ist. Die Fakturierung wird so lange fortgesetzt, bis die DB-Instance durch Löschen oder aufgrund eines Ausfalls beendet wird.

Die Abrechnung erfolgt für jede Stunde, in der die DB-Instance in einem verfügbaren Zustand ausgeführt wird. Wenn Sie für die DB-Instance keine Gebühren mehr zahlen möchten, müssen Sie sie anhalten oder löschen, damit Ihnen keine weiteren Instance-Stunden in Rechnung gestellt werden. Teilweise verbrauchte DB-Instance-Stunden werden in 1-Sekunden-Schritten abgerechnet, mit einer Mindestgebühr von 10 Minuten nach einer abrechenbaren Statusänderung, wie z. B. dem Erstellen, Starten oder Ändern der DB-Instance-Klasse.

Solange Ihre Datenbank-Instance angehalten ist, wird Ihnen der bereitgestellte Speicher in Rechnung gestellt, nicht jedoch die DB-Instance-Stunden.

Wenn Sie festlegen, dass Ihre DB-Instance als Multi-AZ-Bereitstellung genutzt wird, wird entsprechend den Multi-AZ-Preisen, die auf der Seite zu den Timestream-für-InfluxDB-Preisen einzusehen sind, abgerechnet. Die Multi-AZ-Abrechnung basiert auf den folgenden Punkten:

• Multi-AZ-DB-Instance-Stunden: Basierend auf der Klasse (z. B. db.influx.large und db.influx.4xlarge) der genutzten DB-Instance. Ebenso wie Standard-Bereitstellungen in einer Availability Zone, werden teilweise konsumierte DB-Instance-Stunden in 1-Sekunden-Schritten mit einer Mindestgebühr von 10 Minuten nach einer abrechenbaren Statusänderung wie dem Erstellen, Starten oder Ändern der DB-Instance-Klasse abgerechnet. Wenn Sie innerhalb einer angebrochenen Stunde zwischen der Standardbereitstellung und der Multi-AZ-Bereitstellung für Ihre DB-Instance wechseln, werden beide jeweils geltenden Gebühren für diese Stunde in Rechnung gestellt.
• Bereitgestellter Speicherplatz (für Multi-AZ-DB-Instances): Wenn Sie innerhalb einer beliebigen Stunde zwischen der Standardbereitstellung und der Multi-AZ-Bereitstellung für Ihre DB-Instance wechseln, wird die höhere Speichergebühr für diese Stunde in Rechnung gestellt.
• Datenübertragung: Die Datenübertragung, die bei der Replikation von Daten zwischen Ihrer Primär- und Ihrer Standby-Instance anfällt, wird Ihnen nicht in Rechnung gestellt. Die Internet-Übertragung von Daten Ihrer DB-Instance wird in beide Richtungen genauso abgerechnet wie bei standardmäßigen Bereitstellungen.

Falls nicht anders angegeben, gelten unsere Preise zuzüglich anfallender Steuern und Abgaben, darunter MwSt. und Umsatzsteuer. Bei Kunden mit japanischer Rechnungsadresse unterliegt die Nutzung von AWS-Services der japanischen Verbrauchssteuer. 

• Ihre Rechnung für Lesereplikat-Cluster von Timestream für InfluxDB wird pro Instance innerhalb des Clusters gemäß den Preisen berechnet, die auf der Timestream-für-InfluxDB-Preisseite aufgeführt sind. Die Abrechnungsstruktur besteht aus vier Hauptkomponenten:
  Cluster-Knotenstunden werden auf der Grundlage Ihrer ausgewählten Instance-Klasse (z. B. db.influx.large oder db.influx.4xlarge) berechnet. Die Abrechnung erfolgt in 1-Sekunden-Schritten mit einer Mindestgebühr von 10 Minuten nach jeder abrechenbaren Statusänderung, einschließlich Anlegen, Start oder Änderung der Instance-Klasse. Wenn Sie innerhalb einer Stunde zwischen Cluster-Typen konvertieren, werden Ihnen beide in diesem Zeitraum geltenden Tarife in Rechnung gestellt.
• Der Speicherplatz wird Ihnen auf der Grundlage Ihrer bereitgestellten Kapazität in Rechnung gestellt. Bei der Konvertierung zwischen Bereitstellungstypen (Cluster-, Standard- oder Multi-AZ-DB) innerhalb einer Stunde wenden wir den jeweils höheren der für diese Stunde geltenden Speicherraten an.
• Bezüglich der Datenübertragung fallen für Sie keine Gebühren für die Datenreplikation zwischen Ihrer Primär- und Replikat-Instance an. Für die Internetübertragung von Daten in und aus Ihrem DB-Cluster gelten jedoch dieselben Preise wie für Standardbereitstellungen.
• Die Lesereplikat-Funktion wird durch ein lizenziertes Add-on bereitgestellt, das von InfluxData entwickelt und verkauft wird und über den AWS Marketplace aktiviert wird. Diese Lizenz basiert auf einem nutzungsabhängigen Zahlungsmodell. Die Gebühren richten sich nach Ihren Instance-Stunden und nach der Anzahl der vCPUs in Ihrer konfigurierten Instance-Klasse.
  

Um Ihre anfängliche DB-Instance-Klasse und Speicherkapazität auszuwählen, sollten Sie den Rechen- und Speicherbedarf der betreffenden Anwendung abschätzen. Informationen zu den verfügbaren DB-Instance-Klassen finden Sie im Timestream-für-InfluxDB-Benutzerhandbuch.

IOPS-inklusiver Speicher in Timestream für InfluxDB ist eine durch SSD unterstützte Speicheroption, die so konzipiert wurde, dass sie eine schnelle, vorhersehbare und konsistente E/A-Leistung bietet. IOPS-inklusivem Speicher in Timestream für InfluxDB haben Sie drei Stufen zur Auswahl, die von kleinen Workloads bis hin zu großen, leistungsoptimierten Workloads reichen. Sie geben nur die Volumegröße an, die der Stufe zugewiesen ist, die Ihren Anforderungen besser entspricht. IOPS-inklusiver Speicher in Timestream für InfluxDB ist für E/A-intensive, transaktionale Datenbank-Workloads (OLTP) optimiert. Weitere Informationen finden Sie im Timestream-für-InfluxDB-Benutzerhandbuch.

Wählen Sie den Speichertyp, der für Ihren Workload am besten geeignet ist.

• Leistungsstarke OLTP-Workloads: Timestream für InfluxDB IOPS-inklusive Speicher.

Timestream für InfluxDB wählt standardmäßig die optimalen Konfigurationsparameter für Ihre DB-Instance aus und berücksichtigt dabei Instance-Klasse und Speicherkapazität. Wenn Sie sie jedoch ändern möchten, können Sie dies über die AWS-Managementkonsole, Timestream-für-InfluxDB-APIs oder die AWS CLI tun. Beachten Sie, dass eine Änderung der empfohlenen Werte der Konfigurationsparameter unbeabsichtigte Folgen haben kann, die von einer herabgesetzten Leistung bis hin zu Systemzusammenbrüchen reichen können. Derartige Änderungen sollten daher nur von erfahrenen Benutzern vorgenommen werden, die bereit sind, diese Risiken in Kauf zu nehmen.

Beim Start werden wir eine begrenzte Anzahl von Parametern bereitstellen, die von Ihnen geändert werden können. Dazu gehören: flux-log-enabled, log-level, metrics-disable, no-tasks, query-concurrency, query-queue-size und tracing-type. Diese Liste kann im Laufe der Zeit je nach Kundenanforderungen erweitert werden.

Eine DB-Parametergruppe ist eine Art „Container“ für die Werte der Engine-Konfiguration, die auf ein oder mehrere DB-Instances angewendet werden können. Falls Sie eine DB-Instance erstellen, ohne eine DB-Parametergruppe anzugeben, wird eine standardmäßige DB-Parametergruppe verwendet. Diese Standardgruppe enthält Engine-Standardwerte und Systemstandards für Timestream für InfluxDB, die für die von Ihnen ausgeführte DB-Instance optimiert sind.

Wenn Sie die DB-Instance jedoch mit benutzerdefinierten Werten für die Engine-Konfiguration ausführen möchten, können Sie einfach eine neue DB-Parametergruppe erstellen, die betreffenden Parameter ändern und festlegen, dass die DB-Instance die neue DB-Parametergruppe verwendet. 

Wenn Sie Ihre DB-Instance zur Ausführung als Multi-AZ-Bereitstellung erstellen oder modifizieren, stellt Timestream für InfluxDB automatisch ein synchrones Standby-Replikat in einer anderen Availability Zone bereit und verwaltet dieses. Aktualisierungen Ihrer DB-Instance werden synchron über mehrere Availability Zones in der Standby-Datenbank repliziert, damit Ihre letzten Datenbank-Updates synchronisiert und gegen einen Ausfall der DB-Instance geschützt sind. 

Während bestimmten geplanten Wartungs- bzw. Aktualisierungsarbeiten oder im unwahrscheinlichen Fall eines Ausfalls der DB-Instance oder der Availability Zone führt Timestream für InfluxDB automatisch einen Failover zur Standby-Datenbank aus, sodass die Schreib- und Lesevorgänge in Ihrer Datenbank unmittelbar nach dem Wechsel fortgesetzt werden können. Da der Namensdatensatz für Ihre DB-Instance gleich bleibt, kann Ihre Anwendung den Datenbankbetrieb ohne manuellen administrativen Eingriff fortsetzen.

Mit Multi-AZ-Bereitstellungen ist die Replikation transparent. Sie interagieren nicht direkt mit dem Standby, der nicht für den Leseverkehr verwendet werden kann.

Availability Zones sind isolierte Standorte innerhalb einer Region, d. h., sie sind bei Ausfällen in anderen Availability Zones nicht betroffen. Jede Availability Zone wird auf ihrer eigenen physisch getrennten, unabhängigen Infrastruktur ausgeführt und ist auf hohe Zuverlässigkeit ausgelegt. Übliche Fehlerquellen wie Generatoren und Kühlanlagen werden nicht von mehreren Availability Zones geteilt. Die physische Trennung sorgt außerdem dafür, dass sogar bei äußerst seltenen Katastrophen wie Bränden, Stürmen oder Überflutungen nur eine Availability Zone betroffen ist. Availability Zones innerhalb derselben Region profitieren von einer Netzwerkverbindung mit niedrigen Latenzen.

Wenn Sie eine DB-Instance als Multi-AZ-Bereitstellung betreiben, steht die primäre Datenbank für Schreib- und Lesevorgänge in der Datenbank zur Verfügung. Zusätzlich dazu stellt Timestream für InfluxDB im Hintergrund eine „Standby“-Instance zur Verfügung, die ein stets aktuelles Replikat der Primär-Instance darstellt. Bei Failover-Szenarios wird die Standby-Instance hochgestuft. Nach dem Failover wird also die Standby-Instance zur Primär-Instance und nimmt dann Ihre Datenbank-Operationen entgegen. Zu keinem Zeitpunkt vor der Hochstufung interagieren Sie direkt mit der Standby-Instance (beispielsweise bei Lesevorgängen).

Die Hauptvorteile einer Ausführung Ihrer DB-Instance als Multi-AZ-Bereitstellung sind die erhöhte Zuverlässigkeit und Verfügbarkeit der Datenbank. Dank ihrer erhöhten Verfügbarkeit und Fehlertoleranz sind Multi-AZ-Bereitstellungen die ideale Lösung für Produktionsumgebungen.

Wenn Sie Ihre DB-Instance als Multi-AZ-Bereitstellung ausführen, sind Ihre Daten im unwahrscheinlichen Fall, dass eine DB-Instance-Komponente ausfällt oder der Service in einer Availability Zone unterbrochen wird, sicher.

Wenn beispielsweise ein Speicher-Volume Ihrer Primär-Instance ausfällt, initiiert Timestream für InfluxDB automatisch einen Failover zur Standby-Instance, wo all Ihre Datenbank-Updates in intakter Form vorliegen. Dies bietet also zusätzliche Datenbeständigkeit im Vergleich zu Standard-Bereitstellungen in einer einzelnen Availability Zone: Hier wäre eine vom Benutzer angestoßene Wiederherstellung erforderlich, und Updates, die nach dem letztmöglichen Wiederherstellungszeitpunkt (in der Regel in den letzten 5 Minuten) durchgeführt wurden, stünden nicht zur Verfügung.

Beim Betrieb Ihrer DB-Instance als Multi-AZ-Bereitstellung profitieren Sie darüber hinaus von einer verbesserten Datenbankverfügbarkeit. Bei einem Ausfall einer Availability Zone oder DB-Instance wird die Verfügbarkeit lediglich für den Zeitraum beeinträchtigt, der für das automatische Failover benötigt wird. Die Verfügbarkeitsvorteile von Multi-AZ kommen auch bei geplanten Wartungen bzw. Aktualisierungen zum Tragen. Ein weiterer Vorteil, den die Ausführung Ihrer DB-Instance als Multi-AZ-Bereitstellung mit sich bringt, liegt darin, dass das DB-Instance-Failover automatisch erfolgt und keinen Verwaltungsaufwand mit sich bringt. 

Aufgrund der synchronen Datenreplikation, die in Ihrem Auftrag durchgeführt wird, kann es zu erhöhten Latenzen im Vergleich zur standardmäßigen Bereitstellung einer DB-Instance in einer einzelnen Availability Zone kommen.

Nein, mit einem Standby-Replikat mit Multi-AZ können keine Leseanforderungen bearbeitet werden. Der Zweck von Multi-AZ-Bereitstellungen ist eine Verbesserung der Datenbankverfügbarkeit und -zuverlässigkeit und nicht eine Skalierung der Lesevorgänge. Die Replikation zwischen Primär- und Standby-Instance erfolgt synchron. Durch unsere Implementierung wird sichergestellt, dass Primär- und Standby-Instance konstant synchronisiert werden, gleichzeitig ist die Standby-Instance aber von Lese- oder Schreibvorgängen ausgeschlossen.

Um eine Multi-AZ-DB-Instance-Bereitstellung einzurichten, wählen Sie einfach die Option „Standby-Instance erstellen“ für Multi-AZ-Bereitstellung, wenn Sie eine DB-Instance mit der AWS-Managementkonsole starten. Wenn Sie die Timestream-für-InfluxDB-APIs verwenden, können Sie die API „CreateDBInstance“ nutzen und den Multi-AZ-Parameter auf den Wert „Wahr“ setzen.
Sie können auch eine Ihrer vorhandenen Instances ändern und den Bereitstellungstyp auf Multi-AZ setzen.

Bei Multi-AZ-Bereitstellungen erfolgt bei den meisten gängigen Ausfallszenarien nach deren Erkennen eine automatische Wiederherstellung durch Timestream für InfluxDB, sodass Sie ohne Verwaltungsaufwand Datenbankvorgänge schnellstmöglich fortsetzen können. Timestream für InfluxDB führt in einem der folgenden Fälle automatisch einen Failover durch:

• Verlust der Verfügbarkeit in der primären Availability Zone
• Verlust der Netzwerkverbindung zur Primär-Instance
• Ausfall einer Datenverarbeitungseinheit in der Primär-Instance
• Speicherfehler in der Primär-Instance

Hinweis: Bei Multi-AZ-Bereitstellungen von Timestream für InfluxDB erfolgt kein automatisches Failover als Reaktion auf Datenbankvorgänge wie lang andauernde Abfragen, gegenseitige Sperren (Deadlocks) oder Fehler aufgrund von Datenbankbeschädigungen.

Der Failover wird automatisch von Timestream für InfluxDB durchgeführt, damit Sie den Datenbankbetrieb schnellstmöglich und ohne Verwaltungsaufwand wieder aufnehmen können. Bei einem Failover wechselt Timestream für InfluxDB einfach den kanonischen Namensdatensatz (CNAME) für Ihre DB-Instance, sodass auf das Standby-Replikat verwiesen wird, das dadurch zur neuen Primär-Instance hochgestuft wird. Wir empfehlen Ihnen, sich an bewährte Methoden zu halten und eine Funktion auf der Anwendungsebene zu implementieren, über die gegebenenfalls erneut versucht wird, eine Datenbankverbindung herzustellen.

Failover-Vorgänge erfolgen entsprechend der Festlegung des Zeitraums zwischen dem Erkennen des Ausfalls auf der Primär-Instance und Fortsetzung von Transaktionen auf der Standby-Instance in der Regel innerhalb weniger Minuten. Die Failover-Zeit kann auch davon beeinflusst werden, ob große, nicht zugewiesene Transaktionen wiederhergestellt werden müssen, von der Größe des Index und von anderen Faktoren. Für optimale Ergebnisse wird die Verwendung ausreichend großer Instance-Typen mit Multi-AZ empfohlen. AWS empfiehlt außerdem die Verwendung von IOPS-inklusivem Speicher in Timestream für InfluxDB mit Multi-AZ-Instances für eine schnelle, vorhersehbare und konsistente Durchsatzleistung.

Timestream für InfluxDB führt bei einer Vielzahl von Fehlerbedingungen automatisch ein Failover durch, ohne dass Benutzer eingreifen müssen. Derzeit können Sie kein erzwungenes Failover Ihrer DB-Instance von Timestream für InfluxDB manuell einleiten.

Bei Multi-AZ-Bereitstellungen setzen Sie einfach den Multi-AZ-Parameter auf „Wahr“. Die Erstellung der synchronen Standby-Replikation und das Failover werden automatisch abgewickelt. Das bedeutet, dass Sie die Availability Zone nicht auswählen können, in der Ihre Standby-Replica bereitgestellt wird, und auch nicht die Anzahl der verfügbaren Standby-Instances verändern können (Timestream für InfluxDB erzeugt eine dedizierte Standby-Replica für jede primäre DB-Instance). Die Standby-Replica kann auch nicht für das Akzeptieren von Datenbank-Leseaktivitäten konfiguriert werden.

Ja, Ihr Standby-Replikat wird automatisch in einer anderen Availability Zone in derselben Region wie Ihre primäre DB-Instance bereitgestellt.

Ja, Sie können den Standort der aktuellen Primär-Instance mithilfe der AWS-Managementkonsole oder der GetDBInstance-API einsehen.

Availability Zones sind darauf ausgelegt, Netzwerkverbindungen mit niedrigen Latenzen für andere Availability Zones derselben Region bereitzustellen. Zusätzlich empfiehlt es sich eventuell, die Architektur Ihrer Anwendung und anderer AWS-Ressourcen mit Redundanzen über mehrere Availability Zones anzulegen, damit Ihre Anwendung bei einem Ausfall einer einzelnen Availability Zone geschützt ist. Bei Multi-AZ-Bereitstellungen ist dies auf Datenbankebene der Fall, ohne dass hierfür ein administratives Zutun Ihrerseits erforderlich ist.

Ein Lesereplikat-Cluster von Timestream für InfluxDB bietet eine verbesserte Verfügbarkeit und Leseskalierbarkeit für Ihre Datenbank. Wenn Sie einen Cluster erstellen, stellt Timestream für InfluxDB automatisch mindestens ein asynchrones lesbares Replikat in einer anderen Availability Zone bereit und verwaltet es. Die Aktualisierungen Ihres Primärknotens werden asynchron auf diese Lesereplikate repliziert, sodass Sie Ihren Abfrage-Workload auf mehrere Knoten verteilen können.

Der Cluster unterstützt das automatische Failover während der geplanten Wartung oder im unwahrscheinlichen Fall eines Knoten- oder Availability-Zone-Ausfalls. Bei einem Failover können Ihre Anwendungen ohne manuelles Eingreifen weiterarbeiten, da die Writer- und Reader-Endpunkte dieselben Namensdatensätze führen. Beachten Sie jedoch, dass während der Wiederherstellungszeit zwar der ausgefallene Knoten wiederhergestellt und als Lesereplikat wiederhergestellt wird, Anwendungen, die die Endpunkte des Replikatknotens zum Lesen verwenden, jedoch vorübergehend nicht verfügbar sind.

In einem Lesereplikat-Cluster verarbeitet der Primärknoten alle Schreib- und Lesevorgänge in der Datenbank und verwaltet Engine-spezifische Konfigurationen und Verwaltungsfunktionen. Darüber hinaus stellt Timestream für InfluxDB automatisch ein Lesereplikat bereit und verwaltet es, das mit dem Primärknoten synchronisiert ist. Das Lesereplikat dient zwei Hauptzwecken: Es erweitert Ihre Lesekapazität, indem es zusätzliche Leseanforderungen akzeptiert, und es kann in Failover-Szenarien zum primären Replikat hochgestuft werden. Während eines Failover-Ereignisses, wenn das Lesereplikat zum primären Replikat hochgestuft wird, übernimmt es alle Datenbankoperationen. Sobald der zuvor ausgefallene Knoten wieder betriebsbereit ist, tritt er dem Cluster als Lesereplikat bei, wodurch die Resilienz des Clusters erhalten bleibt.

Lesereplikat-Cluster bieten drei wichtige Vorteile: verbesserte Skalierbarkeit, verbesserte Verfügbarkeit und Workload-Optimierung. Die erhöhte Skalierbarkeit ergibt sich aus der Möglichkeit, Lese-Workloads auf mehrere Cluster-Knoten zu verteilen. Das macht sie besonders wertvoll für Anwendungen, bei denen die Leseanforderungen die Schreibvorgänge deutlich überwiegen.

Bei der Konfiguration mit aktiviertem Failover bieten Lesereplikat-Cluster eine höhere Verfügbarkeit durch schnellere Failover-Funktionen. Da alle Knoten im Cluster aktiv bleiben, können Sie ein Replikat auf den Primärknoten hochstufen, ohne auf den Start des Knotens warten zu müssen. Dadurch werden Ausfallzeiten in Failover-Szenarien minimiert.

Darüber hinaus ermöglichen Lesereplikat-Cluster ein effizientes Workload-Management. Sie können Ihren Primärknoten für einfache, schnelle Abfragen verwenden, die normalerweise für Echtzeit-Dashboards, Alarme und Benachrichtigungen verwendet werden, und komplexere analytische Abfragen an Ihre Lesereplikate weiterleiten. Diese Trennung gewährleistet eine optimale Leistung für verschiedene Arten von Workloads.

Der Replikatorprozess hat einen vernachlässigbaren Einfluss auf die Leistung aufgezeigt, mit minimalen Auswirkungen auf den CPU- oder Speicherverbrauch. Beachten Sie jedoch, dass die Replikationsverzögerung – die Zeitspanne zwischen der Annahme eines Datensatzes auf der Primär-Instance und der Verfügbarkeit auf den Lesereplikaten – je nach Auslastungsgrad Ihrer Replikatknoten variieren kann.

Timestream für InfluxDB veröffentlicht eine CloudWatch-Metrik namens „ReplicaLag“, mit der Sie den Synchronisationsstatus Ihrer Lesereplikate überwachen können. Diese in Millisekunden gemessene Metrik verfolgt, wie weit die Replikate vom Primärknoten entfernt sind. Die Replikationslatenz kann durch die Auslastung Ihrer Datenbank beeinflusst werden. Daher empfehlen wir unseren Kunden, diese Metrik aktiv zu überwachen, um sicherzustellen, dass ihre Lesereplikate die für ihren Anwendungsfall akzeptablen Synchronisationsstufen beibehalten.

Um einen Lesereplikat-Cluster in Timestream für InfluxDB einzurichten, melden Sie sich zunächst bei der AWS-Managementkonsole an und navigieren Sie zur Amazon-Timestream-Konsole. Wählen Sie „InfluxDB-Datenbank erstellen“ aus dem Abschnitt InfluxDB-Datenbanken. Wählen Sie bei der Konfiguration der Bereitstellungseinstellungen „DB-Cluster mit Lesereplikaten.“ Sie müssen ein Abonnement über den AWS Marketplace aktivieren, wofür entweder die Berechtigung AWSMarketplaceManageSubscriptions oder AWSMarketplaceFullAccess erforderlich ist. Nachdem Sie Ihr Abonnement bestätigt haben, geben Sie grundlegende Konfigurationsdetails an und wählen Sie die entsprechenden Knoten- und Speicherklassen aus, die für alle Knoten in Ihrem Cluster gelten.

Nein, in einem Lesereplikat-Cluster kann es immer nur einen Primärknoten geben, der Schreibvorgänge verarbeitet. Der Primärknoten bedient alle Schreibanforderungen und verwaltet gleichzeitig Datenbanklesevorgänge, Engine-spezifische Konfigurationen und Verwaltungsfunktionen. Lesereplikate werden mit diesem Primärknoten auf dem neuesten Stand gehalten und können nur Leseanforderungen annehmen. Sie können ein Lesereplikat zwar in Failover-Szenarien als primäres Replikat heraufstufen, die Cluster-Architektur verwendet jedoch ein Single-Writer-Modell, um die Datenkonsistenz sicherzustellen.

Für Lesereplikat-Cluster können Sie das Failover-Feature während der Cluster-Erstellung oder -Änderung aktivieren oder deaktivieren. Wenn diese Option aktiviert ist, wird die Verwaltung von Replikaten, Replikations- und Failover-Prozessen automatisch von Timestream für InfluxDB übernommen. Sie können keine bestimmten Availability Zones für Ihre Replikate auswählen, und Timestream für InfluxDB verwaltet mindestens ein Lesereplikat pro Cluster. Lesereplikate akzeptieren aktiv Leseanforderungen, um Ihren Workload zu verteilen.

Timestream für InfluxDB erkennt häufige Ausfallszenarien in Lesereplikat-Cluster-Bereitstellungen und stellt diese automatisch wieder her, sodass Sie den Datenbankbetrieb schnell und ohne administratives Eingreifen wieder aufnehmen können. Das System führt in einem der folgenden Fälle automatisch einen Failover auf ein Lesereplikat durch:

• Verfügbarkeitsverlust in der Availability Zone des Primärknotens
• Verlust der Netzwerkverbindung zum Primärknoten
• Ausfall der Recheneinheit auf dem Primärknoten
• Speicherausfall auf dem Primärknoten

Hinweis: Lesereplikat-Cluster von Timestream für InfluxDB führen als Reaktion auf Datenbankoperationen, wie z. B. lang andauernde Abfragen, Deadlocks oder Fehler aufgrund von Datenbankbeschädigungen, kein automatisches Failover durch. Denken Sie daran, dass ein automatisches Failover nur erfolgt, wenn Sie dieses Feature während der Installation oder durch Cluster-Änderung speziell für Ihren Lesereplikat-Cluster aktiviert haben.

Das Failover in einem Lesereplikat-Cluster wird automatisch von Timestream für InfluxDB abgewickelt, wenn das Feature aktiviert ist, sodass der Datenbankbetrieb schnell und ohne administratives Eingreifen wieder aufgenommen werden kann. Während des Failovers aktualisiert Timestream für InfluxDB den kanonischen Namensdatensatz (CNAME) Ihrer Datenbank, sodass er auf das Lesereplikat verweist, welches dann zum neuen primären Replikat hochgestuft wird. Wir empfehlen als bewährte Methode, die Logik für Wiederholungsversuche für Datenbankverbindungen in Ihrer Anwendungsebene zu implementieren.

Da Knoten in einem Lesereplikat-Cluster aktiv sind, ist die Failover-Zeit unabhängig von den Workload-Merkmalen stabil. In der Regel werden Failover innerhalb weniger Minuten abgeschlossen, gemessen von der Erkennung des primären Fehlers bis zur Wiederaufnahme der Transaktionen auf dem hochgestuften Replikat. Für eine optimale Leistung empfehlen wir, ausreichend dimensionierte Knotentypen und IOPS-inklusiven Speicher in Timestream für InfluxDB zu verwenden.

Wenn Failover aktiviert ist, verarbeitet Timestream für InfluxDB automatisch das Failover unter verschiedenen Fehlerbedingungen. Derzeit wird die manuelle Initiierung eines erzwungenen Failovers für Lesereplikat-Cluster von Timestream für InfluxDB nicht unterstützt.

Ja, Ihr Lesereplikat wird automatisch in einer anderen Availability Zone derselben Region wie Ihr Primärknoten bereitgestellt.

Ja, Sie können den Standort sowohl Ihrer Primär-Instance als auch Ihres Lesereplikat-Knotens über die AWS-Managementkonsole oder mithilfe der GetDBInstance-API anzeigen.

Availability Zones sind darauf ausgelegt, Netzwerkverbindungen mit niedrigen Latenzen für andere Availability Zones derselben Region bereitzustellen, sodass die Auswirkung der Latenz minimal sein sollte. Wir empfehlen jedoch, Ihre Anwendung und andere AWS-Ressourcen mit Redundanz über mehrere Availability Zones hinweg zu gestalten, um eine maximale Ausfallsicherheit zu gewährleisten. Lesereplikat-Cluster unterstützen diese Architektur auf natürliche Weise, da Sie Ihre Lese-Workloads auf Knoten in verschiedenen Availability Zones verteilen können. Wenn Failover aktiviert ist, kann Ihre Anwendung auch dann weiterarbeiten, wenn eine Availability Zone nicht mehr verfügbar ist.