Statistik transaksi

Dokumen ini menjelaskan statistik transaksi yang ditawarkan Spanner sebagai tabel bawaan. Anda dapat mengambil statistik dari tabel SPANNER_SYS.TXN_STATS* ini menggunakan pernyataan SQL.

Kapan harus menggunakan statistik transaksi

Statistik transaksi berguna saat menyelidiki masalah performa. Misalnya, Anda dapat memeriksa apakah ada transaksi yang berjalan lambat yang dapat memengaruhi performa atau Kueri Per Detik (QPS) di database Anda. Skenario lainnya adalah saat aplikasi klien Anda mengalami latensi eksekusi transaksi yang tinggi. Menganalisis statistik transaksi dapat membantu menemukan potensi hambatan, seperti volume besar update pada kolom tertentu, yang mungkin memengaruhi latensi.

Cara mengakses statistik transaksi

Catatan: Spanner Studio (sebelumnya diberi label Query di konsol Google Cloud ) mendukung operasi SQL, DML, dan DDL dalam satu editor. Untuk mengetahui informasi selengkapnya, lihat Mengelola data Anda menggunakan konsol Google Cloud .

Spanner menyediakan statistik transaksi tabel dalam skema SPANNER_SYS. Anda dapat menggunakan cara berikut untuk mengakses data SPANNER_SYS:

• Halaman Spanner Studio database di konsol Google Cloud .

• Perintah gcloud spanner databases execute-sql.

• Dasbor Insight transaksi.

• Metode executeSql atau executeStreamingSql.

Metode baca tunggal berikut yang disediakan Spanner tidak mendukung SPANNER_SYS:

• Melakukan pembacaan yang kuat dari satu baris atau beberapa baris dalam tabel.
• Melakukan pembacaan basi dari satu baris atau beberapa baris dalam tabel.
• Membaca dari satu baris atau beberapa baris dalam indeks sekunder.

Statistik latensi yang dikelompokkan menurut transaksi

Tabel berikut melacak statistik untuk transaksi yang menggunakan resource TOP selama jangka waktu tertentu.

• SPANNER_SYS.TXN_STATS_TOP_MINUTE: statistik transaksi yang dikelompokkan di seluruh interval 1 menit.

• SPANNER_SYS.TXN_STATS_TOP_10MINUTE: statistik transaksi yang dikelompokkan di seluruh interval 10 menit.

• SPANNER_SYS.TXN_STATS_TOP_HOUR: statistik transaksi yang dikelompokkan di seluruh interval 1 jam.

Tabel ini memiliki properti berikut:

• Setiap tabel berisi data untuk interval waktu yang tidak tumpang-tindih selama durasi yang ditentukan oleh nama tabel.

• Interval didasarkan pada waktu jam

  • Interval 1 menit berakhir pada menit ke-0.
  • Interval 10 menit berakhir setiap 10 menit, dimulai pada setiap jam.
  • Interval 1 jam berakhir pada jam tersebut.

  Misalnya, pada pukul 11.59.30, interval terbaru yang tersedia untuk kueri SQL adalah:

  • 1 menit: 11.58.00–11.58.59 AM
  • 10 menit: 11.40.00–11.49.59
  • 1 jam: 10.00.00–10.59.59 AM

• Spanner mengelompokkan statistik menurut FPRINT (Sidik Jari) transaksi. Jika ada tag transaksi, FPRINT adalah hash dari tag tersebut. Jika tidak, hash tersebut adalah hash yang dihitung berdasarkan operasi yang terlibat dalam transaksi.

• Karena statistik dikelompokkan berdasarkan FPRINT, jika transaksi yang sama dieksekusi beberapa kali dalam interval waktu apa pun, hanya satu entri yang muncul untuk transaksi tersebut dalam tabel ini.

• Setiap baris berisi statistik untuk semua eksekusi transaksi tertentu yang statistiknya diambil oleh Spanner selama interval yang ditentukan.

• Jika Spanner tidak dapat menyimpan statistik untuk semua transaksi yang dijalankan selama interval dalam tabel ini, sistem akan memprioritaskan transaksi dengan latensi, upaya commit, dan byte yang ditulis tertinggi selama interval yang ditentukan.

• Semua kolom dalam tabel dapat bernilai null.

Skema tabel

