Hvordan løser du skæve data og varme partitioner ved sharding?

Question

IT Interview Practice · Accepted Answer

**Find først ud af, hvad der er skævt: lagrede data, anmodninger eller opdateringer af én post.** Flere servere hjælper kun, hvis det overbelastede arbejde kan flyttes til dem.

Antag, at ordrer fordeles efter sælger-ID. De fleste sælgere er små, men én kører en stor kampagne. Dennes shard overbelastes, mens andre er rolige. Det er en hot partition: en partition med mere arbejde, end den kan klare.

## 1. Mål skævheden før nøgleskift

Sammenlign datastørrelse, anmodningsrate, latens og CPU- eller diskpres mellem shards. Opdel derefter den overbelastede shard efter sælger og operation. En shard med gamle poster kan være stor og inaktiv; en lille kan overvældes af gentagne ændringer af én populær vare.

For kampagnen skal du skelne mellem læsning af produktdetaljer, mange uafhængige ordrer og gentagen ændring af samme lagerpost. De kræver forskellige løsninger.

## 2. Forstå den vedvarende skævhed

Shard-nøglen bestemmer placeringen. Hashing af sælger-ID kan sprede forskellige sælgere, men alle ordrer med samme sælgernøgle følger stadig samme placeringsregel. Hashing opdeler ikke automatisk én sælgers belastning.

Nøgler med få forskellige værdier begrænser opdeling. Et tidsinterval kan samle nye skrivninger i den nyeste partition. En mere spredt nøgle kan forbedre fordelingen, men kræve kontakt til mange shards ved almindelige forespørgsler. Se MongoDBs [vejledning til shard-nøgler](https://www.mongodb.com/docs/manual/core/sharding-choose-a-shard-key/).

## 3. Tilpas løsningen til arbejdet

| Evidens | Retning til vurdering | Vigtig begrænsning |
|---|---|---|
| Mange flytbare partitioner på én shard | Omfordel til ledig kapacitet | Dataflytning hjælper kun, hvis arbejdet følger med |
| Gentagen læsning af samme produkt | Cache eller læsereplikaer ved acceptabel friskhed | Fordeler ikke skrivninger til produktet |
| Én sælger skaber mange uafhængige ordrer | Ekstra ordrenøgle eller bucket til opdeling | Samlede sælgerforespørgsler kan kræve flere læsninger og sammenfletning |
| Mange skrivninger konkurrerer om én lagerpost | Reducér konkurrence eller redesign lagertildeling | Flere shards fjerner ikke korrekthedskoordinering |

Isolering af den store sælger kan beskytte andre kunder og købe tid. Den giver ikke ubegrænset kapacitet, så mål stadig sælgerens egen flaskehals.

## 4. Undersøg prisen for at opdele en sælger

Forestil dig routing efter sælger-ID plus en bucket afledt af ordre-ID. Kampagnens uafhængige ordrer kan så fordeles over flere partitioner.

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

En enkelt ordre er lettere at hente, hvis dens bucket kan beregnes. Alle sælger A's nye ordrer kræver nu læsning af flere partitioner og sorteret sammenfletning. Paginering, totaler og tværgående transaktioner bliver mere komplekse. Vælg først opdelingen, når læse- og koordinationsprisen er acceptabel.

## 5. Migrér med bevis for korrekthed

Nye routingregler under fortsatte skrivninger kræver en plan. Kopiér eksisterende poster, opsaml samtidige ændringer, og afstem både antal og forretningstotaler før trafikskift. Antal alene kan overse forkerte ordreværdier.

Definér håndtering af igangværende skrivninger ved skiftet og tilbageførsel uden tab af skrivninger modtaget af den nye struktur. Dobbeltskrivning kræver fejlhåndtering; to skrivninger garanterer ikke identiske lagre.

Test til sidst med den faktiske skæve belastning, inklusive den store sælger, frem for ensartet trafik. Succes er mindre pres på den belastede shard, acceptable forespørgselsomkostninger og uændrede forretningsresultater. **Den rigtige nøgle balancerer arbejdsfordeling med applikationens læsninger og opdateringer.**

Evidens	Retning til vurdering	Vigtig begrænsning
Mange flytbare partitioner på én shard	Omfordel til ledig kapacitet	Dataflytning hjælper kun, hvis arbejdet følger med
Gentagen læsning af samme produkt	Cache eller læsereplikaer ved acceptabel friskhed	Fordeler ikke skrivninger til produktet
Én sælger skaber mange uafhængige ordrer	Ekstra ordrenøgle eller bucket til opdeling	Samlede sælgerforespørgsler kan kræve flere læsninger og sammenfletning
Mange skrivninger konkurrerer om én lagerpost	Reducér konkurrence eller redesign lagertildeling	Flere shards fjerner ikke korrekthedskoordinering

1. Mål skævheden før nøgleskift

2. Forstå den vedvarende skævhed

3. Tilpas løsningen til arbejdet

4. Undersøg prisen for at opdele en sælger

5. Migrér med bevis for korrekthed

Relaterede spørgsmål