Menangani ketimpangan data dalam instance kluster - Tair (Redis® OSS-Compatible)

Jika metrik performa seperti penggunaan memori, utilisasi CPU, dan penggunaan bandwidth dari node data tertentu pada instance kluster Tair (Redis OSS-compatible) jauh lebih tinggi dibandingkan dengan node data lainnya, instance kluster mungkin mengalami masalah ketimpangan data. Jika data instance sangat timpang, pengecualian seperti penghapusan key, kesalahan kehabisan memori (OOM), dan respons yang lambat dapat terjadi meskipun penggunaan memori instance rendah.

Penanganan cepat

Berikut ini menjelaskan cara memastikan apakah ketimpangan data ada dan bagaimana mengidentifikasi serta menangani key besar.

Di panel navigasi sisi kiri halaman detail instance, pilih CloudDBA > Kinerja Real-time untuk memeriksa apakah metrik Memory Usage seimbang di seluruh node data.
Dalam contoh ini, metrik Memory Usage dari node data db-0 secara signifikan lebih tinggi dibandingkan dengan node data lainnya. Ini menunjukkan bahwa ketimpangan data terjadi pada instance.
Catatan
Anda juga dapat menggunakan fitur diagnosis instance untuk memeriksa apakah ketimpangan data ada pada instance saat ini. Untuk informasi lebih lanjut, lihat Melakukan Diagnosis pada Instance.
Lihat jumlah total key untuk setiap node data.
Dalam contoh ini, jumlah total key adalah 2,59 juta di db-0, 2,60 juta di db-1, dan 2,59 juta di db-2. Key didistribusikan secara merata di seluruh node data. Dalam kasus ini, kemungkinan besar node data db-0 memiliki key besar.
Catatan
Jika key tidak didistribusikan secara merata di seluruh node data, ini mungkin menunjukkan masalah dengan desain nama key dalam logika bisnis Anda. Sebagai contoh, penggunaan tag hash dapat menyebabkan klien mengarahkan semua key 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 key.
Gunakan fitur Analisis Key Offline untuk dengan cepat mengidentifikasi key besar.
Fitur ini menganalisis file cadangan instance tanpa memengaruhi bisnis online. Setelah analisis selesai, Anda dapat melihat top 500 large keys. Dalam contoh ini, key bernama mylist diidentifikasi sebagai key besar.
(Opsional) Hubungkan ke node data tertentu untuk kueri dan analisis.
- Untuk instance kluster dalam mode proxy, Anda dapat menjalankan perintah SCAN pada node data yang ditentukan menggunakan perintah ISCAN yang dikembangkan sendiri oleh Alibaba Cloud. Untuk informasi lebih lanjut, lihat Perintah Internal untuk Instance dalam Mode Proxy.
- Untuk instance kluster dalam mode koneksi langsung, Anda dapat memanggil operasi DescribeDBNodeDirectVipInfo untuk mendapatkan alamat IP virtual (VIP) dari setiap node data, lalu hubungkan klien ke node data untuk analisis.
Gunakan salah satu solusi berikut:
- Solusi Sementara: Tingkatkan spesifikasi instance.
- Solusi Jangka Panjang (Direkomendasikan): Restrukturisasi logika bisnis dengan membagi key besar secara tepat.

Untuk informasi lebih lanjut tentang penyebab dan solusi masalah ketimpangan data, lihat bagian berikut. Topik ini juga cocok untuk pemecahan masalah terkait metrik performa tinggi seperti penggunaan memori, utilisasi CPU, penggunaan bandwidth, dan latensi pada instance standar.

Mengapa ketimpangan data terjadi?

Instance kluster Tair (Redis OSS-compatible) menggunakan arsitektur terdistribusi. Ruang penyimpanan instance kluster dibagi menjadi 16.384 slot. Setiap node data menyimpan dan menangani data dalam slot tertentu. Sebagai contoh, dalam instance kluster 3-shard, slot didistribusikan di antara tiga shard dengan cara 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]. Ketika Anda menulis key ke instance kluster atau memperbarui key instance kluster, klien menentukan slot tempat key termasuk dengan menggunakan rumus berikut: Slot=CRC16(key)%16384. Kemudian, klien menulis key ke slot tersebut. Secara teori, mekanisme ini mendistribusikan key secara merata di antara node data, dan cukup untuk menjaga nilai metrik seperti penggunaan memori dan utilisasi CPU hampir pada level yang sama di semua node data.

Namun, dalam praktiknya, ketimpangan data dapat terjadi karena kurangnya perencanaan lanjutan, penulisan data yang tidak biasa, atau lonjakan akses data.

