Statistik pemisahan

Dokumen 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 berdekatan, yang diurutkan berdasarkan kunci utama tabel dan indeks Anda. Pemisahan adalah rentang baris dari sekumpulan 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 ketika terlalu banyak permintaan dikirim ke server yang sama, yang membebani resource server dan berpotensi menyebabkan latensi tinggi. Pemisahan yang terpengaruh oleh hotspot dikenal sebagai pemisahan panas atau hangat.

Statistik hotspot pemisahan (diidentifikasi dalam sistem sebagai CPU_USAGE_SCORE) adalah pengukuran beban pada pemisahan yang dibatasi oleh resource yang tersedia di server. Pengukuran ini diberikan sebagai persentase. Jika lebih dari 50% beban pada pemisahan dibatasi oleh resource yang tersedia, maka pemisahan dianggap hangat. Jika 100% beban pada pemisahan dibatasi, maka pemisahan dianggap panas. Pemisahan panas tersebut juga dapat memengaruhi latensi permintaan yang ditayangkan olehnya.

CPU_USAGE_SCORE pemisahan dapat tetap konstan atau bervariasi dari waktu ke waktu berdasarkan workload yang mengakses pemisahan dan perubahan pada batas pemisahan.

Berdasarkan batasan resource pemisahan hangat dan panas, Spanner dapat menggunakan pemisahan berbasis bebanuntuk mendistribusikan beban secara merata di seluruh ruang kunci. Pemisahan hangat dan panas dapat dipindahkan di seluruh server instance untuk load balancing. Spanner melakukan pemisahan berbasis beban di latar belakang, sehingga meminimalkan dampak pada latensi. Namun, Spanner mungkin tidak dapat menyeimbangkan beban, bahkan setelah beberapa kali upaya pemisahan, karena anti-pola dalam aplikasi. Kolom UNSPLITTABLE_REASONS dalam tampilan statistik memberikan alasan spesifik mengapa pemisahan panas atau hangat tidak dapat dibagi lebih lanjut. Oleh karena itu, pemisahan hangat atau panas persisten yang berlangsung setidaknya 10 menit mungkin memerlukan pemecahan masalah lebih lanjut dan potensi perubahan aplikasi, terutama jika UNSPLITTABLE_REASONS ada.

Statistik pemisahan aktif Spanner membantu Anda mengidentifikasi pemisahan tempat terjadinya hotspot dan memahami alasan hotspot tersebut dapat berlanjut. Statistik ini, bersama dengan kode UNSPLITTABLE_REASONS, dapat membantu Anda mendiagnosis tindakan yang perlu Anda lakukan untuk mengatasi area bermasalah. Kemudian, Anda dapat membuat perubahan pada aplikasi atau skema sesuai kebutuhan.

Cara mengakses statistik pemisahan dinamis

Spanner menyediakan statistik pemisahan aktif dalam skema SPANNER_SYS. Data SPANNER_SYS tersedia melalui antarmuka GoogleSQL dan PostgreSQL. Anda dapat mengakses data ini dengan cara berikut:

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 pemisahan panas

Anda menggunakan tampilan berikut untuk melacak pemisahan panas:

  • SPANNER_SYS.SPLIT_STATS_TOP_MINUTE: menampilkan pemisahan yang populer selama interval 1 menit.
  • SPANNER_SYS.SPLIT_STATS_TOP_10MINUTE: menampilkan pemisahan yang populer selama bagian mana pun dalam interval 10 menit.
  • SPANNER_SYS.SPLIT_STATS_TOP_HOUR: menampilkan pemisahan yang populer selama bagian mana pun dalam interval 1 jam.

