WiredTiger और इन-प्लेस अपडेट

MMAPv1 स्टोरेज इंजन के साथ, इन-प्लेस अपडेट को अक्सर एक अनुकूलन रणनीति के रूप में हाइलाइट किया जाता है क्योंकि दस्तावेज़ के लिए इंडेक्स सीधे स्थान और ऑफ़सेट फ़ाइल करने के लिए इंगित करते हैं। किसी दस्तावेज़ को एक नए संग्रहण स्थान पर ले जाना (विशेषकर यदि अद्यतन करने के लिए कई अनुक्रमणिका प्रविष्टियाँ हैं) MMAPv1 के लिए एक इन-प्लेस अपडेट की तुलना में अधिक ओवरहेड है जिसे केवल परिवर्तित फ़ील्ड को अपडेट करना है। देखें:MMAPv1 में रिकॉर्ड संग्रहण विशेषताएँ।

WiredTiger इन-प्लेस अपडेट का समर्थन नहीं करता है क्योंकि आंतरिक रूप से यह MVCC (मल्टीवर्सन कंसुरेंसी कंट्रोल) का उपयोग करता है, जो आमतौर पर डेटाबेस प्रबंधन सिस्टम द्वारा उपयोग किया जाता है। यह एमएमएपी में सरलीकृत दृष्टिकोण पर एक महत्वपूर्ण तकनीकी सुधार है, और अलगाव स्तर और लेनदेन जैसी अधिक उन्नत सुविधाओं के निर्माण की अनुमति देता है। WiredTiger की अनुक्रमणिका में एक संकेत स्तर होता है (फ़ाइल स्थान और ऑफ़सेट के बजाय एक आंतरिक रिकॉर्ड आईडी को संदर्भित करता है), इसलिए भंडारण स्तर पर दस्तावेज़ स्थानांतरित करना एक महत्वपूर्ण दर्द बिंदु नहीं है।

हालांकि, यह लेख यह भी कहता है कि "हालांकि [वायर्डटाइगर] इन-प्लेस अपडेट की अनुमति नहीं देता है, फिर भी यह कई वर्कलोड के लिए एमएमएपी से बेहतर प्रदर्शन कर सकता है"।

इसका मतलब है कि हालांकि MMAPv1 में इन-प्लेस अपडेट के लिए अधिक कुशल पथ हो सकता है, WiredTiger के अन्य फायदे हैं जैसे कि संपीड़न और बेहतर संगामिति नियंत्रण। आप शायद कुछ दस्तावेज़ों के लिए केवल इन-प्लेस अपडेट वाले वर्कलोड का निर्माण कर सकते हैं जो MMAPv1 में बेहतर प्रदर्शन कर सकते हैं, लेकिन वास्तविक वर्कलोड आमतौर पर अधिक विविध होते हैं। किसी दिए गए कार्यभार के प्रभाव की पुष्टि करने का एकमात्र तरीका प्रतिनिधि वातावरण में परीक्षण करना होगा।

हालाँकि, यदि आप भविष्य के लिए योजना बनाना चाहते हैं तो MMAPv1 बनाम WiredTiger की सामान्य पसंद विवादास्पद है:WiredTiger MongoDB 3.2 के बाद से डिफ़ॉल्ट स्टोरेज इंजन रहा है और कुछ नई उत्पाद सुविधाएँ MMAPv1 द्वारा समर्थित नहीं हैं। उदाहरण के लिए, MMAPv1 मेजॉरिटी रीड कंसर्न का समर्थन नहीं करता है, जिसका अर्थ है कि इसका उपयोग रेप्लिका सेट कॉन्फिग सर्वर (MongoDB 3.4+ में शार्डिंग के लिए आवश्यक) या चेंज स्ट्रीम (MongoDB 3.6+) के लिए नहीं किया जा सकता है। MMAPv1 को MongoDB (4.0) की अगली प्रमुख रिलीज़ में हटा दिया जाएगा और वर्तमान में MongoDB 4.2 में इसे निकालने के लिए शेड्यूल किया गया है।

जब मैं WiredTiger का उपयोग करता हूं तो मुझे किन सटीक प्रभावों के बारे में पता होना चाहिए? उदाहरण के लिए, इन-प्लेस अपडेट के बिना डेटाबेस का आकार तेजी से बढ़ेगा?

संग्रहण परिणाम आपके स्कीमा डिज़ाइन, कार्यभार, कॉन्फ़िगरेशन और MongoDB सर्वर के संस्करण सहित कई कारकों पर निर्भर करते हैं। MMAPv1 और WiredTiger अलग-अलग रिकॉर्ड आवंटन रणनीतियों का उपयोग करते हैं, लेकिन दोनों पूर्व-आवंटित स्थान का उपयोग करने का प्रयास करेंगे जो कि मुक्त/पुन:प्रयोज्य के रूप में चिह्नित है। सामान्य तौर पर WiredTiger भंडारण स्थान के उपयोग के साथ अधिक कुशल है, और इसमें डेटा और अनुक्रमित के लिए संपीड़न का लाभ भी है। MMAPv1 इन-प्लेस अपडेट के लिए ऑप्टिमाइज़ करने और दस्तावेज़ स्थानांतरित होने से बचने के लिए अतिरिक्त संग्रहण स्थान आवंटित करता है, हालाँकि आप संग्रह के लिए "नो पैडिंग" रणनीति चुन सकते हैं जहाँ कार्यभार समय के साथ दस्तावेज़ का आकार नहीं बदलता है।

