Erzwingung von Datentypen in Bigtable

Mit dem flexiblen Schema von Bigtable können Sie Daten aller Art in einer Bigtable-Tabelle speichern, z. B. Strings, Datumsangaben, Zahlen, JSON-Dokumente oder sogar Bilder oder PDFs.

In diesem Dokument wird beschrieben, wann Bigtable den Typ erzwingt, sodass Sie ihn in Ihrem Anwendungscode codieren oder decodieren müssen. Eine Liste der Bigtable-Datentypen finden Sie in der Referenzdokumentation zur Data API unter Typ.

Erzwungene Typen

Der Datentyp wird für die folgenden Daten erzwungen:

  • Spaltenfamilien aggregieren (Zähler)
  • Zeitstempel
  • Kontinuierliche materialisierte Ansichten
  • Strukturierte Zeilenschlüssel

Aggregate

Beim Datentyp aggregate hängt die Codierung vom Aggregationstyp ab. Wenn Sie eine aggregierte Spaltenfamilie erstellen, müssen Sie einen Aggregationstyp angeben.

In dieser Tabelle sind der Eingabetyp und die Codierung für jeden Aggregationstyp aufgeführt.

Aggregationstyp Eingabetyp Encoding
Summe Int64 BigEndianBytes
Min. Int64 BigEndianBytes
Max. Int64 BigEndianBytes
HLL Byte Zetasketch HLL++

Wenn Sie die Daten in aggregierten Zellen mit SQL abfragen, bezieht SQL automatisch Typinformationen ein.

Wenn Sie die Daten in aggregierten Zellen mit der Methode ReadRows der Data API lesen, gibt Bigtable Byte zurück. Ihre Anwendung muss die Werte also mit der Codierung decodieren, die Bigtable verwendet hat, um die typisierten Daten Byte zuzuordnen.

Sie können eine Spaltenfamilie, die nicht aggregierte Daten enthält, nicht in eine aggregierte Spaltenfamilie umwandeln. Spalten in aggregierten Spaltenfamilien dürfen keine nicht aggregierten Zellen enthalten und Standardspaltenfamilien dürfen keine aggregierten Zellen enthalten.

Weitere Informationen zum Erstellen von Tabellen mit aggregierten Spaltenfamilien finden Sie unter Tabelle erstellen. Codebeispiele, die zeigen, wie Sie eine aggregierte Zelle mit codierten Werten erhöhen, finden Sie unter Wert erhöhen.

Zeitstempel

Jede Bigtable-Zelle hat einen Int64-Zeitstempel, der die Anzahl der Mikrosekunden seit der Unix-Epoche, 1970-01-01 00:00:00 UTC, darstellt.

Zeitstempelursprung

Jeder Zeitstempel in einer Bigtable-Tabelle hat einen Ursprung, der angibt, wie der Zeitstempel festgelegt wurde. Bigtable erkennt die folgenden Zeitstempelursprünge:

  • Vom Nutzer angegeben: Zeitstempel, die von Ihnen oder einer Anwendung festgelegt wurden.
  • Von Bigtable generiert: Zeitstempel, die von der Clientbibliothek festgelegt werden, die die lokale Systemuhr des Clients verwendet, oder vom Server generiert, die die aktuelle Zeit des Servers verwenden.

Zeitstempel-Detaillierungsgrad und -Präzision

Bigtable unterstützt die folgenden Zeitstempel-Detaillierungsgrade:

  • Millisekundengranularität (Standard): Der Zeitstempel muss ein Mikrosekundenwert mit einer Genauigkeit von höchstens Millisekunden sein, z. B. 3023483279876000. Bigtable lehnt vom Nutzer angegebene Zeitstempel mit Mikrosekundengenauigkeit ab und kürzt von Bigtable generierte Zeitstempel mit Mikrosekundengenauigkeit auf Millisekundengenauigkeit.
  • Mikrosekundengenauigkeit: Der Zeitstempel kann eine vollständige Mikrosekundengenauigkeit haben, z. B. 3023483279876543. Bigtable akzeptiert benutzerdefinierte und von Bigtable generierte Zeitstempel mit Mikrosekunden-Genauigkeit.

Sie legen die Zeitstempel-Auflösung beim Erstellen einer Tabelle fest.

Zeitstempelbeschränkungen

Für Tabellen mit Zeitstempel-Detaillierungsgrad in Mikrosekunden gelten die folgenden Einschränkungen:

  • Nur die Bigtable-Clientbibliothek für Java ab Version 2.82.0 unterstützt die Zeitstempel-Granularität in Mikrosekunden. Lese- oder Schreibanfragen, die einen anderen Client verwenden, schlagen fehl.
  • Die Mikrosekunden-Zeitstempel-Detaillierungsgrad ist nur für Instanzen in der Enterprise Plus-Version verfügbar.
  • Sie können die Zeitstempel-Auflösung einer Tabelle nach dem Erstellen nicht mehr ändern.
  • Sie können keine kontinuierlichen materialisierten Ansichten für Tabellen mit Mikrosekunden-Detaillierungsgrad erstellen.
  • Sie können keine logischen Ansichten für Tabellen mit Mikrosekunden-Detaillierungsgrad erstellen.
  • Sie können kein Downgrade einer Instanz von Enterprise Plus auf Enterprise durchführen, wenn sie Tabellen mit Mikrosekunden-Detaillierungsgrad enthält. Sie müssen diese Tabellen löschen, bevor Sie ein Downgrade starten.
  • Sicherungen von Tabellen mit Mikrosekunden-Detaillierungsgrad können nur auf Enterprise Plus-Instanzen wiederhergestellt werden.

