वेब सेवांसाठी इन-मेमरी आर्किटेक्चर: तंत्रज्ञान मूलभूत आणि तत्त्वे

इन-मेमरी हा डेटा संचयित करण्याच्या संकल्पनांचा एक संच आहे जेव्हा तो अनुप्रयोगाच्या RAM मध्ये संग्रहित केला जातो आणि डिस्कचा वापर बॅकअपसाठी केला जातो. शास्त्रीय पद्धतींमध्ये, डेटा डिस्कवर संग्रहित केला जातो आणि मेमरी कॅशेमध्ये संग्रहित केली जाते. उदाहरणार्थ, डेटावर प्रक्रिया करण्यासाठी बॅकएंड असलेले वेब ऍप्लिकेशन स्टोरेजमध्ये विनंती करते: ते ते प्राप्त करते, त्याचे रूपांतर करते आणि नेटवर्कवर भरपूर डेटा हस्तांतरित केला जातो. इन-मेमरीमध्ये, गणना डेटा - स्टोरेजवर पाठविली जाते, जिथे ते प्रक्रिया केली जाते आणि नेटवर्क कमी लोड केले जाते.

त्याच्या आर्किटेक्चरबद्दल धन्यवाद, इन-मेमरी डेटा ऍक्सेस अनेक वेळा वाढवते, आणि काहीवेळा तीव्रतेचे ऑर्डर देखील जलद करते. उदाहरणार्थ, बँक विश्लेषकांना विश्लेषणात्मक ऍप्लिकेशनमध्ये गेल्या वर्षभरात जारी केलेल्या कर्जाचा अहवाल डायनॅमिक्समध्ये पहायचा आहे. या प्रक्रियेस क्लासिक DBMS वर काही मिनिटे लागतील, परंतु इन-मेमरीसह ती जवळजवळ लगेच दिसून येईल. याचे कारण असे की हा दृष्टिकोन तुम्हाला अधिक माहिती कॅशे करण्यास अनुमती देतो आणि ती RAM मध्ये “हातात” संग्रहित केली जाते. अनुप्रयोगास हार्ड ड्राइव्हवरून डेटाची विनंती करण्याची आवश्यकता नाही, ज्याची उपलब्धता नेटवर्क आणि डिस्क गतीद्वारे मर्यादित आहे.

इन-मेमरीमध्ये इतर कोणत्या शक्यता उपलब्ध आहेत आणि हा कोणत्या प्रकारचा दृष्टिकोन आहे? व्लादिमीर प्लिगिन - ग्रिडगेन येथे अभियंता. हे पुनरावलोकन साहित्य वेब ऍप्लिकेशन बॅकएंड डेव्हलपरसाठी उपयुक्त ठरेल ज्यांनी इन-मेमरीसह काम केले नाही आणि प्रयत्न करू इच्छितात किंवा सॉफ्टवेअर डेव्हलपमेंट आणि आर्किटेक्चर डिझाइनमधील आधुनिक ट्रेंडमध्ये स्वारस्य आहे.

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

इन-मेमरी कोण आणि कसे वापरते

इन-मेमरी बहुतेकदा वापरली जाते जेथे जलद वापरकर्ता परस्परसंवाद किंवा मोठ्या प्रमाणात डेटावर प्रक्रिया करणे आवश्यक असते.