Nama kolom	Jenis	Deskripsi
INTERVAL_END	TIMESTAMP	Akhir interval waktu saat eksekusi transaksi yang disertakan terjadi.
TRANSACTION_TAG	STRING	Tag transaksi opsional untuk operasi transaksi ini. Untuk mengetahui informasi selengkapnya tentang cara menggunakan tag, lihat Memecahkan masalah dengan tag transaksi. Statistik untuk beberapa transaksi yang memiliki string tag yang sama dikelompokkan dalam satu baris dengan `TRANSACTION_TAG` yang cocok dengan string tag tersebut.
FPRINT	INT64	Hash TRANSACTION_TAG jika ada; Jika tidak, hash dihitung berdasarkan operasi yang terlibat dalam transaksi. INTERVAL_END dan FPRINT bersama-sama bertindak sebagai kunci unik untuk tabel ini.
READ_COLUMNS	ARRAY<STRING>	Kumpulan kolom yang dibaca oleh transaksi.
WRITE_CONSTRUCTIVE_COLUMNS	ARRAY<STRING>	Kumpulan kolom yang ditulis secara konstruktif, yang ditetapkan ke nilai baru, berdasarkan transaksi. Untuk aliran perubahan, jika transaksi melibatkan penulisan ke kolom dan tabel yang dipantau oleh aliran perubahan, WRITE_CONSTRUCTIVE_COLUMNS berisi dua kolom - .data dan ._exists , yang diawali dengan nama aliran perubahan. _exists adalah kolom yang digunakan untuk memeriksa apakah baris tertentu ada atau tidak.
WRITE_DELETE_TABLES	ARRAY<STRING>	Kumpulan tabel yang barisnya dihapus atau diganti oleh transaksi.
ATTEMPT_COUNT	INT64	Jumlah total percobaan transaksi, termasuk percobaan yang dibatalkan sebelum memanggil `commit`.
COMMIT_ATTEMPT_COUNT	INT64	Jumlah total upaya commit transaksi. Nilai ini harus cocok dengan jumlah panggilan ke metode commit transaksi.
COMMIT_ABORT_COUNT	INT64	Jumlah total upaya transaksi yang dibatalkan, termasuk upaya yang dibatalkan sebelum memanggil metode commit transaksi.
COMMIT_RETRY_COUNT	INT64	Jumlah total upaya yang merupakan percobaan ulang dari upaya yang dibatalkan sebelumnya. Transaksi Spanner mungkin dicoba beberapa kali sebelum di-commit karena perselisihan kunci atau peristiwa sementara. Jumlah percobaan ulang yang tinggi dibandingkan dengan upaya penerapan menunjukkan bahwa mungkin ada masalah yang perlu diselidiki. Untuk mengetahui informasi selengkapnya, lihat Memahami transaksi dan jumlah commit di halaman ini.
COMMIT_FAILED_PRECONDITION_COUNT	INT64	Jumlah total upaya commit transaksi yang menampilkan error prakondisi yang gagal, seperti pelanggaran indeks UNIQUE, baris sudah ada, atau baris tidak ditemukan.
SERIALIZABLE_PESSIMISTIC_TXN_COUNT	INT64	Jumlah total percobaan transaksi yang dimulai dengan SERIALIZABLE tingkat isolasi dan penguncian PESSIMISTIC. Ini adalah subset dari ATTEMPT_COUNT.
REPEATABLE_READ_OPTIMISTIC_TXN_COUNT	INT64	Jumlah total percobaan transaksi yang dimulai dengan REPEATABLE READ tingkat isolasi dan penguncian OPTIMISTIC. Ini adalah subset dari ATTEMPT_COUNT.
AVG_PARTICIPANTS	FLOAT64	Jumlah rata-rata peserta dalam setiap upaya penerapan. Untuk mempelajari lebih lanjut peserta, lihat Proses Operasi Baca & Tulis Spanner.
AVG_TOTAL_LATENCY_SECONDS	FLOAT64	Rata-rata detik yang diperlukan dari operasi pertama transaksi hingga commit/abort.
AVG_COMMIT_LATENCY_SECONDS	FLOAT64	Rata-rata detik yang diperlukan untuk melakukan operasi commit.
AVG_BYTES	FLOAT64	Jumlah rata-rata byte yang ditulis oleh transaksi.
TOTAL_LATENCY_DISTRIBUTION	ARRAY<STRUCT>	Histogram total latensi commit, yaitu waktu dari waktu mulai operasi transaksional pertama hingga waktu commit atau waktu pembatalan, untuk semua upaya transaksi. Catatan antarmuka PostgreSQL: Database dialek PostgreSQL tidak mendukung kolom ini. Gunakan kolom TOTAL_LATENCY_DISTRIBUTION_JSON_STRING untuk database dialek PostgreSQL. Jika transaksi dibatalkan beberapa kali lalu berhasil di-commit, latensi diukur untuk setiap upaya hingga commit berhasil dilakukan. Nilai diukur dalam detik. Array berisi satu elemen dan memiliki jenis berikut: ARRAY<STRUCT<   COUNT INT64,   MEAN FLOAT64,   SUM_OF_SQUARED_DEVIATION FLOAT64,   NUM_FINITE_BUCKETS INT64,   GROWTH_FACTOR FLOAT64,   SCALE FLOAT64,   BUCKET_COUNTS ARRAY<INT64>>> Untuk mengetahui informasi selengkapnya tentang nilai, lihat Distribusi dan Eksponensial. Untuk menghitung latensi persentil dari distribusi, gunakan fungsi SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64), yang menampilkan perkiraan persentil ke-n. Untuk contoh terkait, lihat Menemukan latensi persentil ke-99 untuk transaksi. Untuk mengetahui informasi selengkapnya, lihat Persentil dan metrik bernilai distribusi.
OPERATIONS_BY_TABLE	ARRAY<STRUCT>	Dampak operasi INSERT atau UPDATE oleh transaksi berdasarkan per tabel. Hal ini ditunjukkan oleh jumlah baris yang terpengaruh dan jumlah byte yang ditulis. Catatan antarmuka PostgreSQL: Database dialek PostgreSQL tidak mendukung kolom ini. Gunakan kolom OPERATIONS_BY_TABLE_JSON_STRING sebagai gantinya untuk database dialek PostgreSQL. Kolom ini membantu memvisualisasikan beban pada tabel dan memberikan insight tentang kecepatan transaksi menulis ke tabel. Tentukan array sebagai berikut: ARRAY<STRUCT<   TABLE STRING(MAX),   INSERT_OR_UPDATE_COUNT INT64,   INSERT_OR_UPDATE_BYTES INT64>>
TOTAL_LATENCY_DISTRIBUTION_JSON_STRING	STRING	Histogram total latensi commit, yaitu waktu dari waktu mulai operasi transaksional pertama hingga waktu commit atau waktu pembatalan, untuk semua upaya transaksi. Representasi string yang kompatibel dengan JSON dari statistik TOTAL_LATENCY_DISTRIBUTION. String JSON adalah objek JSON dengan struktur yang sama seperti STRUCT yang ditentukan dalam TOTAL_LATENCY_DISTRIBUTION. Jika transaksi dibatalkan beberapa kali lalu berhasil di-commit, latensi diukur untuk setiap upaya hingga commit berhasil dilakukan. Nilai diukur dalam detik. Kolom ini didukung di database dialek GoogleSQL dan PostgreSQL. Kolom ini berisi Distribution. Untuk menghitung latensi persentil dari distribusi, gunakan fungsi SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64), yang menampilkan perkiraan persentil ke-n. Untuk contoh terkait, lihat Menemukan latensi persentil ke-99 untuk transaksi menggunakan kolom TOTAL_LATENCY_DISTRIBUTION_JSON_STRING. Untuk mengetahui informasi selengkapnya, lihat Persentil dan metrik bernilai distribusi.
OPERATIONS_BY_TABLE_JSON_STRING	STRING	Dampak operasi INSERT atau UPDATE oleh transaksi berdasarkan per tabel. Hal ini ditunjukkan oleh jumlah baris yang terpengaruh dan jumlah byte yang ditulis. Representasi string yang kompatibel dengan JSON dari kolom OPERATIONS_BY_TABLE. String JSON adalah objek JSON dengan struktur yang sama seperti STRUCT yang ditentukan di kolom OPERATIONS_BY_TABLE. Kolom ini didukung di database dialek GoogleSQL dan PostgreSQL. Kolom ini membantu memvisualisasikan beban pada tabel dan memberikan insight tentang kecepatan transaksi menulis ke tabel.

