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 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 sehingga 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 warm. Jika 100% beban pada pemisahan dibatasi, maka pemisahan 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 penyeimbangan beban atau dapat dibagi menjadi pemisahan yang lebih kecil. Namun, Spanner mungkin tidak dapat menyeimbangkan beban, bahkan setelah beberapa kali mencoba membagi, 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 aktif Spanner membantu Anda mengidentifikasi pemisahan tempat terjadinya hotspot. 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.

Mengakses statistik pemisahan panas

Spanner menyediakan statistik pemisahan aktif 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.
• 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 pemisahan panas

Anda menggunakan tabel berikut untuk melacak pemisahan panas:

• SPANNER_SYS.SPLIT_STATS_TOP_MINUTE: menampilkan pemisahan yang populer selama interval 1 menit.

Tabel ini memiliki properti berikut:

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

• Interval didasarkan pada waktu jam:

  • Interval 1 menit berakhir pada menit ke-0.

• Setelah setiap interval, Spanner mengumpulkan data dari semua server dan kemudian menyediakan data tersebut di tabel 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 AM

• Spanner mengelompokkan statistik berdasarkan pemisahan.

• Setiap baris berisi persentase yang menunjukkan seberapa sering atau hangat pemisahan terjadi, untuk setiap pemisahan yang datanya dikumpulkan Spanner selama interval yang ditentukan.

• Jika kurang dari 50% beban pada split dibatasi oleh resource yang tersedia, Spanner tidak akan mencatat statistik. 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, berarti tidak ada hotspot.

Skema tabel

Tabel berikut menunjukkan skema tabel untuk statistik berikut:

• SPANNER_SYS.SPLIT_STATS_TOP_MINUTE

Kunci awal pemisahan dan 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.

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;

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:

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 baris Threads yang disisipkan dalam Users(10).

Contoh kueri untuk menemukan pemisahan yang populer

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 .

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;

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 akan terlihat seperti berikut:

Retensi data untuk statistik pemisahan panas

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

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

Memecahkan masalah hotspot menggunakan statistik pemisahan hot

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, masalah mungkin mulai terjadi 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:

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

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

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

Menemukan pemisahan dengan tingkat CPU_USAGE_SCORE tertinggi

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

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";

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;

SQL sebelumnya menghasilkan output berikut:

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

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";

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;

SQL sebelumnya menghasilkan output berikut:

Sepertinya pembagiannya sangat menarik dalam beberapa menit terakhir. Anda mungkin mengamati pemisahan lebih lama untuk menentukan bahwa pemisahan berbasis beban Spanner mengurangi hotspot. Mungkin ada kasus di mana Spanner tidak dapat menyeimbangkan beban lebih lanjut.

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

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";

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;

Baris aktif tunggal

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

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

Memindahkan hotspot

Dalam contoh berikut, beban bergerak melalui pemisahan yang berdekatan dari waktu ke waktu, berpindah ke pemisahan baru di seluruh interval waktu.

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

Load balancing normal

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

Di sini, pemisahan yang lebih besar pada 2024-05-16T17:40:00Z dibagi lagi menjadi pemisahan yang lebih kecil dan akibatnya, statistik CPU_USAGE_SCORE menurun. Spanner mungkin tidak membuat pemisahan ke dalam baris individual. Pemisahan mencerminkan workload yang menyebabkan statistik CPU_USAGE_SCORE tinggi.

Jika Anda telah mengamati pemisahan panas yang persisten selama lebih dari 10 menit, lihat Praktik terbaik untuk memitigasi hotspot.

Praktik terbaik untuk mengurangi hotspot

Jika penyeimbangan beban tidak mengurangi latensi, langkah selanjutnya 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 Lock & Transaction Insights untuk mencari transaksi yang memiliki waktu tunggu kunci yang tinggi dengan kunci awal rentang baris berada dalam pemisahan aktif.

• Gunakan Query Insights untuk mencari kueri yang membaca dari tabel yang berisi pemisahan aktif, 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 panas, dan yang memiliki latensi lebih tinggi dari yang diharapkan.

Beberapa kasus khusus yang perlu diperhatikan:

• Periksa apakah time to live (TTL) diaktifkan baru-baru ini. Jika ada banyak pemisahan dari data lama, TTL dapat meningkatkan tingkat 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

• Pelajari praktik terbaik desain skema.
• Pelajari Key Visualizer.
• Pelajari contoh desain skema.
• Pelajari cara menggunakan dasbor insight perbandingan untuk mendeteksi titik-titik penting.