Shardingમાં data skew અને hot partition કેવી રીતે સુધારશો?

Question

IT Interview Practice · Accepted Answer

**પહેલાં ઓળખો કે અસમાન શું છે: સાચવેલો ડેટા, request traffic કે એક recordના updates.** વધુ server ત્યારે જ મદદ કરે જ્યારે વધુ ભારવાળું કામ તેમની પાસે ખસેડી શકાય.

માનો કે orders merchant ID પ્રમાણે વહેંચાય છે. મોટા ભાગના merchants નાના છે, પરંતુ એક મોટી campaign ચલાવે છે. તેનો shard ભરાઈ જાય છે અને બીજા શાંત રહે છે. આ hot partition છે: તે પોતાની ક્ષમતા કરતાં વધુ કામ મેળવે છે.

## 1. Key બદલતાં પહેલાં અસમાનતા માપો

Shards વચ્ચે data size, request rate, latency અને CPU અથવા disk pressure સરખાવો. પછી overloaded shardને merchant અને operation પ્રમાણે જુઓ. જૂના recordsવાળો shard મોટો છતાં નિષ્ક્રિય હોઈ શકે; નાનો shard લોકપ્રિય વસ્તુના સતત updatesથી ભરાઈ શકે.

Campaignમાં load product details વાંચવાથી, ઘણા independent orders બનાવવાથી કે સમાન inventory record વારંવાર બદલવાથી આવે છે તે શોધો. ત્રણેય માટે જુદા ઉકેલ જોઈએ.

## 2. હાલનું distribution અસમાન કેમ રહે છે તે સમજો

Shard key records ક્યાં જશે તે નક્કી કરે છે. Merchant IDsનું hashing જુદા merchantsને shardsમાં વહેંચી શકે, પરંતુ સમાન merchant keyવાળા બધા orders હજી સમાન placement rule અનુસરે છે. Hashing એક merchantનો load આપમેળે વહેંચતું નથી.

ઓછી distinct valuesવાળી keys data split કરવાની તક ઘટાડે છે. Time range નવી writesને સૌથી નવા partitionમાં કેન્દ્રિત કરી શકે. વધુ વિખેરાયેલી key distribution સુધારે પણ સામાન્ય queriesને ઘણા shardsનો સંપર્ક કરાવશે. MongoDBનું [shard-key માર્ગદર્શન](https://www.mongodb.com/docs/manual/core/sharding-choose-a-shard-key/) આ બાબતો સમજાવે છે.

## 3. વધુ ભારવાળા કામ પ્રમાણે ઉકેલ પસંદ કરો

| પુરાવો | તપાસવાની દિશા | મહત્વની મર્યાદા |
|---|---|---|
| એક shard પર ઘણા ખસેડી શકાય એવા partitions | ઉપલબ્ધ capacityમાં rebalance કરો | Data સાથે સંબંધિત કામ ખસે ત્યારે જ મદદ મળે |
| સમાન product વારંવાર વાંચાય છે | Freshness મંજૂર કરે તો cache અથવા read replicas | તે productની writes વહેંચાતી નથી |
| એક merchant ઘણા independent orders બનાવે છે | વધારાની order-based key અથવા bucketથી merchant વહેંચો | આખા merchantની queries માટે ઘણા reads અને result merging જોઈએ |
| સમાન inventory record પર ઘણી writes સ્પર્ધા કરે છે | Contention ઘટાડો અથવા stock allocation ફરી ડિઝાઇન કરો | વધુ shards correctness માટેના coordinationની જરૂર દૂર કરતા નથી |

મોટા merchantને અલગ કરવાથી બીજા tenants બચી શકે અને સમય મળે. પરંતુ તે merchantને અમર્યાદિત capacity મળતી નથી, એટલે તેનો પોતાનો bottleneck માપો.

## 4. Merchantને વહેંચવાનો ખર્ચ તપાસો

Merchant ID સાથે order ID પરથી બનેલા bucket દ્વારા routing ધારો. Campaignના independent orders પછી ઘણા partitionsમાં જઈ શકે.

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

Bucket ગણાઈ શકે તો એક order મેળવવો સરળ છે. Merchant Aના બધા recent orders માટે હવે ઘણા partitions વાંચીને યોગ્ય ક્રમમાં merge કરવા પડે. Pagination, totals અને partitions વચ્ચેના transactions વધુ જટિલ બને છે. વધારાનો read અને coordination ખર્ચ સ્વીકાર્ય છે તે તપાસ્યા પછી જ split પસંદ કરો.

## 5. સાચાપણું સાબિત કરી શકાય એવી migration કરો

Writes ચાલુ હોય ત્યારે routing rule બદલવા migration plan જોઈએ. હાલના records copy કરો, copy દરમિયાનના ફેરફાર પકડો અને traffic switch કરતાં પહેલાં record counts તથા business totals reconcile કરો. માત્ર counts ખોટી order values ચૂકી શકે.

Cutover સમયે ચાલુ writes કેવી રીતે સંભાળશો અને નવા layoutએ સ્વીકારેલી writes ગુમાવ્યા વિના routing પાછું કેવી રીતે ફેરવશો તે નક્કી કરો. Dual writesમાં failure handling જોઈએ; બે જગ્યાએ લખવાથી બંને સમાન રહેવાની ખાતરી નથી.

છેલ્લે સમાન રીતે બનાવેલા trafficને બદલે મોટા merchant સહિત વાસ્તવિક skewed workloadથી તપાસો. સફળતા એટલે overloaded shard પર ઓછું pressure, સ્વીકાર્ય query cost અને અચલ business results. **યોગ્ય key workload distributionને applicationના reads અને updates સાથે સંતુલિત કરે છે.**

પુરાવો	તપાસવાની દિશા	મહત્વની મર્યાદા
એક shard પર ઘણા ખસેડી શકાય એવા partitions	ઉપલબ્ધ capacityમાં rebalance કરો	Data સાથે સંબંધિત કામ ખસે ત્યારે જ મદદ મળે
સમાન product વારંવાર વાંચાય છે	Freshness મંજૂર કરે તો cache અથવા read replicas	તે productની writes વહેંચાતી નથી
એક merchant ઘણા independent orders બનાવે છે	વધારાની order-based key અથવા bucketથી merchant વહેંચો	આખા merchantની queries માટે ઘણા reads અને result merging જોઈએ
સમાન inventory record પર ઘણી writes સ્પર્ધા કરે છે	Contention ઘટાડો અથવા stock allocation ફરી ડિઝાઇન કરો	વધુ shards correctness માટેના coordinationની જરૂર દૂર કરતા નથી

1. Key બદલતાં પહેલાં અસમાનતા માપો

2. હાલનું distribution અસમાન કેમ રહે છે તે સમજો

3. વધુ ભારવાળા કામ પ્રમાણે ઉકેલ પસંદ કરો

4. Merchantને વહેંચવાનો ખર્ચ તપાસો

5. સાચાપણું સાબિત કરી શકાય એવી migration કરો

સંબંધિત પ્રશ્નો