स्केलिंग योजना: रेप्लिका सेट से शार्डेड क्लस्टर तक
शिक्षार्थी क्षमता योजना तैयार करेंगे और ऐसा शार्ड कुंजी चुनेंगे जो हॉट स्पॉट बनाए बिना एप्लिकेशन के रीड और राइट वितरण का समर्थन करे।
स्केलिंग योजना: रेप्लिका सेट से शार्डेड क्लस्टर तक, CoddyKit पर MongoDB Academy का एक निःशुल्क पाठ है। यह 4 में से 3वाँ पाठ है। आप नीचे पूरा पाठ निःशुल्क पढ़ सकते हैं—फिर अंतर्निहित कोड संपादक और 24/7 एआई ट्यूटर के साथ ब्राउज़र में इसका व्यावहारिक अभ्यास कर सकते हैं। यह MongoDB Academy सीखने के मार्ग का हिस्सा है और आपकी प्रगति वेब तथा CoddyKit ऐप पर सिंक होती रहती है। MongoDB Academy पाठ्यक्रम में कुल 4 पाठ शामिल हैं।
आपको Scale करने की आवश्यकता कब होती है?
अधिकांश एप्लिकेशन एकल MongoDB रेप्लिका सेट से शुरू होते हैं और उन्हें कभी शार्डिंग की आवश्यकता नहीं पड़ती। शार्डिंग से काफी जटिलता बढ़ती है, इसलिए इसे पहला विकल्प नहीं, बल्कि अंतिम उपाय मानना चाहिए। शार्डिंग पर तब विचार करें जब: आपके डेटा का حجم उतना बढ़ जाए कि एकल रेप्लिका सेट में उसे किफायती रूप से संग्रहित करना संभव न रहे; लेखन की गति एकल प्राइमरी की क्षमता से अधिक हो जाए; या कुछ विशिष्ट कलेक्शन इतने बड़े हो जाएँ कि उन्हें मेमोरी में कुशलतापूर्वक अनुक्रमित न किया जा सके। शार्डिंग से पहले हमेशा वर्टिकल स्केलिंग (बड़े इंस्टेंस) और पठन स्केलिंग (पठन को सेकेंडरी सदस्यों में वितरित करना) आज़माएँ।
चरण 1: एकल रेप्लिका सेट
किसी भी MongoDB परिनियोजन के लिए मानक शुरुआती व्यवस्था एक 3-सदस्यीय रेप्लिका सेट है: एक प्राइमरी और दो सेकेंडरी। इससे उच्च उपलब्धता (प्राइमरी के विफल होने पर स्वचालित फेलओवर), डेटा स्थायित्व (लेखन को कई सदस्यों में दोहराया जाना) और पठन स्केलिंग (रिपोर्टिंग कार्यभार के लिए सेकेंडरी सदस्यों को पठन भेजना) मिलता है। हमारे ई-कॉमर्स कैपस्टोन के लिए, 3-सदस्यीय M30 Atlas क्लस्टर प्रतिदिन के लाखों ऑर्डरों को आसानी से संभाल लेता है। यहीं से शुरू करें और शार्डिंग पर विचार करने से पहले माप लें।
// Capacity metrics to monitor on a single replica set
// (via Atlas Metrics or db.serverStatus())
const metricsToWatch = [
'connections.current', // approaching maxIncomingConnections?
'opcounters.insert', // write ops/sec approaching primary limit?
'mem.resident', // working set fitting in RAM?
'wiredTiger.cache.bytesCurrentlyInCache', // cache utilisation
'replicationLag' // secondaries keeping up?
]चरण 2: सेकेंडरी पठन के साथ पठन स्केलिंग
शार्डिंग से पहले, readPreference: 'secondary' का उपयोग करके एनालिटिक्स और रिपोर्टिंग क्वेरी को सेकेंडरी सदस्यों तक भेजकर पठन को स्केल करें। इससे संचालन संबंधी जटिलता बढ़ाए बिना प्राइमरी पर पठन का दबाव कम होता है। Atlas में Analytics Nodes समर्पित सेकेंडरी सदस्य होते हैं (जिन्हें कभी प्राइमरी नहीं चुना जाता) और वे भारी एग्रीगेशन कार्यभार संभालते हैं, जिससे प्राइमरी के प्रदर्शन पर असर नहीं पड़ता। यह तरीका तब तक अच्छी तरह काम करता है, जब तक लेखन की गति स्वयं बाधा न बन जाए।
// Route heavy analytics to secondary nodes
const { MongoClient } = require('mongodb')
const client = new MongoClient(process.env.ATLAS_URI, {
readPreference: 'secondary' // global default for this client
})
// Or per-operation
const result = await db.collection('orders').aggregate(
[ /* heavy reporting pipeline */ ],
{ readPreference: 'secondary' } // does not compete with primary writes
)चरण 3: शार्डिंग कब करें
तब शार्ड करें जब आप ऐसी सीमा पर पहुँच जाएँ जिसे वर्टिकल स्केलिंग हल नहीं कर सकती: सबसे बड़े उपलब्ध इंस्टेंस के साथ भी प्राइमरी की लेखन क्षमता पूरी तरह संतृप्त हो जाए; किसी कलेक्शन का कार्यशील डेटा-समुच्चय (सक्रिय रूप से उपयोग में आने वाला डेटा और इंडेक्स) सबसे बड़े स्तर पर भी क्लस्टर की RAM में न समाए; या कोई विशिष्ट कलेक्शन इतना बड़ा हो जाए कि उसे एक क्लस्टर की डिस्क पर संग्रहित न किया जा सके। व्यवहार में, अधिकांश एप्लिकेशन लेखन क्षमता की सीमाओं से पहले RAM की सीमाओं तक पहुँचते हैं—हर महीने WiredTiger कैश उपयोग और कार्यशील डेटा-समुच्चय के आकार की निगरानी करें।
// Indicator: working set exceeding cache
// db.serverStatus().wiredTiger.cache
const cache = db.serverStatus().wiredTiger.cache
const cacheHitRatio = 1 - (cache['pages read into cache'] / cache['pages requested from the cache'])
console.log('Cache hit ratio:', (cacheHitRatio * 100).toFixed(1) + '%')
// Below 95%: working set is not fitting in cache — time to scaleकिस कलेक्शन को शार्ड करें
केवल उन्हीं कलेक्शन को शार्ड करें जो बाधा उत्पन्न कर रहे हैं। हमारे ई-कॉमर्स प्लेटफ़ॉर्म में orders कलेक्शन सबसे तेज़ी से बढ़ेगा और सबसे अधिक लेखन ट्रैफ़िक उत्पन्न करेगा। products कलेक्शन बड़ा हो सकता है, लेकिन इसमें अधिकतर पठन होता है, जिसे सेकेंडरी सदस्यों से पूरा किया जा सकता है। orders को शार्ड करते हुए products को अनशार्डेड रखना (हर शार्ड पर ब्रॉडकास्ट कलेक्शन के रूप में) एक सामान्य और व्यावहारिक तरीका है।
// Enable sharding on the database
sh.enableSharding('ecommerce')
// Shard the orders collection
sh.shardCollection('ecommerce.orders', { userId: 'hashed' })
// Verify shard distribution
sh.status()
db.orders.getShardDistribution()Orders के लिए शार्ड कुंजी का चयन
orders की शार्ड कुंजी को लेखन को सभी शार्ड में समान रूप से वितरित करना चाहिए और सबसे सामान्य क्वेरी पैटर्न का समर्थन करना चाहिए। userId को हैश्ड शार्ड कुंजी के रूप में उपयोग करने पर लेखन समान रूप से वितरित होता है, क्योंकि उपयोगकर्ता आईडी में बहुत अधिक भिन्न मान होते हैं और वे यादृच्छिक होते हैं। इसका नुकसान यह है कि किसी एक उपयोगकर्ता तक सीमित क्वेरी सभी शार्ड में फैल जाती हैं। { userId: 1, _id: 1 } पर रेंज-आधारित शार्ड कुंजी रखने से एक उपयोगकर्ता के ऑर्डर उसी शार्ड पर रहते हैं (जिससे उपयोगकर्ता-विशिष्ट क्वेरी तेज़ होती हैं), लेकिन यदि कुछ उपयोगकर्ता अधिकांश गतिविधि उत्पन्न करते हैं तो हॉट शार्ड बनने का जोखिम रहता है।
// Option 1: Hashed shard key — uniform write distribution
sh.shardCollection('ecommerce.orders', { userId: 'hashed' })
// Pros: even distribution
// Cons: user order history queries scatter across all shards
// Option 2: Compound ranged shard key — user orders co-located
sh.shardCollection('ecommerce.orders', { userId: 1, _id: 1 })
// Pros: all orders for a user are on one shard — fast history queries
// Cons: may create hot shards if a few users dominate trafficडेटा निवास के लिए ज़ोन शार्डिंग
यदि ई-कॉमर्स प्लेटफ़ॉर्म कई क्षेत्रों में सेवा देता है और डेटा निवास संबंधी आवश्यकताएँ हैं (EU का डेटा यूरोप में ही रहना चाहिए), तो शार्ड कुंजी की सीमाओं के आधार पर दस्तावेज़ों को विशिष्ट शार्ड पर रखने के लिए ज़ोन शार्डिंग का उपयोग करें। प्रत्येक क्षेत्र के लिए ज़ोन बनाएँ, शार्ड को ज़ोन में असाइन करें और निर्धारित करें कि शार्ड कुंजी की कौन-सी सीमाएँ किस ज़ोन से जुड़ेंगी। EU उपयोगकर्ताओं का डेटा EU-क्षेत्र के शार्ड पर रहता है, जिससे अलग-अलग क्लस्टर बनाए रखे बिना GDPR का पालन होता है।
// Zone sharding for regional data residency
// Assign shards to zones
sh.addShardToZone('shard0001', 'EU')
sh.addShardToZone('shard0002', 'US')
sh.addShardToZone('shard0003', 'APAC')
// Define shard key ranges for each region
// (Assuming userId prefix encodes region: 'EU-', 'US-', 'APAC-')
sh.updateZoneKeyRange('ecommerce.orders',
{ userId: 'EU-' }, { userId: 'EU-zzz' }, 'EU'
)
sh.updateZoneKeyRange('ecommerce.orders',
{ userId: 'US-' }, { userId: 'US-zzz' }, 'US'
)mongos और कॉन्फ़िगरेशन सर्वर
शार्ड किए गए क्लस्टर में, mongos इंस्टेंस क्वेरी राउटर स्तर का काम करते हैं। एप्लिकेशन ड्राइवर सीधे शार्ड से नहीं, बल्कि mongos से कनेक्ट होते हैं। mongos कॉन्फ़िग सर्वर रेप्लिका सेट (जिसमें क्लस्टर का मेटाडेटा, चंक मैप और ज़ोन असाइनमेंट होते हैं) को पढ़कर निर्धारित करता है कि प्रत्येक क्वेरी का डेटा किस शार्ड या शार्ड में है। उच्च उपलब्धता के लिए हमेशा कम-से-कम दो mongos इंस्टेंस तैनात करें—वे स्टेटलेस होते हैं और डेटा खोए बिना उन्हें पुनः आरंभ किया जा सकता है।
लक्षित बनाम स्कैटर-गैदर क्वेरी
शार्ड किए गए क्लस्टर में, लक्षित क्वेरी के फ़िल्टर में शार्ड कुंजी शामिल होती है—mongos इसे ठीक एक शार्ड तक भेजता है। स्कैटर-गैदर क्वेरी में शार्ड कुंजी नहीं होती—mongos को इसे सभी शार्ड में प्रसारित करके परिणामों को मिलाना पड़ता है। स्कैटर-गैदर क्वेरी महँगी होती हैं और अधिक दबाव वाले मार्गों पर इनसे बचना चाहिए। अपनी शार्ड कुंजी और क्वेरी पैटर्न इस तरह डिज़ाइन करें कि सबसे अधिक बार चलने वाली क्वेरी में शार्ड कुंजी फ़ील्ड शामिल हो।
// TARGETED: includes shard key (userId) — goes to one shard only
db.orders.find({ userId: 'user-123', status: 'pending' })
// SCATTER-GATHER: no shard key — hits ALL shards (expensive!)
db.orders.find({ status: 'pending', total: { $gt: 100 } })
// Verify with explain in sharded cluster
db.orders.find({ userId: 'user-123' }).explain('executionStats')
// Look for 'SINGLE_SHARD' vs 'SHARD_MERGE' in the winning planक्षमता योजना और निगरानी
क्षमता का मॉडल बनाएँ: दैनिक दस्तावेज़ वृद्धि दर × औसत दस्तावेज़ आकार का अनुमान लगाकर निर्धारित करें कि प्रत्येक शार्ड कब भर जाएगा। Atlas में, उपयोग की सीमाएँ पार होने पर संग्रहण जोड़ने या इंस्टेंस स्तर अपग्रेड करने के लिए Cluster Autoscaling का उपयोग करें। इन स्थितियों के लिए Atlas अलर्ट सेट करें: डिस्क उपयोग 80% से अधिक, 1 घंटे से अधिक समय तक CPU उपयोग 70% से अधिक, और प्रतिकृति विलंब 10 सेकंड से अधिक। सक्रिय निगरानी से रात 3 बजे अचानक की जाने वाली भागदौड़ से बचा जा सकता है।
// Capacity projection script
const avgDocBytes = 1024 // 1 KB average order document
const dailyOrders = 50000
const retentionDays = 365 * 3 // 3 years
const totalOrders = dailyOrders * retentionDays
const totalBytes = totalOrders * avgDocBytes
const totalGB = totalBytes / 1e9
console.log('Projected orders:', totalOrders.toLocaleString())
console.log('Projected storage:', totalGB.toFixed(0), 'GB')
// Add 3x for indexes + WiredTiger overhead
console.log('Recommended disk:', (totalGB * 3).toFixed(0), 'GB')Atlas शार्ड किए गए क्लस्टर बनाम स्वयं-होस्टेड व्यवस्था
Atlas पूरी शार्डिंग अवसंरचना को स्वचालित रूप से प्रबंधित करता है: mongos राउटर, कॉन्फ़िग सर्वर और शार्ड रेप्लिका सेट का प्रावधान करना; चंक्स को संतुलित करना; और क्लस्टर में पैच लगाना। स्वयं-होस्टेड परिनियोजन में प्रत्येक घटक का प्रावधान, निगरानी और रखरखाव मैन्युअल रूप से करना पड़ता है—यह संचालन संबंधी काफी बड़ा बोझ है। अधिकांश टीमों के लिए, Atlas शार्डिंग से मिलने वाली संचालनगत बचत स्वयं-होस्टेड व्यवस्था की तुलना में इसकी अतिरिक्त लागत को उचित ठहराती है, जब तक कि अनुपालन संबंधी आवश्यकताएँ ऑन-प्रिमाइसेस परिनियोजन अनिवार्य न करें।
त्वरित जाँच
इस पाठ में MongoDB और NoSQL डेटाबेस की अवधारणाओं की अपनी समझ जाँचें।
पाठ का पुनरावलोकन
इस पाठ में आपने सीखा: शार्डिंग से पहले वर्टिकल स्केल करें और सेकेंडरी पठन का लाभ उठाएँ—शार्डिंग से काफी जटिलता बढ़ती है, जिसकी अधिकांश एप्लिकेशन को कभी आवश्यकता नहीं पड़ती; शार्ड कुंजी का चयन लेखन वितरण (हैश्ड) और क्वेरी लक्ष्यीकरण (रेंज-आधारित) के बीच संतुलन बनाना चाहिए; और शार्ड कुंजी शामिल करने वाली लक्षित क्वेरी एक ही शार्ड तक जाती हैं, जबकि स्कैटर-गैदर क्वेरी सभी शार्ड को प्रभावित करती हैं और महँगी होती हैं। अगले भाग में हम सुरक्षा को सुदृढ़ करके और उत्पादन-तत्परता जाँच-सूची पूरी करके कैपस्टोन पूरा करेंगे।
एआई शिक्षक के साथ JavaScript सीखें — निःशुल्क
अपने ब्राउज़र में वास्तविक कोड लिखें और चलाएँ, चौबीसों घंटे एआई शिक्षक से तुरंत सहायता पाएँ, और वेब या ऐप पर वहीं से शुरू करें जहाँ आपने छोड़ा था।
- पाठ्यक्रम
- 30
- पाठ
- 120
अक्सर पूछे जाने वाले प्रश्न
क्या “स्केलिंग योजना: रेप्लिका सेट से शार्डेड क्लस्टर तक” पाठ निःशुल्क है?
हाँ—“स्केलिंग योजना: रेप्लिका सेट से शार्डेड क्लस्टर तक” का पूरा पाठ यहाँ वेब पर निःशुल्क पढ़ा जा सकता है। इंटरैक्टिव अभ्यास (अंतर्निहित कोड संपादक और 24/7 एआई ट्यूटर) करने और MongoDB Academy पाठ्यक्रम का बाकी हिस्सा अनलॉक करने के लिए CoddyKit PRO लें। MongoDB Academy पाठ्यक्रम में कुल 4 पाठ शामिल हैं।
“स्केलिंग योजना: रेप्लिका सेट से शार्डेड क्लस्टर तक” में मैं क्या सीखूँगा?
शिक्षार्थी क्षमता योजना तैयार करेंगे और ऐसा शार्ड कुंजी चुनेंगे जो हॉट स्पॉट बनाए बिना एप्लिकेशन के रीड और राइट वितरण का समर्थन करे। आप ब्राउज़र में सीधे चलाए जाने वाले व्यावहारिक कोड के साथ MongoDB Academy का अभ्यास करते हैं, और पाठ पूरा करते समय 24/7 एआई ट्यूटर आपके प्रश्नों के उत्तर देता है।
क्या MongoDB Academy शुरू करने के लिए मुझे किसी अनुभव की आवश्यकता है?
पहले के अनुभव की आवश्यकता नहीं है। CoddyKit पर MongoDB Academy शुरुआती से लेकर उन्नत शिक्षार्थियों तक सभी के लिए व्यवस्थित किया गया है, इसलिए आप यहीं से या शुरुआत से सीखना शुरू कर सकते हैं और अपनी गति से आगे बढ़ सकते हैं। यह 4 में से 3वाँ पाठ है।
“स्केलिंग योजना: रेप्लिका सेट से शार्डेड क्लस्टर तक” पाठ पूरा करने में कितना समय लगता है?
CoddyKit का अधिकांश पाठ लगभग 5–10 मिनट में पूरा हो जाता है। हर पाठ छोटा और संवादात्मक है, इसलिए आप लगातार प्रगति करते हैं और वेब या ऐप पर वहीं से सीखना जारी रख सकते हैं जहाँ आपने छोड़ा था।
क्या मैं इस MongoDB Academy पाठ में कोड लिख और चला सकता हूँ?
हाँ। हर MongoDB Academy पाठ में एक अंतर्निर्मित कोड संपादक शामिल है, जिससे आप सीधे अपने ब्राउज़र में वास्तविक कोड लिख और चला सकते हैं और तुरंत एआई प्रतिक्रिया पा सकते हैं—स्थानीय सेटअप की आवश्यकता नहीं है।
इस पाठ्यक्रम के सभी पाठ
- आवश्यकताओं का विश्लेषण और स्कीमा डिज़ाइन
- इंडेक्स रणनीति और क्वेरी प्लानर का सत्यापन
- स्केलिंग योजना: रेप्लिका सेट से शार्डेड क्लस्टर तक
- सुरक्षा सुदृढ़ीकरण और प्रोडक्शन जाँचसूची