Bagaimana mengatasi data skew dan hot partition saat sharding?

Question

IT Interview Practice · Accepted Answer

**Tentukan dahulu apa yang tidak merata: jumlah data tersimpan, trafik request, atau pembaruan pada satu record.** Penambahan server hanya membantu jika pekerjaan yang berlebihan dapat dipindahkan ke server tersebut.

Misalnya pesanan dibagi berdasarkan ID merchant. Sebagian besar merchant kecil, tetapi satu merchant mengadakan kampanye besar. Shard-nya kelebihan beban sementara shard lain sepi. Inilah hot partition: partisi yang menerima pekerjaan melebihi kemampuannya.

## 1. Ukur ketimpangan sebelum mengganti key

Bandingkan ukuran data, laju request, latensi, dan tekanan CPU atau disk antar-shard. Kemudian uraikan beban shard yang bermasalah berdasarkan merchant dan operasi. Shard yang menyimpan record lama mungkin besar tetapi jarang digunakan; shard kecil dapat kewalahan akibat pembaruan berulang pada satu barang populer.

Untuk kampanye tadi, tentukan apakah beban berasal dari pembacaan detail produk, pembuatan banyak pesanan independen, atau perubahan berulang pada record stok yang sama. Ketiga kasus ini membutuhkan penanganan berbeda.

## 2. Pahami mengapa distribusi sekarang tetap timpang

Shard key menentukan penempatan record. Hash ID merchant dapat menyebarkan merchant berbeda ke berbagai shard, tetapi seluruh pesanan dengan key merchant yang sama tetap mengikuti aturan penempatan yang sama. Hash tidak otomatis membagi beban satu merchant.

Key dengan sedikit nilai berbeda membatasi kesempatan membagi data. Rentang waktu dapat memusatkan penulisan baru pada partisi terbaru. Key yang lebih tersebar dapat memperbaiki distribusi, tetapi membuat kueri umum menghubungi banyak shard. [Panduan shard key](https://www.mongodb.com/docs/manual/core/sharding-choose-a-shard-key/) MongoDB menjelaskan pertimbangan ini.

## 3. Sesuaikan penanganan dengan pekerjaan yang kelebihan beban

| Bukti | Pilihan yang perlu dievaluasi | Batas penting |
|---|---|---|
| Banyak partisi yang dapat dipindahkan berada pada satu shard | Seimbangkan ke kapasitas yang tersedia | Pemindahan data hanya membantu jika pekerjaan terkait ikut berpindah |
| Pembacaan produk yang sama berulang kali | Cache atau replika baca jika kesegaran yang dibutuhkan memungkinkan | Ini tidak membagi penulisan pada produk tersebut |
| Satu merchant membuat banyak pesanan independen | Bagi merchant menggunakan key tambahan berbasis pesanan atau bucket | Kueri seluruh merchant mungkin perlu beberapa pembacaan dan penggabungan hasil |
| Banyak penulisan berebut record stok yang sama | Kurangi perebutan atau rancang ulang alokasi stok | Penambahan shard tidak menghilangkan kebutuhan koordinasi untuk menjaga kebenaran |

Mengisolasi merchant besar dapat melindungi tenant lain dan memberi waktu untuk perbaikan. Ini tidak menyediakan kapasitas tanpa batas bagi merchant tersebut, sehingga hambatan individualnya tetap perlu diukur.

## 4. Periksa biaya membagi satu merchant

Bayangkan pesanan diarahkan menggunakan ID merchant ditambah bucket yang diturunkan dari ID pesanan. Pesanan kampanye yang independen kemudian dapat ditempatkan pada beberapa partisi.

```text
Merchant A + bucket 0 -> Partition 1
Merchant A + bucket 1 -> Partition 2
Merchant A + bucket 2 -> Partition 3
```

Mengambil satu pesanan lebih mudah ketika bucket-nya dapat dihitung. Mengambil semua pesanan terbaru Merchant A kini membutuhkan pembacaan beberapa partisi dan penggabungan secara berurutan. Pagination, total, dan transaksi lintas partisi menjadi lebih rumit. Pilih pembagian ini hanya setelah memastikan tambahan biaya pembacaan dan koordinasi dapat diterima.

## 5. Migrasikan dengan cara membuktikan kebenaran

Mengubah aturan routing saat penulisan terus berlangsung membutuhkan rencana migrasi. Salin record yang ada, tangkap perubahan selama penyalinan, lalu cocokkan jumlah record serta total bisnis sebelum mengalihkan trafik. Jumlah record saja dapat melewatkan nilai pesanan yang salah.

Tentukan penanganan penulisan yang sedang berlangsung saat peralihan dan cara mengembalikan routing tanpa kehilangan penulisan yang sudah diterima susunan baru. Penulisan ganda membutuhkan penanganan kegagalan; sekadar menulis ke dua tempat tidak menjamin keduanya tetap identik.

Terakhir, uji dengan beban tidak merata yang sebenarnya, termasuk merchant besar, bukan trafik buatan yang seragam. Keberhasilan berarti tekanan shard bermasalah menurun, biaya kueri dapat diterima, dan hasil bisnis tidak berubah. **Key yang tepat menyeimbangkan distribusi beban dengan cara aplikasi membaca dan memperbarui data.**

Bukti	Pilihan yang perlu dievaluasi	Batas penting
Banyak partisi yang dapat dipindahkan berada pada satu shard	Seimbangkan ke kapasitas yang tersedia	Pemindahan data hanya membantu jika pekerjaan terkait ikut berpindah
Pembacaan produk yang sama berulang kali	Cache atau replika baca jika kesegaran yang dibutuhkan memungkinkan	Ini tidak membagi penulisan pada produk tersebut
Satu merchant membuat banyak pesanan independen	Bagi merchant menggunakan key tambahan berbasis pesanan atau bucket	Kueri seluruh merchant mungkin perlu beberapa pembacaan dan penggabungan hasil
Banyak penulisan berebut record stok yang sama	Kurangi perebutan atau rancang ulang alokasi stok	Penambahan shard tidak menghilangkan kebutuhan koordinasi untuk menjaga kebenaran

1. Ukur ketimpangan sebelum mengganti key

2. Pahami mengapa distribusi sekarang tetap timpang

3. Sesuaikan penanganan dengan pekerjaan yang kelebihan beban

4. Periksa biaya membagi satu merchant

5. Migrasikan dengan cara membuktikan kebenaran

Pertanyaan terkait