Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Lesevorgänge

Auf dieser Seite werden die Arten von Leseanfragen beschrieben, die Sie an Bigtable senden können. Außerdem werden die Auswirkungen auf die Leistung erläutert und einige Empfehlungen für bestimmte Arten von Abfragen gegeben. Bevor Sie diese Seite lesen, sollten Sie sich mit den Informationen unter Übersicht über Bigtable vertraut machen.

Übersicht

Leseanfragen an Bigtable geben den Inhalt der angeforderten Zeilen in Schlüsselreihenfolge zurück, also in der Reihenfolge, in der sie gespeichert sind. Alle Schreibvorgänge, die eine Antwort zurückgegeben haben, können gelesen werden.

Die von der Tabelle unterstützten Abfragen sollten dabei helfen, den für Ihren Anwendungsfall am besten geeigneten Lesetyp zu bestimmen. Bigtable-Leseanfragen fallen in zwei allgemeine Kategorien:

Einzelne Zeile lesen
Scans oder Lesen mehrerer Zeilen

Informationen dazu, wie Ihr Lesetraffic auf Abfragetypen wie Punktlesevorgänge, kurze Scans, umgekehrte Scans, dünnbesetzte Lesevorgänge und Bulk-Lesevorgänge verteilt ist, finden Sie unter Zugriffsmuster analysieren.

Lesevorgänge sind auf Zeilenebene atomar. Wenn Sie also eine Leseanfrage für eine Zeile senden, gibt Bigtable entweder die gesamte Zeile zurück oder im Falle einer fehlgeschlagenen Anfrage nichts aus der Zeile. Eine Teilzeile wird nie zurückgegeben, es sei denn, Sie fordern eine solche an.

Wir empfehlen Ihnen dringend, unsere Cloud Bigtable-Clientbibliotheken zum Lesen von Daten aus einer Tabelle zu verwenden und nicht die API direkt aufzurufen. Codebeispiele, die das Senden von Leseanfragen zeigen, sind in mehreren Sprachen verfügbar. Alle Leseanfragen führen den API-Aufruf ReadRows aus.

Daten mit serverlosem Computing von Data Boost lesen

Mit Bigtable Data Boost können Sie Lesejobs mit hohem Durchsatz ausführen, ohne den Anwendungstraffic im Bereitstellungspfad zu beeinträchtigen. Data Boost ist ein Dienst für serverloses Computing, mit dem Sie Ihre Bigtable-Daten lesen können, während Ihre Kernanwendung die Knoten Ihres Clusters für die Berechnung verwendet. Enterprise Plus erweitert die Data Boost-Abfragefunktion um SQL-Unterstützung und Zugriff auf HDD- und mehrstufige Speicherdaten.

Data Boost ist ideal für Scans und wird nicht für das Lesen einzelner Zeilen empfohlen. Sie können Data Boost nicht für umgekehrte Scans verwenden. Weitere Informationen und Teilnahmevoraussetzungen finden Sie in der Übersicht zu Data Boost.

Einzeilige Lesevorgänge

Sie können eine einzelne Zeile anhand des Zeilenschlüssels anfordern. Lesevorgänge für einzelne Zeilen, auch als Punktlesevorgänge bezeichnet, sind nicht mit Data Boost kompatibel. Codebeispiele sind für die folgenden Varianten verfügbar:

Scans

Scans sind die gängigste Methode, um Daten aus Bigtable zu lesen. Wenn Sie einen Bereich von zusammenhängenden Zeilen oder mehrere Bereiche von Zeilen aus Bigtable lesen möchten, können Sie ein Zeilenschlüsselpräfix oder Start- und Endzeilenschlüssel angeben. Codebeispiele sind für die folgenden Varianten verfügbar:

Scans umkehren

Mit umgekehrten Scans können Sie einen Bereich von Zeilen rückwärts lesen, indem Sie entweder ein Zeilenschlüsselpräfix oder einen Bereich von Zeilen angeben. Das Zeilenschlüsselpräfix wird als Ausgangspunkt für den Scan verwendet, um rückwärts zu lesen. Wenn Sie einen Zeilenbereich angeben, wird der Endzeilenschlüssel als Startpunkt des Scans verwendet.

Das Scannen in umgekehrter Reihenfolge kann in den folgenden Szenarien nützlich sein:

Sie möchten ein Ereignis (Zeile) finden und dann die vorherigen N Ereignisse lesen.
Sie möchten den höchsten Wert vor einem bestimmten Wert finden. Das kann hilfreich sein, wenn Sie Zeitreihendaten mit einem Zeitstempel als Suffix für den Zeilenschlüssel speichern.