Kontinuierliche materialisierte Ansichten

Kontinuierliche materialisierte Ansichten sind Ressourcen mit Lesezugriff, die Sie mit SQL oder einem ReadRows Data API-Aufruf lesen können. Daten in einer materialisierten Ansicht werden basierend auf der Abfrage typisiert, die sie definiert. Eine Übersicht finden Sie unter Kontinuierliche materialisierte Ansichten.

Wenn Sie SQL verwenden, um eine kontinuierlich aktualisierte materialisierte Ansicht abzufragen, bezieht SQL automatisch Typinformationen ein.

Wenn Sie mit einer Data API-ReadRows-Anfrage aus einer kontinuierlichen materialisierten Ansicht lesen, müssen Sie den Typ jeder Spalte kennen und ihn in Ihrem Anwendungscode decodieren.

Aggregierte Werte in einer kontinuierlichen materialisierten Ansicht werden mit der in der folgenden Tabelle beschriebenen Codierung gespeichert, basierend auf dem Ausgabetyp der Spalte aus der Ansichtsdefinition.

Typ Encoding
BOOL 1-Byte-Wert, 1 = wahr, 0 = falsch
BYTES Keine Codierung
INT64 (oder INT, SMALLINT, INTEGER, BIGINT, TINYINT, BYTEINT) 64-Bit-Big-Endian
FLOAT64 64-Bit-IEEE 754, ausgenommen NaN und +/-inf
STRING UTF-8
TIME/TIMESTAMP 64-Bit-Ganzzahl, die die Anzahl der Mikrosekunden seit der Unix-Epoche darstellt (konsistent mit GoogleSQL)
Weitere Informationen finden Sie in der Data API-Referenz unter Codierung.

Strukturierte Zeilenschlüssel

Mit strukturierten Zeilenschlüsseln können Sie über mehrspaltige Schlüssel auf Ihre Daten zugreifen, ähnlich wie mit zusammengesetzten Schlüsseln in relationalen Datenbanken.

Der Typ und die Codierung für strukturierte Zeilenschlüssel werden durch ein Zeilenschlüsselschema definiert, das Sie optional einer Bigtable-Tabelle hinzufügen können. Strukturierte Zeilenschlüsseldaten werden als Byte gespeichert. GoogleSQL für Bigtable verwendet jedoch automatisch den im Zeilenschlüsselschema definierten Typ und die Codierung, wenn Sie eine SQL-Abfrage für die Tabelle ausführen.

Das Abfragen einer Tabelle mit einer ReadRows-Anfrage mithilfe eines Zeilenschlüsselschemas wird nicht unterstützt. Eine kontinuierliche materialisierte Ansicht hat standardmäßig ein Zeilenschlüsselschema. Weitere Informationen zu strukturierten Zeilenschlüsseln finden Sie unter Zeilenschlüsselschemas verwalten.

Nicht erzwungene Typen

Wenn keine Typinformationen angegeben sind, behandelt Bigtable jede Zelle als Byte mit einer unbekannten Codierung.

Wenn Sie Spaltenfamilien abfragen, die ohne Typerzwingung erstellt wurden, müssen Sie beim Lesen Typinformationen angeben, damit die Daten korrekt gelesen werden. Dies ist bei Datenbankfunktionen relevant, deren Verhalten vom Datentyp abhängt. GoogleSQL for Bigtable bietet CAST-Funktionen, um Typkonvertierungen zum Zeitpunkt der Abfrage durchzuführen. Diese Funktionen konvertieren Byte in die Typen, die von verschiedenen Funktionen erwartet werden.

Bigtable erzwingt zwar keine Typen, aber bei bestimmten Vorgängen wird ein Datentyp vorausgesetzt. So können Sie sicherstellen, dass Ihre Daten so geschrieben werden, dass sie in der Datenbank verarbeitet werden können. Beispiele:

  • Bei Inkrementen mit ReadModifyWriteRow wird davon ausgegangen, dass die Zelle eine vorzeichenbehaftete 64-Bit-Ganzzahl im Big-Endian-Format enthält.
  • Die Funktion TO_VECTOR64 in SQL erwartet, dass die Zelle ein Byte-Array enthält, das eine Verkettung der Big-Endian-Byte von 64-Bit-Gleitkommazahlen ist.
  • Die Funktion TO_VECTOR32 in SQL erwartet, dass die Zelle ein Byte-Array enthält, das eine Verkettung der Big-Endian-Byte von 32-Bit-Gleitkommazahlen ist.

Nächste Schritte