Statistik pemisahan

Halaman ini menjelaskan cara mendeteksi dan men-debug hotspot di database Anda. Anda dapat mengakses statistik tentang hotspot dalam pemisahan dengan GoogleSQL dan PostgreSQL.

Spanner menyimpan data Anda sebagai ruang kunci yang berurutan, yang diurutkan berdasarkan kunci utama tabel dan indeks Anda. Pemisahan adalah rentang baris dari serangkaian tabel atau indeks. Awal pemisahan disebut awal pemisahan. Batas pemisahan menetapkan akhir pemisahan. Pemisahan mencakup awal pemisahan, tetapi tidak mencakup batas pemisahan.

Di Spanner, hotspot adalah situasi saat terlalu banyak permintaan dikirim ke server yang sama, yang memenuhi resource server dan berpotensi menyebabkan latensi tinggi. Pemisahan yang terpengaruh oleh hotspot dikenal sebagai pemisahan hot atau warm.

Statistik hotspot bagian (diidentifikasi dalam sistem sebagai CPU_USAGE_SCORE) adalah pengukuran beban pada bagian yang dibatasi oleh resource yang tersedia di server. Pengukuran ini diberikan sebagai persentase. Jika lebih dari 50% beban pada bagian dibatasi oleh resource yang tersedia, bagian tersebut dianggap warm. Jika 100% beban pada bagian dibatasi, bagian tersebut dianggap hot.

Spanner menggunakan pemisahan berbasis beban untuk mendistribusikan beban data secara merata di seluruh server instance. Pemisahan hangat dan panas dapat dipindahkan di seluruh server untuk load balancing atau dapat dipecah menjadi pemisahan yang lebih kecil. Namun, Spanner mungkin tidak dapat menyeimbangkan beban, bahkan setelah beberapa upaya pemisahan, karena anti-pola dalam aplikasi. Oleh karena itu, hotspot persisten yang berlangsung setidaknya 10 menit mungkin memerlukan pemecahan masalah lebih lanjut dan potensi perubahan aplikasi.

Statistik pemisahan panas Spanner membantu Anda mengidentifikasi pemisahan tempat hotspot terjadi. Kemudian, Anda dapat membuat perubahan pada aplikasi atau skema, sesuai kebutuhan. Anda dapat mengambil statistik ini dari tabel sistem SPANNER_SYS.SPLIT_STATS_TOP_MINUTE menggunakan pernyataan SQL.

Ketersediaan statistik pemisahan panas

Spanner menyediakan statistik pemisahan panas dalam skema SPANNER_SYS. Data SPANNER_SYS hanya tersedia melalui antarmuka GoogleSQL dan PostgreSQL. Anda dapat menggunakan cara berikut untuk mengakses data ini:

• Halaman Spanner Studio database di konsol Google Cloud
• Perintah gcloud spanner databases execute-sql
• executeQuery API

API pembacaan tunggal Spanner tidak mendukung SPANNER_SYS.

Statistik pemisahan panas

Anda menggunakan tabel berikut untuk melacak hot split:

• SPANNER_SYS.SPLIT_STATS_TOP_MINUTE: menampilkan bagian yang aktif selama interval 1 menit.

Tabel ini memiliki properti berikut:

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

• Interval didasarkan pada waktu jam:

  • Interval 1 menit berakhir pada menit.

• Setelah setiap interval, Spanner mengumpulkan data dari semua server, lalu menyediakan data tersebut di tabel SPANNER_SYS tidak lama kemudian.

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

  • 1 menit: 00.58.00-00.58.59

• Spanner mengelompokkan statistik menurut pemisahan.

• Setiap baris berisi persentase yang menunjukkan seberapa panas atau hangat pemisahan, untuk setiap pemisahan yang statistiknya diambil oleh Spanner selama interval yang ditentukan.

• Jika kurang dari 50% beban pada bagian dibatasi oleh resource yang tersedia, Spanner tidak akan mengambil statistik. Jika Spanner tidak dapat menyimpan semua bagian panas selama interval, sistem akan memprioritaskan bagian dengan persentase CPU_USAGE_SCORE tertinggi selama interval yang ditentukan. Jika tidak ada pemisahan yang ditampilkan, ini merupakan indikasi tidak adanya hotspot.

