Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Cómo obtener estadísticas de consulta
En esta página, se explica cómo obtener estadísticas de consultas con la CLI de cbt. También puedes obtener estadísticas de consultas con la biblioteca cliente de Go para Cloud Bigtable.
La capacidad de obtener información sobre una consulta de Bigtable puede ser útil cuando desarrollas una aplicación. Te permite obtener datos sobre el rendimiento de una consulta y, luego, ajustarla o cambiar el diseño del esquema para optimizar su rendimiento.
Aunque, en general, una consulta es cualquier solicitud de datos que se envía a una tabla,
Bigtable muestra estadísticas de consultas solo para solicitudes de lectura.
Antes de comenzar
Si aún no instalaste la CLI de cbt, sigue las instrucciones de la
descripción general de la CLI de cbt, incluidos los pasos para crear un archivo .cbtrc.
Revisa la sección Lee filas de la referencia de la CLI de cbt para familiarizarte con la sintaxis de la línea de comandos y las opciones disponibles para enviar una solicitud cbt read a tu tabla. Ten en cuenta que la CLI de cbt no admite filtros.
Asegúrate de tener el permiso bigtable.tables.readRows para la tabla
o de que seas un miembro del rol bigtable.reader.
Ejecuta tu consulta
Crea una consulta con la sintaxis para leer filas.
Ejecuta el siguiente comando. El parámetro include-stats=full le indica a Bigtable que muestre las estadísticas de la consulta.
cbt read TABLE_IDQUERY include-stats=full
Reemplaza lo siguiente:
TABLE_ID: el ID único de la tabla a la que le realizas la consulta
QUERY: Una consulta con formato de CLI de cbt
La terminal muestra los datos que se leyeron y una lista que contiene las siguientes estadísticas:
rows_seen_count: La cantidad de filas que Bigtable
procesó para la solicitud
rows_returned_count: Es la cantidad de filas que se muestran después de aplicar los filtros.
cells_seen_count: Es la cantidad de celdas procesadas para la solicitud.
cells_returned_count: Es la cantidad de celdas que se muestran después de aplicar los filtros.
frontend_server_latency: Latencia de la solicitud medida desde el grupo de servidores del frontend de Bigtable, expresada en milisegundos
Interpreta los resultados
Observa la proporción de celdas vistas y de celdas devueltas. Si el cociente de cells_seen_count / cells_returned_count es 1 o está cerca de 1, significa que tu consulta no hizo que Bigtable procesara los datos que, en última instancia, se filtraron.
Ten en cuenta la cantidad de filas que se devuelven. Cuanto más alto sea ese número, más trabajo estará realizando Bigtable. La cantidad óptima aquí depende de tu caso de uso y de los requisitos de latencia, pero, en general, una consulta que devuelve menos filas tendrá una latencia más baja.
Ejemplo
Si deseas obtener estadísticas de consultas cuando lees todas las filas que coinciden con la expresión regular orange:*.* en una tabla llamada my-table, puedes ejecutar lo siguiente:
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 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)"]]