WiredTiger को अलग-अलग वर्कलोड के लिए बेहतर बनाने और ट्यूनिंग में महत्वपूर्ण निवेश किया गया है क्योंकि इसे पहली बार MongoDB 3.0 में पेश किया गया था, इसलिए मैं सर्वोत्तम परिणाम के लिए नवीनतम उत्पादन रिलीज़ श्रृंखला के साथ परीक्षण को दृढ़ता से प्रोत्साहित करूंगा। यदि आपके पास स्कीमा डिज़ाइन और स्टोरेज ग्रोथ के बारे में कोई विशिष्ट प्रश्न है, तो मैं चर्चा के लिए डीबीए स्टैक एक्सचेंज पर विवरण पोस्ट करने का सुझाव दूंगा।

मुझे यह भी पता चला कि MongoDB 3.6 में WiredTiger ने संपूर्ण दस्तावेज़ (https://jira.mongodb.org/browse/DOCS-11416) को फिर से लिखने के बजाय डेल्टास को स्टोर करने की क्षमता को जोड़ा। इसका क्या मतलब है, बिल्कुल?

यह एक कार्यान्वयन विवरण है जो कुछ उपयोग के मामलों के लिए WiredTiger की आंतरिक डेटा संरचनाओं को बेहतर बनाता है। विशेष रूप से, MongoDB 3.6+ में WiredTiger बड़े दस्तावेज़ों में छोटे बदलावों के साथ काम करने के बारे में अधिक कुशल हो सकता है (पिछली रिलीज़ की तुलना में)। WiredTiger कैश को दस्तावेज़ों के कई संस्करणों को वापस करने में सक्षम होना चाहिए, जब तक कि वे खुले आंतरिक सत्रों (एमवीसीसी, जैसा कि पहले उल्लेख किया गया है) द्वारा उपयोग किया जाता है, इसलिए छोटे अपडेट वाले बड़े दस्तावेज़ों के लिए डेल्टा की सूची को स्टोर करना अधिक कुशल हो सकता है। हालांकि, अगर बहुत अधिक डेल्टा जमा हो जाते हैं (या डेल्टा दस्तावेज़ में अधिकांश फ़ील्ड बदल रहे हैं) तो यह दृष्टिकोण पूर्ण दस्तावेज़ की एकाधिक प्रतियों को बनाए रखने से कम प्रदर्शनकारी हो सकता है।

जब डेटा एक चेकपॉइंट के माध्यम से डिस्क के लिए प्रतिबद्ध होता है, तब भी दस्तावेज़ के पूर्ण संस्करण को लिखने की आवश्यकता होती है। यदि आप कुछ इंटर्नल के बारे में अधिक जानना चाहते हैं, तो MongoDB 4.0 में बहु-दस्तावेज़ लेनदेन का समर्थन करने के लिए सुविधाओं के विकास के बाद वीडियो की एक MongoDB Path To Transactions श्रृंखला है।

इसके अलावा जो मुझे समझ में नहीं आता है वह यह है कि आजकल अधिकांश (यदि सभी नहीं) हार्ड ड्राइव का सेक्टर आकार 4096 बाइट्स है, इसलिए आप हार्ड ड्राइव पर केवल 4 बाइट्स (उदाहरण के लिए) नहीं लिख सकते हैं, बल्कि इसके बजाय 4096 का पूरा ब्लॉक लिखना होगा। बाइट्स (इसलिए इसे पहले पढ़ें, इसमें 4 बाइट्स अपडेट करें और फिर इसे लिखें)। चूंकि अधिकांश दस्तावेज़ अक्सर <4096 बाइट्स होते हैं, इसका मतलब यह है कि पूरे दस्तावेज़ को फिर से लिखना किसी भी मामले में आवश्यक है (यहां तक ​​​​कि एमएमएपी के साथ भी)। मुझे क्या याद आया?

कार्यान्वयन विवरण में बहुत दूर जाने के बिना और शामिल सभी चलती भागों को समझाने की कोशिश करने के बिना, विचार करें कि विभिन्न दृष्टिकोण वर्कलोड पर कैसे लागू होते हैं जहां कई दस्तावेज़ अपडेट किए जा रहे हैं (एकल दस्तावेज़ स्तर के बजाय) साथ ही स्मृति उपयोग पर प्रभाव (पहले दस्तावेज़ डिस्क पर लिखे गए हैं)। दस्तावेज़ के आकार और संपीड़न जैसे कारकों के आधार पर, I/O का एक एकल ब्लॉक दस्तावेज़ के एक अंश (अधिकतम आकार 16MB) से लेकर कई दस्तावेज़ों तक कहीं भी प्रतिनिधित्व कर सकता है।

MongoDB में सामान्य प्रवाह यह है कि दस्तावेज़ों को इन-मेमोरी व्यू (उदाहरण के लिए, WiredTiger कैश) में अपडेट किया जाता है, जिसमें डेटा फ़ाइलों को समय-समय पर फ़्लश करने से पहले तेज़ एपेंड-ओनली जर्नल प्रारूप में डिस्क में परिवर्तन जारी रहता है। यदि O/S को केवल उन डेटा के ब्लॉक लिखना है जो बदल गए हैं, तो डेटा के कम ब्लॉक को छूने के लिए कम समग्र I/O की आवश्यकता होती है।