Skema tabel

Tabel berikut menunjukkan skema tabel untuk statistik berikut:

• SPANNER_SYS.SPLIT_STATS_TOP_MINUTE

Nama kolom	Jenis	Deskripsi
INTERVAL_END	TIMESTAMP	Akhir interval waktu saat pemisahan menjadi hot
SPLIT_START	STRING	Kunci awal rentang baris dalam pemisahan. Awal pemisahan juga dapat berupa <begin>, yang menunjukkan awal ruang kunci
SPLIT_LIMIT	STRING	Kunci batas untuk rentang baris dalam pemisahan. Batas: kunci juga dapat berupa <end>, yang menunjukkan akhir ruang kunci|
CPU_USAGE_SCORE	INT64	Persentase CPU_USAGE_SCORE pemisahan. Persentase CPU_USAGE_SCORE sebesar 50% menunjukkan adanya | split | hangat atau panas
AFFECTED_TABLES	STRING ARRAY	Tabel yang barisnya mungkin berada dalam pemisahan

Catatan: Pembagian dengan persentase CPU_USAGE_SCORE yang kurang dari 100% dapat digunakan untuk melacak tren dari waktu ke waktu. Spanner menggunakan pemisahan berbasis beban untuk menyeimbangkan beban di seluruh server sehingga Anda mungkin melihat pemisahan berubah atau menyusut dari waktu ke waktu. Namun, Spanner mungkin tidak dapat menyeimbangkan beban karena pola yang bermasalah dalam aplikasi dan pemisahan panas mungkin tetap ada setelah beberapa iterasi pemisahan berbasis beban Spanner. Oleh karena itu, adanya hot split selama lebih dari 10 menit adalah indikasi bahwa Anda mungkin perlu menyelidiki lebih lanjut.

Kunci batas pemisahan dan kunci pemisahan awal

Pemisahan adalah rentang baris yang berurutan dari database, dan ditentukan oleh kunci start dan limit. Pemisahan dapat berupa satu baris, rentang baris sempit, atau rentang baris lebar, dan pemisahan dapat mencakup beberapa tabel atau indeks.

Kolom SPLIT_START dan SPLIT_LIMIT mengidentifikasi kunci utama pemisahan hangat atau panas.

Contoh skema

Skema berikut adalah contoh tabel untuk topik di halaman ini.

GoogleSQL

CREATE TABLE Users (
  UserId INT64 NOT NULL,
  FirstName STRING(MAX),
  LastName STRING(MAX),
) PRIMARY KEY(UserId);

CREATE INDEX UsersByFirstName ON Users(FirstName DESC);

CREATE TABLE Threads (
  UserId INT64 NOT NULL,
  ThreadId INT64 NOT NULL,
  Starred BOOL,
) PRIMARY KEY(UserId, ThreadId),
  INTERLEAVE IN PARENT Users ON DELETE CASCADE;

CREATE TABLE Messages (
  UserId INT64 NOT NULL,
  ThreadId INT64 NOT NULL,
  MessageId INT64 NOT NULL,
  Subject STRING(MAX),
  Body STRING(MAX),
) PRIMARY KEY(UserId, ThreadId, MessageId),
  INTERLEAVE IN PARENT Threads ON DELETE CASCADE;

CREATE INDEX MessagesIdx ON Messages(UserId, ThreadId, Subject),
INTERLEAVE IN Threads;

PostgreSQL

CREATE TABLE users
(
   userid    BIGINT NOT NULL PRIMARY KEY,-- INT64 to BIGINT
   firstname VARCHAR(max),-- STRING(MAX) to VARCHAR(MAX)
   lastname  VARCHAR(max)
);

CREATE INDEX usersbyfirstname
  ON users(firstname DESC);

CREATE TABLE threads
  (
    userid   BIGINT NOT NULL,
    threadid BIGINT NOT NULL,
    starred  BOOLEAN, -- BOOL to BOOLEAN
    PRIMARY KEY (userid, threadid),
    CONSTRAINT fk_threads_user FOREIGN KEY (userid) REFERENCES users(userid) ON
    DELETE CASCADE -- Interleave to Foreign Key constraint
  );

