CouchDB के साथ काम करने के लिए 16 व्यावहारिक सुझाव

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

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

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

अधिक डेटाबेस का उपयोग करें

कई शुरुआती नियमावली ( काउचडीबी: द डेफिनिटिव गाइड सहित) में, उदाहरण बहुत सुंदर लगते हैं, लेकिन वे जीवन के साथ बिल्कुल भी मेल नहीं खाते हैं। लब्बोलुआब यह है कि जैसे ही आपके दस्तावेजों की संख्या किसी भी वास्तविक पैमाने पर बढ़ती है, डेटाबेस में 100,000 दस्तावेजों का कहना है, अस्थायी विचारों का विकास लगभग असंभव हो जाता है, क्योंकि सर्वर को अब मानचित्र फ़ंक्शन के अनुपालन के लिए आपके सभी दस्तावेजों को खींचने की आवश्यकता है। साथ ही, प्रत्येक नक्शे में कुछ इस तरह होगा:

function (doc) {
if (doc.type == 'photo' ) {
...
}
}


जो एक छोटी बाइक जैसा दिखता है।

CouchDB का तर्क यह है कि डेटाबेस में एक दस्तावेज़ को अपडेट करते समय, यह अपडेट सभी नमूनों को "प्रभावित" करता है। यानी, बिल्कुल सभी नमूने सिर्फ एक दस्तावेज को अपडेट करते समय अपने ईटीएजी को अपडेट करेंगे। यह एक डेटाबेस में विभिन्न प्रकार के क्षेत्रों के साथ कई दस्तावेजों का उपयोग करने का एक और नुकसान है। उसी समय, एक दस्तावेज़ को अपडेट करने से ETag पर कोई असर नहीं पड़ता है, जो इस डेटाबेस को अन्य दस्तावेज़ों द्वारा दिया जाएगा, क्योंकि दस्तावेज़ों के लिए ETAG उनके नवीनतम संशोधन हैं।

प्रतिकृति उसी LAN पर होनी चाहिए

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

Erlang पर देशी कम कार्यों का उपयोग करें

पहिया को सुदृढ़ न करें। प्रलेखन में, इस तरह की चीजों को अक्सर कम कार्यों के उदाहरण के रूप में उपयोग किया जाता है:

function (key, values, rereduce) {
return sum(values);
}

उनसे बचने की कोशिश करें और एर्लांग में लिखे गए देशी कम का उपयोग करें: "_count" और "_sum", जो अपने जावास्क्रिप्ट समकक्षों की तुलना में गर्व से तेजी से काम करते हैं।

कॉम्प्लेक्स को कम करने से पहले तीन बार सोचें

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

हमारी परियोजना में, हमारे पास एक टिप्पणी डेटाबेस है जिसमें हम टिप्पणियों को संग्रहीत करते हैं। प्रत्येक टिप्पणी एक अलग दस्तावेज़ में है, इस दस्तावेज़ में भी टिप्पणी का शहर संग्रहीत किया गया है (हमारे पास एक रूसी पोर्टल, कई शहर हैं), साथ ही साथ इसके तथाकथित भी हैं। संबंधित - क्षेत्र के अंतर्गत आता है। चुनौती एन हाल की चर्चाओं में कटौती करना है। MySQL में बोलते हुए, कार्य कुछ इस तरह से आता है:

SELECT * FROM comments GROUP BY (belongs, city) ORDER BY timestamp

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

function (key, values, rereduce) {
if (rereduce) {
var data = [], meta = [], record, tmp, index, total = [];

for ( var i in values) {
for (j=0; j<values[i].length; j++) {
record = values[i][j];

tmp = record[2] + '_' + record[3];
index = meta.indexOf(tmp);

if (index === -1) {
meta.push(tmp);
data.push(record);
} else {
data[index][1] = Math.max(data[index][1], record[1]);
}
}
}

data.sort( function (a, b) {
if (a[1] === b[1]) {
return 0;
}

return (a[1] > b[1])
? -1
: 1;
});

return data.slice(0, 7);
} else {
var output = [];
for ( var i in values) {
output.push([values[i]._id, values[i].ts, values[i].belongs, values[i].city]);
}

return output;
}
}

