Come correggere lo sbilanciamento dei dati e le partizioni sovraccariche nello sharding?

Question

IT Interview Practice · Accepted Answer

**Identifica prima cosa è distribuito male: dati memorizzati, traffico delle richieste o aggiornamenti di un singolo record.** Aggiungere server aiuta solo quando il lavoro sovraccarico può essere spostato su di essi.

Supponiamo che gli ordini siano suddivisi per ID del commerciante. Quasi tutti i commercianti sono piccoli, ma uno avvia una grande campagna. Il suo shard si sovraccarica mentre gli altri restano poco utilizzati. Questa è una hot partition: una partizione che riceve più lavoro di quanto possa gestire.

## 1. Misura lo squilibrio prima di cambiare chiave

Confronta dimensione dei dati, frequenza delle richieste, latenza e pressione su CPU o disco tra gli shard. Poi analizza lo shard sovraccarico per commerciante e operazione. Uno shard con vecchi record può essere grande ma inattivo; uno piccolo può essere travolto da aggiornamenti ripetuti dello stesso articolo popolare.

Per la campagna, stabilisci se il carico deriva dalla lettura dei dettagli dei prodotti, dalla creazione di molti ordini indipendenti o da modifiche ripetute allo stesso record di inventario. I tre casi richiedono rimedi diversi.

## 2. Comprendi perché la distribuzione attuale resta squilibrata

La shard key decide dove collocare i record. Applicare un hash agli ID dei commercianti può distribuire commercianti diversi tra shard, ma tutti gli ordini con la stessa chiave seguono ancora la medesima regola di collocazione. L'hash non divide automaticamente il carico di un singolo commerciante.

Chiavi con pochi valori distinti limitano le possibilità di suddivisione. Un intervallo temporale può concentrare le nuove scritture nell'ultima partizione. Una chiave più dispersa può migliorare la distribuzione ma costringere le query comuni a contattare molti shard. La [guida alla shard key](https://www.mongodb.com/docs/manual/core/sharding-choose-a-shard-key/) di MongoDB illustra queste considerazioni.

## 3. Associa il rimedio al lavoro sovraccarico

| Evidenza | Direzione da valutare | Limite importante |
|---|---|---|
| Molte partizioni trasferibili sono sullo stesso shard | Ribilanciarle sulla capacità disponibile | Spostare dati aiuta solo se si sposta anche il lavoro associato |
| Letture ripetute dello stesso prodotto | Cache o repliche di lettura, se l'aggiornamento richiesto lo consente | Non distribuisce le scritture su quel prodotto |
| Un commerciante crea molti ordini indipendenti | Dividerlo con una chiave aggiuntiva basata sull'ordine o un bucket | Le query sull'intero commerciante possono richiedere più letture e fusione dei risultati |
| Molte scritture competono sullo stesso record di inventario | Ridurre la contesa o riprogettare l'assegnazione delle scorte | Più shard non eliminano il coordinamento necessario alla correttezza |

Isolare il grande commerciante può proteggere gli altri tenant e far guadagnare tempo. Non gli offre capacità illimitata: occorre comunque misurarne il collo di bottiglia individuale.

## 4. Valuta il costo della suddivisione di un commerciante

Immagina di instradare gli ordini usando l'ID del commerciante più un bucket derivato dall'ID dell'ordine. Gli ordini indipendenti della campagna possono così essere collocati su più partizioni.

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

Recuperare un ordine è più semplice quando il suo bucket è calcolabile. Recuperare tutti gli ordini recenti del commerciante A richiede ora di leggere più partizioni e unire i risultati in ordine. Paginazione, totali e transazioni tra partizioni diventano più complessi. Scegli la suddivisione solo dopo aver verificato che questo costo aggiuntivo di lettura e coordinamento sia accettabile.

## 5. Migra con un modo per dimostrare la correttezza

Cambiare la regola di instradamento mentre continuano le scritture richiede un piano. Copia i record esistenti, acquisisci le modifiche avvenute durante la copia e riconcilia conteggi e totali aziendali prima di spostare il traffico. I soli conteggi possono non rilevare valori d'ordine errati.

Definisci come gestire le scritture in corso al passaggio e come ripristinare l'instradamento senza perdere scritture accettate dalla nuova disposizione. Le scritture doppie richiedono gestione degli errori: scrivere in due posti non garantisce che restino identici.

Infine, prova il carico realmente sbilanciato, incluso il grande commerciante, invece di traffico generato uniformemente. Il successo significa minore pressione sullo shard sovraccarico, costi di query accettabili e risultati aziendali invariati. **La chiave giusta bilancia la distribuzione del carico con il modo in cui l'applicazione legge e aggiorna i dati.**

Evidenza	Direzione da valutare	Limite importante
Molte partizioni trasferibili sono sullo stesso shard	Ribilanciarle sulla capacità disponibile	Spostare dati aiuta solo se si sposta anche il lavoro associato
Letture ripetute dello stesso prodotto	Cache o repliche di lettura, se l'aggiornamento richiesto lo consente	Non distribuisce le scritture su quel prodotto
Un commerciante crea molti ordini indipendenti	Dividerlo con una chiave aggiuntiva basata sull'ordine o un bucket	Le query sull'intero commerciante possono richiedere più letture e fusione dei risultati
Molte scritture competono sullo stesso record di inventario	Ridurre la contesa o riprogettare l'assegnazione delle scorte	Più shard non eliminano il coordinamento necessario alla correttezza

1. Misura lo squilibrio prima di cambiare chiave

2. Comprendi perché la distribuzione attuale resta squilibrata

3. Associa il rimedio al lavoro sovraccarico

4. Valuta il costo della suddivisione di un commerciante

5. Migra con un modo per dimostrare la correttezza

Domande correlate