Tampilan ini memiliki properti berikut:

  • Setiap tampilan berisi data untuk interval waktu yang tidak tumpang-tindih dengan durasi yang ditentukan oleh nama tampilan.
  • Interval didasarkan pada waktu jam:
    • Interval 1 menit berakhir pada menit ke-0.
    • Interval 10 menit berakhir pada menit ke-10 setiap jam, misalnya, 11.10.00, 11.20.00.
    • Interval 1 jam berakhir pada jam tersebut.
  • Setelah setiap interval, Spanner mengumpulkan data dari semua server, lalu menyediakan data tersebut di tampilan SPANNER_SYS tidak lama setelahnya. Misalnya, pada pukul 11.59.30, interval terbaru yang tersedia untuk kueri SQL adalah:
    • 1 menit: 11.58.00-11.58.59
    • 10 menit: 11.40.00-11.49.59 AM
    • 1 jam: 10.00.00-10.59.59 AM
  • Spanner mengelompokkan statistik berdasarkan pemisahan.
  • Setiap baris berisi statistik, termasuk persentase CPU_USAGE_SCORE yang menunjukkan seberapa besar atau kecil pemisahan, untuk setiap pemisahan yang statistiknya diambil oleh Spanner selama interval yang ditentukan.
  • Tampilan SPANNER_SYS.SPLIT_STATS_TOP_MINUTE menawarkan statistik perincian terperinci untuk setiap menit. Gunakan tampilan ini untuk melakukan proses debug mendetail pada peristiwa terbaru.
  • Tampilan SPANNER_SYS.SPLIT_STATS_TOP_10MINUTE dan SPANNER_SYS.SPLIT_STATS_TOP_HOUR memberikan tampilan gabungan dalam interval 10 menit dan jam. Gunakan tampilan ini untuk analisis tren atau menyelidiki masalah selama beberapa hari atau minggu terakhir. Untuk mengetahui informasi selengkapnya tentang agregasi, lihat Melihat agregasi peristiwa.
  • Jika Spanner tidak dapat menyimpan semua pemisahan aktif selama interval, sistem akan memprioritaskan pemisahan dengan persentase CPU_USAGE_SCORE tertinggi selama interval yang ditentukan. Jika tidak ada pemisahan yang ditampilkan, ini menunjukkan tidak adanya pemisahan yang populer.

Retensi data

Jumlah maksimum data yang dipertahankan Spanner untuk setiap tampilan, kapan saja, adalah sebagai berikut:

  • SPANNER_SYS.SPLIT_STATS_TOP_MINUTE: interval yang mencakup 24 jam sebelumnya.
  • SPANNER_SYS.SPLIT_STATS_TOP_10MINUTE: interval yang mencakup 4 hari sebelumnya.
  • SPANNER_SYS.SPLIT_STATS_TOP_HOUR: interval yang mencakup 30 hari sebelumnya.

Periode retensi ini tidak dapat ditingkatkan atau diturunkan, dan Anda tidak dapat mencegah Spanner mengumpulkan statistik pemisahan aktif.

  • Untuk menghapus data statistik, Anda harus menghapus database yang dilacak atau menunggu hingga data statistik tidak lagi disimpan.
  • Untuk menyimpan data statistik dalam jangka waktu yang lebih lama, salin data secara berkala dari tampilan statistik pemisahan aktif.

Melihat skema

Tabel berikut menunjukkan skema untuk statistik pemisahan aktif:

Nama kolom Jenis Deskripsi
INTERVAL_END TIMESTAMP Akhir interval waktu saat pemisahan bersifat hangat atau panas.
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. Kunci batas juga dapat berupa <end>, yang menunjukkan akhir ruang kunci.
CPU_USAGE_SCORE INT64 Persentase CPU_USAGE_SCORE dari pemisahan. Persentase A CPU_USAGE_SCORE sebesar 50% menunjukkan adanya pemisahan hangat atau panas.
AFFECTED_TABLES STRING ARRAY Tabel yang barisnya mungkin ada dalam pemisahan.
UNSPLITTABLE_REASONS STRING ARRAY Mengidentifikasi jenis hotspot yang ada yang tidak dapat dimitigasi oleh pemisahan berbasis beban, sering kali karena anti-pola. Adanya alasan apa pun menunjukkan bahwa intervensi pengguna, seperti penyesuaian skema atau beban kerja, kemungkinan diperlukan. Array kosong berarti tidak ada kondisi yang tidak dapat dibagi yang terdeteksi selama interval ini atau beban tinggi terlalu singkat sehingga Spanner tidak dapat menentukan apakah kondisi tersebut tidak dapat dibagi. Lihat Jenis UNSPLITTABLE_REASONS untuk mengetahui detail selengkapnya.

