Statistik transaksi

Spanner menyediakan tabel bawaan yang menyimpan statistik tentang transaksi. 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 mungkin 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 pembaruan pada kolom tertentu, yang mungkin memengaruhi latensi.

Mengakses statistik transaksi

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 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 digabungkan 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 digabungkan di seluruh interval 1 jam.

Tabel ini 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-60, interval 10 menit berakhir setiap 10 menit yang dimulai pada jam ke-60, dan interval 1 jam berakhir pada jam ke-60.

  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 AM
  • 1 jam: 10.00.00–10.59.59

• Spanner mengelompokkan statistik menurut FPRINT (Sidik Jari) transaksi. Jika tag transaksi ada, FPRINT adalah hash tag. Jika tidak, ini 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, kita tetap hanya melihat satu entri 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 penerapan, dan byte yang ditulis tertinggi selama interval yang ditentukan.

• Semua kolom dalam tabel dapat bernilai null.

Skema tabel

¹ _exists adalah kolom internal yang digunakan untuk memeriksa apakah baris tertentu ada atau tidak.

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 Google Cloud console.

Mencantumkan statistik dasar untuk setiap transaksi dalam jangka waktu tertentu

Kueri berikut menampilkan data mentah untuk transaksi teratas dalam 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

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

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

Mencantumkan transaksi berdasarkan jumlah rata-rata byte yang diubah

Kueri berikut menampilkan transaksi yang diambil sampelnya dalam satu jam terakhir, yang 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

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 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 AM
  • 1 jam: 10.00.00–10.59.59

• 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 melakukan commit
  • Jumlah percobaan ulang commit
  • Peserta transaksi
  • Latensi transaksi
  • Byte yang ditulis

  Untuk mengetahui informasi selengkapnya, lihat Metrik Spanner.

Skema 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 Google Cloud console.

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

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

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 latensi persentil ke-99 untuk transaksi yang dijalankan dalam 10 menit sebelumnya:

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;

Output kueri

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 jangka 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.

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 pada kolom tertentu. Dengan menggunakan langkah-langkah berikut, kami akan menunjukkan cara menggunakan statistik transaksi untuk menyelidiki pertentangan dalam database Anda.

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 transaksi tersebut 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 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/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 skenario yang berbeda.

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 bucket yang berbeda. Akibatnya, dalam interval waktu tertentu, pembatalan dan percobaan ulang mungkin tidak sama.

Statistik ini dirancang untuk pemecahan masalah dan introspeksi dan 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

Hal ini dapat ditemukan dari aplikasi yang menggunakan Spanner.

Untuk tujuan latihan ini, anggap saja 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 penyelidikan, kita akan membuat kueri tabel TXN_STATS_TOTAL_10MINUTE di sekitar awal terjadinya masalah. Hasil kueri ini akan menunjukkan kepada kita 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 kita.

Di sini kita melihat bahwa latensi gabungan dan jumlah pembatalan lebih tinggi pada periode yang ditandai. Kita dapat memilih interval 10 menit mana pun saat latensi gabungan dan/atau jumlah pembatalan tinggi. Pilih interval yang berakhir pada 2020-05-17T18:40:00 dan gunakan pada langkah berikutnya untuk mengidentifikasi transaksi mana yang berkontribusi pada latensi tinggi dan jumlah pembatalan.

Mengidentifikasi transaksi yang mengalami latensi tinggi

Sekarang, buat kueri tabel TXN_STATS_TOP_10MINUTE untuk interval yang dipilih pada langkah sebelumnya. Dengan menggunakan data ini, kita dapat mulai mengidentifikasi transaksi mana yang mengalami latensi tinggi dan/atau jumlah pembatalan tinggi.

Jalankan kueri berikut untuk mendapatkan transaksi yang paling memengaruhi performa dalam urutan menurun dari total latensi untuk interval contoh 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;

Kita dapat melihat dengan jelas bahwa baris pertama (ditandai) dalam tabel sebelumnya menunjukkan transaksi yang mengalami latensi tinggi karena banyaknya pembatalan commit. Kita juga dapat melihat jumlah percobaan ulang commit yang tinggi yang menunjukkan bahwa commit yang dibatalkan kemudian dicoba ulang. Pada langkah berikutnya, kita akan menyelidiki lebih lanjut untuk melihat penyebab masalah ini.

Mengidentifikasi kolom yang terlibat dalam transaksi yang mengalami latensi tinggi

Pada langkah ini, kita akan memeriksa 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 pada 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;

Seperti yang ditunjukkan output dalam tabel sebelumnya, transaksi dengan total latensi rata-rata tertinggi membaca kolom yang sama. Kita juga dapat mengamati beberapa persaingan penulisan karena transaksi menulis ke kolom yang sama, yaitu TestHigherLatency._exists.

Menentukan bagaimana performa transaksi telah berubah dari waktu ke waktu

Kita dapat melihat bagaimana statistik yang terkait dengan bentuk transaksi ini telah berubah 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;

Dalam output di atas, kita dapat mengamati 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, kita melihat bahwa jumlah pembatalan commit yang tinggi adalah 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, kita melihat bahwa aplikasi sebenarnya 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 penguncian 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;

Kita dapat melihat bahwa 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;

Kita dapat melihat bahwa transaksi melibatkan pembacaan ke kolom tersembunyi Singers._exists 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.