Rückwärtsscans sind weniger effizient als Vorwärtsscans. Im Allgemeinen sollten Sie Ihre Zeilenschlüssel so gestalten, dass die meisten Scans vorwärts erfolgen. Verwenden Sie umgekehrte Scans für kurze Scans, z. B. 50 Zeilen oder weniger, um eine niedrige Latenzzeit zu gewährleisten.

Wenn Sie in umgekehrter Reihenfolge scannen möchten, setzen Sie den Wert für das ReadRowsRequest-Feld reversed auf „true“. Der Standardwert lautet „falsch“.

Umgekehrte Scans sind verfügbar, wenn Sie die folgenden Clientbibliotheken verwenden:

Bigtable-Clientbibliothek für C++ Version 2.18.0 oder höher
Bigtable-Clientbibliothek für Go, Version 1.21.0 oder höher
Bigtable-Clientbibliothek für Java, Version 2.24.1 oder höher
Bigtable HBase-Client für Java, Version 2.10.0 oder höher

Codebeispiele für die Verwendung von umgekehrten Scans finden Sie unter Umgekehrter Scan.

Anwendungsbeispiele

Die folgenden Beispiele zeigen, wie Sie mit umgekehrten Scans herausfinden können, wann ein Kunde zuletzt sein Passwort geändert hat, und wie Sie Preisschwankungen für ein Produkt an einem bestimmten Tag ermitteln können.

Passwort zurücksetzen

Nehmen wir an, Ihre Zeilenschlüssel enthalten jeweils eine Kundennummer und ein Datum im Format 123ABC#2022-05-02. Eine der Spalten ist password_reset, in der die Stunde gespeichert ist, zu der das Passwort zurückgesetzt wurde. Bigtable speichert die Daten automatisch lexikografisch, wie im Folgenden dargestellt. Die Spalte ist für Zeilen (Tage) nicht vorhanden, an denen das Passwort nicht zurückgesetzt wurde.

`123ABC#2022-02-12,password_reset:03`
`123ABC#2022-04-02,password_reset:11`
`123ABC#2022-04-14`
`123ABC#2022-05-02`
`223ABC#2022-05-22`

Wenn Sie herausfinden möchten, wann der Kunde 123ABC sein Passwort zuletzt zurückgesetzt hat, können Sie einen Bereich von 123ABC# bis 123ABC#<DATE> mit dem heutigen Datum oder einem Datum in der Zukunft für alle Zeilen, die die Spalte password_reset enthalten, mit einem Zeilenlimit von 1 rückwärts scannen.

Preisänderungen

In diesem Beispiel enthalten Ihre Zeilenschlüssel Werte für Produkt, Modell und Zeitstempel. Eine der Spalten enthält den Preis für das Produkt und das Modell zu einem bestimmten Zeitpunkt.

`productA#model2#1675604471,price:82.63`
`productA#model2#1676219411,price:82.97`
`productA#model2#1677681011,price:83.15`
`productA#model2#1680786011,price:83.99`
`productA#model2#1682452238,price:83.12`

Wenn Sie Preisschwankungen um den Preis am 14. Februar 2023 finden möchten, obwohl in der Tabelle kein Zeilenschlüssel für dieses Datum vorhanden ist, können Sie einen Vorwärtsscan ab dem Zeilenschlüssel productA#model2#1676376000 für N Zeilen und dann einen Rückwärtsscan für dieselbe Anzahl von Zeilen ab derselben Startzeile ausführen. Die beiden Scans liefern Ihnen die Preise vor und nach dem angegebenen Zeitpunkt.

Gefilterte Lesevorgänge

Wenn Sie nur Zeilen mit bestimmten Werten oder Teilzeilen benötigen, können Sie einen Filter in der Leseanfrage verwenden. Filter ermöglichen eine äußerst selektive Auswahl von Daten.

Mit Filtern können Sie außerdem gewährleisten, dass Lesevorgänge den von der Tabelle verwendeten Richtlinien für die automatische Speicherbereinigung entsprechen. Dies ist besonders nützlich, wenn Sie häufig neue Zellen mit Zeitstempeln in vorhandene Spalten schreiben. Da es bei der automatischen Speicherbereinigung bis zu einer Woche dauern kann, bis abgelaufene Daten entfernt sind, können Sie durch Verwenden eines Zeitstempelbereichs-Filters beim Lesen von Daten dafür sorgen, dass nicht mehr Daten als benötigt gelesen lesen.

In der Filterübersicht finden Sie ausführliche Erläuterungen der Filtertypen, die Sie verwenden können. Unter Filter verwenden werden Beispiele in mehreren Sprachen gezeigt.