Contoh kueri

Bagian ini mencakup beberapa contoh pernyataan SQL yang mengambil statistik transaksi. Anda dapat menjalankan pernyataan SQL ini menggunakan library klien, gcloud spanner, atau konsolGoogle Cloud .

Mencantumkan statistik dasar untuk setiap transaksi dalam jangka waktu tertentu

Kueri berikut menampilkan data mentah untuk transaksi teratas pada menit sebelumnya.

SELECT fprint,
       read_columns,
       write_constructive_columns,
       write_delete_tables,
       avg_total_latency_seconds,
       avg_commit_latency_seconds,
       operations_by_table,
       avg_bytes
FROM spanner_sys.txn_stats_top_minute
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.txn_stats_top_minute);

Output kueri

fprint	read_columns	write_constructive_columns	write_delete_tables	avg_total_latency_seconds	avg_commit_latency_seconds	operations_by_table	avg_bytes
40015598317	[]	["Routes.name", "Cars.model"]	["Users"]	0.006578737	0.006547737	[["Cars",1107,30996],["Routes",560,26880]]	25286
20524969030	["id", "no"]	[]	[]	0.001732442	0.000247442	[]	0
77848338483	[]	[]	["Cars", "Routes"]	0.033467418	0.000251418	[]	0

Mencantumkan transaksi dengan latensi penerapan rata-rata tertinggi

Kueri berikut menampilkan transaksi dengan latensi commit rata-rata yang tinggi dalam satu jam sebelumnya, yang diurutkan dari latensi commit rata-rata tertinggi hingga terendah.

SELECT fprint,
       read_columns,
       write_constructive_columns,
       write_delete_tables,
       avg_total_latency_seconds,
       avg_commit_latency_seconds,
       avg_bytes
FROM spanner_sys.txn_stats_top_hour
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.txn_stats_top_hour)
ORDER BY avg_commit_latency_seconds DESC;

Output kueri

fprint	read_columns	write_constructive_columns	write_delete_tables	avg_total_latency_seconds	avg_commit_latency_seconds	avg_bytes
40015598317	[]	["Routes.name", "Cars.model"]	["Users"]	0.006578737	0.006547737	25286
77848338483	[]	[]	["Cars", "Routes"]	0.033467418	0.000251418	0
20524969030	["id", "no"]	[]	[]	0.001732442	0.000247442	0

Menemukan latensi rata-rata transaksi yang membaca kolom tertentu

Kueri berikut menampilkan informasi latensi rata-rata untuk transaksi yang membaca kolom ADDRESS dari statistik 1 jam:

SELECT fprint,
       read_columns,
       write_constructive_columns,
       write_delete_tables,
       avg_total_latency_seconds
FROM spanner_sys.txn_stats_top_hour
WHERE 'ADDRESS' IN UNNEST(read_columns)
ORDER BY avg_total_latency_seconds DESC;

Output kueri

fprint	read_columns	write_constructive_columns	write_delete_tables	avg_total_latency_seconds
77848338483	["ID", "ADDRESS"]	[]	["Cars", "Routes"]	0.033467418
40015598317	["ID", "NAME", "ADDRESS"]	[]	["Users"]	0.006578737

Mencantumkan transaksi berdasarkan jumlah rata-rata byte yang diubah

Kueri berikut menampilkan transaksi yang diambil sampelnya dalam satu jam terakhir, diurutkan berdasarkan jumlah rata-rata byte yang diubah oleh transaksi.

SELECT fprint,
       read_columns,
       write_constructive_columns,
       write_delete_tables,
       avg_bytes
FROM spanner_sys.txn_stats_top_hour
ORDER BY avg_bytes DESC;

Output kueri

fprint	read_columns	write_constructive_columns	write_delete_tables	avg_bytes
40015598317	[]	[]	["Users"]	25286
77848338483	[]	[]	["Cars", "Routes"]	12005
20524969030	["ID", "ADDRESS"]	[]	["Users"]	10923

Statistik gabungan

SPANNER_SYS juga berisi tabel untuk menyimpan data gabungan semua transaksi yang statistiknya diambil oleh Spanner dalam jangka waktu tertentu:

• SPANNER_SYS.TXN_STATS_TOTAL_MINUTE: Statistik gabungan untuk semua transaksi selama interval 1 menit
• SPANNER_SYS.TXN_STATS_TOTAL_10MINUTE: Statistik gabungan untuk semua transaksi selama interval 10 menit
• SPANNER_SYS.TXN_STATS_TOTAL_HOUR: Statistik gabungan untuk semua transaksi selama interval 1 jam

Tabel statistik gabungan memiliki properti berikut:

• Setiap tabel berisi data untuk interval waktu yang tidak tumpang-tindih dengan panjang yang ditentukan oleh nama tabel.

• Interval didasarkan pada waktu jam. Interval 1 menit berakhir pada menit ke-1, interval 10 menit berakhir setiap 10 menit yang dimulai pada jam ke-1, dan interval 1 jam berakhir pada jam ke-1.

  Misalnya, pada pukul 11.59.30, interval terbaru yang tersedia untuk kueri SQL tentang statistik transaksi gabungan adalah:

  • 1 menit: 11.58.00–11.58.59 AM
  • 10 menit: 11.40.00–11.49.59
  • 1 jam: 10.00.00–10.59.59 AM

• Setiap baris berisi statistik untuk semua transaksi yang dieksekusi melalui database selama interval yang ditentukan, yang digabungkan. Hanya ada satu baris per interval waktu.

• Statistik yang dicatat dalam tabel SPANNER_SYS.TXN_STATS_TOTAL_* mungkin mencakup transaksi yang tidak dicatat Spanner dalam tabel SPANNER_SYS.TXN_STATS_TOP_*.

