इन-मेमोरी डेटाबेस: एप्लिकेशन, स्केलिंग और महत्वपूर्ण परिवर्धन

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



किन मामलों में मुझे इन-मेमोरी पर स्विच करना चाहिए? पैमाने पर कैसे और क्यों? और क्या ध्यान देने योग्य है? उत्तर वक्ताओं के भाषणों में हैं, जिन्हें हम इस पोस्ट में शामिल करेंगे।

लेकिन पहले, वक्ताओं की कल्पना करो:

• एंड्री ट्रुस्किन, सेंटर फॉर इनोवेशन एंड एडवांस्ड टेक्नॉलॉजीज़ ऑफ़ प्रोमस्वाज़बैंक के प्रमुख
  
• व्लादिस्लाव शपीलेवा, टारेंटूल डेवलपर
  
• अर्टिओम शितोव, ग्रिडगैन सॉल्यूशन आर्किटेक्ट
  

इन-मेमोरी में स्विच करें

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

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

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

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

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

सुलह की समस्या

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

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

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

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

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

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

टारेंटूल के साथ मेमोरी डेटाबेस में स्केलिंग

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

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

डेटा को स्केल करने के लिए शेयरिंग का उपयोग किया जाता है: कई सर्वर बनाए जाते हैं, और वे अलग-अलग डेटा संग्रहीत करते हैं। इसलिए आप गणना और डेटा दोनों को मापते हैं। लेकिन इस मामले में गलती सहनशीलता कम है। यदि एक सर्वर विफल हो जाता है, तो डेटा का हिस्सा खो जाएगा।

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

प्रतिकृति

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

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



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

एक और चुनौती: टोपोलॉजी को जटिल कैसे बनाया जाए? उदाहरण के लिए, Mail.ru में सैकड़ों टारेंटूल के साथ एक टोपोलॉजी है। इसमें एक टारेंटूल कर्नेल है, जिसमें बैकअप के लिए प्रतिकृति टारेंटुला एक सर्कल में बंधे हैं। टारेंटूल में, आप पूरी तरह से मनमाना टोपोलॉजी बना सकते हैं, इस जीवन के साथ पूरी तरह से प्रतिकृति।

sharding

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

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



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



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

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

नतीजतन, हमें तीन प्रकार की शार्किंग मिलती है : पर्वतमाला, हैश और आभासी बाल्टियाँ । पर्वतमाला और बाल्टी के मामले में, एक भौतिक खोज समस्या है।

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

ग्रिडग्रैन प्लेटफार्म उदाहरण के साथ उन्नत इन-मेमोरी

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

ये सभी विचार नए नहीं हैं। इनमें से कई चीजें, एक डिग्री या दूसरे में, क्लासिक डीबीएमएस में लागू की जाती हैं, विशेष रूप से, डेटा केंद्रों के बीच प्रतिकृति।

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

तो अगर अचानक एक तबाही हुई, तो बैकअप से उबरने का एक अवसर होना चाहिए। और अगर हम एक वित्तीय संगठन के बारे में बात कर रहे हैं, तो यह महत्वपूर्ण है कि यह बैकअप सुसंगत हो, न कि सभी ड्राइव से एक प्रति। ताकि कोई स्थिति न हो जहां नोड्स के कुछ हिस्सों पर डेटा को समय X पर पुनर्स्थापित किया गया था, और दूसरे भाग पर Y. समय पर प्वाइंट-इन-टाइम रिकवरी होना बहुत महत्वपूर्ण है, ताकि डेटा भ्रष्टाचार या विशेष रूप से गंभीर दुर्घटना की स्थिति में भी नुकसान की मात्रा को कम से कम किया जा सके।

डेटा को डिस्क पर पुश करने में सक्षम होना महत्वपूर्ण है। ताकि क्लस्टर ओवरलोड के दायरे में न आए और धीमी गति से भी काम करता रहे। और डिस्क से जल्दी से उठने के लिए, और फिर पहले से ही डेटा को मेमोरी में पंप किया।


इन-मेमोरी प्रतिक्रिया ग्रिडग्रेन फॉल्ट टॉलरेंस घटकों के साथ और उसके बिना क्रैश करने के लिए

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

इस परिप्रेक्ष्य में MongoDB पर विचार करें। हर कोई जो MongoDB के साथ काम कर चुका है, बड़ी संख्या में प्रक्रियाओं से अवगत है। यदि हमारे पास 5 शार्क का एक छायांकित MongoDB है, तो प्रत्येक शार्क के पास तीन प्रक्रियाओं का प्रतिकृति सेट होगा (3 के अतिरेक अनुपात के साथ)। और यह केवल डेटा पर ही 15 प्रक्रियाएँ हैं। क्लस्टर कॉन्फ़िगरेशन संग्रहण एक और प्लस 3 प्रक्रिया है, कुल में यह 18 हो जाता है, और इसमें राउटर शामिल नहीं हैं। यदि आप 20 शार्क चाहते हैं, तो 63+ (उदाहरण के लिए, एक और 8, कुल 71) प्रक्रियाओं में से नरक में आपका स्वागत है।



कैसंड्रा के साथ तुलना करें। हम सभी एक ही 5 शार्क लेते हैं - ये 5 प्रक्रियाएं हैं और 3 के समान अतिरेक अनुपात के साथ 5 नोड्स हैं, जो नियंत्रण के मामले में बहुत सरल है। मुझे 20 शार्द चाहिए - ये 20 प्रक्रियाएँ हैं। मैं अपने क्लस्टर को किसी भी संख्या में नोड्स में स्केल कर सकता हूं, जरूरी नहीं कि 3 से अधिक (या अतिरेक गुणांक के दूसरे मूल्य)। प्रतिकृति सेट की तुलना में लागू करने और बनाए रखने के लिए बहुत आसान और सस्ता।



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

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

और अंत में, समर्थन। अगर कुछ अचानक काम नहीं करता है, तो कंपनी बस पैसा खो देती है। कुछ क्षेत्रों के लिए यह महत्वपूर्ण नहीं है, लेकिन अक्सर यह महत्वपूर्ण होता है कि कोई व्यक्ति उत्पाद और उसके काम की जिम्मेदारी उठाता है। यह दावा करने के लिए किसी भी समय संभव था, और यह जल्दी से हल हो गया था।

इस पोस्ट के साथ हम Habr पर Promsvyazbank का वर्ष पूरा कर रहे हैं। हमने एक लघु वीडियो में खाबरोवस्क के निवासियों के लिए नए साल की शुभकामनाएं एकत्र की: