MongoDB स्पेस मैनेजमेंट मास्टर करें: आवंटन, डैशबोर्ड और स्केलिंग टिप्स

उन लोगों के लिए जो MongoDB का उपयोग करने में नए हैं, MongoDB स्पेस उपयोग काफी भ्रमित करने वाला लग सकता है। इस लेख में, मैं समझाऊंगा कि MongoDB स्पेस कैसे आवंटित करता है और ObjectRocket डैशबोर्ड में स्पेस उपयोग की जानकारी की व्याख्या कैसे करें ताकि यह निर्णय लिया जा सके कि आपको अपने इंस्टेंस को कब कॉम्पैक्ट करने की आवश्यकता है या अपने इंस्टेंस के लिए उपलब्ध स्पेस को बढ़ाने के लिए शार्ड जोड़ने की आवश्यकता है।

सबसे पहले, आइए एक बिल्कुल नए मीडियम इंस्टेंस से शुरू करें जिसमें एक सिंगल 5GB शार्ड है। मैं इस इंस्टेंस को "ocean" नामक डेटाबेस में कुछ टेस्ट डेटा से भरने जा रहा हूं। कुछ टेस्ट डेटा जोड़ने और कुछ इंडेक्स बनाने के बाद (इस लेख के उद्देश्यों के लिए, मैंने जानबूझकर अतिरिक्त इंडेक्स जोड़े जो मुझे पता था कि टेस्ट डेटा सेट के सापेक्ष आकार में काफी बड़े होंगे) इस इंस्टेंस के लिए स्पेस उपयोग यहां दिया गया है:

MongoDB डिस्क पर डेटा कैसे संग्रहीत करता है

समझाने के लिए, आइए शुरू करें कि MongoDB डेटा को डिस्क पर एक्सटेंट्स की एक श्रृंखला के रूप में कैसे संग्रहीत करता है। क्योंकि हमारे ObjectRocket इंस्टेंस smallfiles विकल्प के साथ चलते हैं, पहला एक्सटेंट 16MB के रूप में आवंटित किया जाता है। ये एक्सटेंट्स आकार में तब तक दोगुने होते हैं जब तक वे 512MB तक नहीं पहुंच जाते, जिसके बाद हर एक्सटेंट 512MB फाइल के रूप में आवंटित किया जाता है। तो हमारे उदाहरण "ocean" डेटाबेस की फाइल संरचना इस प्रकार है:

$ ls -lh ocean/
total 1.5G
-rw------- 1 mongodb mongodb 16M Aug 20 22:30 ocean.0
-rw------- 1 mongodb mongodb 32M Aug 20 20:44 ocean.1
-rw------- 1 mongodb mongodb 64M Aug 20 22:23 ocean.2
-rw------- 1 mongodb mongodb 128M Aug 20 22:30 ocean.3
-rw------- 1 mongodb mongodb 256M Aug 20 22:30 ocean.4
-rw------- 1 mongodb mongodb 512M Aug 20 22:30 ocean.5
-rw------- 1 mongodb mongodb 512M Aug 20 22:30 ocean.6
-rw------- 1 mongodb mongodb 16M Aug 20 22:30 ocean.ns
drwxr-xr-x 2 mongodb mongodb 4.0K Aug 20 22:30 _tmp

ये एक्सटेंट्स हमारे डेटाबेस के लिए डेटा और इंडेक्स दोनों को संग्रहीत करते हैं। MongoDB के साथ, जैसे ही किसी एक्सटेंट में कोई डेटा लिखा जाता है, अगला तार्किक एक्सटेंट आवंटित किया जाता है। इस प्रकार, उपरोक्त संरचना के साथ, ocean.6 में वर्तमान में कोई डेटा नहीं है, लेकिन ocean.5 भर जाने पर इसके लिए पूर्व-आवंटित किया गया है। जैसे ही ocean.6 में कोई डेटा लिखा जाता है, एक नया 512MB एक्सटेंट, ocean.7, फिर से पूर्व-आवंटित किया जाएगा। जब MongoDB डेटाबेस से डेटा हटाया जाता है, तो स्पेस तब तक जारी नहीं किया जाता जब तक आप कॉम्पैक्ट नहीं करते - इसलिए समय के साथ, ये डेटा फाइल्स फ्रैगमेंटेड हो सकती हैं क्योंकि डेटा हटाया जाता है (या यदि कोई डॉक्यूमेंट अतिरिक्त कुंजियों के जुड़ने के कारण अपने मूल स्टोरेज स्थान से बाहर निकल जाता है)। एक कॉम्पैक्शन इन डेटा फाइल्स को डीफ्रैगमेंट करता है क्योंकि कॉम्पैक्शन के दौरान, डेटा रेप्लिका सेट के दूसरे सदस्य से रेप्लिकेट किया जाता है और डेटा फाइल्स को स्क्रैच से फिर से बनाया जाता है।

एक अतिरिक्त 16MB फाइल नेमस्पेस को संग्रहीत करती है, यह ocean.ns फाइल है। यह वही पैटर्न MongoDB इंस्टेंस पर प्रत्येक डेटाबेस के लिए होता है। हमारे "ocean" डेटाबेस के अलावा, हमारे शार्ड पर दो अतिरिक्त सिस्टम डेटाबेस हैं: "admin" और "local"। "admin" डेटाबेस सभी डेटाबेस उपयोगकर्ताओं की उपयोगकर्ता जानकारी संग्रहीत करता है (2.6.x से पहले, इस डेटाबेस का उपयोग केवल एडमिन उपयोगकर्ताओं के लिए किया जाता था)। भले ही admin डेटाबेस छोटा है, फिर भी हमारे पास इस डेटाबेस के लिए एक 16MB एक्सटेंट, एक पूर्व-आवंटित 32MB एक्सटेंट, और एक 16MB नेमस्पेस फाइल है।

दूसरा सिस्टम डेटाबेस "local" डेटाबेस है। ObjectRocket पर हम जो प्रत्येक शार्ड प्रदान करते हैं वह तीन-सदस्यीय रेप्लिका सेट है। इन रेप्लिकास को सिंक में रखने के लिए, MongoDB एक लॉग रखता है, जिसे oplog कहा जाता है, प्रत्येक अपडेट का। यह प्रत्येक रेप्लिका पर सिंक में रखा जाता है और सेकेंडरी रेप्लिकास पर किए जाने वाले परिवर्तनों को ट्रैक करने के लिए उपयोग किया जाता है। यह oplog "local" डेटाबेस के भीतर एक कैप्ड कलेक्शन के रूप में मौजूद है। ObjectRocket पर हम oplog के आकार को आमतौर पर शार्ड आकार का 10% कॉन्फ़िगर करते हैं - हमारे 5GB शार्ड के मामले में, oplog को 500MB के रूप में कॉन्फ़िगर किया गया है। इस प्रकार "local" डेटाबेस में एक 16MB एक्सटेंट, एक 512MB एक्सटेंट, और एक 16MB नेमस्पेस फाइल होती है।

अंत में, हमारे उदाहरण शार्ड में एक और हाउसकीपिंग क्षेत्र है, जर्नल। जर्नल 1-3 फाइलों का एक सेट है जो प्रत्येक लगभग 128MB आकार की हैं। जब भी कोई राइट होता है, MongoDB पहले अपडेट को क्रमिक रूप से जर्नल में लिखता है। फिर समय-समय पर एक बैकग्राउंड थ्रेड इन अपडेट्स को वास्तविक डेटा फाइल्स (जिन एक्सटेंट्स का मैंने पहले उल्लेख किया था) में फ्लश करता है, आमतौर पर हर 60 सेकंड में एक बार। इस डबल-राइट का कारण यह है कि जर्नल में क्रमिक रूप से लिखना अक्सर वास्तविक डेटा फाइल्स में लिखने के लिए आवश्यक सीकिंग की तुलना में बहुत तेज होता है। परिवर्तनों को तुरंत जर्नल में लिखकर, MongoDB डेटा फ़ाइलों में परिवर्तन लिखे जाने की प्रतीक्षा किए बिना प्रत्येक राइट के लिए क्रैश की स्थिति में डेटा रिकवरी सुनिश्चित कर सकता है। हमारे वर्तमान प्राइमरी रेप्लिका के मामले में, मैं देखता हूं कि हमारे पास दो सक्रिय जर्नल फाइलें हैं:

$ ls -lh journal/
total 273M
-rw------- 1 mongodb mongodb 149M Aug 20 22:26 j._1
-rw------- 1 mongodb mongodb 124M Aug 20 22:30 j._2

MongoDB अपडेट की आवृत्ति बनाम डिस्क पर बैकग्राउंड फ्लश की आवृत्ति के आधार पर इन फाइलों को स्वचालित रूप से घुमाता है।

यह ObjectRocket डैशबोर्ड से कैसे संबंधित है

अब जब मैंने कवर कर लिया है कि MongoDB डिस्क स्पेस का उपयोग कैसे करता है, तो यह ObjectRocket डैशबोर्ड से दिखाए गए स्पेस उपयोग बार से कैसे मेल खाता है जिसे मैंने पहले दिखाया था?

• NS मान, 48MB - मेरे द्वारा उल्लिखित तीन डेटाबेस के लिए तीन 16MB नेमस्पेस फाइलों का योग: ocean, admin, और local।
• डेटा मान, 315MiB - सभी डेटाबेस (सिस्टम डेटाबेस सहित) के लिए db.stats() में रिपोर्ट किए गए dataSize के मान का योग।
• इंडेक्स मान, 253.9MiB - सभी डेटाबेस (सिस्टम डेटाबेस सहित) के लिए db.stats() में रिपोर्ट किए गए indexSize के मान का योग।
• स्टोरेज मान, 687.2MiB - सभी डेटाबेस के लिए डेटा प्लस इंडेक्स का योग प्लस डिलीट से कोई अनरिक्लेम्ड स्पेस।
• कुल फाइल मान, 2.0 GiB - हम प्राइमरी रेप्लिका पर कुल कितना डिस्क उपयोग कर रहे हैं। स्टोरेज मान और NS मान द्वारा कवर किए गए स्पेस के अलावा, इसमें कोई पूर्व-आवंटित एक्सटेंट्स भी शामिल हैं लेकिन जर्नल द्वारा उपयोग की जाने वाली स्पेस नहीं।

फ्रैगमेंटेशन और स्केलिंग गणना

इन मेट्रिक्स को देखते हुए, हम कुछ सरल गणनाएं कर सकते हैं यह निर्धारित करने के लिए कि क्या यह इंस्टेंस इतना फ्रैगमेंटेड है कि इसे कॉम्पैक्शन की आवश्यकता है। फ्रैगमेंटेशन के कारण खोए हुए स्पेस की गणना करने के लिए, निम्न का उपयोग करें:

100% - (डेटा + इंडेक्स) / स्टोरेज

हमारे उदाहरण इंस्टेंस के मामले में, यह 17% निकलता है (100% - (315MiB डेटा + 253.9MiB इंडेक्स) / 687.2MiB स्टोरेज = 17%)। मैं आपके इंस्टेंस को कॉम्पैक्ट करने की सलाह दूंगा जब फ्रैगमेंटेशन 20% के करीब पहुंच जाए।

एक और गणना जो हम कर सकते हैं वह यह है कि क्या हमें इस इंस्टेंस में शार्ड जोड़ने की आवश्यकता है हमारे समग्र स्पेस उपयोग के आधार पर। अपने समग्र स्पेस उपयोग की गणना करने के लिए निम्न करें:

(कुल फाइल / (प्लान आकार * शार्ड्स की संख्या)) * 100%

हमारे उदाहरण इंस्टेंस के लिए, यह 40% निकलता है ((2 GiB / 5 GiB * 1 शार्ड) * 100% = 40%)। हम आम तौर पर शार्ड जोड़ने की सलाह देते हैं जब समग्र स्पेस उपयोग 80% के करीब पहुंच जाता है। यदि आप देखते हैं कि आपका स्पेस उपयोग 80% तक पहुंच रहा है, तो सपोर्ट से संपर्क करें और हम आपके इंस्टेंस में शार्ड जोड़ने में आपकी मदद कर सकते हैं।