Für ähnliche Funktionen wie Amazon Timestream für sollten Sie Amazon Timestream for LiveAnalytics InfluxDB in Betracht ziehen. Es bietet eine vereinfachte Datenaufnahme und Antwortzeiten im einstelligen Millisekundenbereich für Analysen in Echtzeit. Erfahren Sie hier mehr.
Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Daten in Ihren Timestream für InfluxDB 3-Cluster schreiben
Amazon Timestream for InfluxDB 3 bietet robuste Funktionen für die effiziente Erfassung von Zeitreihendaten. Das Verständnis der richtigen Methoden zum Schreiben von Daten ist für die Maximierung der Leistung und die Sicherstellung der Datenintegrität unerlässlich.
Timestream for InfluxDB 3 bietet mehrere HTTP-API-Endpunkte zum Schreiben von Zeitreihendaten und bietet Flexibilität für verschiedene Integrationsmethoden und Kompatibilität mit bestehenden InfluxDB-Workloads.
Übersicht über das Leitungsprotokoll
InfluxDB 3 ist für einen hohen Schreibdurchsatz konzipiert und verwendet eine effiziente, für Menschen lesbare Schreibsyntax, das Line-Protokoll.
Struktur des Leitungsprotokolls
Das Leitungsprotokoll besteht aus den folgenden wesentlichen Elementen:
-
Tabelle: Eine Zeichenketten-ID für die Tabelle, in der Daten gespeichert werden.
-
(Optional) Tag-Set: Durch Kommas getrennte Schlüssel-Wert-Paare, die Metadaten darstellen (indexiert).
-
Feldsatz: Durch Kommas getrennte Schlüssel-Wert-Paare, die die tatsächlichen Messungen darstellen.
-
(Optional) Zeitstempel: Unix-Zeitstempel, der dem Datenpunkt mit einer Genauigkeit von bis zu einer Nanosekunde zugeordnet ist.
Feldwerte können einen der folgenden Datentypen haben:
-
Zeichenketten (müssen in Anführungszeichen gesetzt werden)
-
Floats (zum Beispiel 23,4)
-
Ganzzahlen (zum Beispiel 10i)
-
Ganzzahlen ohne Vorzeichen (z. B. 10u)
-
Boolesche Werte (wahr/falsch)
Das Linienprotokoll folgt dieser allgemeinen Syntax:
myTable,tag1=val1,tag2=val2 field1="v1",field2=1i 0000000000000000000
Beispiel für einen Datenpunkt, der das Leitungsprotokoll verwendet:
home,room=Living\ Room temp=21.1,hum=35.9,co=0i 1735545600
Dadurch wird ein Punkt in der Tabelle „Home“ erstellt mit:
-
Tag: room="Wohnzimmer“
-
Felder: temp=21,1 (Float), hum=35,9 (Float), co=0 (Integer)
-
Zeitstempel: 1735545600 (Unix-Sekunden)
Übersicht über API-Endpunkte
InfluxDB 3 unterstützt drei primäre Schreibendpunkte:
-
Native v3-API (
/api/v3/write_lp): Der empfohlene Endpunkt für neue Implementierungen. -
v2-Kompatibilitäts-API (
/api/v2/write): Für die Migration von InfluxDB v2.x-Workloads. -
v1-Kompatibilitäts-API (
/write): Für die Migration von InfluxDB v1.x-Workloads.
Verwendung der nativen v3-Schreib-API
Der /api/v3/write_lp Endpunkt ist die native InfluxDB 3-API zum Schreiben von Leitungsprotokolldaten.
Format der Anfrage:
POST /api/v3/write_lp?db=DATABASE_NAME&precision=PRECISION&accept_partial=BOOLEAN&no_sync=BOOLEAN
Parameter abfragen:
| Parameter | Beschreibung | Standard |
|---|---|---|
db
|
Datenbankname (erforderlich) | - |
precision
|
Genauigkeit des Zeitstempels (ns, us, ms, s) | Automatisch erkannt |
accept_partial
|
Akzeptiert bei Fehlern teilweise Schreibvorgänge | true |
no_sync
|
Bestätigen Sie vor der WAL-Persistenz | false |
Beispiel für eine Schreibanfrage:
curl -v "https://your-cluster-endpoint:8086/api/v3/write_lp?db=sensors&precision=s" \ --header "Authorization: Bearer YOUR_TOKEN" \ --data-raw "home,room=Living\ Room temp=21.1,hum=35.9,co=0i 1735545600 home,room=Kitchen temp=21.0,hum=35.9,co=0i 1735545600"
Antwortmodi schreiben
Standardmodus (no_sync=false)
-
Wartet darauf, dass Daten in das WAL (Write-Ahead Log) geschrieben wurden, bevor die Bestätigung erfolgt.
-
Bietet Haltbarkeitsgarantien.
-
Höhere Latenz aufgrund von WAL-Persistenzwartezeit.
-
Empfohlen für kritische Daten, bei denen Haltbarkeit unerlässlich ist.
Schneller Modus (no_sync=true)
-
Bestätigt sofort, ohne auf die WAL-Persistenz zu warten.
-
Niedrigstmögliche Schreiblatenz.
-
Risiko eines Datenverlusts, wenn das System abstürzt, bevor der WAL-Schreibvorgang abgeschlossen ist.
-
Ideal für Szenarien mit hohem Durchsatz, in denen Geschwindigkeit Vorrang vor absoluter Haltbarkeit hat.
Verarbeitung teilweiser Schreibvorgänge
Der accept_partial Parameter steuert das Verhalten, wenn Schreibstapel Fehler enthalten:
Wann accept_partial ist true (Standard):
-
Gültige Zeilen wurden erfolgreich geschrieben.
-
Ungültige Zeilen werden zurückgewiesen.
-
Gibt den Status 400 mit Details zu fehlerhaften Leitungen zurück.
-
Nützlich für umfangreiche Batch-Operationen, bei denen einige Fehler akzeptabel sind.
Wenn accept_partial false ist:
-
Der gesamte Stapel wird zurückgewiesen, wenn eine Zeile ausfällt.
-
Es werden keine Daten geschrieben.
-
Gibt den Status 400 mit Fehlerdetails zurück.
-
Stellt die all-or-nothing Schreibsemantik sicher.
Kompatibilität APIs
Kompatibilität APIs ermöglicht eine nahtlose Migration vorhandener InfluxDB v1- oder v2-Workloads zu InfluxDB 3. Diese Endpunkte funktionieren mit bestehenden InfluxDB-Clientbibliotheken, Telegraf und Integrationen von Drittanbietern.
Wichtige Unterschiede:
-
Tags in einer Tabelle (Messung) sind unveränderlich, sobald sie erstellt wurden.
-
Ein Tag und ein Feld können in einer Tabelle nicht denselben Namen haben.
-
Die Schemavalidierung wird beim Schreiben erzwungen.
InfluxDB v2-Kompatibilität
Der /api/v2/write Endpunkt bietet Abwärtskompatibilität für v2-Clients:
curl -i "https://your-cluster-endpoint:8086/api/v2/write?bucket=DATABASE_NAME&precision=s" \ --header "Authorization: Bearer DATABASE_TOKEN" \ --header "Content-type: text/plain; charset=utf-8" \ --data-binary 'home,room=kitchen temp=72 1641024000'
V2-API-Parameter:
| Parameter | Ort | Beschreibung |
|---|---|---|
bucket * |
Abfragezeichenfolge | Ordnet dem Datenbanknamen zu |
precision
|
Abfragezeichenfolge | Genauigkeit des Zeitstempels (ns, us, ms, s, m, h) |
Authorization
|
Header | Träger- oder Token-Schema |
Content-Encoding
|
Header | gzip oder Identität |
InfluxDB v1-Kompatibilität
Der /write Endpunkt bietet Abwärtskompatibilität für v1-Clients:
curl -i "https://your-cluster-endpoint:8086/write?db=DATABASE_NAME&precision=s" \ --user "any:DATABASE_TOKEN" \ --header "Content-type: text/plain; charset=utf-8" \ --data-binary 'home,room=kitchen temp=72 1641024000'
V1-Authentifizierungsoptionen:
-
Standardauthentifizierung: Token als Passwort (
--user "any:TOKEN"). -
Abfrageparameter:
p=TOKENin der URL. -
Bearer/Token Header: Standard-Autorisierungsheader.
V1-API-Parameter:
| Parameter | Ort | Beschreibung |
|---|---|---|
db * |
Abfragezeichenfolge | Datenbankname |
precision
|
Abfragezeichenfolge | Genauigkeit des Zeitstempels |
p
|
Abfragezeichenfolge | Token für die Abfrageauthentifizierung |
u |
Abfragezeichenfolge | Benutzername (ignoriert) |
Authorization
|
Header | Es werden mehrere Schemata unterstützt |
Content-Encoding
|
Header | gzip oder Identität |
Client-Bibliotheken und Integrationen
Offizielle InfluxDB 3-Clientbibliotheken
InfluxDB 3-Clientbibliotheken bieten Benutzeroberflächen in Muttersprache zum Konstruieren und Schreiben von Zeitreihendaten:
-
Python:
influxdb3-python -
Geh:
influxdb3-go -
JavaScript/Node.js:
influxdb3-js -
Java:
influxdb3-java -
C#:
InfluxDB3.Client
Beispiel: Python-Client
from influxdb3 import InfluxDBClient3 client = InfluxDBClient3( host="your-cluster-endpoint:8086", token="YOUR_TOKEN", database="DATABASE_NAME" ) # Write using line protocol client.write("home,room=Living\\ Room temp=21.1,hum=35.9,co=0i") # Write using Point objects from influxdb3 import Point point = Point("home") \ .tag("room", "Living Room") \ .field("temp", 21.1) \ .field("hum", 35.9) \ .field("co", 0) client.write(point)
Beispiel: Go-Client
import "github.com/InfluxCommunity/influxdb3-go/v2/influxdb3" client, err := influxdb3.New(influxdb3.ClientConfig{ Host: "your-cluster-endpoint:8086", Token: "YOUR_TOKEN", Database: "DATABASE_NAME", }) point := influxdb3.NewPoint("home", map[string]string{"room": "Living Room"}, map[string]any{ "temp": 24.5, "hum": 40.5, "co": 15, }, time.Now(), ) err = client.WritePoints(context.Background(), []*influxdb3.Point{point})
Ältere Client-Bibliotheken
Für bestehende Workloads der Versionen 1 und 2 können Sie weiterhin ältere Clientbibliotheken mit den folgenden Kompatibilitätsendpunkten verwenden:
Beispiel: Node.js v1-Client:
const Influx = require('influx') const client = new Influx.InfluxDB({ host: 'your-cluster-endpoint', port: 8086, protocol: 'https', database: 'DATABASE_NAME', username: 'ignored', password: 'DATABASE_TOKEN' })
Bewährte Methoden für das Schreiben von Daten
Beim Schreiben von Daten empfehlen wir Folgendes:
-
Batch-Optimierung
-
Optimale Batchgröße: 5.000-10.000 Zeilen oder 10 MB pro Anfrage.
-
Verwenden Sie Komprimierung (gzip) für große Nutzlasten.
-
Sortieren Sie die Tags nach Schlüsseln in lexikografischer Reihenfolge, um eine bessere Leistung zu erzielen.
-
-
Präzision des Zeitstempels
-
Verwenden Sie die grobste Präzision, die Ihren Anforderungen entspricht.
-
Geben Sie die Genauigkeit explizit an, um Mehrdeutigkeiten zu vermeiden.
-
Sorgen Sie für eine gleichbleibende Präzision in Ihrer gesamten Anwendung.
-
-
Fehlerbehandlung
-
Implementieren Sie eine Wiederholungslogik für vorübergehende Fehler.
-
Verwenden Sie accept_partial=true für belastbare Batch-Operationen.
-
Überwachen Sie Schreibfehler anhand von Metriken. CloudWatch
-
-
Leistungsoptimierung
-
Verwenden Sie no_sync=true für Szenarien mit hohem Durchsatz.
-
Verteilen Sie Schreibvorgänge auf mehrere Verbindungen.
-
Verwenden Sie den writer/reader Endpunkt für alle Schreibvorgänge.
-
-
Überlegungen zum Schema
-
Tags sind nach ihrer Erstellung unveränderlich.
-
Felder und Tags dürfen nicht denselben Namen haben.
-
Entwerfen Sie Schemas unter Berücksichtigung von Abfragemustern.
-
Behalten Sie die Kontrolle über die Tag-Kardinalität.
-
Wichtige Unterschiede zu früheren Versionen:
-
Unveränderliche Tags: Sobald ein Tag in einer Tabelle erstellt wurde, kann sein Typ nicht mehr geändert werden
-
Keine tag/field Namenskonflikte: Ein Tag und ein Feld dürfen in einer Tabelle nicht denselben Namen haben
-
Schema-on-write: InfluxDB 3 validiert Datentypen beim Schreiben
-
Automatische Tabellenerstellung: Tabellen werden beim ersten Schreibvorgang automatisch erstellt
-
Strikte Typprüfung: Feldtypen müssen bei allen Schreibvorgängen konsistent bleiben
Indem Sie die entsprechende Schreib-API nutzen und diese Best Practices befolgen, können Sie Zeitreihendaten effizient in Ihre Timestream for InfluxDB 3-Instance aufnehmen und gleichzeitig eine hohe Leistung und Datenintegrität aufrechterhalten.