• बँका इन-मेमरी वापरा, उदाहरणार्थ, क्लायंट अॅप्लिकेशन वापरताना होणारा विलंब कमी करण्यासाठी किंवा कर्ज जारी करण्यापूर्वी क्लायंटचे विश्लेषण करण्यासाठी.
• फिनटेक डेटा प्रोसेसिंग आणि विश्लेषण आउटसोर्स करणार्‍या बँकांसाठी सेवा आणि अनुप्रयोगांचे कार्यप्रदर्शन सुधारण्यासाठी इन-मेमरी वापरते. 
• विमा कंपन्या: जोखीम मोजण्यासाठी, उदाहरणार्थ, अनेक वर्षांच्या ग्राहक डेटाचे विश्लेषण करून.
• लॉजिस्टिक कंपन्या. ते बर्याच डेटावर प्रक्रिया करतात, उदाहरणार्थ, हजारो पॅरामीटर्ससह मालवाहतूक आणि प्रवासी वाहतुकीसाठी इष्टतम मार्गांची गणना करण्यासाठी आणि शिपमेंटच्या स्थितीचा मागोवा घेण्यासाठी.
• किरकोळ. इन-मेमरी सोल्यूशन्स ग्राहकांना जलद सेवा देण्यासाठी आणि मोठ्या प्रमाणात माहितीवर प्रक्रिया करण्यास मदत करतात: शिपमेंट, इनव्हॉइस, व्यवहार, गोदामांमध्ये हजारो वस्तूंची उपस्थिती आणि विश्लेषणात्मक अहवाल तयार करणे.
• В IoT इन-मेमरी पारंपारिक डेटाबेस बदलते.
• फार्मास्युटिकल कंपन्या इन-मेमरी वापरतात, उदाहरणार्थ, औषध रचनांच्या संयोजनाद्वारे क्रमवारी लावण्यासाठी. 

आमचे क्लायंट इन-मेमरी सोल्यूशन्स कसे वापरतात आणि तुम्ही त्यांची स्वतः अंमलबजावणी कशी करू शकता याची काही उदाहरणे मी तुम्हाला सांगेन.

प्राथमिक स्टोरेज म्हणून इन-मेमरी

आमचा एक क्लायंट यूएसए मधून वैद्यकीय वैज्ञानिक उपकरणांचा मोठा पुरवठादार आहे. ते त्यांचे मुख्य डेटा स्टोरेज म्हणून इन-मेमरी सोल्यूशन वापरतात. सर्व डेटा डिस्कवर संग्रहित केला जातो आणि सक्रियपणे वापरलेल्या डेटाचा उपसंच RAM मध्ये ठेवला जातो. स्टोरेज ऍक्सेस पद्धती मानक आहेत - GDBC (जेनेरिक डेटाबेस कनेक्टर) आणि SQL क्वेरी भाषा.

एकत्रितपणे याला इन-मेमरी डेटाबेस (IMDB) किंवा मेमरी-केंद्रित स्टोरेज म्हणतात. समाधानाच्या या वर्गाला अनेक नावे आहेत, ती फक्त एकच नाहीत. 

IMDB वैशिष्ट्ये:

• इन-मेमरीमध्ये संग्रहित केलेला आणि SQL द्वारे प्रवेश केलेला डेटा इतर पद्धतींप्रमाणेच आहे. ते समक्रमित आहेत, फक्त सादरीकरणाची पद्धत, त्यांना संबोधित करण्याची पद्धत वेगळी आहे. व्यवहार डेटा दरम्यान कार्य करते.

• IMDB रिलेशनल डेटाबेसपेक्षा वेगवान आहे कारण डिस्क पेक्षा RAM वरून माहिती पुनर्प्राप्त करणे जलद आहे. 
• अंतर्गत ऑप्टिमायझेशन अल्गोरिदममध्ये कमी सूचना आहेत.
• आयएमडीबी डेटा, इव्हेंट्स आणि अॅप्लिकेशन्समधील व्यवहार व्यवस्थापित करण्यासाठी योग्य आहेत.

IMDBs आंशिकपणे ACID ला समर्थन देतात: अणु, सुसंगतता आणि अलगाव. परंतु ते "टिकाऊपणा" चे समर्थन करत नाहीत - जेव्हा पॉवर बंद होते, तेव्हा सर्व डेटा गमावला जातो. समस्येचे निराकरण करण्यासाठी, तुम्ही स्नॅपशॉट वापरू शकता - डेटाबेसचा “स्नॅपशॉट”, हार्ड ड्राइव्हवरील डेटाबेस बॅकअपशी साधर्म्य असलेला, किंवा रीबूट केल्यानंतर डेटा पुनर्संचयित करण्यासाठी व्यवहार (लॉग) रेकॉर्ड करा.

