Menangani kesenjangan data kluster - Tair (Redis® OSS-Compatible)

Jika metrik performa seperti penggunaan memori, pemanfaatan CPU, dan penggunaan bandwidth pada node data tertentu dalam instans kluster Tair (Redis OSS-compatible) jauh lebih tinggi dibandingkan node data lainnya, instans tersebut kemungkinan mengalami masalah kesenjangan data. Ketidakseimbangan data yang signifikan dapat menyebabkan berbagai pengecualian—seperti eviksi kunci, error out of memory (OOM), dan tanggapan yang lambat—meskipun penggunaan memori instans secara keseluruhan masih rendah.

Penanganan cepat

Bagian ini menjelaskan cara memastikan terjadinya kesenjangan data serta mengidentifikasi dan menangani large keys.

Pada panel navigasi kiri halaman detail instans, pilih CloudDBA > Real-time Performance untuk memeriksa apakah metrik Memory Usage tersebar merata di seluruh node data.

Pada contoh ini, Memory Usage pada node data db-0 jauh lebih tinggi dibandingkan node lainnya, yang mengindikasikan adanya kesenjangan data. Misalnya, terjadi kesenjangan data jika Memory Usage salah satu node mencapai 57% (9,22 GB) sementara node lain hanya 33% (5,32 GB).

Catatan
Anda juga dapat menggunakan fitur diagnostik instans untuk memeriksa apakah terjadi kesenjangan data pada instans saat ini. Untuk informasi lebih lanjut, lihat Lakukan diagnostik pada instans.
Periksa jumlah total kunci pada setiap node data.
Pada contoh ini, jumlah total kunci adalah 2,59 juta di db-0, 2,60 juta di db-1, dan 2,59 juta di db-2. Kunci-kunci tersebut tersebar merata di seluruh node data. Dalam kasus ini, kemungkinan besar node data db-0 memiliki large keys.
Catatan
Jika kunci tidak tersebar merata di seluruh node data, hal ini mungkin mengindikasikan adanya masalah pada desain nama kunci dalam logika bisnis Anda. Misalnya, penggunaan hash tags dapat menyebabkan klien mengarahkan semua kunci ke node data yang sama ketika algoritma Cyclic Redundancy Check (CRC) digunakan untuk distribusi. Dalam kasus ini, Anda harus melakukan penyesuaian di tingkat aplikasi untuk menghindari penggunaan {} dalam nama kunci.
Gunakan fitur offline key analysis untuk mengidentifikasi large keys secara cepat.

Fitur ini menganalisis file backup instans tanpa memengaruhi bisnis online. Setelah analisis selesai, Anda dapat melihat top 500 large keys. Pada contoh ini, kunci bernama mylist teridentifikasi sebagai large key.

Kunci bertipe list ini menggunakan enkode quicklist, mengonsumsi memori sebesar 3,80 GB, dan berisi sekitar 2,04 juta elemen.
(Opsional) Hubungkan ke node data tertentu untuk kueri dan analisis.
- Untuk instans kluster dalam modus proxy, Anda dapat menjalankan perintah SCAN pada node data tertentu dengan menggunakan perintah ISCAN yang dikembangkan secara internal oleh Alibaba Cloud. Untuk informasi lebih lanjut, lihat Perintah internal untuk instans dalam modus proxy.
- Untuk instans kluster dalam mode koneksi langsung, Anda dapat memanggil operasi DescribeDBNodeDirectVipInfo untuk mendapatkan alamat IP virtual (VIP) setiap node data, lalu menghubungkan klien ke node data tersebut untuk analisis.
Terapkan salah satu solusi berikut:
- Solusi sementara: Upgrade spesifikasi instans.
- Solusi jangka panjang (direkomendasikan): Restrukturisasi logika bisnis dengan membagi large keys secara tepat.

Untuk informasi lebih lanjut mengenai penyebab dan solusi masalah kesenjangan data, lihat bagian berikut. Topik ini juga relevan untuk troubleshooting masalah terkait metrik performa tinggi seperti penggunaan memori, pemanfaatan CPU, penggunaan bandwidth, dan latensi pada instans standar.

Mengapa kesenjangan data terjadi?

Instans kluster Tair (Redis OSS-compatible) menggunakan arsitektur terdistribusi. Ruang penyimpanan instans kluster dibagi menjadi 16.384 slot. Setiap node data menyimpan dan menangani data pada slot tertentu. Misalnya, pada instans kluster dengan 3 shard, slot didistribusikan di antara tiga shard sebagai berikut: shard pertama menangani slot dalam rentang [0,5460], shard kedua menangani slot dalam rentang [5461,10922], dan shard ketiga menangani slot dalam rentang [10923,16383]. Saat Anda menulis atau memperbarui kunci ke instans kluster, klien menentukan slot tempat kunci tersebut berada dengan menggunakan rumus berikut: Slot=CRC16(key)%16384. Kemudian, klien menulis kunci tersebut ke slot yang sesuai. Secara teori, mekanisme ini mendistribusikan kunci secara merata di antara node data, sehingga nilai metrik seperti penggunaan memori dan pemanfaatan CPU seharusnya hampir sama di seluruh node data.