Daten aus einer autorisierten Ansicht lesen

Wenn Sie Daten aus einer autorisierten Ansicht lesen möchten, müssen Sie eine der folgenden Optionen verwenden:

gcloud-CLI
Bigtable-Client für Java

Die anderen Bigtable-Clientbibliotheken unterstützen den Ansichtszugriff noch nicht.

Alle Methoden, die die Methode ReadRows oder SampleRowKeys der Bigtable Data API aufrufen, werden unterstützt. Sie geben beim Erstellen des Clients zusätzlich zur Tabellen-ID die ID der autorisierten Ansicht an.

Daten aus einer kontinuierlichen materialisierten Ansicht lesen

Sie können Daten aus einer kontinuierlichen materialisierten Ansicht mit SQL oder dem ReadRows Data API-Aufruf lesen. Kontinuierliche materialisierte Ansichten haben Lesezugriff. Daten in einer materialisierten Ansicht werden basierend auf der Abfrage, die sie definiert, typisiert.

SQL

Wenn Sie Daten aus einer kontinuierlichen materialisierten Ansicht mit SQL lesen möchten, können Sie entweder den Bigtable Studio-Abfrageeditor oder eine der Clientbibliotheken, die SQL-Abfragen unterstützen, verwenden.

SQL stellt Abfrageergebnisse automatisch als typisierte Spalten bereit, sodass Sie die Codierung in Ihrer Abfrage nicht selbst verwalten müssen.

Wenn Sie eine kontinuierliche materialisierte Ansicht erstellen, erstellt Bigtable automatisch ein Zeilenschlüsselschema für die Tabelle, das die strukturierten Zeilenschlüssel für die Ansicht definiert. Weitere Informationen zum Abfragen strukturierter Zeilenschlüssel mit SQL finden Sie unter Abfragen strukturierter Zeilenschlüssel.

Daten während der ersten Befüllung lesen

Wenn Sie eine kontinuierliche materialisierte Ansicht für eine vorhandene Tabelle erstellen, startet Bigtable einen ersten Befüllungsprozess, bei dem vorhandene Tabellendaten in die Ansicht kopiert werden.

Standardmäßig lehnt Bigtable Leseanfragen ab, die versuchen, aus einer kontinuierlichen materialisierten Ansicht zu lesen, während die Ansicht erstellt wird, um die Datenkorrektheit zu gewährleisten. Wenn Sie eine Ansicht abfragen, die noch gefüllt wird, gibt Bigtable den Fehler Materialized view is still creating. zurück. Der Fehler hat den Statuscode FAILED_PRECONDITION.

Wenn Ihre Anwendung unvollständige Daten tolerieren kann, können Sie sich dafür entscheiden, aus der Ansicht zu lesen, bevor die erste Befüllung abgeschlossen ist. Wenn Sie während der ersten Befüllung aus einer kontinuierlichen materialisierten Ansicht lesen möchten, fügen Sie Ihrer SQL-Abfrage den Abfragehinweis allow_incomplete_view=true auf Anweisungsebene hinzu:

SELECT key_part FROM `VIEW_ID` @{allow_incomplete_view=true}

Ersetzen Sie VIEW_ID durch die eindeutige Kennung Ihrer kontinuierlichen materialisierten Ansicht.

Weitere Informationen finden Sie unter Kontinuierliche materialisierte Ansichten für vorhandene Tabellen erstellen.

Data API

Wenn Sie mit einem ReadRows-Aufruf aus einer der Clientbibliotheken für Bigtable aus einer kontinuierlichen materialisierten Ansicht lesen möchten, sollten Sie die SQL-Abfrage prüfen, mit der die Ansicht definiert wurde. Prüfen Sie, ob die Ansicht eine definierte _key-Spalte hat, die für Ansichten empfohlen wird, die mit ReadRows gelesen werden sollen, und ob sie eine _timestamp-Spalte hat.

Außerdem müssen Sie den Typ jeder Spalte kennen und die Spaltendaten 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, ohne 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.

Zusätzlich zum Typ jeder Spalte in der Ansicht müssen Sie die Spaltenfamilie und den Spaltenqualifizierer kennen. Die Standardspaltenfamilie heißt default und der Spaltenqualifizierer ist der Alias, der in der definierenden Abfrage angegeben ist. Betrachten Sie beispielsweise eine kontinuierliche materialisierte Ansicht, die mit dieser Abfrage definiert wurde:

SELECT
  _key,
  SUM(clicks) AS sum_clicks
FROM
  mytable
GROUP BY
  sum_clicks

