MongoDB
 sql >> डेटाबेस >  >> NoSQL >> MongoDB

MongoDB चिंता लिखें:3 चेतावनी अवश्य जानें

MongoDB में 'चिंता लिखें' लेखन स्वीकृति के उस स्तर का वर्णन करता है जिसकी आप उससे अपेक्षा कर सकते हैं। यह आपके लेखन कार्यों में याद रखने के लिए एक महत्वपूर्ण सेटिंग है और इसका व्यवहार समझने में उपयोगी है, विशेष रूप से वितरित MongoDB परिनियोजन (यानी प्रतिकृति सेट और शार्प क्लस्टर) में। इस पोस्ट में, हम MongoDB लेखन चिंता का उपयोग करते समय 3 गोचाओं पर चर्चा करते हैं।

MongoDB चिंता लिखें

MongoDB का दस्तावेज़ीकरण लेखन चिंता को परिभाषित करता है "एक स्टैंडअलोन मोंगोड या प्रतिकृति सेट या शार्प क्लस्टर के लिए लिखने के संचालन के लिए MongoDB से अनुरोध की गई पावती का स्तर। "

सीधे शब्दों में कहें तो, एक लेखन चिंता MongoDB को लिखने के संचालन के साथ पारित 'टिकाऊपन' का एक संकेत है। स्पष्ट करने के लिए, आइए सिंटैक्स को देखें:

{ w: <value>, j: <boolean>, wtimeout: <number> }
Where*,
 w can be an integer | "majority" | , it represents the number of members that must acknowledge the write. Default value is 1.
 j Requests that a write be acknowledged after it is written to the on-disk journal as opposed to just the system memory. Unspecified by default.
wtimeout specifies timeout for the applying the write concern. Unspecified by default.

* आप लिखित चिंता विशिष्टता दस्तावेज में विस्तृत सिंटैक्स पा सकते हैं।

* उन विभिन्न "टैग्स" के बारे में अधिक जानें जिनका उपयोग आप हमारे MongoDB ब्लॉग में टिकाऊपन को समझना और सुरक्षा लिखें में सामान्य लेखन चिंता मूल्यों के लिए उपयोग कर सकते हैं।

उदाहरण:

db.inventory.insert(
    { sku: "abcdxyz", qty : 100, category: "Clothing" },
    { writeConcern: { w: 2, j: true, wtimeout: 5000 } }
)

उपरोक्त इंसर्ट की लेखन चिंता को इस प्रकार पढ़ा जा सकता है:  इस लेखन को स्वीकार करें जब 'प्रतिकृति सेट के कम से कम 2 सदस्यों ने इसे 5000 मिसे के भीतर अपनी पत्रिकाओं में लिखा हो या कोई त्रुटि वापस कर दी हो '। विकल्प के लिए एक लिखित चिंता मान बहुमत था, जिसका अर्थ है "rपावती मांगता है कि लेखन संचालन प्राथमिक सहित अधिकांश मतदान नोड्स में प्रचारित हो गया है। "

#MongoDB चिंता लिखें - 3 चेतावनी अवश्य जानें ट्वीट करने के लिए क्लिक करें

लिखने की चिंता का महत्व स्पष्ट है। w के बढ़ते मान लिखने की विलंबता को बढ़ाते हैं जबकि उनके खो जाने की संभावना भी कम करते हैं। लेखन चिंता के लिए सही मूल्यों का चयन, प्रदर्शन किए जा रहे लेखन की विलंबता और स्थायित्व आवश्यकताओं पर निर्भर करता है।

इसकी पृष्ठभूमि के रूप में एक लेखन चिंता क्या है, आइए लेखन चिंता का उपयोग करते समय याद रखने के लिए तीन चेतावनियों पर चलते हैं।

CAVEAT 1: बिना समय समाप्ति के प्रतिकृति सेट पर लेखन चिंता सेट करने से लेखन अनिश्चित काल के लिए अवरुद्ध हो सकता है

उपरोक्त बहुसंख्यक परिभाषा (लागू MongoDB 3.0 आगे) में कहा गया है कि "मतदान नोड्स" के बहुमत से पावती का अनुरोध किया गया है। ध्यान दें कि “यदि आप wtimeout निर्दिष्ट नहीं करते हैं विकल्प और लेखन चिंता का स्तर अस्वीकार्य है, लेखन कार्य अनिश्चित काल के लिए अवरुद्ध हो जाएगा। "

इसके अनपेक्षित परिणाम हो सकते हैं, उदाहरण के लिए, एक 2+1 प्रतिकृति सेट (यानी एक प्राथमिक, एक द्वितीयक और एक मध्यस्थ) पर विचार करें। यदि आपकी एकमात्र पढ़ी गई प्रतिकृति नीचे जाती है, तो सभी लेखन चिंता के साथ "बहुमत" के विकल्प को अनिश्चित काल के लिए अवरुद्ध कर देंगे। वही होगा यदि w विकल्प 2 पर सेट है। एक और चरम उदाहरण 3+2 प्रतिकृति सेट (प्राथमिक, 2 सेकेंडरी और 2 आर्बिटर्स, अनुशंसित कॉन्फ़िगरेशन नहीं) के मामले में है। सभी "बहुसंख्यक" लेखन अवरुद्ध हो जाएंगे, भले ही एक डेटा नोड अनुपलब्ध हो, क्योंकि बहुमत संख्या, इस मामले में, 3 है।

