MongoDB अंतरिक्ष उपयोग को समझना

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

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

ऐसा कैसे है कि 315MiB डेटा और 254MiB इंडेक्स का मतलब है कि हम अपने 5 GiB शार्क में से 2.1 GiB का उपयोग कर रहे हैं? समझाने के लिए, आइए शुरू करते हैं कि कैसे MongoDB डिस्क पर डेटा को विस्तार की एक श्रृंखला के रूप में संग्रहीत करता है। चूंकि हमारे ऑब्जेक्टरॉकेट इंस्टेंसेस छोटे फ़ाइल विकल्प के साथ चलते हैं, इसलिए पहली सीमा 16 एमबी के रूप में आवंटित की जाती है। 512MB तक पहुंचने तक इनका आकार दोगुना हो जाता है, जिसके बाद हर सीमा को 512MB फ़ाइल के रूप में आवंटित किया जाता है। तो हमारे उदाहरण "महासागर" डेटाबेस में एक फ़ाइल संरचना इस प्रकार है:

$ 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 के पास फिलहाल कोई डेटा नहीं है, लेकिन महासागर के पूर्ण होने पर पूर्व-आवंटित किया गया है। जैसे ही कोई डेटा महासागर को लिखा जाता है। 6, एक नया 512 एमबी विस्तार, महासागर। 7, फिर से पूर्व-आवंटित किया जाएगा। जब एक MongoDB डेटाबेस से डेटा हटा दिया जाता है, तब तक स्थान जारी नहीं किया जाता है जब तक कि आप कॉम्पैक्ट नहीं करते हैं - इसलिए समय के साथ, ये डेटा फ़ाइलें खंडित हो सकती हैं क्योंकि डेटा हटा दिया जाता है (या यदि कोई दस्तावेज़ अपने मूल संग्रहण स्थान को बढ़ा देता है क्योंकि अतिरिक्त कुंजियाँ जोड़ी जाती हैं)। एक संघनन इन डेटा फ़ाइलों को डीफ़्रैग्मेन्ट करता है क्योंकि एक संघनन के दौरान, डेटा को प्रतिकृति सेट के किसी अन्य सदस्य से दोहराया जाता है और डेटा फ़ाइलों को खरोंच से फिर से बनाया जाता है।

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

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

अंत में, हमारे उदाहरण शार्ड में एक और हाउसकीपिंग क्षेत्र, जर्नल शामिल है। जर्नल 1-3 फाइलों का एक सेट है जो प्रत्येक आकार में लगभग 128 एमबी है। जब भी कोई लेखन होता है, 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 इन फ़ाइलों को स्वचालित रूप से अपडेट की आवृत्ति बनाम डिस्क पर पृष्ठभूमि फ्लश की आवृत्ति के आधार पर घुमाता है।

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

NS मान, 48MB — मेरे द्वारा बताए गए तीन डेटाबेस, महासागर, व्यवस्थापक और स्थानीय के लिए तीन 16MB नामस्थान फ़ाइलों का योग।
डेटा मान, 315MiB — डेटा के लिए रिपोर्ट किए गए मान का योग db.stats() में आकार सभी डेटाबेस के लिए (सिस्टम डेटाबेस सहित)।
सूचकांक मान, 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% तक पहुंच गया है, तो सहायता से संपर्क करें और हम आपके उदाहरण में एक शार्प जोड़ने में आपकी सहायता कर सकते हैं।