CREATE TABLE messages
  (
    userid    BIGINT NOT NULL,
    threadid  BIGINT NOT NULL,
    messageid BIGINT NOT NULL PRIMARY KEY,
    subject   VARCHAR(max),
    body      VARCHAR(max),
    CONSTRAINT fk_messages_thread FOREIGN KEY (userid, threadid) REFERENCES
    threads(userid, threadid) ON DELETE CASCADE
  -- Interleave to Foreign Key constraint
  );

CREATE INDEX messagesidx ON messages(userid, threadid, subject), REFERENCES
threads(userid, threadid);

Bayangkan ruang kunci Anda terlihat seperti ini:

KUNCI UTAMA
<begin>
Users()
Threads()
Users(2)
Users(3)
Threads(3)
Threads(3,"a")
Messages(3,"a",1)
Messages(3,"a",2)
Threads(3, "aa")
Users(9)
Users(10)
Threads(10)
UsersByFirstName("abc")
UsersByFirstName("abcd")
<end>

Contoh pemisahan

Berikut adalah beberapa contoh pemisahan untuk membantu Anda memahami tampilan pemisahan.

SPLIT_START dan SPLIT_LIMIT dapat menunjukkan baris tabel atau indeks, atau dapat berupa <begin> dan <end>, yang mewakili batas ruang kunci database. SPLIT_START dan SPLIT_LIMIT mungkin juga berisi kunci yang terpotong, yaitu kunci yang mendahului kunci lengkap apa pun dalam tabel. Misalnya, Threads(10) adalah awalan untuk baris Threads yang diselingi di Users(10).

SPLIT_START	SPLIT_LIMIT	AFFECTED_TABLES	PENJELASAN
Users(3)	Users(10)	UsersByFirstName, Users, Threads, Messages, MessagesIdx	Pemisahan dimulai pada baris dengan UserId=3 dan berakhir pada baris sebelum baris dengan UserId = 10. Pemisahan berisi baris tabel Users dan semua baris tabel yang diselingi untuk UserId=3 hingga 10.
Messages(3,"a",1)	Threads(3,"aa")	Threads, Messages, MessagesIdx	Pemisahan dimulai pada baris dengan UserId=3, ThreadId="a", dan MessageId=1, serta berakhir pada baris sebelum baris dengan kunci UserId=3 dan ThreadsId = "aa". Pemisahan berisi semua tabel antara Messages(3,"a",1) dan Threads(3,"aa"). Karena split_start dan split_limit diselingi di baris tabel tingkat atas yang sama, pemisahan berisi baris tabel yang diselingi antara awal dan batas. Lihat ringkasan-skema untuk memahami cara tabel sisipan ditempatkan bersama.
Messages(3,"a",1)	<end>	UsersByFirstName, Users, Threads, Messages, MessagesIdx	Pemisahan dimulai di tabel pesan pada baris dengan kunci UserId=3, ThreadId="a", dan MessageId=1. Pemisahan menghosting semua baris dari split_start hingga <end>, akhir ruang kunci database. Semua baris tabel yang mengikuti split_start, seperti Users(4), disertakan dalam pemisahan.
<begin>	Users(9)	UsersByFirstName, Users, Threads, Messages, MessagesIdx	Pemisahan dimulai di <begin>, awal ruang kunci database, dan berakhir di baris sebelum baris Users dengan UserId=9. Jadi, pemisahan memiliki semua baris tabel sebelum Users dan semua baris tabel Users sebelum UserId=9 serta baris tabel sisipannya.
Messages(3,"a",1)	Threads(10)	UsersByFirstName, Users, Threads, Messages, MessagesIdx	Pemisahan dimulai pada Messages(3,"a", 1) yang diselingi di Users(3) dan berakhir pada baris sebelum Threads(10). Threads(10) adalah kunci pemisahan yang terpotong yang merupakan awalan dari kunci tabel Thread yang diselingi di Users(10).
Users()	<end>	UsersByFirstName, Users, Threads, Messages, MessagesIdx	Pemisahan dimulai pada kunci pemisahan Users() yang terpotong yang mendahului kunci lengkap tabel Users. Pemisahan ini diperluas hingga akhir kemungkinan ruang kunci dalam database. Oleh karena itu, affected_tables mencakup tabel Users, tabel dan indeks interleave-nya, serta semua tabel yang mungkin muncul setelah pengguna.
Threads(10)	UsersByFirstName("abc")	UsersByFirstName, Users, Threads, Messages, MessagesIdx	Pemisahan dimulai pada baris Threads dengan UserId = 10 dan berakhir pada indeks, UsersByFirstName pada kunci yang mendahului "abc".

