Diese Seite wurde von der Cloud Translation API übersetzt.

Schreibvorgänge

Auf dieser Seite sind die Typen von Schreibanfragen aufgeführt, die Sie an Bigtable senden können und beschreibt, wann Sie sie verwenden sollten und wann nicht. Weitere Informationen zum Aggregieren von Daten in einer Zelle zum Zeitpunkt des Schreibvorgangs siehe Werte beim Schreiben aggregieren (Vorschau).

Mit der Bigtable Data API und den Clientbibliotheken können Sie Daten programmatisch in Ihre Tabellen schreiben. Bigtable sendet für jeden Schreibvorgang eine Antwort oder Bestätigung zurück.

Jede Clientbibliothek bietet die Möglichkeit, die folgenden Schreibanfragetypen zu senden:

Einfache Schreibvorgänge
Erhöhungen und Ergänzungen
Bedingte Schreibvorgänge
Batchschreibvorgänge

Bigtable-Clientbibliotheken haben eine integrierte intelligente Wiederholungsfunktion für einfache Schreibvorgänge und Batchschreibvorgänge. Sie kommen also problemlos mit vorübergehenden Ausfällen zurecht. Wenn Ihre Anwendung beispielsweise versucht, Daten zu schreiben, und ein vorübergehender Ausfall oder ein Netzwerkproblem auftritt, wird der Versuch automatisch wiederholt, bis der Schreibvorgang durchgeführt wurde oder das Zeitlimit für Anfragen erreicht ist. Dieses Die Ausfallsicherheit funktioniert sowohl bei Single-Cluster-Instanzen als auch bei replizierten Instanzen, Single-Cluster- oder Multi-Cluster-Routing.

Für Batch- und Streaming-Schreibvorgänge können Sie die Methode Bigtable Beam-Connector. Weitere Informationen finden Sie unter Batch-Schreibvorgänge.

Informationen zu Limits für Schreibanfragen finden Sie unter Kontingente und Limits.

Beispiele für die Cloud Bigtable-Clientbibliotheken zu Schreibanfragen finden Sie unter Beispiele schreiben.

Schreibvorgangstypen und ihre Verwendung

Alle Schreibanfragen umfassen die folgenden grundlegenden Komponenten:

Den Namen der Tabelle, in die Daten geschrieben werden sollen.
Eine App-Profil-ID, die Bigtable mitteilt, wie der Traffic weitergeleitet werden soll.
Eine oder mehrere Mutationen. Eine Mutation besteht aus den folgenden Elementen: <ph type="x-smartling-placeholder">
- Name der Spaltenfamilie
- Spaltenqualifizierer
- Zeitstempel
- Wert, den Sie in die Datenbank schreiben.

Der Zeitstempel einer Mutation hat einen Standardwert für das aktuelle Datum und die aktuelle Uhrzeit. gemessen als die seit der Unix-Epoche, 00:00:00 UTC vergangene Zeit 1. Januar 1970.

Ein Zeitstempel, den Sie an Bigtable senden, muss ein Mikrosekundenwert sein und darf höchstens auf eine Genauigkeit im Millisekundenbereich. Zeitstempel mit Mikrosekundengenauigkeit, z. B. 3023483279876543 wurde abgelehnt. In diesem Beispiel ist der zulässige Zeitstempelwert 3023483279876000

Alle Mutationen in einem einzelne Schreibanfrage denselben Zeitstempel haben, es sei denn, Sie überschreiben sie. Sie können den Zeitstempel aller Mutationen in einer Schreibanfrage gleich oder unterscheiden.

Einfache Schreibvorgänge

Sie können eine einzelne Zeile in Bigtable mit einer MutateRow-Anfrage schreiben, die den Tabellennamen, die ID des zu verwendenden Anwendungsprofils, einen Zeilenschlüssel und bis zu 100.000 Mutationen für diese Zeile enthält. Ein einzeiliger Schreibvorgang ist atomar. Verwenden Sie diesen Schreibvorgangstyp, wenn Sie mehrere Mutationen an einer einzelnen Zeile vornehmen.

Codebeispiele zum Senden einfacher Schreibanfragen finden Sie unter Einfache Schreibanfragen ausführen.

Wann einfache Schreibvorgänge nicht verwendet werden sollen

