स्कैला पर दर्द रहित फॉलबैक कैश

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



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

नोट। लेख में कम से कम स्काला कोड और अधिकतम सामान्य सिद्धांत और विचार होंगे।

अस्थिर या धीमा बैकएंड

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

एंबेडेड कैश

पहला विचार पढ़ने के लिए डेटा लेना, डेटा प्राप्त करने वाले अनुरोधों और प्रत्येक इन-मेमोरी नोड के स्तर पर कैश को कॉन्फ़िगर करना है।



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

प्रतिनिधि

दूसरा विकल्प एक प्रॉक्सी है, जो अनुरोधों का हिस्सा लेता है या आवेदन को संशोधित करता है।



लेकिन प्रॉक्सी में, आप आवेदन के लिए सभी काम खुद नहीं कर सकते।

कैशिंग डेटाबेस

तीसरा विकल्प मुश्किल है जब डेटा का हिस्सा जिसे बैकेंड रिटर्न देता है, उसे लंबे समय तक भंडारण में रखा जा सकता है। जब उनकी आवश्यकता होती है, तो हम क्लाइंट को दिखाते हैं, भले ही वे प्रासंगिक न हों। यह कुछ नहीं से बेहतर है।



इस निर्णय पर चर्चा की जाएगी।

फ़ॉलबैक कैश

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

घटकों

हमारी लाइब्रेरी कुछ इस तरह दिखती है।



बायां हिस्सा इस भंडार के साथ बातचीत करने के लिए समर्पित है, जिसमें दो महत्वपूर्ण घटक शामिल हैं:

• घटक जो इनिशियलाइज़ेशन प्रक्रिया के लिए जिम्मेदार है - फॉलबैक कैश का उपयोग करने से पहले DBMS के साथ प्रारंभिक क्रिया;
  
• स्वचालित क्रमांकन पीढ़ी मॉड्यूल।
  

दाईं ओर सामान्य कार्यक्षमता है जो फालबैक से संबंधित है।

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

भंडारण आवश्यकताओं

लंबी शैल्फ जीवन - 30-500 दिन । कुछ कार्यों में लंबा समय लग सकता है, और यह सब समय डेटा को संग्रहीत करने के लिए आवश्यक है। इसलिए, हम ऐसा स्टोरेज चाहते हैं जो लंबे समय तक डेटा स्टोर कर सके। इन-मेमोरी इसके लिए उपयुक्त नहीं है।

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

उच्च डेटा उपलब्धता । सेवा से कुछ भी हो सकता है, लेकिन हम चाहते हैं कि DBMS हर समय उपलब्ध रहे।

कम भंडारण लागत । हम कैश में अतिरिक्त डेटा भेजते हैं। नतीजतन, ओवरहेड होता है। हमारे समाधान को लागू करते समय, हम इसे कम करना चाहते हैं।

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

मान्यताओं

आवश्यकताएँ उम्मीदवारों की सूची को कम करती हैं। हम मानते हैं कि हमने बाकी को लागू कर दिया है, और निम्नलिखित धारणाएं बनाते हैं, यह जानते हुए कि वास्तव में हमें फालबैक कैश की आवश्यकता क्यों है।

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

डेटा की प्रासंगिकता और अमान्यकरण की आवश्यकता नहीं है । अनुरोध के समय, यह माना जाता है कि हमारे पास नवीनतम संस्करण है जिसे हम दिखा रहे हैं।

हम बैकएंड से डेटा भेजते हैं और प्राप्त करते हैं। इस डेटा की संरचना पहले से ज्ञात है ।

भंडारण चयन

विकल्प के रूप में, हमने तीन मुख्य विकल्पों पर विचार किया।

पहला है कैसंड्रा । लाभ: UDT संग्रह के साथ उच्च उपलब्धता, आसान मापनीयता और अंतर्निहित क्रमबद्धता तंत्र।

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

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

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

दूसरा विकल्प CouchBase है । लाभ: डेटा पहुंच, मापनीयता और योजना।

CouchBase के साथ, आपको क्रमांकन के बारे में कम सोचने की आवश्यकता है। यह प्लस और माइनस दोनों है - हमें डेटा स्कीम को नियंत्रित करने की आवश्यकता नहीं है। वैश्विक सूचकांक हैं जो आपको एक क्लस्टर में वैश्विक स्तर पर अंतराल प्रश्नों को चलाने की अनुमति देते हैं।

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

स्कीमलैस और JSON भी माइनस हो सकते हैं। डेटा को इतने लंबे समय तक संग्रहीत किया जा सकता है कि एप्लिकेशन को बदलने का समय हो। इस मामले में, CouchBase को संग्रहीत करने और पढ़ने के लिए डेटा संरचना भी बदल जाएगी। पिछला संस्करण संगत नहीं हो सकता है। आप इसे पढ़ते समय केवल इसके बारे में जानेंगे, न कि डेटा को विकसित करते समय, जब यह उत्पादन में कहीं निहित हो। हमें उचित प्रवासन के बारे में सोचना होगा, और यह वही है जो हम नहीं करना चाहते हैं।

