Bagaimanakah mengatasi taburan data tidak sekata dan hot partition semasa sharding?

Question

IT Interview Practice · Accepted Answer

**Kenal pasti dahulu perkara yang tidak seimbang: data tersimpan, trafik permintaan atau kemas kini satu rekod.** Pelayan tambahan hanya membantu apabila kerja berlebihan boleh dipindahkan kepadanya.

Andaikan pesanan dibahagi mengikut ID peniaga. Kebanyakannya kecil, tetapi seorang menjalankan kempen besar. Shardnya terlebih beban sedangkan yang lain lengang. Inilah hot partition: partisi yang menerima kerja melebihi kemampuannya.

## 1. Ukur ketidakseimbangan sebelum menukar kunci

Bandingkan saiz data, kadar permintaan, latensi serta tekanan CPU atau cakera antara shard. Kemudian pecahkan shard bermasalah mengikut peniaga dan operasi. Shard besar berisi rekod lama boleh tidak sibuk; shard kecil boleh dibebani kemas kini berulang pada satu produk popular.

Untuk kempen, tentukan sama ada beban datang daripada bacaan produk, penciptaan banyak pesanan bebas atau perubahan berulang rekod stok sama. Ketiga-tiganya memerlukan penyelesaian berlainan.

## 2. Fahami sebab pengagihan kekal tidak seimbang

Kunci shard menentukan lokasi rekod. Hash ID peniaga boleh mengagihkan peniaga berlainan, tetapi semua pesanan dengan kunci peniaga sama masih mengikuti aturan penempatan sama. Hash tidak membahagi beban seorang peniaga secara automatik.

Kunci dengan sedikit nilai berbeza mengehadkan peluang pembahagian. Julat masa boleh menumpukan tulisan baharu pada partisi terkini. Kunci lebih berselerak boleh membaiki agihan tetapi menyebabkan pertanyaan biasa menghubungi banyak shard. [Panduan kunci shard](https://www.mongodb.com/docs/manual/core/sharding-choose-a-shard-key/) MongoDB menerangkan pertimbangan ini.

## 3. Padankan penyelesaian dengan kerja berlebihan

| Bukti | Arah penilaian | Batas penting |
|---|---|---|
| Banyak partisi boleh pindah berada pada satu shard | Seimbangkan ke kapasiti tersedia | Pemindahan data membantu jika kerja berkaitan turut berpindah |
| Bacaan berulang produk sama | Cache atau replika bacaan jika kesegaran membenarkan | Ini tidak mengagihkan penulisan produk itu |
| Seorang peniaga mencipta banyak pesanan bebas | Pecahkan dengan kunci pesanan tambahan atau bucket | Pertanyaan seluruh peniaga mungkin memerlukan bacaan berganda dan gabungan |
| Banyak penulisan berebut rekod stok sama | Kurangkan perebutan atau ubah peruntukan stok | Shard tambahan tidak menghapuskan penyelarasan ketepatan |

Mengasingkan peniaga besar boleh melindungi penyewa lain dan memberi masa. Ia tidak memberi kapasiti tanpa had kepadanya, jadi ukur kesesakan individunya juga.

## 4. Semak kos memecahkan seorang peniaga

Bayangkan pesanan diarahkan dengan ID peniaga bersama bucket daripada ID pesanan. Pesanan kempen yang bebas boleh ditempatkan merentas beberapa partisi.

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

Mendapatkan satu pesanan mudah jika bucket boleh dikira. Mendapatkan semua pesanan terkini Peniaga A kini memerlukan beberapa partisi dibaca dan digabung mengikut turutan. Penomboran halaman, jumlah dan transaksi rentas partisi menjadi rumit. Pilih pembahagian selepas memastikan kos bacaan dan penyelarasan tambahan boleh diterima.

## 5. Migrasi dengan bukti ketepatan

Mengubah aturan penghalaan ketika penulisan berterusan memerlukan rancangan. Salin rekod, tangkap perubahan semasa penyalinan dan padankan bilangan serta jumlah perniagaan sebelum menukar trafik. Bilangan sahaja boleh terlepas amaun pesanan salah.

Tentukan penulisan yang sedang berjalan ketika peralihan dan cara mengundur penghalaan tanpa kehilangan tulisan diterima susun atur baharu. Penulisan dwi perlu pengendalian kegagalan; menulis di dua tempat sahaja tidak menjamin kesamaan.

Akhirnya, uji beban sebenar yang tidak seimbang termasuk peniaga besar, bukan trafik seragam. Kejayaan ialah kurang tekanan pada shard bermasalah, kos pertanyaan diterima dan hasil perniagaan tidak berubah. **Kunci yang tepat mengimbangi agihan beban dengan cara aplikasi membaca dan mengemas kini data.**

Bukti	Arah penilaian	Batas penting
Banyak partisi boleh pindah berada pada satu shard	Seimbangkan ke kapasiti tersedia	Pemindahan data membantu jika kerja berkaitan turut berpindah
Bacaan berulang produk sama	Cache atau replika bacaan jika kesegaran membenarkan	Ini tidak mengagihkan penulisan produk itu
Seorang peniaga mencipta banyak pesanan bebas	Pecahkan dengan kunci pesanan tambahan atau bucket	Pertanyaan seluruh peniaga mungkin memerlukan bacaan berganda dan gabungan
Banyak penulisan berebut rekod stok sama	Kurangkan perebutan atau ubah peruntukan stok	Shard tambahan tidak menghapuskan penyelarasan ketepatan

1. Ukur ketidakseimbangan sebelum menukar kunci

2. Fahami sebab pengagihan kekal tidak seimbang

3. Padankan penyelesaian dengan kerja berlebihan

4. Semak kos memecahkan seorang peniaga

5. Migrasi dengan bukti ketepatan

Soalan berkaitan