• Beberapa kolom dalam tabel ini ditampilkan sebagai metrik di Cloud Monitoring. Metrik yang diekspos adalah:

  • Jumlah upaya penerapan
  • Jumlah percobaan ulang commit
  • Peserta transaksi
  • Latensi transaksi
  • Byte yang ditulis

  Untuk mengetahui informasi selengkapnya, lihat Metrik Spanner.

Skema tabel

Nama kolom	Jenis	Deskripsi
INTERVAL_END	TIMESTAMP	Akhir interval waktu saat statistik ini diambil.
ATTEMPT_COUNT	INT64	Jumlah total upaya transaksi, termasuk upaya yang dibatalkan sebelum memanggil `commit`.
COMMIT_ATTEMPT_COUNT	INT64	Jumlah total upaya commit transaksi. Nilai ini harus cocok dengan jumlah panggilan ke metode commit transaksi.
COMMIT_ABORT_COUNT	INT64	Jumlah total percobaan transaksi yang dibatalkan, termasuk yang dibatalkan sebelum memanggil metode commit transaksi.
COMMIT_RETRY_COUNT	INT64	Jumlah upaya commit yang merupakan percobaan ulang dari upaya yang dibatalkan sebelumnya. Transaksi Spanner mungkin telah dicoba beberapa kali sebelum di-commit karena perselisihan kunci atau peristiwa sementara. Jumlah percobaan ulang yang tinggi dibandingkan dengan upaya penerapan menunjukkan bahwa mungkin ada masalah yang perlu diselidiki. Untuk mengetahui informasi selengkapnya, lihat Memahami transaksi dan jumlah commit di halaman ini.
COMMIT_FAILED_PRECONDITION_COUNT	INT64	Jumlah total upaya commit transaksi yang menampilkan error prasyarat gagal, seperti pelanggaran indeks, baris sudah ada, atau baris tidak ditemukan.UNIQUE
SERIALIZABLE_PESSIMISTIC_TXN_COUNT	INT64	Jumlah total percobaan transaksi yang dimulai dengan tingkat isolasi SERIALIZABLE dan penguncian PESSIMISTIC. Ini adalah subset dari ATTEMPT_COUNT.
REPEATABLE_READ_OPTIMISTIC_TXN_COUNT	INT64	Jumlah total percobaan transaksi yang dimulai dengan tingkat isolasi REPEATABLE READ dan penguncian OPTIMISTIC. Ini adalah subset dari ATTEMPT_COUNT.
AVG_PARTICIPANTS	FLOAT64	Jumlah rata-rata peserta dalam setiap upaya penerapan. Untuk mempelajari lebih lanjut peserta, lihat Proses Operasi Baca & Tulis Spanner.
AVG_TOTAL_LATENCY_SECONDS	FLOAT64	Rata-rata detik yang diperlukan dari operasi pertama transaksi hingga commit/abort.
AVG_COMMIT_LATENCY_SECONDS	FLOAT64	Rata-rata detik yang diperlukan untuk melakukan operasi commit.
AVG_BYTES	FLOAT64	Jumlah rata-rata byte yang ditulis oleh transaksi.
TOTAL_LATENCY_DISTRIBUTION	ARRAY<STRUCT>	Histogram total latensi commit, yaitu waktu dari waktu mulai operasi transaksional pertama hingga waktu commit atau batalkan untuk semua upaya transaksi. Catatan antarmuka PostgreSQL: Database dialek PostgreSQL tidak mendukung kolom ini. Gunakan kolom TOTAL_LATENCY_DISTRIBUTION_JSON_STRING sebagai gantinya untuk database dialek PostgreSQL. Jika transaksi dibatalkan beberapa kali lalu berhasil di-commit, latensi diukur untuk setiap upaya hingga commit berhasil dilakukan. Nilai diukur dalam detik. Array berisi satu elemen dan memiliki jenis berikut: ARRAY<STRUCT<   COUNT INT64,   MEAN FLOAT64,   SUM_OF_SQUARED_DEVIATION FLOAT64,   NUM_FINITE_BUCKETS INT64,   GROWTH_FACTOR FLOAT64,   SCALE FLOAT64,   BUCKET_COUNTS ARRAY<INT64>>> Untuk mengetahui informasi selengkapnya tentang nilai, lihat Distribusi dan Eksponensial. Untuk menghitung latensi persentil dari distribusi, gunakan fungsi SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64), yang menampilkan perkiraan persentil ke-n. Sebagai contoh, lihat Menemukan latensi persentil ke-99 untuk transaksi. Untuk mengetahui informasi selengkapnya, lihat Persentil dan metrik bernilai distribusi.
OPERATIONS_BY_TABLE	ARRAY<STRUCT>	Dampak operasi INSERT atau UPDATE oleh semua transaksi berdasarkan per tabel. Hal ini ditunjukkan oleh jumlah baris yang terpengaruh dan jumlah byte yang ditulis. Catatan antarmuka PostgreSQL: Database dialek PostgreSQL tidak mendukung kolom ini. Gunakan kolom OPERATIONS_BY_TABLE_JSON_STRING sebagai gantinya untuk database dialek PostgreSQL. Kolom ini membantu memvisualisasikan beban pada tabel dan memberikan insight tentang kecepatan penulisan transaksi ke tabel. Tentukan array sebagai berikut: ARRAY<STRUCT<   TABLE STRING(MAX),   INSERT_OR_UPDATE_COUNT INT64,   INSERT_OR_UPDATE_BYTES INT64>>
TOTAL_LATENCY_DISTRIBUTION_JSON_STRING	STRING	Histogram total latensi commit, yaitu waktu dari waktu mulai operasi transaksional pertama hingga waktu commit atau waktu pembatalan, untuk semua upaya transaksi. Representasi string yang kompatibel dengan JSON dari statistik TOTAL_LATENCY_DISTRIBUTION. String JSON adalah objek JSON dengan struktur yang sama seperti STRUCT yang ditentukan dalam TOTAL_LATENCY_DISTRIBUTION. Jika transaksi dibatalkan beberapa kali lalu berhasil di-commit, latensi diukur untuk setiap upaya hingga commit berhasil dilakukan. Nilai diukur dalam detik. Kolom ini didukung di database dialek GoogleSQL dan PostgreSQL. Kolom ini berisi Distribution. Untuk menghitung latensi persentil dari distribusi, gunakan fungsi SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64), yang menampilkan perkiraan persentil ke-n. Untuk contoh terkait, lihat Menemukan latensi persentil ke-99 untuk transaksi menggunakan kolom TOTAL_LATENCY_DISTRIBUTION_JSON_STRING. Untuk mengetahui informasi selengkapnya, lihat Persentil dan metrik bernilai distribusi.
OPERATIONS_BY_TABLE_JSON_STRING	STRING	Dampak operasi INSERT atau UPDATE oleh transaksi berdasarkan per tabel. Hal ini ditunjukkan oleh jumlah baris yang terpengaruh dan jumlah byte yang ditulis. Representasi string yang kompatibel dengan JSON dari kolom OPERATIONS_BY_TABLE. String JSON adalah objek JSON dengan struktur yang sama seperti STRUCT yang ditentukan di kolom OPERATIONS_BY_TABLE. Kolom ini didukung di database dialek GoogleSQL dan PostgreSQL. Kolom ini membantu memvisualisasikan beban pada tabel dan memberikan insight tentang kecepatan transaksi menulis ke tabel.