तीसरा विकल्प टारनटूल है । यह अपनी सुपर स्पीड के लिए प्रसिद्ध है। इसमें एक अद्भुत LUA इंजन है जो आपको तर्क का एक गुच्छा लिखने की अनुमति देता है जो LuaJit पर सर्वर पर सही निष्पादित करेगा।

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

शेयरिंग / प्रतिकृति

शायद हमारे आवेदन को शेयरिंग / प्रतिकृति की आवश्यकता होगी। तीन रिपॉजिटरी उन्हें अलग तरीके से लागू करते हैं।

कैसेंड्रा एक संरचना का सुझाव देता है जिसे आमतौर पर "रिंग" कहा जाता है।



कई नोड उपलब्ध हैं। उनमें से प्रत्येक प्रतिरूप के रूप में निकटतम नोड्स से अपना डेटा और डेटा संग्रहीत करता है। यदि कोई बाहर निकलता है, तो उसके बगल में स्थित नोड ड्रॉपआउट होने तक उसके डेटा के हिस्से की सेवा कर सकता है।

समान संरचना के लिए Sharding \ Replication जिम्मेदार है। 10 टुकड़ों और प्रतिकृति कारक 3 में अनपैक करने के लिए, 10 नोड्स पर्याप्त हैं। प्रत्येक नोड्स पड़ोसी से 2 प्रतिकृतियां संग्रहीत करेगा।

काउचबेस में, नोड्स के बीच परस्पर क्रिया संरचना समान रूप से संरचित है:

• ऐसा डेटा है जो सक्रिय के रूप में चिह्नित है, जिसके लिए नोड स्वयं जिम्मेदार है;
  
• पड़ोसी नोड्स की प्रतिकृतियां हैं जो काउचबेस स्टोर करती हैं।
  

यदि एक नोड बाहर निकलता है, तो पड़ोसी, साझा लोग, चाबियों के इस हिस्से के रखरखाव के लिए जिम्मेदारी लेते हैं।

टारनटूल में, वास्तुकला MongoDB के समान है। लेकिन एक अति सूक्ष्म अंतर के साथ: एक दूसरे के साथ दोहराए जाने वाले समूह हैं।



पिछले दो आर्किटेक्चर के लिए, यदि हम 4 शार्क बनाना चाहते हैं और प्रतिकृति कारक 3, 4 नोड्स की आवश्यकता है। टारनटूल के लिए - 12! लेकिन नुकसान टारनटूल की गारंटी की गति से ऑफसेट है।

कैसेंड्रा

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

ऑटो क्रमांकन

SQL प्रोटोकॉल मानता है कि आप डेटा स्कीमा को परिभाषित करने के लिए काफी स्वतंत्र हैं।

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

इसलिए, स्वचालित रूप से उत्पन्न क्रमांकन लगभग उसी तरीके से होता है। यदि हमारे पास एक बुनियादी प्रकार है जो डेटाबेस से एक से एक प्रकार से मेल खा सकता है, तो हम ऐसा करते हैं। Int, Long, String, Double के प्रकार का एक सेट कैसंड्रा में भी है।

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

स्काला में संग्रह से सभी प्रकार के संग्रह प्रकार सूची में परिवर्तित हो जाते हैं। ये आदेशित संग्रह हैं जिनमें एक सूचकांक मिलान तत्व है।

अनियंत्रित सेट संग्रह की गारंटी है कि प्रत्येक मूल्य के साथ एक तत्व है। कैसंड्रा भी उनके लिए एक विशेष सेट प्रकार है।

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

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

दूसरा प्रकार बीजीय योग का प्रकार है । इस स्थिति में, प्रकार कई पूर्व ज्ञात उपप्रकारों या उप-प्रजाति से मेल खाता है। इसके अलावा, एक निश्चित तरीके से, हम इसे एक संरचना प्रदान करते हैं।

सार डेटा प्रकार UDT में अनुवाद

हमारे पास एक संरचना है, और हम इसे एक से एक प्रदर्शित करते हैं - प्रत्येक क्षेत्र के लिए हम कैसेंड्रा में बनाए गए यूडीटी में क्षेत्र को परिभाषित करते हैं:

case class Account ( id: Long, tags: List[String], user: User, finData: Option[FinData] ) create type account ( id bigint, tags: frozen<list<text>>, user frozen<user>, fin_data frozen<fin_data> ) 

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

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