और सब कुछ ठीक काम किया, लेकिन नमूना ताज़ा दर के साथ एक समस्या थी। एक टिप्पणी करने के बाद, इस नमूने को अपडेट करने में 4GB मेमोरी वाले एक सर्वर पर 2 सेकंड लगे और एक Athlon 64 X2 5600+ प्रोसेसर ( लिंक )। और टिप्पणियों की एक निरंतर स्ट्रीम के साथ, डेटाबेस की निरंतर शिथिलता अस्वीकार्य थी। अब डेटाबेस में दस्तावेजों की संख्या 22,000 है, नमूने में - 258,000। इसलिए निष्कर्ष: केवल शक्तिशाली सर्वर के साथ शक्तिशाली कम कार्यों का उपयोग करें। अन्यथा, पूरा विचार व्यर्थ हो जाता है।

ETag के माध्यम से कैश डेटा

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

काउचडी स्टाइल में सोचें

CouchDB में सोचना एक अलग, समझने वाली बात है। % DBMS% से काउचडीबी तक एक पार्सर लिखना पर्याप्त नहीं है, यह वास्तव में काउचबडी शैली में सोचने की आदत है, और फिर आप पूरी तरह से अलग दृष्टिकोण से सभी कार्यों का अनुभव करेंगे।

मैं एक सरल उदाहरण दूंगा। ऐसी घटनाएं होती हैं जो किसी समय पर होती हैं। अगर हमें MySQL में यह पता लगाने की आवश्यकता है कि आज क्या घटनाएं हो रही हैं, तो हम यह प्रश्न लिखते हैं:

SELECT * FROM table_name WHERE UNIX_TIMESTAMP() BETWEEN start_timestamp AND finish_timestamp


और अब CouchDB पर वापस जाएं और याद रखें कि नमूनों में वर्तमान समय जैसी कोई चीज नहीं है। सभी नमूने 1 बार बनते हैं, और बाद में, जब दस्तावेजों को बदलते / बनाते / हटाते हैं, तो वे केवल अपडेट किए जाते हैं। तदनुसार, हमारे पास केवल दस्तावेज हैं और कुछ भी नहीं है। यह समझना महत्वपूर्ण है कि आपको एक चयन करना चाहिए ताकि आप किसी भी पैरामीटर को कुंजी के रूप में पास कर सकें। यही है, आप केवल कुंजी द्वारा चयन को सीमित कर सकते हैं। इस समस्या का समाधान एक नमूना संकलित करना है जिसमें प्रत्येक दस्तावेज़ के लिए पूरे दिन जिसमें घटना होती है, उसे एक कुंजी के रूप में चुना जाएगा । और भविष्य में, उस दिन होने वाली सभी घटनाओं को प्राप्त करने के लिए, आपको बस "कुंजी = वर्तमान_दिवस" ​​के साथ दृश्य को संदर्भित करना होगा?

लगभग जो कुछ आप SQL में करते हैं वह CouchDB पर बहुत आसान और अधिक सुंदर तरीके से लागू किया जाता है।

मैं केवल 3 साल पहले अपने अवलोकन के साथ इस छद्म-पीली हेडलाइन को पतला करूंगा। एक समय में, मैं एक कंपनी में एक जूनियर प्रोग्रामर के रूप में काम करने के लिए हुआ था जो कि उपग्रहों को पिन करता है। इन साइटों पर, उपस्थिति एक दिन में 30 से अधिक लोगों की नहीं थी, लेकिन उनमें से प्रत्येक के तहत सर्वर साइड पर एक XSL टेम्पलेट कनवर्टर के साथ एक शक्तिशाली इंजन था। मैं यह भी स्पष्ट नहीं करना चाहता कि यह मूर्खता क्यों है। सामान्य विचार यह है कि आपको हमेशा वही उपकरण चुनना चाहिए जो समस्याओं को हल करने के लिए सबसे उपयुक्त हो। उपग्रहों के मामले में, ये सरल HTML पृष्ठ हैं जो आपका सीएमएस उत्पन्न कर सकते हैं; उच्च यातायात के साथ शक्तिशाली पोर्टल्स के मामले में, यह किसी भी तरह से एक मुफ्त जूमला नहीं हो सकता है।