Wenn Sie die Ansicht mit ReadRows abfragen, geben Sie die Spaltenfamilie default und den Spaltenqualifizierer sum_clicks an.

Lesevorgänge und Leistung

Lesevorgänge mit Filtern sind langsamer als Lesevorgänge ohne Filter und erhöhen außerdem die CPU-Auslastung. Allerdings können Sie damit die beanspruchte Netzwerkbandbreite erheblich reduzieren, da die zurückgegebene Datenmenge begrenzt wird. Im Allgemeinen sollten Filter verwendet werden, um die Durchsatzeffizienz und nicht die Latenz zu steuern.

Wenn Sie die Leseleistung optimieren möchten, sollten Sie die folgenden Strategien in Betracht ziehen:

Schränken Sie das Rowset so weit wie möglich ein. Die Begrenzung der Anzahl der Zeilen, die Ihre Knoten scannen müssen, ist der erste Schritt zur Verbesserung der Zeit bis zum ersten Byte und der Gesamtabfragelatenz. Wenn Sie das Rowset nicht beschränken, muss Bigtable höchstwahrscheinlich die gesamte Tabelle scannen. Aus diesem Grund empfehlen wir Ihnen, das Schema so zu entwerfen, dass Ihre häufigsten Abfragen diese Strategie befolgen können.
Nach dem Einschränken des Rowsets können Sie zur weiteren Leistungsoptimierung einen einfachen Filter hinzufügen. Das Einschränken der Gruppe von Spalten oder der Anzahl der zurückgegebenen Versionen erhöht im Allgemeinen nicht die Latenz und kann manchmal dazu beitragen, dass Bigtable irrelevante Daten in jeder Zeile effizienter bei der Suche übergeht.
Wenn Sie die Leseleistung nach den ersten beiden Strategien noch weiter optimieren möchten, sollten Sie einen komplexeren Filter verwenden. Sie könnten dafür verschiedene Gründe haben:
- Sie erhalten immer noch viele Daten, die Sie nicht benötigen.
- Sie möchten den Anwendungscode vereinfachen, indem Sie die Abfrage in Bigtable verschieben.
Beachten Sie jedoch, dass Filter, die Bedingungen, Interleaves oder Abgleiche mit regulären Ausdrücken für große Werte erfordern, eher schaden als nützen, wenn sie den Großteil der gescannten Daten durchlassen. Dies führt zu einer erhöhten CPU-Auslastung im Cluster ohne große Einsparungen auf der Clientseite.

Zusätzlich zu diesen Strategien sollten Sie eine große Anzahl nicht zusammenhängender Zeilenschlüssel oder Zeilenbereiche nicht in einer einzelnen Leseanforderung lesen. Wenn Sie in einer einzelnen Anfrage Hunderte von Zeilenschlüsseln oder Zeilenbereichen anfordern, scannt Bigtable die Tabelle und liest die angeforderten Zeilen sequenziell. Diese fehlende Parallelität wirkt sich auf die gesamte Latenz aus und alle Lesevorgänge, die einen Hot-Knoten erreichen, können die tail-Latenz erhöhen. Je mehr Zeilenbereiche angefordert werden, desto länger dauert der Lesevorgang. Wenn diese Latenz nicht akzeptabel ist, sollten Sie stattdessen mehrere gleichzeitige Anfragen senden, die jeweils weniger Zeilenbereiche abrufen.

Im Allgemeinen optimiert das Lesen weiterer Zeilenbereiche in einer einzelnen Anfrage den Durchsatz, jedoch nicht die Latenz. Werden weniger Zeilenbereiche in mehreren gleichzeitigen Anfragen gelesen, wird dadurch die Latenz, nicht der Durchsatz optimiert. Die richtige Balance zwischen Latenz und Durchsatz hängt von den Anforderungen Ihrer Anwendung ab. Dies kann durch eine Anpassung der Anzahl gleichzeitiger Leseanfragen und der Anzahl an Zeilenbereichen in einer Anfrage erreicht werden.

Große Zeilen

Bigtable erzwingt die folgenden Limits für große Zeilen:

256 MB ist die maximale Größe einer Zeile. Wenn Sie eine Zeile lesen müssen, die das Limit überschreitet, können Sie Ihre Anfrage paginieren und einen cells per row limit-Filter und einen cells per row offset-Filter verwenden. Beachten Sie, dass der Lesevorgang unter Umständen nicht atomar ist, wenn ein Schreibvorgang für eine Zeile zwischen den paginierten Leseanfragen eingeht.
512 KB ist die maximale Größe eines ReadRows-API-Aufrufs. Wenn Sie das Limit überschreiten, gibt Bigtable den Fehler INVALID_ARGUMENT zurück.