वास्तु दोष CouchDB

प्रोग्रामिंग में मेरा पसंदीदा विषय उन नकारात्मक प्रभावों में तल्लीन करना है, जो हमारे द्वारा, हमारी राय में, तुच्छ कार्यों में प्रस्तुत किए जाते हैं।

ऐसा ही एक मुद्दा डेटाबेस में रिकॉर्ड को हटा रहा है। यह कार्यक्रम, अधिकांश प्रोग्रामर के अनुसार, डेटाबेस के साथ काम को गति देता है और इसे अधिक कॉम्पैक्ट बनाता है। चाल यह है कि यह सच नहीं है। और अगर रिलेशनल डेटाबेस के साथ यह केवल आंशिक रूप से सच है, तो NoSQL के साथ यह एक पूर्ण झूठ हो सकता है।

हम बाद में Apache CouchDB में इस समस्या के बारे में बात करेंगे।
विषय में चित्र:

डाटा कैसे स्टोर किया जाता है

किसी भी डेटाबेस में डेटा एक फ़ाइल सिस्टम के सिद्धांत पर संग्रहीत किया जाता है: एक डेटा प्लेसमेंट मैप और एक फ़ाइल होती है जिसमें उन्हें सीधे रखा जाता है। SQL के लिए, यह आमतौर पर एक टेबल है, और NoSQL के लिए, यह आमतौर पर एक पेड़ है।
जब हम डेटा हटाते हैं, जैसा कि फ़ाइल सिस्टम के मामले में, डेटाबेस उस रिकॉर्ड के बिना मैप फ़ाइल और डेटा फ़ाइल को फिर से बनाने में समय बर्बाद नहीं करेगा, जिसे हम हटाना चाहते हैं। वह नक्शे में हटाए गए प्रविष्टि को चिह्नित करता है। यह सत्यापित करना आसान है, इसके लिए हम MySQL का उपयोग करके MySQL में एक सरल तालिका बनाएंगे, वहां एक रिकॉर्ड जोड़ें, फिर हटाएं और आंकड़े देखें:

इसे ऑप्टिमाइज़ करने के लिए, हमें मैप फ़ाइल और डेटा फ़ाइल को फिर से बनाना होगा। पूरा हुआ:
OPTIMIZE TABLE guest;
और:


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

यह ध्यान दिया जाना चाहिए कि उपरोक्त पूरी तरह से InnoDB के लिए उपयुक्त नहीं है, जहां और भी बारीकियां हैं, लेकिन आज CouchDB के बारे में एक लेख है, और MySQL के बारे में नहीं है।

कैसे हटाने CouchDB में काम करता है

एक साधारण दस्तावेज़ लें:

और इसे हटा दें। क्या चल रहा है? डेटाबेस दस्तावेज़ को हटाए गए के रूप में चिह्नित करता है। वह यह कैसे करती है? यह दस्तावेज़ को पढ़ता है, इसमें से सभी फ़ील्ड निकालता है, अतिरिक्त _deleted: सच्ची संपत्ति सम्मिलित करता है, और एक नए संशोधन के तहत दस्तावेज़ लिखता है। एक उदाहरण:


अब, यदि आप दस्तावेज़ का नवीनतम संस्करण प्राप्त करने का प्रयास करते हैं, तो आपको एक 404 त्रुटि प्राप्त होगी जो यह दर्शाती है कि दस्तावेज़ हटा दिया गया है। हालांकि, यदि आप दस्तावेज़ के पहले संशोधन की ओर मुड़ते हैं, तो यह उपलब्ध होगा।
अगला, कॉम्पैक्ट करें । हटाए गए दस्तावेज़ों के लिए, डेटाबेस स्वचालित रूप से सभी संशोधनों को हटा देगा, केवल एक को छोड़कर जो कहता है कि दस्तावेज़ हटा दिया गया है। यह प्रतिकृति के दौरान किसी अन्य डेटाबेस को सूचित करने के लिए किया जाता है। यह संशोधन डेटाबेस में हमेशा के लिए रहता है और इसे हटाया नहीं जा सकता। (सच है, आप _purge का उपयोग कर सकते हैं, लेकिन यह बहुत अधिक नकारात्मक प्रभावों के साथ एक बैसाखी है और उत्पादन के लिए अनुशंसित नहीं है।)