वापस शीर्षक पर। सभी प्रोग्रामर यह नहीं समझते हैं कि उनका कोड कैसे काम करता है, और विशेष रूप से डेटाबेस के साथ बातचीत कैसे होती है। अक्सर ऐसे प्रश्न होते हैं जिनमें सरल डेटा प्राप्त करने के लिए भारी संख्या में JOIN होते हैं, और यहां तक ​​कि EXPLAIN इस व्यक्ति को यह निर्धारित करने में मदद नहीं करेगा कि उसकी क्वेरी का कौन सा हिस्सा धीमा हो जाता है, क्योंकि पूरी क्वेरी को सिर का उपयोग किए बिना बनाया जाता है। इसके अलावा, एक लाइव प्रोजेक्ट पर, यह सभी सरल प्राथमिक कुंजी चयनों के लिए नीचे आता है, अन्य सभी प्रश्न एक बोझ बन जाते हैं, और जटिल एसक्यूएल प्रश्नों को संकलित करने का ज्ञान बेकार हो जाता है।

फिलहाल, मुझे इस बात पर गहरा यकीन है कि काउचडीबी नौसिखिए प्रोग्रामरों को अपना सिर घुमाने की अनुमति देता है और उन्हें काम करने के लिए शक्तिशाली अनुरोध नहीं करता है। कम-कार्यों की सुविधा मूर्खतापूर्ण डेटा ट्रंकेशन को लिखने की अनुमति नहीं देती है, स्मृति अतिप्रवाह बाहर फेंकती है। लगभग उन सभी चीजों का उपयोग किया जाता है जो एक दिन में 5,000 लोगों के आवागमन के साथ सरल साइटों के साथ काम करते हैं, काउचबीडी पर लागू करने के लिए बहुत अधिक सुंदर और आसान हैं: URL द्वारा पृष्ठ प्राप्त करना, समाचारों की सूची प्राप्त करना, अतिथि पुस्तक, फोटो गैलरी और अधिक के साथ काम करना। उसी समय, केवल संभव UTF-8 एन्कोडिंग का उपयोग आपको बहुत सारी चीजों से बचाएगा, जो आपको विकास के दौरान सोचने की आवश्यकता नहीं है।

वर्तमान गतिविधियों को देखने के लिए उपयोगिताओं का उपयोग करें

CouchDB में सभी मौजूदा गतिविधियों को देखा जा सकता है। MacOS पर, CouchDB के साथ काम करने की उपयोगिता CouchDBX कहलाती है । विंडोज के लिए एक समान उपयोगिता है। वे पोर्ट 5984 पर CouchDB सर्वर चलाते हैं और आपको वास्तविक समय में वर्तमान सर्वर अनुरोध देखने की अनुमति देते हैं। लिनक्स में, सर्वर को डेमॉन मोड में शुरू करने के लिए पर्याप्त है (इसके लिए / usr / bin / couchdb में -d विकल्प इसके लिए जिम्मेदार है) और सभी अनुरोध कंसोल में प्रदर्शित होंगे।

साथ ही, सभी वर्तमान क्रियाओं को Futon के स्थिति टैब में देखा जा सकता है।

अक्सर अपडेट किए गए डेटा के लिए CouchDB का उपयोग न करें।