यदि हम एक प्रकार से मिलते हैं जिसमें कई पूर्व-ज्ञात विकल्प हैं, तो हम कैसेंड्रा में एक नए डेटा प्रकार को भी परिभाषित करते हैं। प्रत्येक विकल्प के लिए, यूडीटी में हमारे डेटा प्रकार में एक फ़ील्ड।

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

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

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

प्रारंभ

आरंभिक प्रक्रिया एक प्रारंभिक प्रक्रिया है जिसे हमें अपने कमबैक का उपयोग करने से पहले पूरा करना होगा।

यह प्रक्रिया कैसे काम करती है?

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

 sealed trait User case class Anonymous extends User case class Registered extends User case class Moderator extends User case class Admin extends User create type user ( anonymous frozen<anonymous>, registered frozen<registered>, moderator frozen<moderator>, admin frozen<admin> ) 

ऐसा ही होता है। हमारे पास प्रकार , टेबल और क्वेरी हैं । प्रकार अन्य प्रकारों पर निर्भर करते हैं, दूसरों पर। टेबल्स इन प्रकारों पर निर्भर करते हैं। क्वेरी पहले से ही उन तालिकाओं पर निर्भर करती हैं जिनसे वे डेटा पढ़ते हैं। प्रारंभिक इन सभी निर्भरताओं की जांच करेगा और DBMS में वह सब कुछ बना देगा जो इसे बना सकता है, कुछ नियमों के अनुसार।

माइग्रेशन टाइप करें

यह कैसे निर्धारित किया जाए कि एक प्रकार को आकस्मिक रूप से माइग्रेट किया जा सकता है?

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

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

प्रारंभिककरण: प्रकार

कल्पना करें कि कई प्रकार की परिभाषाएँ हैं:

 case class Product (id: Long, name: ctring, price: BigDecimal) case class UserOffers (valiDate: LocalDate, offers: Seq[Products]) case class UserProducts (user User, products: Map[Date, Product]) case class UserInfo: UserOffers, products: UserProducts) 

केस क्लास - एक ऐसा वर्ग जिसमें खेतों का एक सेट होता है। यह रस्ट में संरचना का एक एनालॉग है।

हम 4 प्रकारों में से प्रत्येक के लिए लगभग ऐसी डेटा परिभाषाएँ उत्पन्न करेंगे - जिसे हम अंततः क्रैंक करना चाहते हैं:

 CREATE TYPE product (id bigint, name text, price decimal); CREATE TYPE user_offers (valid_date date, offers frozen<list<frozen<offer>>>); CREATE TYPE user_products (user frozen<user>, products frozen<map<date, frozen<product>>); CREATE TYPE user_jnfo (offers: frozen<user_offers>, products: frozen<user_products>); 

User_offers का प्रकार ऑफ़र के प्रकार पर निर्भर करता है, user_products उत्पाद के प्रकार पर निर्भर करता है, user_info दूसरे और तीसरे प्रकार पर।



हमारे पास प्रकारों के बीच ऐसी निर्भरता है, और हम इसे सही ढंग से प्रारंभ करना चाहते हैं। आरेख दिखाता है कि हम समानांतर में user_offers और user_products को इनिशियलाइज़ करेंगे। इसका मतलब यह नहीं है कि हम दो समानांतर संचालन शुरू करेंगे। नहीं, हम सभी कथन शुरू करते हैं, सभी क्रमिक रूप से विश्लेषण करते हैं, इसलिए गलती से दो समानांतर धागे में एक ही प्रकार का निर्माण नहीं करते हैं।

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



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



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

प्रारंभिक: टेबल्स

आगे हम टेबल बनाते हैं।

 def getOffer (user: User, number: Long): Future[OfferData] create table get_offer( key frozen<tuple<frozen<user>, bigint>>PRIMARY KEY, value frozen<friend_data> ) 

ऐसा अनुरोध सीधे REST या SOAP अनुरोध लॉन्च कर सकता है, अंदर अतिरिक्त संचालन बना सकता है, या कई अनुरोध भी चला सकता है। यह सब आपके कोड पर निर्भर करता है - आपने किस तरह से कोड का आयोजन किया है। फॉलबैक पूरी तरह से विश्लेषण नहीं करता है कि उस पद्धति के अंदर क्या होता है जिस पर आप इस तरह के स्टब को लटकाते हैं।

विधि अतुल्यकालिक होनी चाहिए, क्योंकि फ़ॉलबैक एक ही है।

स्काला में, इसे एक विशेष प्रकार के Future के साथ टैग किया जाता है। इसका मतलब है कि परिणाम किसी दिन वापस आ जाएगा। जब वास्तव में - यह अज्ञात है: शायद तुरंत, या शायद नहीं।

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

 insert into get_offer(key, value) values (?key, ?value); select value from get_offer where key = ?key; 

DBMS के साथ बातचीत करने के लिए सब कुछ तैयार है। यह पता लगाना बाकी है कि हम फालबैक से डेटा कैसे पढ़ेंगे।