Kunci awal dan kunci batas pemisahan

Pemisahan adalah rentang baris yang berdekatan 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 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 merepresentasikan batas ruang kunci database. SPLIT_START dan SPLIT_LIMIT juga dapat berisi kunci yang dipangkas, yaitu kunci yang mendahului kunci lengkap dalam tabel. Misalnya, Threads(10) adalah awalan untuk setiap baris Threads yang disisipkan dalam 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 disisipkan 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, lalu berakhir pada baris sebelum baris dengan kunci UserId=3 dan ThreadsId = "aa". Pemisahan ini berisi semua tabel antara Messages(3,"a",1) dan Threads(3,"aa"). Karena split_start dan split_limit disisipkan dalam baris tabel tingkat teratas yang sama, pemisahan berisi baris tabel yang disisipkan antara awal dan batas. Lihat schemas-overview 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. Bagian ini 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 yang disisipkan.
Messages(3,"a",1) Threads(10) UsersByFirstName, Users, Threads, Messages, MessagesIdx Pemisahan dimulai pada Messages(3,"a", 1) yang disisipkan di Users(3) dan berakhir pada baris sebelum Threads(10). Threads(10) adalah kunci pemisahan yang dipangkas yang merupakan awalan dari kunci tabel Threads yang disisipkan dalam Users(10).
Users() <end> UsersByFirstName, Users, Threads, Messages, MessagesIdx Pemisahan dimulai pada kunci pemisahan yang dipangkas dari Users() yang mendahului kunci penuh dari tabel Users. Pemisahan diperluas hingga akhir kemungkinan ruang kunci dalam database. Oleh karena itu, affected_tables mencakup tabel Users, tabel dan indeks yang disisipkan, 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".

Jenis UNSPLITTABLE_REASONS

Jika Spanner tidak dapat mengurangi hotspot melalui pemisahan berbasis beban, kolom UNSPLITTABLE_REASONS dalam tampilan SPLIT_STATS_TOP_* mengutip satu atau beberapa alasan berikut:

HOT_ROW

Deskripsi: Beban tinggi terkonsentrasi pada satu baris. Spanner tidak dapat menambahkan titik pemisahan dalam satu baris.

Penyebab Umum:

  • Operasi bervolume tinggi yang sering (pembacaan, penulisan, atau pembaruan) pada satu kunci.
  • Desain skema yang memusatkan akses ke satu baris.

Strategi Mitigasi:

  • Mengurangi QPS ke pemisahan panas.
  • Mendesain ulang skema untuk mendistribusikan beban. Misalnya, penghitung shard di beberapa baris.
  • Tinjau Praktik terbaik desain skema.

MOVING_HOT_SPOT

Deskripsi: Rentang kunci yang mengalami beban tinggi berubah seiring waktu, sering kali secara berurutan. Pemisahan berbasis beban tidak efektif karena hotspot dipindahkan sebelum Spanner dapat memisahkan rentang yang sebelumnya terpengaruh.

Penyebab Umum:

  • Penyisipan dengan bagian kunci utama yang meningkat atau menurun secara monoton, seperti stempel waktu commit.
  • Pembacaan titik berurutan di seluruh keyspace tabel.

Strategi Mitigasi:

  • Hindari kunci yang meningkat atau menurun secara monoton untuk bagian pertama kunci primer dalam beban kerja yang intensif penulisan. Untuk mengetahui strategi mitigasi yang mendetail, lihat Praktik terbaik desain skema. Tekniknya mencakup penggunaan UUID atau menambahkan hash kunci di depannya.