Für die folgenden Anwendungsfälle sind einfache Schreibvorgänge nicht die beste Möglichkeit, um Daten zu schreiben:

Sie schreiben einen Datenbatch mit zusammenhängenden Zeilenschlüsseln. In sollten Sie in diesem Fall Batchschreibvorgänge anstelle von aufeinanderfolgenden einfachen Schreibvorgängen verwenden, da ein zusammenhängender Batch in einem einzigen Back-End-Aufruf angewendet werden kann.
Sie möchten einen hohen Durchsatz (Zeilen pro Sekunde oder Byte pro Sekunde) und benötigen keine niedrige Latenz. In diesem Fall sind Batchschreibvorgänge schneller.

Erhöhungen und Ergänzungen

Wenn Sie einen Wert erhöhen oder erhöhen möchten, sollten Sie aggregates verwenden. zum Zeitpunkt des Schreibens aktualisieren, ist die beste Option. Zusammenfassungen werden nicht unterstützt Anfügevorgänge. Weitere Informationen finden Sie unter Aggregierte Werte zum Zeitpunkt des Schreibens (Vorschau).

Wenn Sie Daten an einen vorhandenen Wert anhängen möchten oder ein numerische Werte vorhanden ist und Sie keine Aggregatfunktionen verwenden können, können Sie ReadModifyWriteRow-Anfrage. Diese Anfrage enthält den Tabellennamen, die ID das zu verwendende Anwendungsprofil, einen Zeilenschlüssel und eine Reihe von Regeln das Schreiben der Daten. Jede Regel umfasst den Namen der Spaltenfamilie, den Spaltenqualifizierer, und entweder einen Anfügewert oder einen inkrementellen Wert.

Regeln werden der Reihe nach angewendet. Wenn Ihre Anfrage beispielsweise eine Anfrage zum Erhöhen des Werts für eine Spalte um zwei enthält und eine spätere Regel in derselben Anfrage dieselbe Spalte um 1 erhöht, wird die Spalte in diesem einzelnen atomaren Schreibvorgang um 3 erhöht. Die spätere Regel überschreibt nicht die frühere Regel.

Ein Wert kann nur erhöht werden, wenn er als 64-Bit-Big-Endian-Ganzzahl codiert ist. Bigtable behandelt eine Erhöhung auf einen leeren oder nicht vorhandenen Wert wie einen Wert, der null ist. ReadModifyWriteRow-Anfragen sind atomar. Sie werden nicht wiederholt, wenn sie aus irgendeinem Grund fehlschlagen.

Codebeispiele zum Anhängen eines Werts in einer Zelle finden Sie unter Vorhandenen Wert erhöhen.

Wann `ReadModifyWriteRow` nicht verwendet werden sollte

Sende in den folgenden Situationen keine ReadModifyWriteRow-Anfragen:

Ihr Anwendungsfall kann mit zusammengefassten Daten verarbeitet werden (Vorschau)
Sie verwenden ein Anwendungsprofil mit Multi-Cluster-Routing.
Sie verwenden mehrere Single-Cluster-App-Profile und senden Schreibvorgänge, die mit Daten in Konflikt stehen können, die in derselben Zeile und Spalte in anderen Clustern in der Instanz geschrieben wurden. Beim Single-Cluster-Routing wird eine Schreibanfrage an einen einzelnen Cluster gesendet und anschließend repliziert.
Sie nutzen die intelligente Wiederholungsfunktion, die von den Clientbibliotheken bereitgestellt wird. Es ist nicht möglich, einen neuen Versuch zum Inkrementen und Anhängen zu starten.
Sie schreiben große Datenmengen und müssen die Schreibvorgänge schnell beenden. Eine Anfrage, die eine Zeile liest und dann ändert, ist langsamer als eine einfache Schreibanfrage. Dieser Schreibvorgangstyp ist daher bei umfangreichen Projekten oft nicht der beste Ansatz.

Wenn Sie beispielsweise etwas zählen möchten, das im Feld z. B. Seitenaufrufe, sollten Sie mithilfe von aggregates, um die Anzahl zum Schreibzeitpunkt zu aktualisieren. Ich jeden Aufruf auch als einfachen Schreibvorgang aufzeichnen, einen Wert erhöhen und dann mit einem Dataflow-Job Daten.