प्रत्येक चीज़ की अपनी सर्वोत्तम प्रथाएँ होती हैं। CouchDB में, ये पक्ष निश्चित रूप से अक्सर अद्यतन किए गए डेटा के साथ काम को शामिल नहीं करते हैं। CouchDB में डेटा लाना आदर्श है। ऐसा क्यों हो रहा है? जब एक दस्तावेज़ डेटाबेस में अद्यतन किया जाता है, तो ETag डेटाबेस में सभी नमूनों के लिए रीसेट हो जाता है। इसका मतलब है कि वे सभी अमान्य, पुराने हो गए हैं। नमूनों के लिए, इसका अर्थ है कि अगले कॉल पर (डेटाबेस में सभी नमूनों के लिए मिनट +1 अनुरोध) अपने ईटैग को अपडेट और अपडेट करना। सर्वर स्तर पर, इसका मतलब है कि डेटाबेस आकार में बढ़ रहा है, जिसे आपको संघनन ऑपरेशन का उपयोग करके निपटना होगा।

कंपटीशन के बारे में मत भूलना

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

प्रजातियों का पुनर्जनन। बासी = अद्यतन_तो

काउचबीडी संस्करण 1.10 जारी होने से पहले, एक छोटी सी समस्या गैर-उत्पन्न विचारों से डेटा का चयन थी। ऐसा करने के लिए, प्रजाति का चयन करते समय पैरामीटर "बासी = ठीक" का उपयोग करने का प्रस्ताव किया गया था, और प्रजातियों के पुनर्जनन को लटका दिया गया था, उदाहरण के लिए, क्रॉस्टेब में। संस्करण 1.10 से शुरू होकर, पैरामीटर "बासी = update_after" दिखाई दिया, जो "बासी = ठीक" के समान कार्य करता है, लेकिन यह इसे प्राप्त करने के बाद दृश्य को अपडेट करने का कारण बनता है। दृश्य डेटा की सरल प्राप्ति के साथ, हमारे पास जटिल डिजाइन दस्तावेजों के साथ त्वरित कार्य के लिए सभी संभावनाएं हैं।

किसी प्रोडक्शन सर्वर पर दृश्य जोड़ने या बदलने से डिज़ाइन दस्तावेज़ के पड़ोसी विचार प्रभावित होते हैं

जब एक डिज़ाइन दस्तावेज़ में एक दृश्य जोड़ा जाता है, तो इसे इकट्ठा किया जाता है। इसका अर्थ है कि दृश्य (कहते हैं, _design / list / _view / by_name) हर समय एकत्र किया जाएगा, इससे सटे हुए विचार (जैसे, _design / list / _view / by_age) उपलब्ध नहीं होंगे। जब आप किसी प्रोडक्शन सर्वर पर दृश्य जोड़ते हैं, तो उसके बारे में मत भूलना।

स्रोत से स्थापित करें बार-बार अपडेट करें।

जितने का उपयोग किया जाता है, उबंटू / डेबियन अनुरक्षकों को रिपॉजिटरी में पैकेज अपडेट करने की कोई जल्दी नहीं है। इसका मतलब यह है कि उबंटू मेवरिक काउचबीडी में संस्करण 1.0.1 है, जबकि ल्यूसिड में यह आम तौर पर 0.10 है, जबकि काउचबडी को अपाचे प्राथमिकता वाली परियोजनाओं की सूची में लंबे समय से शामिल किया गया है और लगातार विकसित हो रहा है। इस समय नवीनतम संस्करण (1.10) में निम्नलिखित चीजें हैं:

• नेटिव एसएसएल सपोर्ट
• डेटाबेस की सूची को अंततः वर्णानुक्रम में क्रमबद्ध किया जाता है
• विचारों के लिए अधिक सटीक ETag समर्थन (चर्चा में, वे कहते हैं कि नमूने अपने ETag को बदल नहीं सकते हैं जब दस्तावेजों को अपडेट किया जाता है जो उनमें शामिल नहीं हैं);
• मानचित्र कार्यों में कामन मॉड्यूल का समर्थन (याद रखें NodeJS के बारे में)
• विकल्प "बासी = update_after", जो "बासी = ठीक" के रूप में कार्य करता है, लेकिन इसके बाद देखने के लिए कारण बनता है

