Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Ver as estatísticas da consulta
Nesta página, descrevemos como conferir as estatísticas de consulta usando a
CLI cbt. Também é possível
ver as estatísticas da consulta usando a biblioteca de cliente Go para o Cloud Bigtable.
A capacidade de receber informações sobre uma consulta do Bigtable pode ser
útil quando você está desenvolvendo um aplicativo. Isso permite que você veja dados sobre o desempenho de uma
consulta e, em seguida, ajuste a consulta ou altere o design do esquema para ajustar
o desempenho da consulta.
Em geral, uma consulta é qualquer solicitação de dados enviada para uma tabela,
mas o Bigtable retorna estatísticas de consulta apenas para solicitações de leitura.
Antes de começar
Se você ainda não instalou a
CLI cbt,
siga as
instruções na
visão geral da
CLI cbt,
incluindo as etapas para criar um arquivo .cbtrc.
Consulte a seção
Ler linhas
da referência da
CLI cbt
para conhecer a
sintaxe de linha de comando e as opções disponíveis para enviar uma solicitação cbt read
para a tabela. A CLI
cbt
não é compatível com filtros.
Verifique se você tem a permissão bigtable.tables.readRows para a tabela
ou que é a principal do papel bigtable.reader.
Executar a consulta
Crie uma consulta usando a sintaxe para
Ler linhas.
Execute o comando a seguir. O parâmetro include-stats=full diz
ao Bigtable para retornar as estatísticas da consulta.
cbt read TABLE_IDQUERY include-stats=full
Substitua:
TABLE_ID: o ID exclusivo da tabela que você está
consultando.
QUERY: uma
consulta formatada
em CLI cbt
O terminal exibe os dados que foram lidos e uma lista que contém as
seguintes estatísticas:
rows_seen_count: o número de linhas que o Bigtable
processou na solicitação.
rows_returned_count: o número de linhas retornadas após a aplicação de filtros.
cells_seen_count: o número de células processadas na solicitação.
cells_returned_count: o número de células retornadas após a aplicação de
filtros.
frontend_server_latency: latência da solicitação medida pelo
pool de servidores de front-end do Bigtable, expressa em milissegundos.
Interprete os resultados
Veja a proporção de células vistas em relação às células retornadas. Se o quociente de
cells_seen_count / cells_returned_count for 1 ou próximo de 1, isso é uma
indicação de que a consulta não fez com que o Bigtable processe dados
que foram filtrados.
Considere o número de linhas retornadas. Quanto maior esse número, mais trabalho
o Bigtable está fazendo. O número ideal aqui depende do
caso de uso e dos requisitos de latência. Porém, em geral, uma consulta que retorna
menos linhas terá uma latência menor.
Exemplo
Se você quiser receber estatísticas de consulta ao ler todas as linhas que correspondem à expressão
regular orange:*.* em uma tabela chamada my-table, execute o
seguinte:
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 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)"]]