Bedingte Schreibvorgänge

Wenn Sie eine Zeile auf eine Bedingung prüfen und dann je nach Ergebnis Daten in diese Zeile schreiben möchten, senden Sie eine CheckAndMutateRow-Anfrage. Dieser Anfragetyp umfasst einen Zeilenschlüssel und einen Zeilenfilter. Ein Zeilenfilter besteht aus einer Reihe von Regeln, mit denen Sie den Wert vorhandener Daten prüfen. Danach werden Mutationen nur dann bestimmten Spalten in der Zeile zugewiesen, wenn bestimmte Bedingungen erfüllt sind, die vom Filter überprüft wurden. Das Überprüfen und anschließende Schreiben wird als einzelne atomare Aktion abgeschlossen.

Eine Filteranfrage muss einen oder beide der folgenden Mutationstypen enthalten:

"Wahre" Mutationen oder die Mutationen, die angewendet werden müssen, wenn der Filter einen Wert zurückgibt
"Falsche" Mutationen, die angewendet werden, wenn der Filter keine Ergebnisse liefert

Sie können bis zu 100.000 Mutationen jedes Typs (wahr und falsch) in einem einzigen Schreibvorgang bereitstellen und Sie müssen mindestens einen davon senden. Bigtable sendet eine Antwort, wenn alle Mutationen abgeschlossen sind.

Codebeispiele zum Senden von bedingten Schreibvorgängen finden Sie unter Wert bedingt schreiben.

Wann bedingte Schreibvorgänge nicht verwendet werden sollen

Für den folgenden Anwendungsfall können Sie keine bedingten Schreibvorgänge verwenden:

Sie verwenden ein Anwendungsprofil mit Multi-Cluster-Routing.
Sie verwenden mehrere Single-Cluster-App-Profile und senden Schreibvorgänge, die mit Daten in Konflikt stehen können, die in derselben Zeile und Spalte in anderen Clustern in der Instanz geschrieben wurden. Beim Single-Cluster-Routing wird eine Schreibanfrage an einen einzelnen Cluster gesendet und anschließend repliziert.
Sie schreiben große Datenmengen und müssen die Schreibvorgänge schnell beenden. Ähnlich wie bei ReadModifyWriteRow müssen bedingte Schreibanfragen Zeilen vor dem Ändern lesen, sodass CheckAndModifyRow-Anfragen langsamer sind als einfache Schreibanfragen erstellen. Daher ist diese Art von Schreibvorgang oft nicht die beste bedarfsgerecht umsetzen.

Batchschreibvorgänge

Mit einer MutateRows-Anfrage können Sie mit einem Aufruf mehr als eine Zeile schreiben. MutateRows-Anfragen enthalten einen Satz von bis zu 100.000 Einträgen, die jeweils atomar angewendet werden. Jeder Eintrag besteht aus einem Zeilenschlüssel und mindestens einer Mutation, die auf die Zeile angewendet werden soll. Eine Batchschreibanfrage kann bis zu 100.000 Mutationen enthalten, die auf alle Einträge verteilt sind. Ein Batchschreibvorgang könnte beispielsweise eine der folgenden Varianten enthalten:

100.000 Einträge mit 1 Mutation in jedem Eintrag
1 Eintrag mit 100.000 Mutationen
1.000 Einträge mit jeweils 100 Mutationen

Jeder Eintrag in einer MutateRows-Anfrage ist atomar, die Anfrage insgesamt jedoch nicht. Bei Bedarf wiederholt Bigtable alle Einträge im Batch, die nicht erfolgreich sind, bis alle Schreibvorgänge erfolgreich sind oder das Zeitlimit für Anfragen erreicht ist. Dann wird eine Antwort zurückgegeben, die jeden Schreibvorgang im Stapel identifiziert und angibt, ob der Schreibvorgang erfolgreich war oder nicht.

Codebeispiele zum Senden von Batchschreibvorgängen finden Sie unter Batchschreibvorgänge ausführen.

Wann keine Batchschreibvorgänge verwendet werden sollen