दोष-सहिष्णु अनुप्रयोग तयार करण्यासाठी

दोष-सहिष्णु वेब अनुप्रयोगाच्या क्लासिक आर्किटेक्चरची कल्पना करूया. हे असे कार्य करते: सर्व विनंत्या सर्व्हर दरम्यान वेब बॅलन्सरद्वारे वितरित केल्या जातात. ही प्रणाली स्थिर आहे कारण सर्व्हर एकमेकांना डुप्लिकेट करतात आणि घटनांच्या बाबतीत बॅकअप घेतात.

बॅलन्सर एका सत्रातील सर्व विनंत्या एका सर्व्हरकडे काटेकोरपणे निर्देशित करतो. ही स्टिक सेशन मेकॅनिझम आहे: प्रत्येक सेशन सर्व्हरशी संबंधित आहे जिथे ते स्थानिकरित्या संग्रहित आणि प्रक्रिया केली जाते. 

सर्व्हरपैकी एक अयशस्वी झाल्यावर काय होते?

आर्किटेक्चर डुप्लिकेट केल्यामुळे सेवेवर परिणाम होणार नाही. परंतु आम्ही मृत सर्व्हरच्या सत्रांचा उपसंच गमावू. आणि त्याच वेळी, या सत्रांशी जोडलेले वापरकर्ते. उदाहरणार्थ, क्लायंट ऑर्डर देतो आणि अचानक त्याला ऑफिसमधून बाहेर फेकतो. जेव्हा तो पुन्हा लॉग इन करतो आणि सर्व काही पुन्हा करावे लागेल हे लक्षात येते तेव्हा तो दुःखी होईल.

मोठ्या संख्येने वापरकर्त्यांना समर्थन देण्यासाठी आणि धीमे न होण्यासाठी वेब अनुप्रयोग आवश्यक आहे जेणेकरून ते आरामात कार्य करू शकतील. परंतु ते नाकारल्यास, प्रत्येक त्यानंतरच्या विनंतीसह सत्र स्टोअरशी संवाद साधण्यासाठी लागणारा वेळ वाढेल. हे इतर वापरकर्त्यांसाठी सरासरी विलंब वाढवते. पण त्यांना पूर्वीपेक्षा जास्त वेळ थांबायचे नाही.

ही समस्या आमच्या इतर क्लायंटप्रमाणे सोडवली जाऊ शकते, यूएसए मधील एक मोठा PASS प्रदाता. वेब सेशन्स क्लस्टर करण्यासाठी ते इन-मेमरी वापरते. हे करण्यासाठी, ते त्यांना स्थानिक पातळीवर नाही तर मध्यभागी - इन-मेमरी क्लस्टरमध्ये संग्रहित करते. या प्रकरणात, सत्रे खूप जलद उपलब्ध आहेत कारण ते आधीच RAM मध्ये आहेत.

जेव्हा सर्व्हर क्रॅश होतो, तेव्हा बॅलन्सर क्रॅश झालेल्या सर्व्हरकडून इतर सर्व्हरला विनंत्या पाठवतो, जसे शास्त्रीय आर्किटेक्चरमध्ये. परंतु एक महत्त्वाचा फरक आहे: सत्रे इन-मेमरी क्लस्टरमध्ये संग्रहित केली जातात आणि सर्व्हरना पडलेल्या सर्व्हरच्या सत्रांमध्ये प्रवेश आहे.

हे आर्किटेक्चर संपूर्ण सिस्टमची दोष सहनशीलता वाढवते. शिवाय, स्टिक सेशन यंत्रणा पूर्णपणे सोडून देणे शक्य आहे.

हायब्रिड ट्रान्झॅक्शनल अॅनालिटिकल प्रोसेसिंग (HTAP)