LARGE_SCAN_HOT_SPOT

Deskripsi: Pemisahan mengalami beban tinggi karena operasi yang sering atau intensif resource yang memindai rentang kunci. Hal ini dapat mencakup pembacaan rentang (termasuk pembacaan yang dikeluarkan sebagai bagian dari transaksi) atau kueri. Spanner menahan diri untuk tidak membagi rentang yang tercakup oleh operasi tersebut secara berlebihan untuk menghindari potensi penurunan performa untuk pemindaian ini, yang dapat terjadi jika data menjadi terlalu terfragmentasi di banyak pemisahan kecil.

Penyebab Umum:

  • Kueri atau operasi baca yang menjalankan pemindaian rentang luas pada data yang sering diakses.
  • Pernyataan DML (UPDATE, DELETE) dengan klausa WHERE yang memerlukan pemindaian rentang.
  • Tidak adanya indeks yang sesuai, sehingga menyebabkan pemindaian tabel dasar.

Strategi Mitigasi:

  • Mengoptimalkan pernyataan SQL (SELECT, UPDATE, DELETE) untuk mengurangi jumlah baris yang dipindai.
  • Buat indeks yang sesuai untuk mendukung predikat kueri dan DML umum, serta meminimalkan jumlah baris yang dipindai.

UNISOLATABLE_HOT_ROW

Deskripsi: Spanner mengidentifikasi kunci beban tinggi yang sempit, tetapi tidak dapat mengisolasinya dengan menyisipkan titik pemisahan baru, karena tidak tersedianya titik pemisahan yang sesuai. Kasus ini mirip dengan HOT_ROW, tetapi SPLIT_START dan SPLIT_LIMIT tidak sepenuhnya mengisolasi hotspot.

Penyebab Umum:

  • Pemuatan lokal yang intens pada satu baris atau baris yang berdekatan yang berbagi awalan kunci.

Strategi Mitigasi:

  • Menganalisis pola akses aplikasi untuk kunci dalam SPLIT_START dan SPLIT_LIMIT yang dilaporkan.
  • Strategi mitigasi sering kali tumpang-tindih dengan HOT_ROW, yang berfokus pada pengurangan beban operasional langsung pada rentang kunci sempit yang bermasalah.

UNSPECIFIED

Deskripsi: Pemisahan mengalami beban tinggi dan tidak dapat dipisahkan, tetapi penyebabnya tidak termasuk dalam kategori spesifik lainnya. Hal ini dapat terjadi dalam skenario beban yang kompleks atau karena perilaku sistem internal.

Strategi Mitigasi:

  • Selidiki beban kerja, kueri, atau transaksi aplikasi yang mengakses tabel dalam pemisahan aktif (tercantum dalam AFFECTED_TABLES) yang menunjukkan peningkatan beban.
  • Gunakan alat seperti Query Insights dan Transaction Insights untuk mengidentifikasi operasi yang mahal.
  • Evaluasi beban kerja dan pastikan Anda menggunakan Praktik terbaik desain skema dan Praktik terbaik SQL.
  • Jika hotspot terus berlanjut selama lebih dari 10 menit meskipun telah dilakukan pengoptimalan sebelumnya, buka kasus dukungan.

Melihat agregasi peristiwa

Entri dalam tampilan SPANNER_SYS.SPLIT_STATS_TOP_10MINUTE dan SPANNER_SYS.SPLIT_STATS_TOP_HOUR mewakili penggabungan interval 1 menit dalam periode masing-masing:

CPU_USAGE_SCORE: Ini menunjukkan CPU_USAGE_SCORE maksimum yang direkam untuk pemisahan dalam interval 1 menit dalam periode 10 menit atau 1 jam.

UNSPLITTABLE_REASONS: Array ini adalah gabungan dari semua UNSPLITTABLE_REASONS unik yang diamati untuk pemisahan di semua interval 1 menit dalam periode.

