वेब सेवाओं के लिए इन-मेमोरी आर्किटेक्चर: प्रौद्योगिकी बुनियादी बातें और सिद्धांत

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

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

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

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

इन-मेमोरी का उपयोग कौन और कैसे करता है

इन-मेमोरी का उपयोग अक्सर वहां किया जाता है जहां तेज उपयोगकर्ता इंटरैक्शन या बड़ी मात्रा में डेटा की प्रोसेसिंग की आवश्यकता होती है।

• बैंकों उदाहरण के लिए, जब ग्राहक एप्लिकेशन का उपयोग करते हैं तो देरी को कम करने के लिए या ऋण जारी करने से पहले ग्राहक का विश्लेषण करने के लिए इन-मेमोरी का उपयोग करें।
• интех डेटा प्रोसेसिंग और विश्लेषण को आउटसोर्स करने वाले बैंकों के लिए सेवाओं और अनुप्रयोगों के प्रदर्शन को बेहतर बनाने के लिए इन-मेमोरी का उपयोग करता है। 
• बीमा कंपनी: उदाहरण के लिए, कई वर्षों के ग्राहक डेटा का विश्लेषण करके जोखिमों की गणना करना।
• रसद कंपनियाँ. वे बहुत सारे डेटा को संसाधित करते हैं, उदाहरण के लिए, हजारों मापदंडों के साथ माल और यात्री परिवहन के लिए इष्टतम मार्गों की गणना करने और शिपमेंट की स्थिति को ट्रैक करने के लिए।
• खुदरा. इन-मेमोरी समाधान ग्राहकों को तेजी से सेवा देने और बड़ी मात्रा में जानकारी संसाधित करने में मदद करते हैं: शिपमेंट, चालान, लेनदेन, गोदामों में हजारों सामानों की उपस्थिति, और विश्लेषणात्मक रिपोर्ट तैयार करना।
• В IoT इन-मेमोरी पारंपरिक डेटाबेस का स्थान लेती है।
• फार्मास्युटिकल उदाहरण के लिए, दवा संयोजनों के संयोजन को क्रमबद्ध करने के लिए कंपनियाँ इन-मेमोरी का उपयोग करती हैं। 

मैं आपको कुछ उदाहरण बताऊंगा कि हमारे ग्राहक इन-मेमोरी समाधानों का उपयोग कैसे करते हैं और आप उन्हें स्वयं कैसे कार्यान्वित कर सकते हैं।

प्राथमिक भंडारण के रूप में इन-मेमोरी

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

सामूहिक रूप से इसे इन-मेमोरी डेटाबेस (IMDB) या मेमोरी-सेंट्रिक स्टोरेज कहा जाता है। समाधानों के इस वर्ग के कई नाम हैं, केवल ये ही नहीं हैं। 

आईएमडीबी विशेषताएं:

• जो डेटा इन-मेमोरी में संग्रहीत किया जाता है और SQL के माध्यम से एक्सेस किया जाता है वह अन्य तरीकों के समान ही होता है। वे समकालिक हैं, केवल प्रस्तुति का तरीका, उन्हें संबोधित करने का तरीका अलग है। लेन-देन डेटा के बीच काम करता है।

• IMDB रिलेशनल डेटाबेस से तेज़ है क्योंकि यह डिस्क की तुलना में RAM से जानकारी प्राप्त करने में तेज़ है। 
• आंतरिक अनुकूलन एल्गोरिदम में कम निर्देश होते हैं।
• IMDB अनुप्रयोगों में डेटा, घटनाओं और लेनदेन के प्रबंधन के लिए उपयुक्त हैं।

IMDB आंशिक रूप से ACID का समर्थन करते हैं: परमाणुता, संगति और अलगाव। लेकिन वे "स्थायित्व" का समर्थन नहीं करते - जब बिजली बंद हो जाती है, तो सारा डेटा खो जाता है। समस्या को हल करने के लिए, आप स्नैपशॉट का उपयोग कर सकते हैं - डेटाबेस का एक "स्नैपशॉट", हार्ड ड्राइव पर डेटाबेस बैकअप के समान, या रिबूट के बाद डेटा को पुनर्स्थापित करने के लिए लेनदेन (लॉग) रिकॉर्ड करें।

दोष-सहिष्णु अनुप्रयोग बनाना

