CouchDB .view फ़ाइल नियंत्रण से बाहर बढ़ रही है?

Question

मुझे हाल ही में एक ऐसी स्थिति का सामना करना पड़ा जहां मेरा कॉच डीबी इंस्टेंस 20 जीबी वीएम इंस्टेंस पर सभी उपलब्ध डिस्क स्पेस का इस्तेमाल करता था। जांच पर मैंने पाया कि/usr/local/var/lib/couchdb/में एक निर्देशिका में .view फ़ाइलों का एक गुच्छा शामिल है, जिनमें से सबसे बड़ा 16 जीबी था। मैं सामान्य ऑपरेशन को पुनर्स्थापित करने के लिए * .view फ़ाइलों को हटाने में सक्षम था। मुझे यकीन नहीं है कि क्यों .view फ़ाइलें इतनी बड़ी हो गईं और कैसे CouchDB प्रबंधित करता है .view फ़ाइलें।

थोड़ा और जानकारी। मेरे पास 512 एमबी और कॉच डीबी 0.10 के साथ उबंटू 9 .10 (कर्मिक) चल रहा एक वीएम है। वीएम में एक क्रॉन जॉब है जो एक पायथन स्क्रिप्ट को आमंत्रित करता है जो एक दृश्य से पूछताछ करता है। क्रॉन जॉब प्रत्येक पांच मिनट में एक बार चलता है। प्रत्येक बार दृश्य को .view फ़ाइल के आकार के बारे में पूछताछ की जाती है। मैंने एक घंटे के आधार पर इसकी निगरानी करने के लिए एक नौकरी लिखी है और कुछ दिनों के बाद मुझे फ़ाइल में रोलिंग या अन्यथा आकार में कमी दिखाई नहीं दे रही है।

क्या किसी को इस मुद्दे में कोई अंतर्दृष्टि है? क्या दस्तावेज का एक टुकड़ा है जिसे मैंने याद किया है? मैं इस विषय पर कुछ भी नहीं ढूंढ पा रहा हूं लेकिन यह गलत स्थानों या मेरे खोज शब्दों को देखने के कारण हो सकता है।

Answer 1

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

हर बार जब आप कोई दस्तावेज़ अपडेट या हटाते हैं तो दृश्य अनुक्रमणिका दस्तावेज़ों में प्रासंगिक परिवर्तनों के साथ अपडेट की जाएंगी। दृश्य के लिए अद्यतन किया जाएगा जब यह पूछताछ की जाएगी। इसलिए यदि आप बहुत से दस्तावेज़ परिवर्तन कर रहे हैं तो आपको अपनी अनुक्रमणिका को बढ़ने की उम्मीद करनी चाहिए और उसे कॉम्पैक्शन और क्लीनअप के साथ प्रबंधित करने की आवश्यकता होगी।

यदि आपके विचार दस्तावेज़ों के दिए गए सेट के लिए बहुत बड़े हैं तो आपके पास खराब तरीके से डिज़ाइन किए गए विचार हो सकते हैं। वैकल्पिक रूप से आपके डिज़ाइन को केवल बड़े विचारों की आवश्यकता हो सकती है और आपको इसे प्रबंधित करने की आवश्यकता होगी क्योंकि आप कोई अन्य संसाधन करेंगे।

यह बता देना आसान होगा कि क्या हो रहा है यदि आप वर्णन कर सकते हैं कि कौन से दस्तावेज़ अपडेट (इंक बनाएं और हटाएं) हो रहे हैं और आपके दृश्य कार्य उत्सर्जित हो रहे हैं, खासकर बड़े दृश्य के लिए।

Answer 2

आपकी .view फ़ाइलें बढ़ती हैं, हर बार जब आप दृश्य तक पहुंचते हैं तो CouchDB पहुंच पर विचार अपडेट करता है। कॉच डीबी विचारों को डेटाबेस जैसी कॉम्पैक्शन की भी आवश्यकता है। यदि आपके दस्तावेज़ों में लगातार परिवर्तन होते हैं, जिसके परिणामस्वरूप आपके दृश्य में परिवर्तन होते हैं, तो आपको समय-समय पर दृश्य संयोजन को चलाना चाहिए। http://wiki.apache.org/couchdb/HTTP_view_API#View_Compaction

अपने विचारों के आकार को कम करने के लिए, डेटा पर एक नज़र डालें, आप उत्सर्जित कर रहे हैं। जब आप उत्सर्जित करते हैं (foo, doc) पूरे दस्तावेज़ को दृश्य में कॉपी किया जाता है, तो जब आप दृश्य पूछते हैं तो यह तुरंत उपलब्ध होता है। समारोह (डॉक्टर) {emit (doc.title, डॉक्टर); } के परिणामस्वरूप डाटाबेस के रूप में बड़ा दृश्य होगा। आप भी उत्सर्जित कर सकते हैं (doc.title, शून्य); और जब आप दृश्य तक पहुंचते हैं तो CouchDB डेटाबेस को डेटाबेस से लाने के लिए include_docs विकल्प का उपयोग करें (जिसके परिणामस्वरूप थोड़ा प्रदर्शन दंड होगा)। देखें http://wiki.apache.org/couchdb/HTTP_view_API#Querying_Options

Answer 3

उपयोग अनुक्रमिक या यादृच्छिक

हाँ, CouchDB बहुत डिस्क भूख लगी है के बजाय दस्तावेज़ों के लिए monotonic पहचान-पत्र, और यह नियमित रूप से compactions की जरूरत है। लेकिन एक और चीज है जो इस डिस्क उपयोग को कम करने में मदद कर सकती है, खासकर कभी-कभी जब यह अनावश्यक होती है।

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

इसके बजाय, sequential or monotonic आईडी का उपयोग सभी से बच सकता है।

Answer 4

मुझे यह समस्या भी हुई है, एक ब्राउज़ किए गए-आधारित गेम के लिए कॉच डीबी की कोशिश कर रहा है।

हमारे पास साइट लॉन्च के पहले दिन लगभग 100,000 अप्रत्याशित विज़िटर थे, और 2 दिनों के भीतर कॉच डीबी डेटाबेस अंतरिक्ष में लगभग 40 जीबी ले रहा था। इससे सर्वर क्रैश हो गया क्योंकि एचडी पूरी तरह से भरा हुआ था।

कंपैक्शन ने लगभग 50 एमबी तक लाया। मैंने _revs_limit (जो 1000 तक डिफ़ॉल्ट) 10 से भी सेट किया है क्योंकि हमें संशोधन इतिहास की परवाह नहीं है, और यह पूरी तरह से चल रहा है। लगभग 1 एम उपयोगकर्ताओं के बाद, डेटाबेस आकार आमतौर पर लगभग 2-3 जीबी होता है। जब मैं कॉम्पैक्शन चलाता हूं तो यह लगभग 500 एमबी है।

10 दस्तावेज़ संशोधन सीमा निर्धारित करना:
curl -X PUT -d "10" http://dbuser:dbpassword@127.0.0.1:5984/yourdb/_revs_limit

या बिना उपयोगकर्ता: पासवर्ड (अनुशंसित):
curl -X PUT -d "10" http://127.0.0.1:5984/yourdb/_revs_limit