Pemisahan muncul dalam tampilan ini jika CPU_USAGE_SCORE-nya 50% atau lebih tinggi dalam setidaknya salah satu interval 1 menit yang membentuknya.

Contoh agregasi

Periksa pemisahan dari Users(101) ke Users(102). Tabel berikut menunjukkan kemungkinan entri dalam tampilan MINUTE selama periode 10 menit dari 10.00.00 hingga 10.10.00:

INTERVAL_END SPLIT_START SPLIT_LIMIT CPU_USAGE_SCORE AFFECTED_TABLES UNSPLITTABLE_REASONS
10:01:00 Pengguna(101) Pengguna(102) 60 [Pesan,Pengguna,Thread] []
10:02:00 Pengguna(101) Pengguna(102) 95 [Pesan,Pengguna,Thread] [HOT_ROW]
10:03:00 Pengguna(101) Pengguna(102) 80 [Pesan,Pengguna,Thread] [HOT_ROW]
10:04:00 Pengguna(101) Pengguna(102) 55 [Pengguna,Thread] []
10:06:00 Pengguna(101) Pengguna(102) 70 [Pengguna,Thread] [LARGE_SCAN_HOT_SPOT]
10:07:00 Pengguna(101) Pengguna(102) 65 [Pengguna,Thread] [LARGE_SCAN_HOT_SPOT]
10:09:00 Pengguna(101) Pengguna(102) 52 [Pengguna,Thread] []

Entri gabungan yang sesuai di 10MINUTE untuk interval yang berakhir pada 10.10.00 untuk pemisahan ini adalah:

INTERVAL_END SPLIT_START SPLIT_LIMIT CPU_USAGE_SCORE AFFECTED_TABLES UNSPLITTABLE_REASONS
10:10:00 Pengguna(101) Pengguna(102) 95 [Pesan,Pengguna,Thread] [HOT_ROW, LARGE_SCAN_HOT_SPOT]
  • CPU_USAGE_SCORE: 95 adalah nilai maksimum dari kolom CPU_USAGE_SCORE dalam tampilan 1 menit untuk pemisahan ini dalam jangka waktu tersebut.
  • UNSPLITTABLE_REASONS: [HOT_ROW, LARGE_SCAN_HOT_SPOT] adalah gabungan dari semua alasan unik yang ada di kolom UNSPLITTABLE_REASONS dalam tampilan 1 menit.

Contoh ini menunjukkan cara tampilan 10MINUTE merangkum beban paling berat dan semua jenis masalah yang tidak dapat dibagi yang terjadi selama periode tersebut. Tampilan HOUR mengikuti logika agregasi yang sama selama periode 60 menit.

Menemukan pemisahan yang populer

Anda dapat menggunakan pernyataan SQL berikut untuk mengambil statistik pemisahan aktif. Anda dapat menjalankan pernyataan SQL ini menggunakan library klien, Google Cloud CLI, atau konsolGoogle Cloud .

SELECT
  t.interval_end,
  t.split_start,
  t.split_limit,
  t.cpu_usage_score,
  t.affected_tables,
  t.unsplittable_reasons
FROM
  SPANNER_SYS.SPLIT_STATS_TOP_DURATION AS t
WHERE
  -- Optional: Filter by a specific interval end time
  -- t.interval_end = 'INTERVAL_END_TIME'
ORDER BY
  t.interval_end DESC, t.cpu_usage_score DESC;

Ganti kode berikut:

  • DURATION: pilih MINUTE, 10MINUTE, atau HOUR, berdasarkan periode observasi. Contoh, SPANNER_SYS.SPLIT_STATS_TOP_HOUR.
  • INTERVAL_END_TIME: Ganti dengan TIMESTAMP waktu berakhir periode pengamatan. Misalnya, 2072-06-08 08:30:00Z.

Menafsirkan hasil kueri

Untuk mengetahui daftar lengkap kode UNSPLITTABLE_REASONS dan kemungkinan diagnosisnya, lihat Jenis UNSPLITTABLE_REASONS. Misalnya, output kueri Anda mungkin terlihat seperti berikut:

SPLIT_START SPLIT_LIMIT CPU_USAGE_SCORE AFFECTED_TABLES UNSPLITTABLE_REASONS
Rangkaian pesan(10) Threads(10, "aa") 100 Pesan,Rangkaian pesan [UNISOLATABLE_HOT_ROW]
Pesan(631, "abc", 1) Pesan(631, "abc", 3) 100 Pesan [HOT_ROW]
Pengguna(620) <end> 100 Pesan,Pengguna,Rangkaian pesan [MOVING_HOT_SPOT]
Pengguna(101) Pengguna(102) 90 Pesan,Pengguna,Rangkaian pesan [HOT_ROW]
Pengguna(13) Pengguna(76) 82 Pesan,Pengguna,Rangkaian pesan [LARGE_SCAN_HOT_SPOT]
Threads(12, "zebra") Pengguna(14) 76 Pesan,Pengguna,Rangkaian pesan []

Dari hasil ini, Anda dapat menyimpulkan masalah berikut:

  • Threads(10) to Threads(10, "aa"): Hot at 100% with [UNISOLATABLE_HOT_ROW]. Satu kunci, awalan rentang kunci dalam tabel Threads, atau tabel yang disisipkan bersifat aktif, dan Spanner tidak dapat membagi rentang lebih lanjut.
  • Messages(631, "abc", 1) hingga Messages(631, "abc", 3): Hot pada 100% dengan [HOT_ROW]. Beban terkonsentrasi pada MessageId 1 dan 2 untuk Pengguna dan Thread ini.
  • Pengguna(620) ke <end>: Hot pada 100% dengan [MOVING_HOT_SPOT]. Hal ini sering kali menunjukkan pola penyisipan dengan ID Pengguna yang meningkat atau menurun secara monoton, sehingga menyebabkan akhir ruang kunci terus-menerus panas.
  • Pengguna(101) hingga Pengguna(102): Hot pada 90% dengan [HOT_ROW]. Beban terpusat pada satu baris Pengguna UserId = 101 dan anak-anaknya yang saling terkait.
  • Pengguna(13) ke Pengguna(76): Sangat populer dengan 82% [LARGE_SCAN_HOT_SPOT]. Hal ini menunjukkan pemindaian yang sering atau mahal di seluruh rentang ID Pengguna ini.
  • Threads(12, "zebra") ke Users(14): Hangat dengan penggunaan 76%. Tidak ada alasan tidak dapat dibagi yang terdeteksi dalam interval ini. Spanner mungkin masih dapat membagi ini jika beban berlanjut atau meningkat.

Memecahkan masalah hotspot menggunakan statistik pemisahan panas

Bagian ini menjelaskan cara mendeteksi dan memecahkan masalah hotspot.

Pilih jangka waktu yang akan diselidiki

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

Memeriksa alasan yang tidak dapat dibagi

Karena Spanner menyeimbangkan beban dengan pemisahan berbasis beban, kami menyarankan agar Anda menyelidiki hotspot yang berlanjut selama lebih dari 10 menit, terutama jika memiliki UNSPLITTABLE_REASONS. Kehadiran UNSPLITTABLE_REASONS menunjukkan bahwa Spanner tidak dapat membagi pembagian panas, dan perubahan skema atau workload mungkin diperlukan untuk mengurangi hotspot.

Anda dapat membuat kueri untuk UNSPLITTABLE_REASONS seperti yang ditunjukkan dalam kueri contoh berikut:

SELECT
  reason,
  COUNT(*) AS occurrences
FROM
  SPANNER_SYS.SPLIT_STATS_TOP_MINUTE AS t,
  UNNEST(t.unsplittable_reasons) AS reason
WHERE
  t.cpu_usage_score >= 50
  AND ARRAY_LENGTH(t.unsplittable_reasons) > 0
  AND t.interval_end >= "2072-05-18T17:40:00Z"  -- Start of window
  AND t.interval_end <= "2072-05-18T17:50:00Z"  -- End of window