Contoh kueri

Bagian ini mencakup beberapa contoh pernyataan SQL yang mengambil statistik transaksi. Anda dapat menjalankan pernyataan SQL ini menggunakan library klien, gcloud spanner, atau konsolGoogle Cloud .

Menemukan jumlah total upaya penerapan untuk semua transaksi

Kueri berikut menampilkan jumlah total upaya commit untuk semua transaksi dalam interval 1 menit lengkap terbaru:

SELECT interval_end,
       commit_attempt_count
FROM spanner_sys.txn_stats_total_minute
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.txn_stats_total_minute)
ORDER BY interval_end;

Output kueri

interval_end	commit_attempt_count
2020-01-17 11:46:00-08:00	21

Perhatikan bahwa hanya ada satu baris dalam hasil karena statistik gabungan hanya memiliki satu entri per interval_end untuk durasi waktu apa pun.

Menemukan total latensi commit di semua transaksi

Kueri berikut menampilkan total latensi commit di semua transaksi dalam 10 menit sebelumnya:

SELECT (avg_commit_latency_seconds * commit_attempt_count / 60 / 60)
  AS total_commit_latency_hours
FROM spanner_sys.txn_stats_total_10minute
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.txn_stats_total_10minute);

Output kueri

total_commit_latency_hours
0.8967

Perhatikan bahwa hanya ada satu baris dalam hasil karena statistik gabungan hanya memiliki satu entri per interval_end untuk durasi waktu apa pun.

Menemukan latensi persentil ke-99 untuk transaksi

Kueri berikut menampilkan persentil ke-99 waktu eksekusi di seluruh kueri yang dijalankan dalam 10 menit sebelumnya.

Untuk database dialek GoogleSQL, Anda dapat menggunakan kolom TOTAL_LATENCY_DISTRIBUTION:

SELECT interval_end, avg_total_latency_seconds,
       SPANNER_SYS.DISTRIBUTION_PERCENTILE(total_latency_distribution[OFFSET(0)], 99.0)
  AS percentile_latency
FROM spanner_sys.txn_stats_total_10minute
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.txn_stats_total_10minute)
ORDER BY interval_end;

Untuk database dialek PostgreSQL, gunakan kolom TOTAL_LATENCY_JSON_DISTRIBUTION_JSON_STRING sebagai gantinya:

SELECT interval_end, avg_total_latency_seconds,
       SPANNER_SYS.DISTRIBUTION_PERCENTILE(total_latency_distribution_json_string, 99.0)
  AS percentile_latency
FROM spanner_sys.txn_stats_total_10minute
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.txn_stats_total_10minute)
ORDER BY interval_end;

Output kueri

interval_end	avg_total_latency_seconds	percentile_latency
2022-08-17 11:46:00-08:00	0.34576998305986395	9.00296190476190476

Perhatikan perbedaan besar antara latensi rata-rata dan persentil ke-99. Latensi persentil ke-99 membantu mengidentifikasi kemungkinan transaksi pencilan dengan latensi tinggi.

Hanya ada satu baris dalam hasil karena statistik gabungan hanya memiliki satu entri per interval_end untuk durasi waktu apa pun.

Retensi data

Setidaknya, Spanner menyimpan data untuk setiap tabel selama periode waktu berikut:

• SPANNER_SYS.TXN_STATS_TOP_MINUTE dan SPANNER_SYS.TXN_STATS_TOTAL_MINUTE: Interval yang mencakup 6 jam sebelumnya.

• SPANNER_SYS.TXN_STATS_TOP_10MINUTE dan SPANNER_SYS.TXN_STATS_TOTAL_10MINUTE: Interval yang mencakup 4 hari sebelumnya.

• SPANNER_SYS.TXN_STATS_TOP_HOUR dan SPANNER_SYS.TXN_STATS_TOTAL_HOUR: Interval yang mencakup 30 hari sebelumnya.

Catatan: Anda tidak dapat mencegah Spanner mengumpulkan statistik transaksi. Untuk menghapus data dalam tabel ini, Anda harus menghapus database yang terkait dengan tabel atau menunggu hingga Spanner menghapus data secara otomatis. Anda tidak dapat memperpanjang periode retensi data untuk tabel ini.

Statistik transaksi di Spanner memberikan insight tentang cara aplikasi menggunakan database, dan berguna saat menyelidiki masalah performa. Misalnya, Anda dapat memeriksa apakah ada transaksi yang berjalan lambat yang dapat menyebabkan pertentangan, atau Anda dapat mengidentifikasi potensi sumber beban tinggi, seperti volume besar pembaruan ke kolom tertentu.

Memahami transaksi dan jumlah penerapan

Transaksi Spanner mungkin harus dicoba beberapa kali sebelum di-commit. Hal ini paling sering terjadi saat dua transaksi mencoba memproses data yang sama secara bersamaan, dan salah satu transaksi harus dibatalkan untuk mempertahankan properti isolasi transaksi. Beberapa peristiwa sementara lainnya yang juga dapat menyebabkan transaksi dibatalkan meliputi:

• Masalah jaringan sementara.

• Perubahan skema database yang diterapkan saat transaksi sedang dalam proses melakukan commit.