आइए दोष-सहिष्णु वेब एप्लिकेशन की क्लासिक वास्तुकला की कल्पना करें। यह इस तरह काम करता है: सभी अनुरोध सर्वरों के बीच एक वेब बैलेंसर द्वारा वितरित किए जाते हैं। यह प्रणाली स्थिर है क्योंकि सर्वर एक-दूसरे की नकल करते हैं और घटनाओं के मामले में बैकअप लेते हैं।

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

जब कोई सर्वर विफल हो जाता है तो क्या होता है?

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

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

इस समस्या को हमारे अन्य क्लाइंट, यूएसए के एक बड़े PASS प्रदाता की तरह हल किया जा सकता है। यह वेब सत्रों को क्लस्टर करने के लिए इन-मेमोरी का उपयोग करता है। ऐसा करने के लिए, यह उन्हें स्थानीय रूप से नहीं, बल्कि केंद्रीय रूप से - इन-मेमोरी क्लस्टर में संग्रहीत करता है। इस मामले में, सत्र बहुत तेजी से उपलब्ध होते हैं क्योंकि वे पहले से ही रैम में होते हैं।

जब कोई सर्वर क्रैश हो जाता है, तो बैलेंसर क्रैश हुए सर्वर से अन्य सर्वरों को अनुरोध भेजता है, जैसा कि शास्त्रीय वास्तुकला में होता है। लेकिन एक महत्वपूर्ण अंतर है: सत्र इन-मेमोरी क्लस्टर में संग्रहीत होते हैं और सर्वर के पास गिरे हुए सर्वर के सत्रों तक पहुंच होती है।

यह आर्किटेक्चर पूरे सिस्टम की दोष सहनशीलता को बढ़ाता है। इसके अलावा, स्टिक सत्र तंत्र को पूरी तरह से त्यागना संभव है।

हाइब्रिड ट्रांजेक्शनल एनालिटिकल प्रोसेसिंग (HTAP)

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

HTAP में, सब कुछ अलग तरीके से काम करता है - एक ही डेटा स्टोर का उपयोग अनुप्रयोगों से लेनदेन लोड के लिए और विश्लेषणात्मक प्रश्नों के लिए किया जाता है जिन्हें पूरा होने में लंबा समय लग सकता है। जब डेटा रैम में होता है, तो विश्लेषणात्मक क्वेरीज़ तेजी से निष्पादित होती हैं, और डेटाबेस वाला सर्वर कम लोड होता है (औसतन)।

एक हाइब्रिड दृष्टिकोण लेनदेन प्रसंस्करण और विश्लेषण के बीच की दीवार को तोड़ देता है। यदि हम एक ही स्टोरेज पर एनालिटिक्स करते हैं, तो रैम से डेटा पर एनालिटिकल क्वेरीज़ लॉन्च की जाती हैं। वे कहीं अधिक सटीक, अधिक व्याख्या योग्य और पर्याप्त हैं।

इन-मेमोरी समाधानों का एकीकरण

एक (अपेक्षाकृत) सरल तरीका - सब कुछ खरोंच से विकसित करें. हम डेटा को डिस्क पर रखते हैं और हॉट डेटा को मेमोरी में स्टोर करते हैं। यह सर्वर रीबूट या आउटेज से बचने में मदद करता है।

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

यदि स्क्रैच से सब कुछ बनाना संभव नहीं है, तो इन-मेमोरी को पहले से ही एकीकृत करना संभव है मौजूदा वास्तुकला. लेकिन सभी इन-मेमोरी समाधान इसके लिए उपयुक्त नहीं हैं। तीन अनिवार्य शर्तें हैं. इन-मेमोरी समाधान को निम्नलिखित का समर्थन करना चाहिए:

• डेटाबेस से जुड़ने का मानक तरीका जो इसके नीचे स्थित होगा (उदाहरण के लिए, MySQL);
• एक मानक क्वेरी भाषा, ताकि भंडारण के साथ बातचीत के तर्क को फिर से लिखना और बदलना न पड़े;
• लेन-देन संबंधी - अंतःक्रिया के शब्दार्थ को सुरक्षित रखें।

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

यदि डेटा तक तेज़ पहुंच और उसका प्रसंस्करण आपके लिए महत्वपूर्ण है, उदाहरण के लिए, बिजनेस एनालिटिक्स के लिए, तो आप इन-मेमोरी को लागू करने के बारे में सोच सकते हैं। और कार्यान्वयन के लिए, आप एक नया आर्किटेक्चर डिज़ाइन करते समय दोनों विधियों का उपयोग कर सकते हैं।

स्रोत: www.habr.com