GROUP BY
  reason
ORDER BY
  occurrences DESC;

Keberadaan UNSPLITTABLE_REASONS menunjukkan perlunya proses penelusuran bug lebih lanjut.

Anda juga dapat memantau alasan tidak dapat dibagi menggunakan Cloud Monitoring. Metrik yang digunakan adalah unsplittable_reason_count. Untuk mengetahui informasi selengkapnya, lihat Metrik Spanner.

Temukan pemisahan dengan CPU_USAGE_SCORE tertinggi dan UNSPLITTABLE_REASONS-nya

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

GoogleSQL 

SELECT t.split_start,
     t.split_limit,
     t.cpu_usage_score,
     t.affected_tables,
     t.unsplittable_reasons
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 YYYY-MM-DDTHH:MM:SSZ. Contoh, 2072-05-18T17:40:00Z.

PostgreSQL 

SELECT t.split_start,
     t.split_limit,
     t.cpu_usage_score,
     t.affected_tables,
     t.unsplittable_reasons
FROM   spanner_sys.split_stats_top_minute t
WHERE  t.cpu_usage_score >= 50
AND  t.interval_end = 'interval_end_date_time'::timestamptz;

Ganti interval_end_date_time dengan tanggal dan waktu untuk interval, menggunakan format YYYY-MM-DDTHH:MM:SSZ. Contoh, 2072-05-18T17:40:00Z.

SQL sebelumnya menghasilkan output berikut:

SPLIT_START SPLIT_LIMIT CPU_USAGE_SCORE AFFECTED_TABLES UNSPLITTABLE_REASONS
Users(180) <end> 85 Messages,Users,Threads [MOVING_HOT_SPOT]
Users(24) Users(76) 76 Messages,Users,Threads [HOT_ROW, LARGE_SCAN_HOT_SPOT]
Threads(10) UsersByFirstName("abc") 100 UsersByFirstName, Users, Threads, Messages, MessagesIdx []

Dari tabel hasil ini, kita dapat melihat bahwa ada tiga pemisahan panas dan dua di antaranya tidak dapat dipisahkan. Hotspot dengan UNSPLITTABLE_REASONS yang terus muncul dari waktu ke waktu memerlukan penyelidikan lebih lanjut. Untuk memahami arti setiap alasan dan cara mengatasinya, lihat jenis UNSPLITTABLE_REASONS.

Praktik terbaik untuk mengurangi hotspot

Catatan: Jika Anda mengalami peningkatan beban dan baru-baru ini meningkatkan skala instance, Spanner mungkin memerlukan waktu beberapa menit untuk melakukan operasi penyeimbangan bebannya sebelum latensi Anda menurun.

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

Mengidentifikasi penyebabnya

  • Gunakan Insight Kunci & Transaksi untuk mencari transaksi yang memiliki waktu tunggu kunci yang tinggi saat kunci awal rentang baris berada dalam pemisahan aktif.
  • Gunakan Query Insights untuk mencari kueri yang membaca dari tabel yang berisi pemisahan panas, dan baru-baru ini mengalami peningkatan latensi, atau rasio latensi terhadap CPU yang lebih tinggi.
  • Gunakan Kueri Aktif Terlama untuk mencari kueri yang membaca dari tabel yang berisi pemisahan aktif, dan memiliki latensi yang 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 meningkatkan level CPU_USAGE_SCORE selama penghapusan massal. Dalam hal ini, masalah akan teratasi sendiri setelah penghapusan awal selesai.

Mengoptimalkan workload

  • Ikuti praktik terbaik SQL. Pertimbangkan pembacaan yang tidak valid, penulisan yang tidak melakukan pembacaan terlebih dahulu, atau menambahkan indeks.
  • Ikuti Praktik terbaik skema. Pastikan skema Anda dirancang untuk menangani load balancing dan menghindari hotspot.

Langkah berikutnya