• Instance Spanner tidak memiliki kapasitas untuk menangani semua permintaan yang diterimanya.

Dalam skenario seperti itu, klien harus mencoba ulang transaksi yang dibatalkan hingga berhasil di-commit atau waktunya habis. Untuk pengguna library klien Spanner resmi, setiap library telah menerapkan mekanisme coba lagi otomatis. Jika Anda menggunakan versi kustom kode klien, sertakan commit transaksi Anda dalam loop percobaan ulang.

Transaksi Spanner juga dapat dibatalkan karena error yang tidak dapat dicoba lagi seperti waktu tunggu transaksi habis, masalah izin, atau nama tabel atau kolom yang tidak valid. Tidak perlu mencoba lagi transaksi tersebut dan library klien Spanner akan segera menampilkan error.

Tabel berikut menjelaskan beberapa contoh cara COMMIT_ATTEMPT_COUNT, COMMIT_ABORT_COUNT, dan COMMIT_RETRY_COUNT dicatat dalam berbagai skenario.

Skenario	COMMIT_ATTEMPT_COUNT	COMMIT_ABORT_COUNT	COMMIT_RETRY_COUNT
Transaksi berhasil dilakukan pada percobaan pertama.	1	0	0
Transaksi dibatalkan karena error waktu tunggu habis.	1	1	0
Transaksi dibatalkan karena masalah jaringan sementara dan berhasil dilakukan setelah satu kali percobaan ulang.	2	1	1
5 transaksi dengan FPRINT yang sama dieksekusi dalam interval 10 menit. 3 transaksi berhasil dilakukan pada percobaan pertama, sementara 2 transaksi dibatalkan lalu berhasil dilakukan pada percobaan ulang pertama.	7	2	2

Data dalam tabel transaksi-stats adalah data gabungan untuk interval waktu. Untuk interval tertentu, transaksi dapat dibatalkan dan dicoba lagi di sekitar batas dan masuk ke dalam bucket yang berbeda. Akibatnya, dalam interval waktu tertentu, pembatalan dan percobaan ulang mungkin tidak sama.

Statistik ini dirancang untuk pemecahan masalah dan introspeksi, serta tidak dijamin 100% akurat. Statistik digabungkan dalam memori sebelum disimpan dalam tabel Spanner. Selama upgrade atau aktivitas pemeliharaan lainnya, server Spanner dapat dimulai ulang, sehingga memengaruhi akurasi angka.

Memecahkan masalah pertentangan database menggunakan statistik transaksi

Anda dapat menggunakan kode SQL atau dasbor Insight transaksi untuk melihat transaksi di database yang dapat menyebabkan latensi tinggi karena persaingan kunci.

Topik berikut menunjukkan cara menyelidiki transaksi tersebut menggunakan kode SQL.

Pilih jangka waktu yang akan diselidiki

ID ini dapat ditemukan dari aplikasi yang menggunakan Spanner.

Untuk tujuan latihan ini, asumsikan bahwa masalah mulai terjadi sekitar pukul 17.20 pada 17 Mei 2020.

Anda dapat menggunakan Tag Transaksi untuk mengidentifikasi sumber transaksi dan melakukan korelasi antara Tabel Statistik Transaksi dan tabel Statistik Kunci untuk pemecahan masalah pertentangan kunci yang efektif. Baca selengkapnya di Memecahkan masalah dengan tag transaksi.

Mengumpulkan statistik transaksi untuk jangka waktu yang dipilih

Untuk memulai investigasi, kueri tabel TXN_STATS_TOTAL_10MINUTE di sekitar awal terjadinya masalah. Hasil kueri ini menunjukkan bagaimana latensi dan statistik transaksi lainnya berubah selama jangka waktu tersebut.

Misalnya, kueri berikut menampilkan statistik transaksi gabungan dari 4:30 pm hingga 7:40 pm (inklusif).

SELECT
  interval_end,
  ROUND(avg_total_latency_seconds,4) as avg_total_latency_seconds,
  commit_attempt_count,
  commit_abort_count
FROM SPANNER_SYS.TXN_STATS_TOTAL_10MINUTE
WHERE
  interval_end >= "2020-05-17T16:40:00"
  AND interval_end <= "2020-05-17T19:40:00"
ORDER BY interval_end;

Tabel berikut mencantumkan contoh data yang ditampilkan dari kueri.

interval_end	avg_total_latency_seconds	commit_attempt_count	commit_abort_count
2020-05-17 16:40:00-07:00	0,0284	315691	5170
2020-05-17 16:50:00-07:00	0,0250	302124	3828
17-05-2020 17:00:00-07:00	0.0460	346087	11382
17-05-2020 17.10.00-07:00	0,0864	379964	33826
2020-05-17 17:20:00-07:00	0,1291	390343	52549
2020-05-17 17:30:00-07:00	0,1314	456455	76392
2020-05-17 17:40:00-07:00	0,1598	507774	121458
2020-05-17 17:50:00-07:00	0,1641	516587	115875
2020-05-17 18:00:00-07:00	0,1578	552711	122626
2020-05-17 18:10:00-07:00	0,1750	569460	154205
2020-05-17 18:20:00-07:00	0,1727	613571	160772
2020-05-17 18:30:00-07:00	0,1588	601994	143044
2020-05-17 18:40:00-07:00	0.2025	604211	170019
2020-05-17 18:50:00-07:00	0,1615	601622	135601
2020-05-17 19:00:00-07:00	0,1653	596804	129511
2020-05-17 19:10:00-07:00	0.1414	560023	112247
2020-05-17 19:20:00-07:00	0,1367	570864	100596
2020-05-17 19:30:00-07:00	0,0894	539729	65316
2020-05-17 19:40:00-07:00	0,0820	479151	40398

Latensi gabungan dan jumlah pembatalan lebih tinggi pada periode yang ditandai. Pilih interval 10 menit saat latensi gabungan dan jumlah pembatalan atau keduanya tinggi. Interval yang berakhir pada 2020-05-17T18:40:00 digunakan pada langkah berikutnya untuk mengidentifikasi transaksi mana yang berkontribusi pada latensi tinggi dan jumlah pembatalan.

Mengidentifikasi transaksi yang mengalami latensi tinggi