Namun, dalam praktiknya, kesenjangan data dapat terjadi karena kurangnya perencanaan awal, pola penulisan data yang tidak biasa, atau lonjakan akses data.

Catatan

Umumnya, kesenjangan data terjadi ketika sumber daya pada node data tertentu lebih banyak digunakan dibandingkan node lainnya. Anda dapat melihat metrik node data pada tab Data Node di halaman Performance Monitor di Konsol. Jika metrik suatu node data secara konsisten 20% lebih tinggi dibandingkan node lainnya, kemungkinan terjadi kesenjangan data. Tingkat keparahan kesenjangan data sebanding dengan selisih antara metrik node data abnormal dan node data normal.
Ketika penggunaan memori satu node data mencapai 100%, node data tersebut memicu eviksi data. Kebijakan eviksi default adalah volatile-lru.

Gambar berikut menunjukkan dua skenario khas kesenjangan data. Meskipun kunci tersebar merata di seluruh instans kluster (dua kunci per node data), kesenjangan data tetap terjadi.

Jumlah permintaan per detik (QPS) untuk key1 pada node data Shard 1 jauh lebih tinggi dibandingkan kunci lainnya. Ini merupakan kasus data access skew, yang dapat menyebabkan pemanfaatan CPU dan penggunaan bandwidth tinggi pada node data tersebut, sehingga memengaruhi performa semua kunci pada node tersebut.
Ukuran key5 pada node data Shard 2 adalah 1 MB, jauh lebih besar dibandingkan kunci lainnya. Ini dianggap sebagai kasus data volume skew, yang dapat menyebabkan penggunaan memori dan bandwidth tinggi pada node data tersebut, sehingga memengaruhi performa semua kunci pada node tersebut.

Solusi sementara

Jika terjadi kesenjangan data pada suatu instans, Anda dapat menerapkan solusi sementara untuk mengurangi dampaknya dalam jangka pendek.

Masalah	Kemungkinan penyebab	Solusi sementara
Memory usage skew	Large keys dan hash tags	Upgrade spesifikasi instans. Untuk informasi lebih lanjut, lihat Ubah konfigurasi instans. Penting Sistem melakukan pemeriksaan awal terhadap kesenjangan data selama perubahan spesifikasi instans. Jika tipe instans yang Anda pilih tidak dapat menangani masalah kesenjangan data, sistem akan melaporkan error. Pilih tipe instans dengan spesifikasi lebih tinggi dan coba lagi. Setelah Anda meng-upgrade spesifikasi instans, kesenjangan penggunaan memori mungkin berkurang. Namun, kesenjangan juga dapat terjadi pada sumber daya bandwidth dan CPU.
Bandwidth usage skew	Large keys, hotkeys, dan perintah yang intensif sumber daya	Tingkatkan bandwidth satu atau beberapa node data. Untuk informasi lebih lanjut, lihat Tingkatkan bandwidth instans secara manual. Catatan Bandwidth node data dapat ditingkatkan hingga enam kali bandwidth default instans, tetapi peningkatan bandwidth tidak boleh melebihi 192 Mbit/s. Jika langkah ini masih belum menyelesaikan masalah kesenjangan data, kami merekomendasikan agar Anda melakukan penyesuaian di tingkat aplikasi.
CPU utilization skew	Large keys, hotkeys, dan perintah yang intensif sumber daya	Jika hotkeys tersebar di slot yang berbeda, tambahkan node data selama jam sepi untuk menyeimbangkan beban lebih merata di seluruh sistem. Optimalkan perintah yang intensif sumber daya. Misalnya, kurangi jumlah kunci yang diambil dalam setiap perintah SCAN. Catatan Lakukan penskalaan instans selama jam sepi karena proses migrasi data yang terjadi selama penskalaan dapat mengonsumsi sumber daya CPU yang signifikan.

Untuk mengatasi kesenjangan data secara sementara, Anda juga dapat mengurangi permintaan terhadap large keys dan hotkeys. Untuk menyelesaikan masalah terkait large keys dan hotkeys, Anda harus melakukan penyesuaian di tingkat aplikasi. Kami merekomendasikan agar Anda segera mengidentifikasi penyebab kesenjangan data pada instans Anda dan menanganinya di tingkat aplikasi guna mengoptimalkan performa instans. Untuk informasi lebih lanjut, lihat bagian Penyebab dan solusi topik ini.

Penyebab dan solusi