Catatan: SPLIT_LIMIT lebih besar dari SPLIT_START. Namun, perbandingan leksikal dari awal dan batas pemisahan mungkin tidak berfungsi di seluruh pemisahan.

Contoh kueri untuk menemukan hot split

Contoh berikut menunjukkan pernyataan SQL yang dapat Anda gunakan untuk mengambil statistik pemisahan panas. Anda dapat menjalankan pernyataan SQL ini menggunakan library klien, gcloud, atau konsol Google Cloud.

GoogleSQL

SELECT t.split_start,
       t.split_limit,
       t.cpu_usage_score,
       t.affected_tables,
FROM   SPANNER_SYS.SPLIT_STATS_TOP_MINUTE t
WHERE  t.interval_end =
  (SELECT MAX(interval_end)
  FROM    SPANNER_SYS.SPLIT_STATS_TOP_MINUTE)
ORDER BY  t.cpu_usage_score DESC;

PostgreSQL

SELECT t.split_start,
       t.split_limit,
       t.cpu_usage_score,
       t.affected_tables
FROM   SPANNER_SYS.SPLIT_STATS_TOP_MINUTE t
WHERE  t.interval_end = (
  SELECT MAX(interval_end)
  FROM   SPANNER_SYS.SPLIT_STATS_TOP_MINUTE
)
ORDER BY t.cpu_usage_score DESC;

Output kueri terlihat seperti berikut:

SPLIT_START	SPLIT_LIMIT	CPU_USAGE_SCORE	AFFECTED_TABLES
Users(13)	Users(76)	82	Messages,Users,Threads
Users(101)	Users(102)	90	Messages,Users,Threads
Threads(10, "a")	Threads(10, "aa")	100	Messages,Threads
Messages(631, "abc", 1)	Messages(631, "abc", 3)	100	Messages
Threads(12, "zebra")	Users(14)	76	Messages,Users,Threads
Users(620)	<end>	100	Messages,Users,Threads

Retensi data untuk statistik hot split

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

• SPANNER_SYS.SPLIT_STATS_TOP_MINUTE: Interval yang mencakup 6 jam sebelumnya.

Catatan: Anda tidak dapat mencegah Spanner mengumpulkan statistik pemisahan panas. Untuk menghapus data dalam tabel ini, Anda harus menghapus database yang terkait dengan tabel atau menunggu hingga Spanner menghapus data secara otomatis. Periode retensi untuk tabel ini bersifat tetap. Jika Anda ingin menyimpan statistik untuk jangka waktu yang lebih lama, sebaiknya salin data dari tabel ini secara berkala.

Memecahkan masalah hotspot menggunakan statistik hot split

Bagian ini menjelaskan cara mendeteksi dan memecahkan masalah hotspot.

Memilih jangka waktu untuk diselidiki

Periksa metrik latensi untuk database Spanner Anda guna menemukan jangka waktu saat aplikasi Anda mengalami latensi dan penggunaan CPU yang tinggi. Misalnya, laporan ini mungkin menunjukkan bahwa masalah dimulai sekitar pukul 22.50 pada 18 Mei 2024.

Menemukan hotspot persisten

Karena Spanner menyeimbangkan beban Anda dengan pemisahan berbasis beban, sebaiknya Anda menyelidiki apakah hotspotting telah berlanjut selama lebih dari 10 menit. Anda dapat melakukannya dengan membuat kueri tabel SPANNER_SYS.SPLIT_STATS_TOP_MINUTE, seperti yang ditunjukkan dalam contoh berikut:

GoogleSQL