यह काम को कैसे प्रभावित करता है?

CouchDB में, डेटा को B + ट्री के रूप में संग्रहीत किया जाता है। हटाए गए दस्तावेज़, भले ही वह डमी हो, पेड़ का हिस्सा बना हुआ है। इसका मतलब है कि इस मृत रिकॉर्ड को ध्यान में रखा गया है। और यह न केवल अनुक्रमणिका बनाते समय ध्यान में रखा जाता है, बल्कि एक दस्तावेज़ के सामान्य सम्मिलन के दौरान भी, क्योंकि जब कोई दस्तावेज़ डाला जाता है, तो एक पेड़ को फिर से बनाया जा सकता है, और जितने अधिक रिकॉर्ड होते हैं, उतनी ही धीमी प्रक्रिया होती है।

सिर पर नियंत्रण रखें

अंत में, यह समझा जाना बाकी है कि एर्लांग कितना तेज़ है। अब, यदि हम सिंथेटिक परीक्षण लेते हैं, तो हम देख सकते हैं कि एरलांग का प्रदर्शन PHP के करीब है। यही है, बी + पेड़ को सबसे तेज भाषा से हेरफेर नहीं किया जाता है।

यह वास्तविकता में कैसे धीमा हो जाता है

यदि WRITE आपके सबसे दुर्लभ ऑपरेशन नहीं है, तो पेड़ में कई मिलियन दस्तावेज होने पर, आपको अचानक (और अप्रत्याशित रूप से) पता चल सकता है कि डेटाबेस बहुत धीमा होने लगा है। उदाहरण के लिए, आप CouchDB का उपयोग कम जीवन प्रत्याशा (सत्र, लॉक फाइलें, कतारों) के साथ दस्तावेजों को संग्रहीत करने के लिए करते हैं। आइए वास्तविक उत्पादन के साथ एक चार्ट लें:

ग्राफ से पता चलता है कि चोटियाँ काफी तीखी हैं। चोटी में एक तेज वृद्धि हमेशा अनुमानित नहीं होती है। कभी-कभी हमारे पास लगभग 2 मिलियन डेटाबेस अपडेट (पेड़ में 1 मिलियन दस्तावेज़) होते हैं और यह काफी अच्छी तरह से काम करता है, लेकिन एक और 100 हजार दिखाई देते हैं, और प्रदर्शन पाइप में क्रैश हो जाता है। शिखर में तीव्र गिरावट होती है क्योंकि हम आधार को फिर से बनाते हैं और कई हफ्तों के लिए प्रदर्शन स्वीकार्य हो जाता है।

निष्कर्ष

• CouchDB एक B + पेड़ में सभी दस्तावेजों को संग्रहीत करता है, जिसे समय-समय पर पुनर्निर्माण किया जाता है। इसके लिए एर्लांग सबसे तेज़ भाषा नहीं है। कम जीवनकाल वाले दस्तावेज़ों के लिए CouchDB का उपयोग न करें, अन्यथा आपके पास बहुत बड़ा पेड़ होगा, क्योंकि दस्तावेज़ कभी भी इसे हटाए नहीं जाएंगे।
• यदि आप दस्तावेज़ों को नहीं हटाते हैं, तो भी आपके पास कई मिलियन रिकॉर्ड होने पर नए जोड़ने के लिए अंतराल होगा।
• मैं आपको CouchDB के साथ काम करने के लिए 16 व्यावहारिक सुझावों पर ध्यान देने की सलाह देता हूं।
• यह स्पष्ट हो जाता है कि काउचडीबी के निर्माता डेमियन काट्ज ने काउचबेस को कांटा करने और सी में कोर को फिर से लिखने का फैसला किया। वैसे, CouchBase में अंतर्निहित मेमकास्ट होता है, जो आपको कम जीवन प्रत्याशा वाले दस्तावेज़ों को एक अलग क्षेत्र में संग्रहीत करने की अनुमति देता है।