Kueri tabel TXN_STATS_TOP_10MINUTE untuk interval yang dipilih pada langkah sebelumnya. Dengan menggunakan data ini, Anda dapat mulai mengidentifikasi transaksi mana yang mengalami latensi tinggi atau jumlah pembatalan tinggi, atau keduanya.

Jalankan kueri berikut untuk mendapatkan transaksi yang paling memengaruhi performa dalam urutan menurun dari total latensi untuk contoh interval yang berakhir pada 2020-05-17T18:40:00.

SELECT
  interval_end,
  fprint,
  ROUND(avg_total_latency_seconds,4) as avg_total_latency_seconds,
  ROUND(avg_commit_latency_seconds,4) as avg_commit_latency_seconds,
  commit_attempt_count,
  commit_abort_count,
  commit_retry_count
FROM SPANNER_SYS.TXN_STATS_TOP_10MINUTE
WHERE
  interval_end = "2020-05-17T18:40:00"
ORDER BY avg_total_latency_seconds DESC;

interval_end	fprint	avg_total_latency_seconds	avg_commit_latency_seconds	commit_attempt_count	commit_abort_count	commit_retry_count
2020-05-17 18:40:00-07:00	15185072816865185658	0,3508	0,0139	278802	142205	129884
2020-05-17 18:40:00-07:00	15435530087434255496	0,1633	0,0142	129012	27177	24559
2020-05-17 18:40:00-07:00	14175643543447671202	0,1423	0,0133	5357	636	433
2020-05-17 18:40:00-07:00	898069986622520747	0,0198	0,0158	6	0	0
2020-05-17 18:40:00-07:00	10510121182038036893	0,0168	0,0125	7	0	0
2020-05-17 18:40:00-07:00	9287748709638024175	0,0159	0,0118	4269	1	0
2020-05-17 18:40:00-07:00	7129109266372596045	0,0142	0,0102	182227	0	0
2020-05-17 18:40:00-07:00	15630228555662391800	0,0120	0,0107	58	0	0
2020-05-17 18:40:00-07:00	7907238229716746451	0,0108	0,0097	65	0	0
2020-05-17 18:40:00-07:00	10158167220149989178	0,0095	0,0047	3454	0	0
2020-05-17 18:40:00-07:00	9353100217060788102	0,0093	0,0045	725	0	0
2020-05-17 18:40:00-07:00	9521689070912159706	0,0093	0,0045	164	0	0
2020-05-17 18:40:00-07:00	11079878968512225881	0,0064	0,0019	65	0	0

Baris pertama (ditandai) dalam tabel sebelumnya menunjukkan transaksi yang mengalami latensi tinggi karena banyaknya pembatalan commit. Ada juga sejumlah besar percobaan ulang commit yang menunjukkan bahwa commit yang dibatalkan kemudian dicoba ulang. Langkah berikutnya adalah menyelidiki lebih lanjut untuk melihat penyebab masalah ini.

Mengidentifikasi kolom yang terlibat dalam transaksi yang mengalami latensi tinggi

Pada langkah ini, periksa apakah transaksi latensi tinggi beroperasi pada set kolom yang sama dengan mengambil data read_columns, write_constructive_columns, dan write_delete_tables untuk transaksi dengan jumlah pembatalan yang tinggi. Nilai FPRINT juga akan berguna di langkah berikutnya.

SELECT
  fprint,
  read_columns,
  write_constructive_columns,
  write_delete_tables
FROM SPANNER_SYS.TXN_STATS_TOP_10MINUTE
WHERE
  interval_end = "2020-05-17T18:40:00"
ORDER BY avg_total_latency_seconds DESC LIMIT 3;

fprint	read_columns	write_constructive_columns	write_delete_tables
15185072816865185658	[TestHigherLatency._exists,TestHigherLatency.lang_status,TestHigherLatency.score,globalTagAffinity.shares]	[TestHigherLatency._exists,TestHigherLatency.shares,TestHigherLatency_lang_status_score_index.shares]	[]
15435530087434255496	[TestHigherLatency._exists,TestHigherLatency.lang_status,TestHigherLatency.likes,globalTagAffinity.score]	[TestHigherLatency._exists,TestHigherLatency.likes,TestHigherLatency_lang_status_score_index.likes]	[]
14175643543447671202	[TestHigherLatency._exists,TestHigherLatency.lang_status,TestHigherLatency.score,globalTagAffinity.ugcCount]	[TestHigherLatency._exists,TestHigherLatency.ugcCount,TestHigherLatency_lang_status_score_index.ugcCount]	[]

Seperti yang ditunjukkan output dalam tabel sebelumnya, transaksi dengan total latensi rata-rata tertinggi membaca kolom yang sama. Ada juga beberapa pertentangan tulis karena transaksi menulis ke kolom yang sama, yaitu, TestHigherLatency._exists.

Menentukan bagaimana performa transaksi telah berubah dari waktu ke waktu

Anda dapat melihat perubahan statistik yang terkait dengan bentuk transaksi ini selama jangka waktu tertentu. Gunakan kueri berikut, dengan $FPRINT adalah sidik jari transaksi latensi tinggi dari langkah sebelumnya.

SELECT
  interval_end,
  ROUND(avg_total_latency_seconds, 3) AS latency,
  ROUND(avg_commit_latency_seconds, 3) AS commit_latency,
  commit_attempt_count,
  commit_abort_count,
  commit_retry_count,
  commit_failed_precondition_count,
  avg_bytes
FROM SPANNER_SYS.TXN_STATS_TOP_10MINUTE
WHERE
  interval_end >= "2020-05-17T16:40:00"
  AND interval_end <= "2020-05-17T19:40:00"
  AND fprint = $FPRINT
ORDER BY interval_end;