SELECT Count(DISTINCT t.interval_end)
FROM   SPANNER_SYS.SPLIT_STATS_TOP_MINUTE t
WHERE  t.utilization >= 50
  AND  t.interval_end >= "interval_end_date_time"
  AND  t.interval_end <= "interval_end_date_time";

Ganti interval_end_date_time dengan tanggal dan waktu untuk interval, menggunakan format 2024-05-18T17:40:00Z.

PostgreSQL

SELECT COUNT(DISTINCT t.interval_end)
FROM   SPLIT_STATS_TOP_MINUTE t
WHERE  t.utilization >= 50
  AND  t.interval_end >= 'interval_end_date_time'::timestamptz
  AND  t.interval_end <= 'interval_end_date_time'::timestamptz;

Ganti interval_end_date_time dengan tanggal dan waktu untuk interval, menggunakan format 2024-05-18T17:40:00Z.

Jika hasil kueri sebelumnya sama dengan 10, artinya database Anda mengalami hotspotting yang mungkin memerlukan proses debug lebih lanjut.

Menemukan pemisahan dengan level CPU_USAGE_SCORE tertinggi

Untuk contoh ini, kita menjalankan SQL berikut untuk menemukan rentang baris dengan tingkat CPU_USAGE_SCORE tertinggi:

GoogleSQL

SELECT t.split_start,
       t.split_limit,
       t.affected_tables,
       t.cpu_usage_score
FROM   SPANNER_SYS.SPLIT_STATS_TOP_MINUTE t
WHERE  t.cpu_usage_score >= 50
  AND  t.interval_end = "interval_end_date_time";

Ganti interval_end_date_time dengan tanggal dan waktu untuk interval, menggunakan format 2024-05-18T17:40:00Z.

PostgreSQL

SELECT t.split_start,
       t.split_limit,
       t.affected_tables,
       t.cpu_usage_score
FROM   SPLIT_STATS_TOP_MINUTE t
WHERE  t.cpu_usage_score = 100
  AND  t.interval_end = 'interval_end_date_time'::timestamptz;

Ganti interval_end_date_time dengan tanggal dan waktu untuk interval, menggunakan format 2024-05-18T17:40:00Z.

SQL sebelumnya menghasilkan output berikut:

SPLIT_START	SPLIT_LIMIT	CPU_USAGE_SCORE	AFFECTED_TABLES
Users(180)	<end>	85	Messages,Users,Threads
Users(24)	Users(76)	76	Messages,Users,Threads

Dari tabel hasil ini, kita dapat melihat bahwa hotspot terjadi pada dua bagian. Pembagian berbasis beban Spanner mungkin mencoba menyelesaikan hotspot pada pemisahan ini. Namun, hal ini mungkin tidak dapat dilakukan jika ada pola yang bermasalah dalam skema atau beban kerja. Untuk mendeteksi apakah ada pemisahan yang memerlukan intervensi Anda, sebaiknya lacak pemisahan selama minimal 10 menit. Misalnya, SQL berikut melacak bagian pertama selama sepuluh menit terakhir.

GoogleSQL

SELECT t.interval_end,
       t.split_start,
       t.split_limit,
       t.cpu_usage_score
FROM   SPANNER_SYS.SPLIT_STATS_TOP_MINUTE t
WHERE  t.split_start = "users(180)"
  AND  t.split_limit = "<end>"
  AND  t.interval_end >= "interval_end_date_time"
  AND  t.interval_end <= "interval_end_date_time";

Ganti interval_end_date_time dengan tanggal dan waktu untuk interval, menggunakan format 2024-05-18T17:40:00Z.

PostgreSQL

SELECT t.interval_end,
       t.split_start,
       t.split_limit,
       t.cpu_usage_score
FROM   SPANNER_SYS.SPLIT_STATS_TOP_MINUTE t
WHERE  t.split_start = 'users(180)'
  AND  t.split_limit = ''
  AND  t.interval_end >= 'interval_end_date_time'::timestamptz
  AND  t.interval_end <= 'interval_end_date_time'::timestamptz;

Ganti interval_end_date_time dengan tanggal dan waktu untuk interval, menggunakan format 2024-05-18T17:40:00Z.

SQL sebelumnya menghasilkan output berikut:

