शार्डिंग में डेटा का असंतुलन और हॉट पार्टिशन कैसे ठीक करें?

Question

IT Interview Practice · Accepted Answer

**पहले पहचानें कि असमान क्या है: stored data, request traffic या एक record के updates।** Servers बढ़ाने से तभी मदद मिलती है जब overloaded काम उन तक जा सके।

मान लें 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 एक लोकप्रिय item के repeated updates से भर सकता है।

Campaign में पता करें कि load product details पढ़ने से, कई independent orders बनाने से या एक inventory record बार-बार बदलने से आता है। तीनों के उपाय अलग हैं।

## 2. समझें कि मौजूदा distribution असमान क्यों रहता है

Shard key तय करती है कि records कहां जाएंगे। Merchant IDs hash करने से अलग merchants फैल सकते हैं, लेकिन समान merchant key वाले सभी orders वही placement rule मानते हैं। Hashing एक merchant का load अपने-आप नहीं बांटता।

कम distinct values वाली keys data split करने के मौके सीमित करती हैं। Time range नई writes को सबसे नए partition पर केंद्रित कर सकती है। अधिक बिखरी key distribution सुधार सकती है, पर सामान्य queries को कई shards तक जाना पड़ सकता है। MongoDB की [shard-key guidance](https://www.mongodb.com/docs/manual/core/sharding-choose-a-shard-key/) ये पहलू समझाती है।

## 3. Overloaded काम के अनुसार उपाय चुनें

| प्रमाण | परखने की दिशा | महत्वपूर्ण सीमा |
|---|---|---|
| एक shard में कई movable partitions | उपलब्ध capacity में rebalance करें | Data के साथ संबंधित काम भी जाए तभी लाभ है |
| समान product के repeated reads | Freshness स्वीकार हो तो cache या read replicas | उस product की writes नहीं बंटतीं |
| एक merchant कई independent orders बनाता है | अतिरिक्त order-based key या bucket से बांटें | पूरे 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 और cross-partition transactions जटिल होंगे। अतिरिक्त read और coordination cost स्वीकार्य हो तभी split चुनें।

## 5. Correctness साबित कर सकने वाली migration करें

Writes चलते समय routing बदलने को migration plan चाहिए। Existing records copy करें, इस दौरान changes पकड़ें और traffic switch से पहले record counts तथा business totals reconcile करें। केवल counts गलत order values छोड़ सकते हैं।

Cutover पर in-flight writes कैसे संभलेंगी और नए layout की accepted writes खोए बिना routing rollback कैसे होगा, तय करें। Dual writes को failure handling चाहिए; दो जगह लिखना समानता की guarantee नहीं है।

अंत में uniform traffic के बजाय बड़े merchant सहित वास्तविक skewed workload से जांचें। सफलता है overloaded shard पर कम pressure, स्वीकार्य query costs और अपरिवर्तित business results। **सही key workload distribution को application के reads और updates के साथ संतुलित करती है।**

प्रमाण	परखने की दिशा	महत्वपूर्ण सीमा
एक shard में कई movable partitions	उपलब्ध capacity में rebalance करें	Data के साथ संबंधित काम भी जाए तभी लाभ है
समान product के repeated reads	Freshness स्वीकार हो तो cache या read replicas	उस product की writes नहीं बंटतीं
एक merchant कई independent orders बनाता है	अतिरिक्त order-based key या bucket से बांटें	पूरे merchant की queries में कई reads और result merging लग सकती है
एक inventory record पर बहुत-सी writes भिड़ती हैं	Contention घटाएं या stock allocation बदलें	अधिक shards correctness के coordination को नहीं हटाते

1. Key बदलने से पहले असंतुलन मापें

2. समझें कि मौजूदा distribution असमान क्यों रहता है

3. Overloaded काम के अनुसार उपाय चुनें

4. Merchant बांटने की कीमत जांचें

5. Correctness साबित कर सकने वाली migration करें

संबंधित प्रश्न