Sie schreiben Bulk-Daten in Zeilen, die nicht nahe beieinander liegen. Bigtable speichert Daten lexikografisch nach Zeilenschlüssel, das binäre Äquivalent der alphabetischen Reihenfolge. Aus diesem Grund werden unterschiedliche Zeilenschlüssel in einer Anfrage von Bigtable nacheinander und nicht parallel verarbeitet. Sowohl der Durchsatz als auch die Latenz werden hoch sein. Verwenden Sie MutateRows, wenn die Zeilenschlüssel ähnlich sind und Bigtable Zeilen schreibt, die nahe beieinander liegen, um diese hohe Latenz zu vermeiden. Verwenden Sie MutateRow oder einfache Schreibvorgänge für Zeilen, die nicht nah beieinander liegen.
Sie fordern mehrere Mutationen in derselben Zeile an. In diesem Fall ist die Leistung besser, wenn Sie alle Mutationen in einer einzelnen einfachen Schreibanfrage ausführen. Dies liegt daran, dass bei einem einfachen Schreibvorgang alle Änderungen in einer einzigen atomaren Aktion durchgeführt werden, während beim Batchschreibvorgang Mutationen in dieselbe Zeile serialisiert werden, was Latenz verursacht.

Ablaufsteuerung für Batchschreibvorgänge

Wenn Sie Ihre Batchschreibvorgänge mit einer der folgenden Methoden senden, können Sie Ablaufsteuerung für Batch-Schreibvorgänge in Ihrem Code.

Wenn die Batch-Ablaufsteuerung für einen Dataflow-Job aktiviert ist, Bigtable führt automatisch folgende Schritte aus :

Ratenbegrenzungen für Traffic, um eine Überlastung des Bigtable-Clusters zu vermeiden
Stellt sicher, dass der Cluster unter genügend Last zum Auslösen von Bigtable ist Autoscaling (falls aktiviert), sodass weitere Knoten automatisch zum Cluster bei Bedarf

Diese kombinierten Aktionen verhindern eine Clusterüberlastung und Jobfehler und Sie vermeiden Ihren Cluster manuell skalieren müssen, bevor der Batch-Schreibvorgang ausgeführt wird. Wenn die Ablaufsteuerung aktiviert ist, erfolgt die Clusterskalierung während des Dataflow-Job statt vorher, sodass es länger dauern kann, als wenn Sie Ihren Cluster manuell skalieren.

Sie müssen ein Anwendungsprofil verwenden, das für Single-Cluster-Routing konfiguriert ist. Wird aktiviert Bigtable-Autoscaling für den Zielcluster ist kein Anforderung, aber mit Autoscaling können Sie den Batch-Schreibfluss optimal nutzen. Steuerung. Sie können Dataflow-Autoscaling wie bei für jeden anderen Job.

Weitere Informationen zu Bigtable-Autoscaling finden Sie unter Autoscaling. Informationen zur Weiterleitung von App-Profilen finden Sie unter App-Profile.

Für ein Codebeispiel, das zeigt, wie Sie die Ablaufsteuerung für Batch-Schreibvorgänge mithilfe der Bigtable HBase Beam-Connector, siehe Schreiben in Bigtable.

Daten in eine autorisierte Ansicht schreiben

Um Daten in eine autorisierte Ansicht zu schreiben, müssen Sie eine der folgenden Methoden verwenden:

gcloud-CLI
Bigtable-Client für Java

Die anderen Bigtable-Clientbibliotheken bieten noch keine Unterstützung für autorisierten Ansichtszugriff.

Wenn Sie Daten in eine autorisierte Ansicht schreiben, geben Sie die Methode die ID der autorisierten Ansicht.

Alle Schreibvorgänge in eine autorisierte Ansicht werden direkt auf die zugrunde liegende .

Einschränkungen für die Definition autorisierter Ansichten

In einer autorisierten Ansicht die Zeilen oder Spalten, in die Sie Daten schreiben können durch die Definition der autorisierten Ansicht eingeschränkt sind. Mit anderen Worten: Sie können nur in Zeilen und Spalten schreiben, die dieselben Kriterien erfüllen, autorisierten Ansicht aus.

Wenn die autorisierte Ansicht beispielsweise durch das Präfix des Zeilenschlüssels definiert wird, examplepetstore1, können Sie keine Daten mit dem Zeilenschlüssel examplepetstore2; muss der Anfang des Zeilenschlüsselwerts den gesamten String examplepetstore1.

