Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Visualizzare le statistiche sulle query
Questa pagina descrive come ottenere le statistiche delle query utilizzando la riga di comando cbt. Puoi anche recuperare le statistiche sulle query utilizzando la libreria client Go per Cloud Bigtable.
La possibilità di ottenere informazioni su una query Bigtable può essere utile quando sviluppi un'applicazione. Ti consente di ottenere dati sul rendimento di una query, quindi di modificarla o di modificare il design dello schema per perfezionarne il rendimento.
Sebbene in genere una query sia qualsiasi richiesta di dati inviata a una tabella,
Bigtable restituisce le statistiche sulle query solo per le richieste di lettura.
Consulta la sezione Leggi righe del riferimento all'interfaccia a riga di comando cbt per familiarizzare con la sintassi della riga di comando e le opzioni disponibili per l'invio di una richiesta cbt read alla tabella. Tieni presente che la cbtCLI
non supporta i filtri.
Assicurati di disporre dell'autorizzazione bigtable.tables.readRows per la tabella o di essere un'entità del ruolo bigtable.reader.
Esegui la query
Crea una query utilizzando la sintassi per
Leggi righe.
Esegui questo comando. Il parametro include-stats=full indica a Bigtable di restituire le statistiche delle query.
cbt read TABLE_IDQUERY include-stats=full
Sostituisci quanto segue:
TABLE_ID: l'ID univoco della tabella su cui stai eseguendo la query
QUERY: una query formattata in cbt CLI
Il terminale mostra i dati letti e un elenco contenente le seguenti statistiche:
rows_seen_count: il numero di righe elaborate da Bigtable per la richiesta
rows_returned_count: il numero di righe restituite dopo l'applicazione dei filtri
cells_seen_count: il numero di celle elaborate per la richiesta
cells_returned_count: il numero di celle restituite dopo l'applicazione
di filtri
frontend_server_latency: latenza della richiesta misurata dal pool di server front-end Bigtable, espressa in millisecondi
Interpreta i risultati
Esamina il rapporto tra le celle visualizzate e quelle restituite. Se il quoziente per
cells_seen_count / cells_returned_count è 1 o è vicino a 1, è un
indicazione che la tua query non ha causato l'elaborazione dei dati da parte di Bigtable
che alla fine sono stati filtrati.
Tieni conto del numero di righe restituite. Più elevato è questo numero, maggiore è il lavoro svolto da Bigtable. Il numero ottimale dipende dal tuo caso d'uso e dai requisiti di latenza, ma in generale una query che restituisce meno righe avrà una latenza inferiore.
Esempio
Se vuoi ottenere le statistiche delle query quando leggi tutte le righe che corrispondono all'espressione regolare orange:*.* in una tabella denominata my-table, puoi eseguire quanto segue:
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 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)"]]
