Kako riješiti neravnomjernu raspodjelu podataka i preopterećene particije pri shardingu?

Question

IT Interview Practice · Accepted Answer

**Najprije utvrdite što je neravnomjerno: pohranjeni podaci, promet zahtjeva ili izmjene jednog zapisa.** Dodavanje poslužitelja pomaže samo ako se preopterećeni rad može premjestiti na njih.

Pretpostavimo da se narudžbe dijele prema ID-ju trgovca. Većina trgovaca je mala, ali jedan pokreće veliku kampanju. Njegov shard postaje preopterećen dok su drugi mirni. To je vruća particija: prima više rada nego što može obraditi.

## 1. Izmjerite neravnotežu prije promjene ključa

Usporedite veličinu podataka, broj zahtjeva, latenciju i opterećenje CPU-a ili diska među shardovima. Zatim preopterećeni shard razložite po trgovcu i operaciji. Shard sa starim zapisima može biti velik, ali neaktivan; mali shard mogu preopteretiti stalne promjene jednog popularnog artikla.

Za kampanju utvrdite dolazi li opterećenje od čitanja proizvoda, stvaranja mnogo neovisnih narudžbi ili stalnog mijenjanja istog zapisa zalihe. Ta tri slučaja traže različite lijekove.

## 2. Shvatite zašto raspodjela ostaje neravnomjerna

Shard ključ odlučuje kamo idu zapisi. Hashiranje ID-jeva trgovaca može raspodijeliti različite trgovce, ali sve narudžbe istog ključa i dalje slijede isto pravilo smještaja. Hashiranje ne dijeli automatski opterećenje jednog trgovca.

Ključevi s malo različitih vrijednosti ograničavaju mogućnosti podjele. Vremenski raspon može koncentrirati nove upise u najnovijoj particiji. Raspršeniji ključ može poboljšati raspodjelu, ali uobičajene upite prisiliti na više shardova. MongoDB-ove [smjernice za shard ključ](https://www.mongodb.com/docs/manual/core/sharding-choose-a-shard-key/) objašnjavaju te kompromise.

## 3. Uskladite rješenje s preopterećenim radom

| Dokaz | Smjer za procjenu | Važna granica |
|---|---|---|
| Mnogo pomičnih particija nalazi se na jednom shardu | Raspodijeliti ih prema dostupnom kapacitetu | Premještanje pomaže samo ako se preseli i povezani rad |
| Ponavljano čitanje istog proizvoda | Cache ili replike za čitanje ako svježina dopušta | Ne raspodjeljuje upise tog proizvoda |
| Jedan trgovac stvara mnogo neovisnih narudžbi | Podijeliti ga dodatnim ključem narudžbe ili spremnikom | Upiti za cijelog trgovca mogu trebati više čitanja i spajanje rezultata |
| Mnogo upisa natječe se za isti zapis zalihe | Smanjiti natjecanje ili promijeniti dodjelu zalihe | Više shardova ne uklanja koordinaciju potrebnu za ispravnost |

Izdvajanje velikog trgovca može zaštititi druge korisnike i kupiti vrijeme. Ne daje mu neograničen kapacitet pa i dalje mjerite njegovo usko grlo.

## 4. Provjerite cijenu podjele trgovca

Zamislite usmjeravanje narudžbi prema ID-ju trgovca i spremniku izračunatom iz ID-ja narudžbe. Neovisne narudžbe kampanje tada mogu biti u više particija.

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

Dohvat jedne narudžbe lakši je ako se njezin spremnik može izračunati. Dohvat svih nedavnih narudžbi trgovca A sada čita više particija i spaja rezultate redom. Paginacija, zbrojevi i transakcije preko particija postaju složeniji. Odaberite podjelu tek kad provjerite prihvatljivost dodatnog čitanja i koordinacije.

## 5. Migrirajte uz dokaz ispravnosti

Promjena usmjeravanja dok upisi traju zahtijeva migracijski plan. Kopirajte postojeće zapise, uhvatite promjene tijekom kopiranja i usporedite broj zapisa te poslovne zbrojeve prije prebacivanja prometa. Sam broj zapisa može propustiti pogrešne iznose.

Definirajte postupanje s upisima u tijeku pri prebacivanju i povratak usmjeravanja bez gubitka upisa prihvaćenih u novom rasporedu. Dvostruki upisi trebaju obradu kvarova; pisanje na dva mjesta ne jamči jednakost.

Na kraju testirajte stvarno neravnomjerno opterećenje, uključujući velikog trgovca, umjesto jednoliko generiranog prometa. Uspjeh znači manji pritisak na preopterećeni shard, prihvatljive troškove upita i nepromijenjene poslovne rezultate. **Dobar ključ usklađuje raspodjelu rada s načinom čitanja i mijenjanja podataka.**

Dokaz	Smjer za procjenu	Važna granica
Mnogo pomičnih particija nalazi se na jednom shardu	Raspodijeliti ih prema dostupnom kapacitetu	Premještanje pomaže samo ako se preseli i povezani rad
Ponavljano čitanje istog proizvoda	Cache ili replike za čitanje ako svježina dopušta	Ne raspodjeljuje upise tog proizvoda
Jedan trgovac stvara mnogo neovisnih narudžbi	Podijeliti ga dodatnim ključem narudžbe ili spremnikom	Upiti za cijelog trgovca mogu trebati više čitanja i spajanje rezultata
Mnogo upisa natječe se za isti zapis zalihe	Smanjiti natjecanje ili promijeniti dodjelu zalihe	Više shardova ne uklanja koordinaciju potrebnu za ispravnost

1. Izmjerite neravnotežu prije promjene ključa

2. Shvatite zašto raspodjela ostaje neravnomjerna

3. Uskladite rješenje s preopterećenim radom

4. Provjerite cijenu podjele trgovca

5. Migrirajte uz dokaz ispravnosti

Povezana pitanja