INTERVAL_END	SPLIT_START	SPLIT_LIMIT	CPU_USAGE_SCORE
2024-05-18T17:46:00Z	Users(180)	<end>	85
2024-05-18T17:47:00Z	Users(180)	<end>	85
2024-05-18T17:48:00Z	Users(180)	<end>	85
2024-05-18T17:49:00Z	Users(180)	<end>	85
2024-05-18T17:50:00Z	Users(180)	<end>	85

Pemisahan tampaknya telah menjadi hot topic selama beberapa menit terakhir. Anda dapat mengamati pemisahan selama lebih lama untuk menentukan bahwa pemisahan berbasis beban Spanner mengurangi hotspot. Mungkin ada kasus saat Spanner tidak dapat melakukan load balancing lebih lanjut.

Misalnya, buat kueri tabel SPANNER_SYS.SPLIT_STATS_TOP_MINUTE. Lihat contoh skenario berikut.

GoogleSQL

SELECT t.interval_end,
      t.split_start,
      t.split_limit,
      t.cpu_usage_score
FROM  SPANNER_SYS.SPLIT_STATS_TOP_MINUTE t
WHERE t.interval_end >= "interval_end_date_time"
      AND t.interval_end <= "interval_end_date_time";

Ganti interval_end_date_time dengan tanggal dan waktu untuk interval, menggunakan format 2024-05-18T17:40:00Z.

PostgreSQL

SELECT t.interval_end,
       t.split_start,
       t.split_limit,
       t._cpu_usage
FROM   SPANNER_SYS.SPLIT_STATS_TOP_MINUTE t
WHERE  t.interval_end >= 'interval_end_date_time'::timestamptz
  AND  t.interval_end <= 'interval_end_date_time'::timestamptz;

Ganti interval_end_date_time dengan tanggal dan waktu untuk interval, menggunakan format 2024-05-18T17:40:00Z.

Satu baris panas

Pada contoh berikut, sepertinya Threads(10,"spanner") berada dalam pemisahan baris tunggal yang tetap aktif selama lebih dari 10 menit. Hal ini dapat terjadi jika ada beban persisten pada baris populer.

INTERVAL_END	SPLIT_START	SPLIT_LIMIT	CPU_USAGE_SCORE
2024-05-16T20:40:00Z	Threads(10,"spanner")	Threads(10,"spanner1")	62
2024-05-16T20:41:00Z	Threads(10,"spanner")	Threads(10,"spanner1")	62
2024-05-16T20:42:00Z	Threads(10,"spanner")	Threads(10,"spanner1")	62
2024-05-16T20:43:00Z	Threads(10,"spanner")	Threads(10,"spanner1")	62
2024-05-16T20:44:00Z	Threads(10,"spanner")	Threads(10,"spanner1")	62
2024-05-16T20:45:00Z	Threads(10,"spanner")	Threads(10,"spanner1")	62
2024-05-16T20:46:00Z	Threads(10,"spanner")	Threads(10,"spanner1")	80
2024-05-16T20:47:00Z	Threads(10,"spanner")	Threads(10,"spanner1")	80
2024-05-16T20:48:00Z	Threads(10,"spanner")	Threads(10,"spanner1")	80
2024-05-16T20:49:00Z	Threads(10,"spanner")	Threads(10,"spanner1")	100
2024-05-16T20:50:00Z	Threads(10,"spanner")	Threads(10,"spanner1")	100

Spanner tidak dapat menyeimbangkan beban untuk satu kunci ini karena tidak dapat dibagi lebih lanjut.

Memindahkan hotspot

Pada contoh berikut, beban berpindah melalui bagian yang berdekatan dari waktu ke waktu, berpindah ke bagian baru di seluruh interval waktu.

INTERVAL_END	SPLIT_START	SPLIT_LIMIT	CPU_USAGE_SCORE
2024-05-16T20:40:00Z	Threads(1,"a")	Threads(1,"aa")	100
2024-05-16T20:41:00Z	Threads(1,"aa")	Threads(1,"ab")	100
2024-05-16T20:42:00Z	Threads(1,"ab")	Threads(1,"c")	100
2024-05-16T20:43:00Z	Threads(1,"c")	Threads(1,"ca")	100