Wenn die autorisierte Ansicht durch den Spaltenqualifizierer definiert wird, order-phone vorangestellt ist, können Sie Daten mit dem Spaltenqualifizierer schreiben order-phone123. Der Spaltenqualifizierer order-tablet kann jedoch nicht verwendet werden.

Ihre Schreibanfrage kann auch nicht auf Daten verweisen, die sich außerhalb des z. B. wenn Sie nach einem Wert in einem bedingte Schreibanfrage.

Bei Anfragen, bei denen Daten außerhalb der autorisierten Ansicht ausgewählt haben, wird die Fehlermeldung PERMISSION_DENIED zurückgegeben.

Replikation

Wenn ein Cluster einer replizierten Instanz einen Schreibvorgang empfängt, wird dieser Schreibvorgang sofort auf die anderen Cluster in der Instanz repliziert.

Atomarität

Für jede MutateRows-Anfrage, die Sie an eine replizierte Instanz senden, wird ein Commit durchgeführt als einzelne atomare Aktion im Cluster, an den die Anfrage weitergeleitet wird. Wenn der Parameter auf die anderen Cluster in der Instanz repliziert wird, erhalten alle den Schreibvorgang als atomaren Vorgang. Cluster erhalten keine Teillieferung Mutationen; eine Mutation entweder erfolgreich oder atomar für alle Zellen fehlschlägt die es verändert.

Konsistenz

Wie lange es dauert, bis die von Ihnen geschriebenen Daten für Lesevorgänge zur Verfügung stehen, hängt von mehreren Faktoren ab, einschließlich der Anzahl der Cluster in Ihrer Instanz und des Routing-Typs, den Ihr App-Profil verwendet.

Mit einer Single-Cluster-Instanz können die Daten sofort gelesen werden, aber wenn ein Instanz mehr als einen Cluster hat, d. h., sie verwendet Replikation, Bigtable ist Eventual Consistency. Sie können Read-Your-Writes-Konsistenz erreichen, indem Sie Anfragen an denselben Cluster weiterleiten.

Sie können ein Konsistenztoken erstellen und verwenden und CheckConsistency aufrufen in StandardReadRemoteWrites-Modus, nachdem Sie Schreibanfragen gesendet haben. Das Token prüft die Replikationskonsistenz. Im Allgemeinen erstellen Sie ein Konsistenztoken entweder nachdem ein Batch von Schreibvorgängen gesendet wurde oder nach einem bestimmten Intervall, als Stunde. Anschließend können Sie das Token zur Verwendung in einem anderen Prozess übergeben, z. B. als Modul, das eine Leseanfrage sendet, bei der mithilfe des Tokens geprüft wird, wurden alle Daten repliziert, bevor ein Leseversuch unternommen wird.

Wenn Sie ein Token direkt nach dem Erstellen verwenden, kann es einige Minuten dauern, bis die Konsistenz bei der ersten Verwendung überprüft wurde. Diese Verzögerung liegt daran, dass jeder Cluster jeden anderen Cluster überprüft, um sicherzustellen, dass keine Daten mehr eingehen. Nach der erstmaligen Verwendung oder wenn Sie einige Minuten auf die erstmalige Verwendung des Tokens warten, ist das Token bei jeder Verwendung sofort erfolgreich.

Konfliktlösung

Jeder Zellenwert in einer Bigtable-Tabelle wird durch das Vierertupel (Zeilenschlüssel, Spaltenfamilie, Spaltenqualifizierer, Zeitstempel) eindeutig identifiziert. Weitere Informationen zu diesen Kennzeichnungen finden Sie unter Bigtable-Speichermodell. In dem seltenen Fall, dass zwei Schreibvorgänge mit demselben identischen Vierertupel an zwei verschiedene Cluster gesendet werden, löst Bigtable den Konflikt automatisch mithilfe eines internen Algorithmus des Typs last write wins auf Grundlage der serverseitigen Zeit auf. Die Bigtable-Implementierung "Last write Wins" (Zeitpunkte des letzten Schreibvorgangs) ist deterministisch. Wenn die Replikation aufholt, haben alle Cluster denselben Wert für das Vierertupel.