दोषरहित इलास्टिक खोज डेटा माइग्रेशन

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

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

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

लोचदार

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

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

ElasticSearch नोएसक्यूएल का प्रतिनिधि है जो ल्यूसिन इंजन पर एक RESTful JSON एपीआई के साथ जुड़ा हुआ है, जावा में खुला स्रोत है, जो न केवल एक खोज सूचकांक बनाने में सक्षम है, बल्कि मूल दस्तावेज़ को भी संग्रहीत करता है। इस तरह के एक फंतासी मूल भंडारण के लिए एक अलग DBMS की भूमिका पर पुनर्विचार करने में मदद करता है, या यहां तक ​​कि इसे छोड़ देता है। परिचय का अंत।

मानचित्रण

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

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

उपनाम

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

Reindex API

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

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

एक फ़ील्ड को इस तरह जोड़ा जाता है। स्रोत सूचकांक योजना ली गई है, एक नई संपत्ति दर्ज की गई है, एक खाली सूचकांक बनाया गया है। फिर शुरू होता है:

{ "source": { "index": "test" }, "dest": { "index": "test_clone" } } 

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

 { "source": { "index": "test", "_source": ["field1", "field3"] }, "dest": { "index": "test_clone" } } 

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

प्रवास

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

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

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

इन मामलों में गंतव्य इंडेक्स में कार्रवाई को पुन: प्रस्तुत नहीं किया जाना चाहिए। अन्य परिवर्तनों का पुनरुत्पादन किया जाता है।

हैप्पी कोडिंग!