Catatan

Umumnya, ketimpangan data terjadi ketika sumber daya node data tertentu lebih banyak diminta dibandingkan dengan node data lainnya. Anda dapat melihat metrik node data di tab Data Node pada halaman Monitor Kinerja di konsol. Jika metrik node data secara konsisten 20% lebih tinggi dibandingkan dengan node data lainnya, ketimpangan data mungkin ada. Tingkat keparahan ketimpangan data sebanding dengan perbedaan antara metrik node data abnormal dan node data normal.
Ketika penggunaan memori node data tunggal mencapai 100%, node data memicu penghapusan data. Kebijakan penghapusan default adalah volatile-lru.

Gambar berikut menunjukkan dua skenario ketimpangan data yang khas. Meskipun key didistribusikan secara merata di seluruh instance kluster (dua key per node data), ketimpangan data tetap terjadi.

Jumlah permintaan per detik (QPS) untuk key1 pada node data Shard 1 jauh lebih tinggi dibandingkan dengan key lainnya. Ini adalah kasus Ketimpangan Akses Data, yang dapat menyebabkan utilisasi CPU dan penggunaan bandwidth yang tinggi pada node data. Ini memengaruhi kinerja semua key pada node data.
Ukuran key5 pada node data Shard 2 adalah 1 MB, yang jauh lebih besar dibandingkan dengan key lainnya. Ini dianggap sebagai kasus Ketimpangan Volume Data, yang dapat menyebabkan penggunaan memori dan bandwidth yang tinggi pada node data. Ini memengaruhi kinerja semua key pada node data.

Solusi sementara

Jika ketimpangan data terjadi pada instance, Anda dapat menerapkan solusi sementara untuk mengurangi masalah dalam jangka pendek.

Masalah	Penyebab potensial	Solusi sementara
Ketimpangan penggunaan memori	Key besar dan tag hash	Tingkatkan spesifikasi instance. Untuk informasi lebih lanjut, lihat Ubah konfigurasi instance. Penting Sistem memulai pra-pemeriksaan untuk ketimpangan data selama perubahan spesifikasi instance. Jika jenis instance yang Anda pilih tidak dapat menangani masalah ketimpangan data, sistem akan melaporkan kesalahan. Pilih jenis instance dengan spesifikasi lebih tinggi dan coba lagi. Setelah Anda meningkatkan spesifikasi instance, ketimpangan penggunaan memori mungkin berkurang. Namun, ketimpangan juga dapat terjadi pada bandwidth dan sumber daya CPU.
Ketimpangan penggunaan bandwidth	Key besar, hotkey, dan perintah intensif sumber daya	Tingkatkan bandwidth satu atau lebih node data. Untuk informasi lebih lanjut, lihat Secara manual tingkatkan bandwidth instance. Catatan Bandwidth node data dapat ditingkatkan hingga enam kali bandwidth default instance, tetapi peningkatan bandwidth tidak boleh melebihi 192 Mbit/s. Jika langkah ini masih belum menyelesaikan masalah ketimpangan data, kami sarankan Anda membuat penyesuaian di tingkat aplikasi.
Ketimpangan utilisasi CPU	Key besar, hotkey, dan perintah intensif sumber daya	Jika hotkey didistribusikan di slot yang berbeda, tambahkan node data selama jam-jam sepi untuk menyeimbangkan beban lebih merata di seluruh sistem. Optimalkan perintah intensif sumber daya. Sebagai contoh, kurangi jumlah key yang diambil dengan setiap perintah SCAN. Catatan Skalakan instance selama jam-jam sepi karena proses migrasi data yang terjadi selama penskalaan dapat mengonsumsi sumber daya CPU yang signifikan.

Untuk sementara menangani ketimpangan data, Anda juga dapat mengurangi permintaan untuk key besar dan hotkey. Untuk menyelesaikan masalah terkait key besar dan hotkey, Anda harus membuat penyesuaian di tingkat aplikasi. Kami sarankan Anda segera mengidentifikasi penyebab ketimpangan data di instance Anda dan menangani masalah tersebut di tingkat aplikasi untuk mengoptimalkan kinerja instance. Untuk informasi lebih lanjut, lihat bagian Penyebab dan Solusi dari topik ini.

Penyebab dan solusi

Untuk menyelesaikan penyebab utama ketimpangan data, kami sarankan Anda mengevaluasi pertumbuhan bisnis Anda dan membuat persiapan yang diperlukan untuk pertumbuhan masa depan. Anda dapat mengambil langkah-langkah untuk membagi key besar dan menulis data dengan cara yang sesuai dengan penggunaan yang diharapkan.

