Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Abfragestatistiken abrufen
Auf dieser Seite wird beschrieben, wie Sie mit der cbt-Befehlszeile Abfragestatistiken abrufen. Sie können Abfragestatistiken auch mit der Go-Clientbibliothek für Cloud Bigtable abrufen.
Die Möglichkeit, Informationen zu einer Bigtable-Abfrage abzurufen, kann bei der Entwicklung einer Anwendung nützlich sein. Sie können damit Daten zur Leistung einer Abfrage abrufen und die Abfrage oder das Schemadesign anpassen, um die Leistung der Abfrage zu optimieren.
Im Allgemeinen ist eine Abfrage jede Datenanfrage, die an eine Tabelle gesendet wird. Bigtable gibt jedoch nur Abfragestatistiken für Leseanfragen zurück.
Hinweise
Wenn Sie die cbt-Befehlszeile noch nicht installiert haben, folgen Sie der Anleitung in der
Übersicht der cbt-Befehlszeile, einschließlich der Schritte zum Erstellen einer .cbtrc-Datei.
Sehen Sie sich den Abschnitt Zeilen lesen der cbt-Befehlszeilen-Referenz an, um sich mit der Befehlszeilensyntax und den Optionen zum Senden einer cbt read-Anfrage an Ihre Tabelle vertraut zu machen. Die cbt-Befehlszeile unterstützt keine Filter.
Sie benötigen die Berechtigung bigtable.tables.readRows für die Tabelle oder Sie müssen ein Hauptkonto mit der Rolle bigtable.reader sein.
Abfrage ausführen
Erstellen Sie eine Abfrage mit der Syntax für Zeilen lesen.
Führen Sie den folgenden Befehl aus: Der Parameter include-stats=full weist Bigtable an, die Abfragestatistiken zurückzugeben.
cbt read TABLE_IDQUERY include-stats=full
Dabei gilt:
TABLE_ID: Die eindeutige ID der abzufragenden Tabelle
QUERY: Eine Abfrage im cbt-Befehlszeilenformat
Im Terminal werden die gelesenen Daten und eine Liste mit den folgenden Statistiken angezeigt:
rows_seen_count: Die Anzahl der Zeilen, die Bigtable für die Anfrage verarbeitet hat
rows_returned_count: Die Anzahl der Zeilen, die nach der Anwendung von Filtern zurückgegeben werden
cells_seen_count: Die Anzahl der Zellen, die für die Anfrage verarbeitet werden
cells_returned_count: Die Anzahl der Zellen, die nach der Anwendung von Filtern zurückgegeben werden
frontend_server_latency: Die Anfragelatenz, die vom Bigtable-Frontend-Serverpool gemessen wird, ausgedrückt in Millisekunden
Ergebnisse interpretieren
Sehen Sie sich das Verhältnis der gesehenen Zellen zu den zurückgegebenen Zellen an. Wenn der Quotient für cells_seen_count ÷ cells_returned_count = 1 oder nahe bei 1 liegt, wurden durch Ihre Abfrage keine Daten in Bigtable verarbeitet, die letztendlich herausgefiltert wurden.
Berücksichtigen Sie die Anzahl der zurückgegebenen Zeilen. Je höher diese Zahl ist, desto mehr Arbeit leistet Bigtable. Die optimale Anzahl hängt von Ihrem Anwendungsfall und Ihren Latenzanforderungen ab. Im Allgemeinen ist die Latenz bei einer Abfrage mit weniger Zeilen niedriger.
Beispiel
Wenn Sie Abfragestatistiken erhalten möchten, wenn Sie alle Zeilen lesen, die mit dem regulären Ausdruck orange:*.* in einer Tabelle namens my-table übereinstimmen, können Sie Folgendes ausführen:
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-09-04 (UTC)."],[[["\u003cp\u003eThis page explains how to retrieve query statistics for read requests in Cloud Bigtable using the \u003ccode\u003ecbt\u003c/code\u003e CLI, which is useful for analyzing query performance and refining schema design.\u003c/p\u003e\n"],["\u003cp\u003eTo get query stats, use the \u003ccode\u003ecbt read\u003c/code\u003e command with the \u003ccode\u003einclude-stats=full\u003c/code\u003e parameter, specifying the table ID and query details.\u003c/p\u003e\n"],["\u003cp\u003eThe returned query stats include \u003ccode\u003erows_seen_count\u003c/code\u003e, \u003ccode\u003erows_returned_count\u003c/code\u003e, \u003ccode\u003ecells_seen_count\u003c/code\u003e, \u003ccode\u003ecells_returned_count\u003c/code\u003e, and \u003ccode\u003efrontend_server_latency\u003c/code\u003e, allowing for analysis of the query's efficiency.\u003c/p\u003e\n"],["\u003cp\u003eA \u003ccode\u003ecells_seen_count\u003c/code\u003e / \u003ccode\u003ecells_returned_count\u003c/code\u003e ratio near 1 suggests an efficient query where minimal data is filtered out, while a lower row count returned generally indicates reduced latency.\u003c/p\u003e\n"],["\u003cp\u003eBefore using this feature, it is crucial to install and configure the \u003ccode\u003ecbt\u003c/code\u003e CLI, be familiar with \u003ccode\u003ecbt read\u003c/code\u003e syntax, and have \u003ccode\u003ebigtable.tables.readRows\u003c/code\u003e permission.\u003c/p\u003e\n"]]],[],null,["Get query stats\n\nThis page describes how to get *query stats* using the\n`cbt` CLI\n. You can\nalso get query stats using the Go client library for Cloud Bigtable.\n\nThe content provided here is intended for application developers. Before you\nread this page, you should understand the\n[Bigtable storage model](/bigtable/docs/com/bigtable/docs/overview#storage-model). You\nshould also be familiar with\n[Schema design best practices](/bigtable/docs/schema-design) and\n[understand performance](/bigtable/docs/schema-design).\n\nThe ability to get information about a Bigtable query can be\nuseful when you are developing an application. It lets you get data on a query's\nperformance and then adjust the query or change your schema design to fine-tune\nthe performance of your query.\n\nAlthough in general a *query* is any data request sent to a table,\nBigtable returns query statistics only for read requests.\n\nBefore you begin\n\n1. If you haven't already installed the `cbt` CLI , follow the instructions on the [`cbt` CLI\n overview](/bigtable/docs/cbt-overview) including the steps to create a `.cbtrc` file.\n2. Review the [Read rows](/bigtable/docs/cbt-reference#read_rows) section of the `cbt` CLI reference to familiarize yourself with the command-line syntax and options available for sending a `cbt read` request to your table. Note that the `cbt` CLI does not support filters.\n3. Ensure that you have `bigtable.tables.readRows` permission for the table or that you are a principal of the `bigtable.reader` role.\n\nRun your query\n\n1. Create a query using the syntax for\n [Read rows](/bigtable/docs/cbt-reference#read_rows).\n\n2. Run the following command. The `include-stats=full` parameter tells\n Bigtable to return the query stats.\n\n cbt read \u003cvar translate=\"no\"\u003eTABLE_ID\u003c/var\u003e \u003cvar translate=\"no\"\u003eQUERY\u003c/var\u003e include-stats=full\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003eTABLE_ID\u003c/var\u003e: the unique ID for the table that you are querying\n - \u003cvar translate=\"no\"\u003eQUERY\u003c/var\u003e: a `cbt` CLI -formatted query\n\n The terminal displays the data that was read and a list containing the\n following stats:\n - `rows_seen_count`: the number of rows that Bigtable processed for the request\n - `rows_returned_count`: the number of rows returned after applying filters\n - `cells_seen_count`: the number of cells processed for the request\n - `cells_returned_count`: the number of cells returned after applying filters\n - `frontend_server_latency`: request latency measured from the Bigtable front-end server pool, expressed in milliseconds\n\nInterpret the results\n\n- Look at the ratio of cells seen to cells returned. If the quotient for\n `cells_seen_count` / `cells_returned_count` is 1 or close to 1, that's an\n indication that your query didn't cause Bigtable to process data\n that was ultimately filtered out.\n\n- Consider the number of rows returned. The higher that number is, the more work\n that Bigtable is doing. The optimal number here is dependent on\n your use case and latency requirements, but in general, a query that returns\n fewer rows will have lower latency.\n\nExample\n\nIf you want to get query stats when you read all rows that match the regular\nexpression `orange:*.*` in a table called `my-table`, you can run the\nfollowing: \n\n cbt read my-table regex='.*orange' columns='.*:.*' include-stats=full\n\nThe output is similar to the following: \n\n ----------------------------------------\n orange\n Details:Color @ 2022/09/26-14:48:01.286000\n \"orange\"\n Details:Size @ 2022/09/26-14:48:01.286000\n \"medium\"\n\n Request Stats\n ====================\n rows_seen_count: 10\n rows_returned_count : 1\n cells_seen_count: 2\n cells_returned_count: 2\n frontend_server_latency: 13ms\n\nWhat's next\n\n- [Identify a cluster's hot tablets.](/bigtable/docs/hot-tablets)\n- [Review schema design best practices.](/bigtable/docs/schema-design)"]]
