Schreibvorgänge
Auf dieser Seite werden die Arten von Schreibanfragen aufgeführt, die Sie an Bigtable senden können. Außerdem wird beschrieben, wann Sie sie verwenden sollten und wann nicht. Informationen zum Aggregieren von Daten in einer Zelle beim Schreiben finden Sie unter Werte beim Schreiben aggregieren.
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. Diese Ausfallsicherheit funktioniert sowohl mit Single-Cluster- als auch mit replizierten Instanzen, mit Single-Cluster-Routing oder Multi-Cluster-Routing.
Für Batch- und Streaming-Schreibvorgänge können Sie den Bigtable Beam-Connector verwenden. Weitere Informationen finden Sie unter Batch-Schreibvorgänge.
Weitere Informationen zu Limits für Schreibanfragen finden Sie unter Kontingente und Limits.
Beispiele für die auf dieser Seite beschriebenen Schreibanfragen in der Cloud Bigtable-Clientbibliothek finden Sie unter Schreibbeispiele.
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:
- 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 Uhrzeit, gemessen als die Zeit, die seit der Unix-Epoche (00:00:00 UTC am 1. Januar 1970) verstrichen ist.
Standardmäßig muss ein Zeitstempel, den Sie an Bigtable senden, ein Mikrosekundenwert sein und darf höchstens eine Genauigkeit im Millisekundenbereich haben. Bigtable lehnt Zeitstempel mit Mikrosekundengenauigkeit wie 3023483279876543 ab, es sei denn, Sie schreiben in eine Tabelle mit Mikrosekunden-Zeitstempel-Detaillierungsgrad.
Tabellen mit Mikrosekunden-Detaillierungsgrad akzeptieren vom Nutzer bereitgestellte Zeitstempel mit vollständiger Mikrosekunden-Genauigkeit.
Diese Funktion ist nur für Instanzen in der Enterprise Plus-Version verfügbar.
Alle Mutationen in einer einzelnen Schreibanfrage haben denselben Zeitstempel, sofern Sie sie nicht überschreiben. Sie können den Zeitstempel aller Mutationen in einer Schreibanfrage so festlegen, dass er identisch oder unterschiedlich ist.
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 diesem Fall sollten Sie Batch-Schreibvorgänge anstelle von aufeinanderfolgenden einfachen Schreibvorgängen verwenden, da ein zusammenhängender Batch in einem einzigen Backend-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.
Inkrementelle Aktualisierungen
Mit Bigtable können Sie Zellen mit dem Datentyp Aggregat erstellen. Aggregatzellen sind für Fälle optimiert, in denen Sie die Werte in vorhandenen Tabellenzellen ändern möchten. Dabei werden die Zellenwerte beim Schreiben der Daten aggregiert. Folgende Aggregationstypen sind verfügbar:
- Summe: Zähler erhöhen oder laufende Summe beibehalten.
- Minimum: Senden Sie eine Ganzzahl an eine Zelle. Bigtable behält den niedrigeren der beiden Werte bei.
- Maximum: Senden Sie eine Ganzzahl an eine Zelle. Bigtable behält den höheren der beiden Werte bei.
- HyperLogLog (HLL): Sendet einen Wert, der einer probabilistischen Menge aller der Zelle hinzugefügten Werte hinzugefügt wird.
Anfragen zum Aktualisieren von aggregierten Zellen werden mit einer MutateRow-Anfrage und einem Mutationstyp von entweder AddToCell oder MergeToCell oder einem der Löschmutationstypen gesendet.
Anhängen
Wenn Sie Daten an einen vorhandenen Wert anhängen möchten, können Sie eine ReadModifyWriteRow-Anfrage verwenden.
Diese Anfrage enthält den Tabellennamen, die ID des zu verwendenden Anwendungsprofils, einen Zeilenschlüssel und eine Reihe von Regeln, die beim Schreiben der Daten verwendet werden sollen. Jede Regel enthält den Namen der Spaltenfamilie, den Spaltenqualifizierer und entweder einen Wert zum Anhängen oder einen Inkrementbetrag.
Regeln werden der Reihe nach angewendet. Wenn Ihre Anfrage beispielsweise eine Anfrage zum Anhängen des Werts für eine Spalte enthält, die den Wert some mit dem String thing enthält, und eine spätere Regel in derselben Anfrage dieselbe Spalte mit body anhängt, wird der Wert zweimal in einem einzigen atomaren Schreibvorgang geändert und der resultierende Wert ist somethingbody. Die spätere Regel überschreibt nicht die frühere Regel.
Sie können eine Ganzzahl auch mit einem ReadModifyWriteRow-Aufruf erhöhen. Wir empfehlen jedoch, stattdessen aggregierte Zellen und AddToCell oder MergeToCell zu verwenden.
Ein Wert kann nur mit ReadModifyWrite erhöht werden, wenn er als vorzeichenbehaftete 64-Bit-Big-Endian-Ganzzahl codiert ist. Bigtable behandelt eine Erhöhung eines leeren oder nicht vorhandenen Werts so, als wäre der Wert null.
ReadModifyWriteRow-Anfragen sind atomar. Sie werden nicht wiederholt, wenn sie aus irgendeinem Grund fehlschlagen.
Wann ReadModifyWriteRow nicht verwendet werden sollte
Senden Sie in den folgenden Situationen keine ReadModifyWriteRow-Anfragen:
Ihr Anwendungsfall kann durch Senden einer
MutateRow-Anfrage mit einerAddToCell-Mutation bearbeitet werden. Weitere Informationen finden Sie unter Werte beim Schreiben aggregieren.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 dann repliziert.
Sie nutzen die intelligente Wiederholungsfunktion, die von den Clientbibliotheken bereitgestellt wird. Eine
ReadModifyWriteRow-Anfrage kann nicht noch einmal versucht werden.Sie schreiben große Datenmengen und die Schreibvorgänge müssen schnell abgeschlossen werden. Eine Anfrage, die eine Zeile liest und dann ändert, ist langsamer als eine einfache Schreibanfrage. Daher ist diese Art von Schreibvorgang oft nicht der beste Ansatz für große Datenmengen.
Wenn Sie beispielsweise etwas zählen möchten, das in die Millionen geht, z. B. Seitenaufrufe, sollten Sie
MutateRowmit einerAddToCell-Mutation verwenden, um Ihre Zählungen beim Schreiben zu aktualisieren.
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.
Da bei einem bedingten Schreibvorgang die Zeile gelesen wird, um den Filter auszuwerten, muss der Aufrufer sowohl die Berechtigung bigtable.tables.readRows als auch die Berechtigung bigtable.tables.mutateRows für die Tabelle haben (oder die entsprechenden Berechtigungen bigtable.authorizedViews.readRows und bigtable.authorizedViews.mutateRows für eine autorisierte Ansicht). Weitere Informationen finden Sie unter Zugriffssteuerung.
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
ReadModifyWriteRowmüssen bei bedingten Schreibanfragen Zeilen gelesen werden, bevor sie geändert werden. Daher sindCheckAndModifyRow-Anfragen langsamer als einfache Schreibanfragen. Daher ist diese Art von Schreibvorgang oft nicht der beste Ansatz für große Datenmengen.
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, dem binären Ä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 SieMutateRowoder 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 Batch-Schreibvorgänge
Wenn Sie Ihre Batch-Schreibvorgänge (einschließlich Löschvorgänge) mit einer der folgenden Methoden senden, können Sie die Flusssteuerung für Batch-Schreibvorgänge in Ihrem Code aktivieren.
- Bigtable Beam-Connector (
BigtableIO) - Bigtable-Clientbibliothek für Java
- Bigtable HBase Beam-Connector (
CloudBigtableIO) - Bigtable-HBase-Client für Java
Wenn die Flusssteuerung für Batchschreibvorgänge für einen Dataflow-Job aktiviert ist, führt Bigtable automatisch Folgendes aus :
- Begrenzt die Traffic-Rate, um eine Überlastung des Bigtable-Clusters zu vermeiden
- Sorgt dafür, dass der Cluster ausreichend ausgelastet ist, um das Bigtable-Autoscaling (falls aktiviert) auszulösen, sodass dem Cluster bei Bedarf automatisch weitere Knoten hinzugefügt werden.
Diese kombinierten Aktionen verhindern eine Überlastung des Clusters und einen Jobfehler. Sie müssen Ihren Cluster nicht manuell skalieren, um den Batch-Schreibvorgang auszuführen. Wenn die Flusssteuerung aktiviert ist, erfolgt die Clusterskalierung während des Dataflow-Jobs und nicht davor. Daher kann es länger dauern, bis der Job abgeschlossen ist, als wenn Sie den Cluster manuell skalieren.
Sie müssen ein Anwendungsprofil verwenden, das für Single-Cluster-Routing konfiguriert ist. Das Aktivieren von Bigtable-Autoscaling für den Zielcluster ist nicht erforderlich. Mit Autoscaling können Sie jedoch die Flusssteuerung für Batch-Schreibvorgänge optimal nutzen. Sie können Dataflow-Autoscaling wie bei jedem anderen Job verwenden.
Weitere Informationen zum Bigtable-Autoscaling finden Sie unter Autoscaling. Informationen zu Routingrichtlinien für Anwendungsprofile finden Sie unter Anwendungsprofile – Übersicht.
Codebeispiele finden Sie unter Flusssteuerung für Batchschreibvorgänge aktivieren.
Daten in eine autorisierte Ansicht schreiben
Wenn Sie Daten in eine autorisierte Ansicht schreiben möchten, müssen Sie eine der folgenden Optionen verwenden:
- gcloud-CLI
- Bigtable-Client für Java
Die anderen Bigtable-Clientbibliotheken unterstützen den Zugriff auf autorisierte Ansichten noch nicht.
Wenn Sie Daten in eine autorisierte Ansicht schreiben, geben Sie zusätzlich zur Tabellen-ID die ID der autorisierten Ansicht an.
Alle Schreibvorgänge in eine autorisierte Ansicht werden direkt auf die zugrunde liegende Tabelle angewendet.
Einschränkungen bei der Definition autorisierter Ansichten
In einer autorisierten Ansicht sind die Zeilen oder Spalten, in die Sie Daten schreiben können, durch die Definition der autorisierten Ansicht eingeschränkt. Mit anderen Worten: Sie können nur in Zeilen und Spalten schreiben, die die für die autorisierte Ansicht angegebenen Kriterien erfüllen.
Wenn die autorisierte Ansicht beispielsweise durch das Zeilenschlüsselpräfix examplepetstore1 definiert ist, können Sie keine Daten mit dem Zeilenschlüssel examplepetstore2 schreiben. Der Anfang des Zeilenschlüsselwerts muss den gesamten String examplepetstore1 enthalten.
Wenn die autorisierte Ansicht durch das Spaltenqualifiziererpräfix order-phone definiert ist, können Sie Daten mit dem Spaltenqualifizierer order-phone123 schreiben, aber nicht mit dem Spaltenqualifizierer order-tablet.
Ihre Schreibanfrage darf auch nicht auf Daten verweisen, die sich außerhalb der autorisierten Ansicht befinden, z. B. wenn Sie in einer bedingten Schreibanfrage nach einem Wert suchen.
Für jede Anfrage, die Daten außerhalb der autorisierten Ansicht schreibt oder referenziert, wird die Fehlermeldung PERMISSION_DENIED zurückgegeben.
Replikation
Wenn ein Cluster einer replizierten Instanz einen Schreibvorgang empfängt, wird dieser Schreibvorgang sofort in die anderen Cluster der Instanz repliziert.
Atomarität
Jede MutateRows-Anfrage, die Sie an eine replizierte Instanz senden, wird als einzelne atomare Aktion auf dem Cluster festgeschrieben, an den die Anfrage weitergeleitet wird. Wenn der Schreibvorgang in die anderen Cluster der Instanz repliziert wird, erhalten diese Cluster den Schreibvorgang ebenfalls als atomaren Vorgang. Cluster erhalten keine partiellen Mutationen. Eine Mutation ist entweder erfolgreich oder schlägt atomar für alle Zellen fehl, die sie ä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.
Bei einer Instanz mit einem einzelnen Cluster können die Daten sofort gelesen werden. Wenn eine Instanz jedoch mehr als einen Cluster hat, also die Replikation verwendet, ist Bigtable eventuell konsistent. Sie können die Read-Your-Writes-Konsistenz erreichen, indem Sie Anfragen an denselben Cluster weiterleiten.
Sie können ein Konsistenztoken erstellen und verwenden und CheckConsistency im Modus StandardReadRemoteWrites aufrufen, nachdem Sie Schreibanfragen gesendet haben. Das Token prüft die Replikationskonsistenz. Im Allgemeinen erstellen Sie ein Konsistenztoken entweder nach dem Senden eines Batches von Schreibvorgängen oder nach einem bestimmten Intervall, z. B. einer Stunde. Anschließend können Sie das Token an einen anderen Prozess übergeben, z. B. an ein Modul, das eine Leseanfrage stellt. Dieses Modul verwendet das Token, um zu prüfen, ob alle Daten repliziert wurden, bevor es versucht, die Daten zu lesen.
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. Wenn 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.