Penyebab	Deskripsi	Solusi
Key Besar	Key besar diidentifikasi berdasarkan ukuran key dan jumlah anggota dalam key. Umumnya, key besar sering ditemukan dalam struktur data key-value seperti Hash, List, Set, dan Zset. Key besar terjadi ketika struktur ini menyimpan sejumlah besar field atau field yang terlalu besar. Key besar adalah salah satu penyebab utama ketimpangan data. Untuk informasi lebih lanjut tentang cara menghapus key besar atau hotkey secara elegan tanpa memengaruhi bisnis Anda, lihat Identifikasi dan Tangani Key Besar dan Hotkey.	Cegah terjadinya key besar. Pisahkan key hash yang berisi puluhan ribu anggota menjadi beberapa key hash yang memiliki jumlah anggota yang dapat dikelola.
Hotkey	Hotkey adalah key yang memiliki nilai QPS jauh lebih tinggi dibandingkan dengan key lainnya. Hotkey umum ditemukan selama uji stres pada key tunggal, atau dalam skenario flash sale yang melibatkan ID produk populer. Untuk informasi lebih lanjut tentang hotkey, lihat Identifikasi dan Tangani Key Besar dan Hotkey.	Cegah terjadinya hotkey. Gunakan fitur cache query proxy untuk menyimpan data panas. Untuk informasi lebih lanjut, lihat Langkah 2: Optimalkan Key Besar dan Hotkey.
Perintah Intensif Sumber Daya	Setiap perintah memiliki metrik yang disebut kompleksitas waktu yang mengukur konsumsi sumber daya dan waktunya. Dalam kebanyakan kasus, semakin tinggi kompleksitas waktu suatu perintah, semakin banyak sumber daya yang dikonsumsi perintah tersebut. Sebagai contoh, kompleksitas waktu perintah `HGETALL` adalah O(n). Ini menunjukkan bahwa perintah tersebut mengonsumsi sumber daya sebanding dengan jumlah field yang ditentukan untuk perintah tersebut. Demikian pula, jika perintah `SET` atau `GET` melibatkan volume data yang besar, perintah tersebut mengonsumsi sejumlah besar sumber daya node data.	Kueri log query lambat dari node data. Untuk informasi lebih lanjut, lihat Kueri Log Query Lambat. Gunakan fitur wawasan latensi untuk melihat perintah yang mengonsumsi sejumlah besar sumber daya performa. Untuk informasi lebih lanjut, lihat Wawasan Latensi. Jangan gunakan perintah intensif sumber daya. Untuk menonaktifkan perintah tertentu, konfigurasikan parameter `#no_loose_disabled-commands` pada halaman Parameter Settings.
Tag Hash	Tair mendistribusikan key ke node data tertentu berdasarkan konten yang terkandung dalam bagian `{}` dari nama key. Sebagai contoh, key `{item}id1`, `{item}id2`, dan `{item}id3` disimpan di node data yang sama karena mereka berbagi konten `{}` yang sama. Akibatnya, penggunaan memori dan konsumsi sumber daya node data ini meningkat secara signifikan.	Jangan gunakan `{}` dalam nama key. Catatan Jika Anda ingin menggunakan `{}` dalam nama key, pastikan bahwa key yang berbeda memiliki konten yang berbeda dalam `{}`. Dengan cara ini, Anda dapat menyimpan key di beberapa node data.

FAQ

Dalam instance kluster dengan key besar, apakah saya dapat meningkatkan spesifikasi node data tempat key besar berada?
Tidak. Tair (Redis OSS-compatible) tidak mengizinkan Anda untuk secara terpisah meningkatkan spesifikasi node data individu. Ini hanya mengizinkan peningkatan spesifikasi secara bersamaan untuk semua node data dalam instance.
Apakah saya dapat menambahkan node data dan mendistribusikan ulang key untuk menghilangkan key besar dalam instance kluster?
Tidak. Meskipun menambahkan node data dapat membantu mengurangi sebagian tekanan memori dari node data yang ada, Tair (Redis OSS-compatible) mendistribusikan data pada tingkat key, yang berarti key besar tidak dapat dibagi secara otomatis. Akibatnya, setelah key didistribusikan ulang, satu node data mungkin masih memiliki penggunaan memori yang lebih tinggi dibandingkan dengan yang lainnya, sehingga menghasilkan ketimpangan data. Pendekatan yang direkomendasikan adalah membagi key besar secara manual menjadi yang lebih kecil.