interval_end	latensi	commit_latency	commit_attempt_count	commit_abort_count	commit_retry_count	commit_failed_precondition_count	avg_bytes
2020-05-17 16:40:00-07:00	0,095	0,010	53230	4752	4330	0	91
2020-05-17 16:50:00-07:00	0,069	0,009	61264	3589	3364	0	91
17-05-2020 17:00:00-07:00	0,150	0,010	75868	10557	9322	0	91
17-05-2020 17.10.00-07:00	0,248	0,013	103151	30220	28483	0	91
17-05-2020 17:20:00-07:00	0,310	0,012	130078	45655	41966	0	91
2020-05-17 17:30:00-07:00	0,294	0,012	160064	64930	59933	0	91
2020-05-17 17:40:00-07:00	0,315	0,013	209614	104949	96770	0	91
17-05-2020 17:50:00-07:00	0,322	0,012	215682	100408	95867	0	90
17-05-2020 18:00:00-07:00	0,310	0,012	230932	106728	99462	0	91
17-05-2020 18:10:00-07:00	0,309	0,012	259645	131049	125889	0	91
2020-05-17 18:20:00-07:00	0,315	0,013	272171	137910	129411	0	90
2020-05-17 18:30:00-07:00	0,292	0,013	258944	121475	115844	0	91
2020-05-17 18:40:00-07:00	0.350	0,013	278802	142205	134229	0	91
2020-05-17 18:50:00-07:00	0,302	0,013	256259	115626	109756	0	91
17-05-2020 19:00:00-07:00	0,315	0,014	250560	110662	100322	0	91
17-05-2020 19:10:00-07:00	0,271	0,014	238384	99025	90187	0	91
2020-05-17 19:20:00-07:00	0,273	0,014	219687	84019	79874	0	91
2020-05-17 19:30:00-07:00	0,198	0,013	195357	59370	55909	0	91
2020-05-17 19:40:00-07:00	0,181	0,013	167514	35705	32885	0	91

Dalam output ini, amati bahwa total latensi tinggi untuk jangka waktu yang ditandai. Selain itu, di mana pun total latensi tinggi, commit_attempt_count commit_abort_count, dan commit_retry_count juga tinggi meskipun latensi penerapan (commit_latency) tidak banyak berubah. Karena commit transaksi lebih sering dibatalkan, upaya commit juga tinggi karena coba lagi commit.

Kesimpulan

Dalam contoh ini, jumlah pembatalan commit yang tinggi menjadi penyebab latensi yang tinggi. Langkah berikutnya adalah melihat pesan error pembatalan commit yang diterima oleh aplikasi untuk mengetahui alasan pembatalan. Dengan memeriksa log di aplikasi, Anda dapat melihat bahwa aplikasi benar-benar mengubah beban kerjanya selama waktu ini, yaitu, beberapa bentuk transaksi lain muncul dengan attempts_per_second yang tinggi, dan transaksi yang berbeda tersebut (mungkin tugas pembersihan malam) bertanggung jawab atas konflik kunci tambahan.

Mengidentifikasi transaksi yang tidak dicoba lagi dengan benar

Kueri berikut menampilkan transaksi yang diambil sampelnya dalam sepuluh menit terakhir yang memiliki jumlah pembatalan commit yang tinggi, tetapi tidak ada percobaan ulang.

SELECT
  *
FROM (
  SELECT
    fprint,
    SUM(commit_attempt_count) AS total_commit_attempt_count,
    SUM(commit_abort_count) AS total_commit_abort_count,
    SUM(commit_retry_count) AS total_commit_retry_count
  FROM
    SPANNER_SYS.TXN_STATS_TOP_10MINUTE
  GROUP BY
    fprint )
WHERE
  total_commit_retry_count = 0
  AND total_commit_abort_count > 0
ORDER BY
  total_commit_abort_count DESC;

fprint	total_commit_attempt_count	total_commit_abort_count	total_commit_retry_count
1557557373282541312	3367894	44232	0
5776062322886969344	13566	14	0

Transaksi dengan fprint 1557557373282541312 dibatalkan 44232 kali, tetapi tidak pernah dicoba lagi. Hal ini terlihat mencurigakan karena jumlah pembatalan tinggi dan tidak mungkin setiap pembatalan disebabkan oleh error yang tidak dapat dicoba lagi. Di sisi lain, untuk transaksi dengan fprint 5776062322886969344, kecurigaannya lebih rendah karena jumlah pembatalan total tidak terlalu tinggi.

Kueri berikut menampilkan detail selengkapnya tentang transaksi dengan fprint 1557557373282541312, termasuk read_columns,write_constructive_columns, dan write_delete_tables. Informasi ini membantu mengidentifikasi transaksi dalam kode klien, tempat logika percobaan ulang dapat ditinjau untuk skenario ini.

SELECT
  interval_end,
  fprint,
  read_columns,
  write_constructive_columns,
  write_delete_tables,
  commit_attempt_count,
  commit_abort_count,
  commit_retry_count
FROM
  SPANNER_SYS.TXN_STATS_TOP_10MINUTE
WHERE
  fprint = 1557557373282541312
ORDER BY
  interval_end DESC;

interval_end	fprint	read_columns	write_constructive_columns	write_delete_tables	commit_attempt_count	commit_abort_count	commit_retry_count
2021-01-27T18:30:00Z	1557557373282541312	['Singers._exists']	['Singers.FirstName', 'Singers.LastName', 'Singers._exists']	[]	805228	1839	0
2021-01-27T18:20:00Z	1557557373282541312	['Singers._exists']	['Singers.FirstName', 'Singers.LastName', 'Singers._exists']	[]	1034429	38779	0
2021-01-27T18:10:00Z	1557557373282541312	['Singers._exists']	['Singers.FirstName', 'Singers.LastName', 'Singers._exists']	[]	833677	2266	0
2021-01-27T18:00:00Z	1557557373282541312	['Singers._exists']	['Singers.FirstName', 'Singers.LastName', 'Singers._exists']	[]	694560	1348	0

Transaksi melibatkan pembacaan ke kolom Singers._exists tersembunyi untuk memeriksa keberadaan baris. Transaksi juga menulis ke kolom Singers.FirstName dan Singer.LastName. Informasi ini dapat membantu menentukan apakah mekanisme percobaan ulang transaksi yang diterapkan di library klien kustom Anda berfungsi seperti yang diharapkan.

Langkah berikutnya

• Pelajari alat Introspeksi lainnya.
• Pelajari informasi lain yang disimpan Spanner untuk setiap database di tabel skema informasi database.
• Pelajari lebih lanjut praktik terbaik SQL untuk Spanner.
• Pelajari lebih lanjut Menyelidiki penggunaan CPU yang tinggi.