इस समस्या को कम करने का सबसे आसान तरीका हमेशा एक wtimeout मान निर्दिष्ट करना है ताकि यदि लेखन चिंता को लागू नहीं किया जा सकता है तो क्वेरी टाइमआउट हो सकती है। हालांकि, ऐसी टाइमआउट त्रुटियों के मामले में, MongoDB टाइमआउट होने से पहले कुछ सदस्यों को किए गए सफल लेखन को पूर्ववत नहीं करता है।

यह सुनिश्चित करने के लिए वर्तमान में कोई सेटिंग नहीं है कि वर्तमान में पहुंच योग्य अधिकांश नोड्स तक कोई लेखन पहुंच जाए, इसलिए वांछित टोपोलॉजी के आधार पर लेखन चिंता w के मूल्य को सेट करने के बारे में सावधान रहें। टिकाऊपन, और उपलब्धता.

CAVEAT 2: आप w:बहुमत के साथ भी डेटा खो सकते हैं

यह सहज ज्ञान युक्त लगता है कि एक बार अधिकांश मतदान सदस्यों द्वारा एक लेखन को स्वीकार कर लिया गया है, इसके स्थायित्व की गारंटी है। हालाँकि, ऐसा नहीं है! याद रखें कि जब j विकल्प निर्दिष्ट नहीं होता है, तो स्मृति में लिखे जाने के ठीक बाद एक लेखन को स्वीकार किया जाता है।

इसलिए, ऐसा लेखन खो सकता है यदि एक सनकी पावर आउटेज अधिकांश नोड्स को बाहर निकाल देता है, जिस पर राइट ने प्रचार किया था (और सिंकपीरियोडसेक से पहले यानी इससे पहले कि इसे फ्लश किया जा सके) डिस्क)।

लिखने की स्थायित्व सुनिश्चित करने के लिए, अपने डेटाबेस पर जर्नलिंग को बंद न करना और j विकल्प को सही पर सेट करना सबसे अच्छा है। वास्तव में, MongoDB 3.6 की शुरुआत करते हुए, --nojournal WiredTiger स्टोरेज इंजन का उपयोग करके प्रतिकृति सेट सदस्यों के लिए ध्वज को हटा दिया गया है।

"बहुमत" के w मान और प्रतिकृति सेट पर j विकल्प अनिर्दिष्ट होने के साथ, सटीक स्थायित्व व्यवहार प्रतिकृति सेट कॉन्फ़िगरेशन के मान पर निर्भर करता है writeConcernMajorityJournalDefault. जब सही पर सेट किया जाता है (और जब जर्नलिंग सक्षम होती है), तो यह स्वीकार करता है कि वे अधिकांश मतदान सदस्यों की पत्रिकाओं में लिखे जाने के बाद लिखते हैं।

इसके अलावा:जर्नलिंग चालू होने पर भी, यदि कमिटइंटरवलएम की अवधि के भीतर कोई रुकावट आती है, तो आपके लेखन एमएमएपीवी1 स्टोरेज इंजन पर खो सकते हैं। दूसरी ओर, WiredTiger स्टोरेज इंजन, जर्नल फाइलों के एक सिंक को बाध्य करता है, जब उसे j विकल्प के साथ राइट टू ट्रू प्राप्त होता है। और, यहां तक ​​कि जे के गलत पर सेट के साथ, नवीनतम WiredTiger आधारित परिनियोजन के लिए एक स्वीकृत "बहुमत" लेखन केवल तभी खो सकता है जब अधिकांश डेटा नोड्स एक साथ क्रैश हो जाते हैं।

CAVEAT 3: w:0 सेट करते समय j:true लिखने के प्रदर्शन में सुधार नहीं करता है

एक बार सोचने के बाद तर्क करना काफी आसान है, लेकिन भूलना भी उतना ही आसान है। w विकल्प को 0 पर सेट करना आमतौर पर डेटाबेस को "फायर-एंड-फॉरगेट" फैशन में लिखने के लिए किया जाता है - जब आपको डेटाबेस इन्फ्रास्ट्रक्चर पर उचित मात्रा में विश्वास होता है और प्रत्येक लेखन के स्थायित्व की तुलना में विलंबता के बारे में अधिक परवाह होती है। हालाँकि, यदि आप j विकल्प को सही पर सेट करते हैं, तो आपका w विकल्प प्रभावी रूप से ओवरराइड हो जाएगा क्योंकि डेटाबेस यह सुनिश्चित करेगा कि लिखने से पहले ऑन-डिस्क जर्नल में लिखा गया है।

यदि आप अपने लेखन कार्यों की सफलता की गारंटी के लिए लेखन चिंताओं का उपयोग कर रहे हैं, तो सुनिश्चित करें कि आपको ये तीन महत्वपूर्ण चेतावनी याद हैं! हम यहां मदद करने के लिए हैं, इसलिए बेझिझक ट्विटर या ईमेल के माध्यम से किसी भी प्रश्न से जुड़ें।


  1. Redis
  2.   
  3. MongoDB
  4.   
  5. Memcached
  6.   
  7. HBase
  8.   
  9. CouchDB
  1. प्रोजेक्शन खोज क्वेरी के साथ काम नहीं कर रहा है

  2. mongoose.model में संग्रह का नाम कैसे बदलें?

  3. ग्लासफ़िश में तृतीय पक्ष पुस्तकालयों का उपयोग कैसे करें?

  4. MongoDB में .NET के माध्यम से इंडेक्स कैसे बनाएं?

  5. क्या मोंगोडब की जर्नल फ़ाइल को हटाना सुरक्षित है?