हम ज्ञापन के बजाय MongoDB का उपयोग करते हैं: होना या न होना?

"मेमकोच्ड के बजाय मोंगोडीबी का उपयोग" विषय पर बहुत सारी सफलता की कहानियां हैं। ऐसा लगता है कि कार्यों की एक विस्तृत श्रेणी है जिसके लिए विचार अच्छी तरह से काम करता है: सबसे पहले, ये ऐसी परियोजनाएं हैं जहां कैश टैगिंग का भारी उपयोग किया जाता है। लेकिन अगर आप कोशिश करते हैं, तो आप देखेंगे कि MongoDB में कैश रिकॉर्ड से हटाए जाने के कार्य का अभाव है जो कम से कम अक्सर (LRU - Least हाल ही में उपयोग किए गए) हैं। उचित सीमा के भीतर कैश आकार कैसे बनाए रखें? LRU, वैसे, "घोड़ा" मेमकेड का है; आप अपने कैश ओवरफ्लो होने की चिंता किए बिना मेमकेड में लिख सकते हैं; लेकिन MongoDB के बारे में क्या?

इस बारे में सोचते हुए, मैंने पायथन में एक छोटी सी उपयोगिता CacheLRUd (GitHub पर पोस्ट) लिखी। यह विभिन्न DBMSs (मुख्य रूप से, MongoDB में) के रिकॉर्ड को LRU हटाने का समर्थन करने के लिए एक डेमॉन है। इस तरह के डेमों का खेत (प्रत्येक MongoDB प्रतिकृति पर एक) समय-समय पर रिकॉर्ड को हटाने के द्वारा संग्रह के आकार की निगरानी करता है जो कम से कम बार पढ़े जाते हैं। यूएई के आधार पर एक प्रोटोकॉल का उपयोग करके किसी विशेष कैश प्रविष्टि को पढ़ने के तथ्यों को ट्रैक करना विकेन्द्रीकृत (विफलता के एक बिंदु के बिना) है (ऐसा क्यों? क्योंकि "भोले" विकल्प को एप्लिकेशन से MongoDB मास्टर डेटाबेस में लिखना है प्रत्येक रीड ऑपरेशन के साथ एक बुरा विचार है, विशेष रूप से) यदि मास्टर आधार किसी अन्य डेटा केंद्र में है)। नीचे विवरण पढ़ें।

लेकिन क्यों?

आपको MongoDB के साथ मेमकेड को बदलने की आवश्यकता क्यों हो सकती है? आइए इसे जानने की कोशिश करें। "कैश" की अवधारणा के दो अलग-अलग प्रकार के उपयोग हैं।

1. कैश का उपयोग डेटाबेस (या अन्य सबसिस्टम) पर लोड को कम करने के लिए किया जाता है जो अब प्रबंधन नहीं कर रहा है। उदाहरण के लिए, मान लें कि हमारे पास संसाधन पढ़ने के लिए प्रति सेकंड 100 अनुरोध हैं। कैशिंग सक्षम करने और एक छोटी कैश उम्र बढ़ने के समय (उदाहरण के लिए, 1 सेकंड) को सेट करके, हम इस तरह डेटाबेस पर लोड को 100 गुना कम कर देते हैं: अब, सौ में से केवल एक क्वेरी DBMS तक पहुंचती है। और हमें लगभग डरने की ज़रूरत नहीं है कि उपयोगकर्ता को पुराना डेटा दिखाई देगा: आखिरकार, उम्र बढ़ने का समय बहुत कम है।
2. एक अन्य प्रकार का कैश है: यह पृष्ठ के कम या ज्यादा स्थिर टुकड़ों (या पूरे पृष्ठ) का कैश है, और उनका उपयोग पेज बनाने में लगने वाले समय को कम करने के लिए किया जाता है (शायद ही कभी देखे गए सहित)। यह पहले वाले से अलग है कि कैश्ड रिकॉर्ड का जीवनकाल लंबा है (घंटे या दिन भी), जिसका अर्थ है कि पूरा सवाल उठता है: कैसे गारंटी दें कि कैश में अप-टू-डेट डेटा है, इसे कैसे साफ करें? इसके लिए, टैग का उपयोग किया जाता है: कुछ बड़े संसाधन X से संबंधित कैश के प्रत्येक टुकड़े को कुछ टैग के साथ टैग किया जाता है। संसाधन X को बदलते समय कमांड "क्लियर टैग X" दें।

पहले उपयोग के मामले के लिए, मेमकेड से बेहतर कुछ भी नहीं लगता है कि इसका आविष्कार किया गया है। लेकिन दूसरे मेमस्किल्ड पर्चियों के लिए, और यहाँ "मेमोकेड के बजाय मोंगोडीबी" का विचार बचाव में आ सकता है। शायद यह आपका मामला है अगर आपका कैश है:

• अपेक्षाकृत छोटा (ऊपरी सीमा सैकड़ों गीगाबाइट है)।
• इसमें बहुत सारे "लंबे समय तक जीवित रहने वाले" रिकॉर्ड शामिल हैं जो घंटों और दिनों में पुराने हैं (या कभी भी समाप्त नहीं होते हैं)।
• आप टैग का पर्याप्त उपयोग करते हैं और मज़बूती से काम करने के लिए टैग क्लीनअप ऑपरेशन पर भरोसा करते हैं।
• मैं कई डेटा केंद्रों सहित क्लस्टर में सभी मशीनों पर साझा किए गए और समान रूप से आसानी से सुलभ (यानी प्रतिकृति) बनाना चाहूंगा।
• जब कोई कैश मशीन कुछ समय के लिए उपलब्ध रहना बंद हो जाए तो आप चिंता नहीं करना चाहते।

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

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