सर्किट ब्रेकर

यहां, जिम्मेदारी प्रसिद्ध सर्किट ब्रेकर पैटर्न के क्षेत्र में गुजरती है।



एक विशिष्ट सर्किट ब्रेकर में तीन राज्य शामिल हैं।

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

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

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

अल्पकालिक स्थिति में, हम फिर से बंद करने या एक लंबे समय के लिए खोलने का चयन करते हैं। यदि आधे-खुले राज्य में हम सफलतापूर्वक फ़ॉलबैक तक पहुँचते हैं और अगला अनुरोध प्राप्त करते हैं, तो हम बंद अवस्था में जाते हैं। यदि हम नहीं कर सकते हैं, तो हम ओपन में लौटते हैं, लेकिन लंबे समय तक।



हमने दो अतिरिक्त राज्यों को जोड़ा है जो स्पष्ट रूप से सर्किट ब्रेकर सर्किट से संबंधित नहीं हैं:

• मजबूर - जबरदस्ती बंद राज्य;
  
• उल्टा - खुले, बंद राज्य के लिए प्राथमिकता उलटी।
  

देखते हैं कि वे क्या करते हैं।

राज्यों के संचालन का सिद्धांत

बंद रहता है। योजना बड़ी है, लेकिन यह सामान्य सिद्धांत को समझने के लिए पर्याप्त है। हम फालबैक को समानांतर में रखते हैं कि हम बैकएंड से परिणाम कैसे लौटाते हैं, अगर सब कुछ वहां ठीक हो गया और फॉलबैक से पढ़ा गया। यदि यह हर जगह खराब है, तो हम त्रुटि प्राथमिकता लौटाते हैं।

दो त्रुटियों में से, बैकेंड त्रुटि का चयन करें।

यदि कोई त्रुटि नहीं है, तो हम इसके साथ समानांतर में काउंटर को बढ़ाते हैं और बहुत अधिक अनुरोध होने पर खुले राज्य में जाते हैं।



खोलें। ओपन की खुली स्थिति सरल है - हम लगातार फालबैक से पढ़ते हैं, चाहे कुछ भी हो, और थोड़ी देर बाद हम हाफ-ओपन स्टेट में स्विच करने का प्रयास करते हैं।

आधा खुला । संरचना में स्थित राज्य बंद जैसा दिखता है। अंतर यह है कि एक सफल उत्तर के मामले में, हम एक बंद स्थिति में जाते हैं। विफलता के मामले में - हम एक विस्तारित अंतराल के साथ खुले में वापस लौटते हैं।



जबरन कैश को गर्म करने के लिए एक अतिरिक्त राज्य है । जब हम इसे डेटा से भरते हैं, तो यह कभी भी फॉलबैक से पढ़ने की कोशिश नहीं करता है, लेकिन केवल रिकॉर्ड जोड़ता है।



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

समस्याओं

इस पूरी योजना के साथ, हमें कई समस्याएं थीं। सबसे गंभीर एक समझ है कि कैसे कसान्द्रा में तैयार बयान काम करते हैं। यह समस्या 4.0 संस्करण में तय की गई है, जो अभी तक जारी नहीं की गई है, इसलिए मैं आपको बताता हूं।

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

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

हमने इस समस्या को निम्न प्रकार से निपटाया: हमने अपने प्रत्येक तैयार अनुरोध में एक अद्वितीय पाठ जोड़ा ।

 create table get_offer( key frozen<tuple<frozen<user>, bigint>> PRIMARY KEY, value frozen<friend_data>, query_tag text ) insert into get_offer (key, value, query_tag) values (?key, ?value, 'tag_123'); select value as tag_123 from get_offer where key = ?key; 

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

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

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

यदि आप कई थ्रेड्स या कई नोड्स से प्रक्रियाओं को समानांतर करने का प्रयास करते हैं तो आप कैसेंड्रा को तोड़ सकते हैं।

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

तीसरी समस्या है फॉलबैक कैश में डेटा की कमी । यह हो सकता है कि हम इस विधि को "पूर्ण" कर दें, यह ऐतिहासिक डेटा को एक साल पहले संग्रहीत करना चाहिए, लेकिन वास्तव में हमने इसे कल लॉन्च किया था।

समस्या को गर्म करके हल किया गया था । हमने मजबूर राज्य का उपयोग किया और विशेष नोड्स लॉन्च किए जो वास्तविक उपयोगकर्ताओं के साथ संवाद नहीं करेंगे। वे सभी संभव कुंजियाँ लेंगे जो हम मानते हैं और एक सर्कल में कैश को गर्म करेंगे। वार्मिंग इतनी तेजी से हो रही है कि हम जिस बैकेंड से पढ़ रहे हैं उसे मारने के लिए नहीं।

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