Untuk menyelesaikan akar penyebab kesenjangan data, kami merekomendasikan agar Anda mengevaluasi pertumbuhan bisnis Anda dan melakukan persiapan yang diperlukan untuk pertumbuhan di masa depan. Anda dapat mengambil langkah-langkah untuk membagi large keys dan menulis data dengan cara yang sesuai dengan penggunaan yang diharapkan.

Penyebab	Deskripsi	Solusi
Large keys	Large key diidentifikasi berdasarkan ukuran kunci dan jumlah anggota dalam kunci tersebut. Umumnya, large keys sering ditemukan pada struktur data key-value seperti Hash, List, Set, dan Zset. Large keys terjadi ketika struktur-struktur ini menyimpan sejumlah besar field atau field yang ukurannya terlalu besar. Large keys merupakan salah satu penyebab utama kesenjangan data. Untuk informasi lebih lanjut tentang cara menghapus large keys atau hotkeys secara aman tanpa memengaruhi bisnis Anda, lihat Identifikasi dan tangani large keys dan hotkeys.	Cegah terjadinya large keys. Pisahkan kunci hash yang berisi puluhan ribu anggota menjadi beberapa kunci hash dengan jumlah anggota yang lebih mudah dikelola.
Hotkeys	Hotkeys adalah kunci-kunci yang memiliki nilai QPS jauh lebih tinggi dibandingkan kunci lainnya. Hotkeys umum ditemukan selama uji stres pada satu kunci tunggal, atau dalam skenario penjualan kilat yang melibatkan ID produk populer. Untuk informasi lebih lanjut tentang hotkeys, lihat Identifikasi dan tangani large keys dan hotkeys.	Cegah terjadinya hotkeys. Gunakan fitur proxy query cache untuk menyimpan data panas dalam cache. Untuk informasi lebih lanjut, lihat Langkah 2: Optimalkan large keys dan hotkeys.
Resource-intensive commands	Setiap perintah memiliki metrik yang disebut time complexity yang mengukur konsumsi sumber daya dan waktu. Dalam kebanyakan kasus, semakin tinggi time complexity suatu perintah, semakin banyak sumber daya yang dikonsumsi. Misalnya, time complexity perintah `HGETALL` adalah O(n). Ini menunjukkan bahwa perintah tersebut mengonsumsi sumber daya sebanding dengan jumlah field yang ditentukan. Demikian pula, jika perintah `SET` atau `GET` melibatkan volume data yang besar, perintah tersebut akan mengonsumsi banyak sumber daya node data.	Kueri log kueri lambat dari node data. Untuk informasi lebih lanjut, lihat Kueri log kueri lambat. Gunakan fitur latency insights untuk melihat perintah-perintah yang mengonsumsi banyak sumber daya performa. Untuk informasi lebih lanjut, lihat Latency insights. Jangan gunakan perintah yang intensif sumber daya. Untuk menonaktifkan perintah tertentu, konfigurasikan parameter `#no_loose_disabled-commands` pada halaman Parameter Settings.
Hash Tags	Tair mendistribusikan kunci ke node data tertentu berdasarkan konten yang terdapat dalam bagian `{}` dari nama kunci. Misalnya, kunci `{item}id1`, `{item}id2`, dan `{item}id3` disimpan di node data yang sama karena memiliki konten `{}` yang sama. Akibatnya, penggunaan memori dan konsumsi sumber daya node data tersebut meningkat secara signifikan.	Jangan gunakan `{}` dalam nama kunci. Catatan Jika Anda ingin menggunakan `{}` dalam nama kunci, pastikan kunci-kunci berbeda memiliki konten berbeda dalam `{}`. Dengan demikian, Anda dapat menyimpan kunci-kunci tersebut di beberapa node data.

FAQ

Pada instans kluster yang memiliki large keys, apakah saya dapat meng-upgrade spesifikasi node data tempat large key berada?
Tidak. Tair (Redis OSS-compatible) tidak mengizinkan Anda meng-upgrade spesifikasi node data secara individual. Sistem hanya mengizinkan upgrade spesifikasi simultan untuk semua node data dalam instans.
Apakah saya dapat menambahkan node data dan mendistribusikan ulang kunci untuk menghilangkan large keys dalam instans kluster?
Tidak. Meskipun penambahan node data dapat membantu mengurangi tekanan memori pada node data yang ada, Tair (Redis OSS-compatible) mendistribusikan data di tingkat kunci, yang berarti large keys tidak dapat dibagi secara otomatis. Akibatnya, setelah kunci didistribusikan ulang, satu node data mungkin tetap memiliki penggunaan memori lebih tinggi dibandingkan node lainnya, sehingga menyebabkan kesenjangan data. Pendekatan yang direkomendasikan adalah membagi large keys secara manual menjadi kunci-kunci yang lebih kecil.