Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Mendapatkan statistik kueri
Halaman ini menjelaskan cara mendapatkan statistik kueri menggunakan
CLI cbt. Anda juga dapat
mendapatkan statistik kueri menggunakan library klien Go untuk Cloud Bigtable.
Kemampuan untuk mendapatkan informasi tentang kueri Bigtable dapat
berguna saat Anda mengembangkan aplikasi. Dengan fitur ini, Anda bisa mendapatkan data tentang performa kueri, lalu menyesuaikan kueri atau mengubah desain skema untuk meningkatkan performa kueri.
Meskipun secara umum kueri adalah permintaan data apa pun yang dikirim ke tabel, Bigtable hanya menampilkan statistik kueri untuk permintaan baca.
Sebelum memulai
Jika Anda belum menginstal cbt CLI, ikuti petunjuk di
ringkasan cbt CLI, termasuk langkah-langkah untuk membuat file .cbtrc.
Tinjau bagian Baca baris dalam referensi CLI cbt untuk memahami sintaksis dan opsi command line yang tersedia untuk mengirim permintaan cbt read ke tabel Anda. Perhatikan bahwa
CLI cbt
tidak mendukung filter.
Pastikan Anda memiliki izin bigtable.tables.readRows untuk tabel atau bahwa Anda adalah akun utama dari peran bigtable.reader.
Menjalankan kueri
Buat kueri menggunakan sintaksis untuk
Baca baris.
Jalankan perintah berikut. Parameter include-stats=full memberi tahu
Bigtable untuk menampilkan statistik kueri.
cbt read TABLE_IDQUERY include-stats=full
Ganti kode berikut:
TABLE_ID: ID unik untuk tabel yang Anda buat kueri
QUERY: kueri berformat cbt CLI
Terminal menampilkan data yang dibaca dan daftar yang berisi
statistik berikut:
rows_seen_count: jumlah baris yang diproses Bigtable untuk permintaan
rows_returned_count: jumlah baris yang ditampilkan setelah menerapkan filter
cells_seen_count: jumlah sel yang diproses untuk permintaan
cells_returned_count: jumlah sel yang ditampilkan setelah menerapkan
filter
frontend_server_latency: latensi permintaan yang diukur dari
kumpulan server frontend Bigtable, yang dinyatakan dalam milidetik
Menafsirkan hasilnya
Lihat rasio sel yang dilihat dengan sel yang ditampilkan. Jika hasil bagi untuk
cells_seen_count / cells_returned_count adalah 1 atau mendekati 1, hal ini
menunjukkan bahwa kueri Anda tidak menyebabkan Bigtable memproses data
yang pada akhirnya difilter.
Pertimbangkan jumlah baris yang ditampilkan. Makin tinggi angka tersebut, makin banyak pekerjaan
yang dilakukan Bigtable. Jumlah optimal di sini bergantung pada
kasus penggunaan dan persyaratan latensi Anda, tetapi secara umum, kueri yang menampilkan
lebih sedikit baris akan memiliki latensi yang lebih rendah.
Contoh
Jika ingin mendapatkan statistik kueri saat membaca semua baris yang cocok dengan ekspresi reguler orange:*.* dalam tabel yang disebut my-table, Anda dapat menjalankan hal berikut:
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 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)"]]