पूर्ण पाठ खोज

मैंने इस बारे में बात की कि कैसे CouchDB कई कार्यों के लिए उपयुक्त है, लेकिन सभी नहीं। पूर्ण-पाठ खोज बस इस अपवाद के अंतर्गत आती है। चूंकि हम किसी भी पैरामीटर को सीधे दृश्य में पास नहीं कर सकते हैं, हम डेटाबेस में वास्तव में कुछ खोज नहीं सकते हैं। इसलिए, आप CouchDB का उपयोग करके किसी साइट पर खोज को व्यवस्थित नहीं कर सकते। इन समस्याओं के विभिन्न समाधान हैं, लेकिन ये सभी साइकिल हैं। सच कहूँ तो, यह हमेशा इतना बुरा नहीं होता है: अक्सर यह आपको समझने की अनुमति देता है कि आपके आगंतुक क्या देखना चाहते हैं। एक और महत्वपूर्ण बिंदु है: कम-विज़िट की गई साइट पर, खोज की लगभग आवश्यकता नहीं है। और एक बड़े पोर्टल पर, खोज पर्याप्त रूप से प्रासंगिक होनी चाहिए, जो आपको सरल LIKE / LOCATE प्रश्नों के साथ प्राप्त करने की अनुमति नहीं देगा।

इस समस्या का एक सरल समाधान है Google से यैंडेक्स या कस्टम खोज इंजन से साइट खोज का उपयोग करना।

इस समस्या का एक अधिक जटिल और अभिन्न समाधान एक अलग खोज सर्वर का उपयोग करना हो सकता है। यह स्फिंक्स, अपाचे सोलर, ल्यूसीन हो सकता है (प्रलेखन में उल्लिखित काउचड- ल्यूसीन का एक गुच्छा है)। वास्तव में, यह एक अलग लेख के लिए एक विषय है, इसलिए अब मैं इस पर ध्यान केंद्रित नहीं करूंगा।

इसके अलावा, आपको अपने सिर में पूर्ण-पाठ खोज और टैग द्वारा खोज को स्पष्ट रूप से अलग करना चाहिए, हालांकि उपस्थिति में वे यूआरएल में समान हैं।

जियो सर्च

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

डेटा बैकअप

CouchDB में डेटा बैकअप चीजों में से एक है जिसे आपको इसके लिए प्यार करना चाहिए। बैकअप केवल / var / lib / couchdb निर्देशिका से डेटाबेस फ़ाइलों की प्रतिलिपि बनाकर किया जाता है। याद रखें कि आप केवल तभी फाइल कॉपी कर सकते हैं जब CouchDB सर्वर बंद हो , अन्यथा आपकी सभी डेटाबेस फाइलें पिट जाएंगी। इस प्रकार, सामान्य प्रक्रिया इस प्रकार है:

1. CouchDB सर्वर बंद करें
2. हमें जिन डेटाबेसों की आवश्यकता है, उन्हें कॉपी करें
3. CouchDB सर्वर चालू करें

सर्वर चल रहा है जब प्रतिकृति किया जाता है। * .Couch एक्सटेंशन वाली फ़ाइलों में उनके संबंधित डेटाबेस के सभी दस्तावेज़ होते हैं। निर्देशिकाओं।% Database_name% _design में संबंधित डेटाबेस के उत्पन्न विचार होते हैं। यदि आप निर्देशिकाओं को विचारों के साथ कॉपी नहीं करते हैं, तो कुछ भी गलत नहीं होगा: पहली बार जब आप विचारों का अनुरोध करते हैं, तो वे आपके कंप्यूटर पर उत्पन्न होंगे।

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

---

पोस्ट हैबरूसर ने 1999 में लिखा था और उनके अनुरोध पर प्रकाशित किया गया था।