Kepiye ngatasi data skew lan hot partition nalika sharding?

Question

IT Interview Practice · Accepted Answer

**Pisanan goleki apa sing ora rata: data sing disimpen, trafik request, utawa pembaruan siji record.** Nambah server mung mbantu yen gaweyan sing kakehan bisa dipindhah menyang server kasebut.

Upamane pesenan dibagi miturut ID pedagang. Umume pedagang cilik, nanging siji nganakake kampanye gedhe. Shard-e kebak beban nalika liyane sepi. Iki hot partition: partisi sing nampa gaweyan luwih akeh tinimbang kemampuane.

## 1. Ukur ketimpangan sadurunge ngganti key

Bandhingake ukuran data, laju request, latensi, lan tekanan CPU utawa disk antarane shard. Banjur rinci shard sing kakehan beban miturut pedagang lan operasi. Shard kanthi record lawas bisa gedhe nanging ora sibuk; shard cilik bisa kewalahan amarga pembaruan bola-bali siji barang populer.

Kanggo kampanye iki, temtokake apa beban saka maca rincian produk, nggawe akeh pesenan mandiri, utawa ngowahi record stok sing padha bola-bali. Telung kasus kasebut butuh obat beda.

## 2. Pahami sebabe distribusi saiki tetep ora rata

Shard key nemtokake panggonan record. Hash ID pedagang bisa nyebar pedagang beda ing sawetara shard, nanging kabeh pesenan kanthi key pedagang padha tetep manut aturan panggonan sing padha. Hash ora otomatis mbagi beban siji pedagang.

Key kanthi sithik nilai beda matesi kesempatan mbagi data. Rentang wektu bisa nglumpukake panulisan anyar ing partisi paling anyar. Key luwih nyebar bisa ndandani distribusi nanging nggawe query umum ngubungi akeh shard. [Pandhuan shard key](https://www.mongodb.com/docs/manual/core/sharding-choose-a-shard-key/) MongoDB nerangake pertimbangan kasebut.

## 3. Cocogake solusi karo gaweyan sing kakehan

| Bukti | Pilihan sing dievaluasi | Wates penting |
|---|---|---|
| Akeh partisi bisa dipindhah ana ing siji shard | Seimbangake menyang kapasitas sing ana | Mindhah data mung mbantu yen gaweyan gandhengan uga pindhah |
| Wacan produk sing padha bola-bali | Cache utawa read replica yen kesegaran ngidini | Ora mbagi panulisan menyang produk kasebut |
| Siji pedagang nggawe akeh pesenan mandiri | Bagi nganggo key tambahan saka pesenan utawa bucket | Query kabeh pedagang bisa butuh sawetara wacan lan nggabung asil |
| Akeh panulisan rebutan siji record stok | Kurangi rebutan utawa desain ulang alokasi stok | Shard luwih akeh ora ngilangi koordinasi kanggo njaga bener |

Misahake pedagang gedhe bisa nglindhungi tenant liya lan menehi wektu. Nanging ora menehi kapasitas tanpa wates, mula tetep ukur hambatan pedagang kasebut.

## 4. Priksa biaya mbagi siji pedagang

Bayangna pesenan diarahake nganggo ID pedagang ditambah bucket saka ID pesenan. Pesenan mandiri kampanye bisa diselehake ing sawetara partisi.

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

Njupuk siji pesenan luwih gampang yen bucket bisa diitung. Njupuk kabeh pesenan anyar Pedagang A saiki kudu maca sawetara partisi lan nggabung kanthi urut. Pagination, total, lan transaksi lintas partisi luwih rumit. Pilih pembagian sawise mriksa biaya tambahan maca lan koordinasi bisa ditampa.

## 5. Migrasi kanthi cara mbuktekake asil bener

Ngganti aturan routing nalika panulisan terus mlaku butuh rencana migrasi. Salin record, cathet owah-owahan sajrone nyalin, lan cocokake cacah record uga total bisnis sadurunge ngalih trafik. Cacah wae bisa ora nemokake nilai pesenan sing salah.

Temtokake penanganan panulisan sing isih mlaku nalika ngalih lan cara mbalekake routing tanpa kelangan panulisan sing ditampa tata letak anyar. Dual write butuh penanganan kegagalan; mung nulis ing rong panggonan ora njamin tetep padha.

Pungkasan, uji nganggo beban nyata sing timpang, kalebu pedagang gedhe, ora mung trafik seragam. Sukses tegese tekanan shard mudhun, biaya query bisa ditampa, lan asil bisnis ora owah. **Key sing trep ngimbangi distribusi beban karo carane aplikasi maca lan nganyari data.**

Bukti	Pilihan sing dievaluasi	Wates penting
Akeh partisi bisa dipindhah ana ing siji shard	Seimbangake menyang kapasitas sing ana	Mindhah data mung mbantu yen gaweyan gandhengan uga pindhah
Wacan produk sing padha bola-bali	Cache utawa read replica yen kesegaran ngidini	Ora mbagi panulisan menyang produk kasebut
Siji pedagang nggawe akeh pesenan mandiri	Bagi nganggo key tambahan saka pesenan utawa bucket	Query kabeh pedagang bisa butuh sawetara wacan lan nggabung asil
Akeh panulisan rebutan siji record stok	Kurangi rebutan utawa desain ulang alokasi stok	Shard luwih akeh ora ngilangi koordinasi kanggo njaga bener

1. Ukur ketimpangan sadurunge ngganti key

2. Pahami sebabe distribusi saiki tetep ora rata

3. Cocogake solusi karo gaweyan sing kakehan

4. Priksa biaya mbagi siji pedagang

5. Migrasi kanthi cara mbuktekake asil bener

Pitakon sing gegandhengan