Hal ini dapat terjadi, misalnya, karena beban kerja yang membaca atau menulis kunci dalam urutan yang meningkat secara monoton. Spanner tidak dapat menyeimbangkan beban untuk memitigasi efek perilaku aplikasi ini.

Load balancing normal

Spanner mencoba menyeimbangkan beban dengan menambahkan lebih banyak bagian atau memindahkan bagian. Contoh berikut menunjukkan tampilannya.

INTERVAL_END	SPLIT_START	SPLIT_LIMIT	CPU_USAGE_SCORE
2024-05-16T20:40:00Z	Threads(1000,"zebra")	<end>	82
2024-05-16T20:41:00Z	Threads(1000,"zebra")	<end>	90
2024-05-16T20:42:00Z	Threads(1000,"zebra")	<end>	100
2024-05-16T20:43:00Z	Threads(1000,"zebra")	Threads(2000,"spanner")	100
2024-05-16T20:44:00Z	Threads(1200,"c")	Threads(2000)	92
2024-05-16T20:45:00Z	Threads(1500,"c")	Threads(1700,"zach")	76
2024-05-16T20:46:00Z	Threads(1700)	Threads(1700,"c")	76
2024-05-16T20:47:00Z	Threads(1700)	Threads(1700,"c")	50
2024-05-16T20:48:00Z	Threads(1700)	Threads(1700,"c")	39

Di sini, bagian yang lebih besar pada 2024-05-16T17:40:00Z dibagi lebih lanjut menjadi bagian yang lebih kecil dan sebagai hasilnya, statistik CPU_USAGE_SCORE menurun. Spanner mungkin tidak membuat pemisahan ke dalam setiap baris. Pemisahan ini mencerminkan beban kerja yang menyebabkan statistik CPU_USAGE_SCORE tinggi.

Jika Anda telah mengamati hot split persisten selama lebih dari 10 menit, lihat Praktik terbaik untuk mengurangi hotspot.

Praktik terbaik untuk mengurangi hotspot

Catatan: Jika beban Anda meningkat dan baru-baru ini Anda melakukan penskalaan instance, Spanner mungkin memerlukan waktu beberapa menit untuk melakukan operasi load balancing sebelum latensi Anda menurun.

Jika load balancing tidak mengurangi latensi, langkah berikutnya adalah mengidentifikasi penyebab hotspot. Setelah itu, opsi yang tersedia adalah mengurangi beban kerja hotspotting, atau mengoptimalkan skema dan logika aplikasi untuk menghindari hotspot.

Mengidentifikasi penyebabnya

• Gunakan Insight Transaksi & Kunci untuk mencari transaksi yang memiliki waktu tunggu kunci yang tinggi dengan kunci awal rentang baris berada dalam pemisahan panas.

• Gunakan Query Insights untuk mencari kueri yang membaca dari tabel yang berisi hot split, dan baru-baru ini meningkatkan latensi, atau rasio latensi yang lebih tinggi ke CPU.

• Gunakan Kueri Aktif Terlama untuk mencari kueri yang dibaca dari tabel yang berisi pemisahan panas, dan yang memiliki latensi lebih tinggi dari yang diharapkan.

Beberapa kasus khusus yang perlu diperhatikan:

• Periksa apakah time to live (TTL) baru-baru ini diaktifkan. Jika ada banyak pemisahan dari data lama, TTL dapat menaikkan level CPU_USAGE_SCORE selama penghapusan massal. Dalam hal ini, masalah akan teratasi dengan sendirinya setelah penghapusan awal selesai.

Mengoptimalkan beban kerja

• Ikuti praktik terbaik SQL. Pertimbangkan operasi baca yang sudah tidak berlaku, operasi tulis yang tidak melakukan operasi baca terlebih dahulu, atau menambahkan indeks.
• Ikuti Praktik terbaik skema. Pastikan skema Anda dirancang untuk menangani load balancing dan menghindari hotspot.

Langkah selanjutnya

• Pelajari praktik terbaik desain skema.
• Pelajari Key Visualizer.
• Lihat contoh desain skema.
• Pelajari cara menggunakan dasbor analisis pemisahan untuk mendeteksi hotspot14