यहां बताया गया है कि CacheLRUd का एक लोड नहीं किए गए प्रोजेक्ट पर काम करने का परिणाम कैसा दिखता है। यह देखा जा सकता है कि कैश के साथ संग्रह का आकार वास्तव में विन्यास में निर्दिष्ट 1 जी स्तर पर स्थिर रखा गया है।

CacheLRUd स्थापित करें

## EACH MongoDB NODE पर सेवा स्थापित करें:
सीडी / ऑप्ट
git क्लोन क्लोन git@github.com: दिमित्रीकोटरोव / cachelrud.git
ln -s /opt / cachelrud/bin/cachelrud.init /etc/init.d/cachelrud

## कॉन्फ़िगर करें:
cp /opt / cachelrud/cachelrud.conf /etc/cachelrud.conf # और फिर संपादित करें

## RHEL (RedHat, CentOS) के लिए:
chkconfig - एडड cachelrud
chkconfig cachelrud on

## ... या डेबियन / उबंटू के लिए:
अद्यतन- rc.d cachelrud चूक

दानव कैसे काम करता है

कोई चमत्कार नहीं हैं, और आपके आवेदन को कैशेएलआरयूड डेमन (डेमन फार्म) को बताना चाहिए कि यह कौन से कैश प्रविष्टियों को पढ़ता है। एप्लिकेशन, स्पष्ट रूप से, सिंक्रोनस मोड में ऐसा नहीं कर सकता (उदाहरण के लिए, MongoDB मास्टर डेटाबेस में कैश दस्तावेज़ में last_read_at फ़ील्ड को अपडेट करना), क्योंकि) ए) मास्टर डेटाबेस वर्तमान एप्लिकेशन वेब थूथन के सापेक्ष एक अलग डेटा सेंटर में हो सकता है, बी) MongoDB टीसीपी प्रोटोकॉल का उपयोग करता है, जो संचार अस्थिरता के मामले में टाइमआउट और क्लाइंट के "ठंड" के साथ धमकी देता है, ग) प्रत्येक रीड पर लिखना बेकार है, यह वितरित सिस्टम में काम नहीं करता है।

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

• यदि लोड अपेक्षाकृत कम है, तो CDPLRUd डेमन को यूडीपी पैकेट भेजें जो वर्तमान MongoDB मास्टर नोड पर बैठा है (बाकी बस निष्क्रिय खड़े रहेंगे और अपनी बारी का इंतजार करेंगे)। वर्तमान में मास्टर कौन है यह निर्धारित करना आवेदन पक्ष पर बहुत आसान है: उदाहरण के लिए, PHP में, MongoClient :: getConnections का उपयोग इसके लिए किया जाता है।
• यदि एक डेमॉन विफल हो जाता है, तो आप UDP संदेश भेज सकते हैं, उदाहरण के लिए, वर्तमान डेटा केंद्र में CacheLRUd डेमॉन को।

विवरण प्रलेखन में वर्णित हैं।

और क्या उपयोगी है

CacheLRUdWrapper : यह PHP में एप्लिकेशन कोड से CacheLRUd के साथ संचार करने के लिए एक सरल वर्ग है, मानक Zend_Cache_Backend को लपेटता है (हालांकि यह वर्ग Zend फ्रेमवर्क 1 के लिए है; यदि यह ZF2 के लिए इसे फिर से लिखता है या अन्य भाषाओं के लिए सामान्य रूप से, मुझे अनुरोधों को खींचने में खुशी होगी)।

Zend_Cache_Backend_Mongo : यह पड़ोसी GitHub रिपॉजिटरी से MongoDB के लिए Zend_Cache_Bachend कार्यान्वयन है। CacheLRUdWrapper में इस वर्ग की वस्तु को लपेटें, और ZF1 की शैली में MongoDB में LRU कैश के साथ काम करने के लिए इंटरफ़ेस प्राप्त करें:

 $ संग्रह = $ mongoClient-> yourDatabase-> cacheCollection;
 $ संग्रह-> w = 0;
 $ संग्रह-> setReadPreference (MongoClient :: RP_NEAREST);  // मास्टर से भी पढ़ने की अनुमति देता है
 $ प्राइमरीहोस्ट = अशक्त;
 foreach ($ mongoClient-> getConnections () $ जानकारी के रूप में) {
     अगर (in_array ($ जानकारी ['कनेक्शन'] ['connection_type_desc'], सरणी ("STANDALONE", "PRIMARY"))) {
         $ प्राइमहॉस्ट = $ जानकारी ['सर्वर'] ['होस्ट'];
     }
 }
 $ बैकेंड = नया Zend_Cache_Backend_Mongo (सरणी ('संग्रह' => $ संग्रह));
 अगर ($ प्राइमहॉस्ट) {
     // हमारे पास एक प्राथमिक (प्रगति में कोई विफलता नहीं है) आदि - इसका उपयोग करें।
     $ बैकेंड = नया Zend_Cache_Backend_CacheLRUdWrapper (
         $ बैकेंड
         $ संग्रह-> getName (),
         $ प्राथमिक आधार,
         अशक्त,
         सरणी ($ yourLoggerClass, 'yourLoggerFunctionName')
     );
 }
 // आप इस लाइन के नीचे $ बैकेंड का उपयोग कर सकते हैं।

टिप्पणियों में साझा करें: आप इस सब के बारे में क्या सोचते हैं?