सामान्यतः, व्यवहार आणि विश्लेषणात्मक प्रणाली वेगळ्या ठेवल्या जातात. जेव्हा ते वेगळे होतात तेव्हा मुख्य आधार भाराखाली येतो. विश्लेषणात्मक प्रक्रियेसाठी, डेटा प्रतिकृतीमध्ये कॉपी केला जातो जेणेकरुन विश्लेषणात्मक प्रक्रियेमुळे व्यवहार प्रक्रियेत व्यत्यय येणार नाही. परंतु कॉपी करणे हे एका अंतराने होते - अंतराशिवाय प्रतिकृती करणे अशक्य आहे. जर आम्ही हे समकालिकपणे केले तर ते मुख्य आधार देखील कमी करेल आणि आम्हाला कोणतेही विजय मिळणार नाहीत.

HTAP मध्ये, सर्वकाही वेगळ्या पद्धतीने कार्य करते - समान डेटा स्टोअर ऍप्लिकेशन्समधील व्यवहार लोड करण्यासाठी आणि विश्लेषणात्मक क्वेरीसाठी वापरले जाते ज्या पूर्ण होण्यासाठी बराच वेळ लागू शकतो. जेव्हा डेटा RAM मध्ये असतो, तेव्हा विश्लेषणात्मक क्वेरी जलद अंमलात आणल्या जातात आणि डेटाबेससह सर्व्हर कमी लोड केला जातो (सरासरी).

संकरित दृष्टीकोन व्यवहार प्रक्रिया आणि विश्लेषण यांच्यातील भिंत तोडतो. जर आम्ही त्याच स्टोरेजवर विश्लेषण केले, तर RAM मधील डेटावर विश्लेषणात्मक क्वेरी सुरू केल्या जातात. ते अधिक अचूक, अधिक व्याख्या करण्यायोग्य आणि पुरेसे आहेत.

इन-मेमरी सोल्यूशन्सचे एकत्रीकरण

एक (तुलनेने) सोपा मार्ग - सुरवातीपासून सर्वकाही विकसित करा. आम्ही डिस्कवर डेटा ठेवतो आणि मेमरीमध्ये गरम डेटा संग्रहित करतो. हे सर्व्हर रीबूट किंवा आउटेज टिकून राहण्यास मदत करते.

जेव्हा डेटा डिस्कवर संग्रहित केला जातो तेव्हा येथे कामावर दोन मुख्य परिस्थिती आहेत. प्रथम, आम्हाला क्लस्टर किंवा भागांच्या क्रॅश किंवा नियमित रीबूटपासून वाचायचे आहे - आम्हाला ते एक साधा डेटाबेस म्हणून वापरायचे आहे. दुसऱ्या परिस्थितीमध्ये, जेव्हा खूप डेटा असतो, तेव्हा त्यातील काही मेमरीमध्ये असतो.

सुरवातीपासून सर्वकाही तयार करणे शक्य नसल्यास, इन-मेमरी आधीपासूनच समाकलित करणे शक्य आहे. विद्यमान आर्किटेक्चर. परंतु सर्व इन-मेमरी सोल्यूशन्स यासाठी योग्य नाहीत. तीन अनिवार्य अटी आहेत. इन-मेमरी सोल्यूशनला समर्थन देणे आवश्यक आहे:

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

जर तिन्ही अटी पूर्ण झाल्या तर एकत्रीकरण शक्य आहे. आम्ही ॲप्लिकेशन आणि डेटाबेस दरम्यान इन-मेमरी डेटा ग्रिड ठेवतो. आता लिखित विनंत्या अंतर्निहित डेटाबेसला सुपूर्द केल्या जातील, आणि डेटा कॅशेमध्ये नसल्यास वाचन विनंत्या अंतर्निहित डेटाबेसला सुपूर्द केल्या जातील.

जर तुमच्यासाठी डेटा आणि त्यावर प्रक्रिया करण्यासाठी जलद प्रवेश महत्त्वाचा असेल, उदाहरणार्थ, व्यवसाय विश्लेषणासाठी, तुम्ही इन-मेमरी लागू करण्याबद्दल विचार करू शकता. आणि अंमलबजावणीसाठी, नवीन आर्किटेक्चर डिझाइन करताना आपण दोन्ही पद्धती वापरू शकता.

स्त्रोत: www.habr.com