Manticore इंडेक्स के मूल बातें

प्रकाशित: Apr 05, 2018
स्वत: अनुवाद: Basics of Manticore Indexes

इस लेख में, हम Manticore इंडेक्स का परिचय चर्चा करते हैं।

Manticore खोज दो भंडारण इंडेक्स प्रकारों का समर्थन करता है:

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

इसके अतिरिक्त, रियल-टाइम प्रकार पर आधारित एक विशेष इंडेक्स, जिसे percolate कहा जाता है, का उपयोग Percolate Queries संग्रहीत करने के लिए किया जा सकता है।

वर्तमान संस्करण में, इंडेक्स एक सामान्य डेटाबेस तालिका की तरह स्कीमा का उपयोग करते हैं। स्कीमा में 3 बड़े प्रकार के कॉलम हो सकते हैं:

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

निम्नलिखित डेटा प्रकारों को विशेषताओं में संग्रहीत किया जा सकता है:

बिना साइन किया हुआ 32 बिट और साइन किया हुआ 64 बिट पूर्णांक
32 बिट सिंगल प्रिसिजन फ्लोट
UNIX समय मोहर
बूलियन
स्ट्रिंग
JSON ऑब्जेक्ट्स
बिना साइन किए गए 32-बिट पूर्णांकों या साइन किए गए 64-बिट पूर्णांकों की बहु-मूल्य विशेषता सूची

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

एक अन्य भंडारहीन इंडेक्स प्रकार है template । टेम्पलेट इंडेक्स डेटा का भंडारण नहीं करता है, लेकिन यह भंडारण के साथ एक इंडेक्स की तरह टोकनाइजेशन सेटिंग्स रख सकता है। इसे टोकनाइजेशन नियमों का परीक्षण करने या हाइलाइट उत्पन्न करने के लिए उपयोग किया जा सकता है।

प्लेन इंडेक्स

संख्यात्मक (जिसमें MVA शामिल है) विशेषताओं को छोड़कर, प्लेन इंडेक्स में डेटा का शेष बिना परिवर्तन के है। यदि आपको नए रिकॉर्ड को अपडेट/जोड़ने की आवश्यकता है, तो आपको पुनर्निर्माण को फिर से निष्पादित करना होगा। जब इंडेक्स का पुनर्निर्माण किया जा रहा हो, तब मौजूदा इंडेक्स अभी भी अनुरोधों को सेवा देने के लिए उपलब्ध है। जब नया संस्करण तैयार होता है, तो एक प्रक्रिया जिसे rotation कहा जाता है, की जाती है जो नए संस्करण को ऑनलाइन लाती है और पुराने को त्याग देती है।

इंडेक्सिंग प्रदर्शन प्रक्रिया कई कारकों पर निर्भर करती है:

स्रोत डेटा प्रदान करने की गति
टोकनाइजेशन सेटिंग्स
हार्डवेयर संसाधन (CPU शक्ति, भंडारण गति)

सबसे सरल उपयोग परिदृश्य में, हम एकल प्लेन इंडेक्स का उपयोग करेंगे जिसे हम समय-समय पर पुनर्निर्मित करते हैं।

इसका तात्पर्य है:

इंडेक्स डेटा के स्रोत से ताजा नहीं है
इंडेक्सिंग की अवधि डेटा के साथ बढ़ती है

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

यह इंडेक्स काफी छोटा होगा और हम इसे अधिक बार इंडेक्स करेंगे। समय-समय पर, जब यह डेल्टा इंडेक्स बढ़ेगा, हम इसे “रीसेट” करना चाहेंगे।

यह मुख्य इंडेक्स को फिर से इंडेक्स करके या डेल्टा को मुख्य में मर्ज करके किया जा सकता है। मुख्य+डेल्टा इंडेक्स स्कीमा के बारे में विवरण डेल्टा इंडेक्स अपडेट में है।

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

इसके लिए एक विकल्प है जो एक दस्तावेज़ ids की सूची को परिभाषित करने की अनुमति देता है जो डेल्टा इंडेक्स द्वारा दबी हुई है। अधिक जानकारी के लिए, sql_query_killlist देखें।

रीयल-टाइम इंडेक्स

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

रियल-टाइम इंडेक्स खाली शुरू होता है और आप डेटाबेस तालिका के लिए समान तरीके से डेटा जोड़ सकते हैं, प्रतिस्थापित कर सकते हैं, अपडेट कर सकते हैं या हटा सकते हैं। अद्यतनों को पहले एक मेमोरी क्षेत्र (जिसे RAM चंक कहा जाता है) में रखा जाता है, जिसे rt_mem_limit द्वारा परिभाषित किया जाता है। जब यह भरा जाता है, तो इसे डिस्क चंक के रूप में निकाला जाता है - जिसका संरचना प्लेन इंडेक्स के समान होती है। जैसे-जैसे डिस्क चंक की संख्या बढ़ती है, खोज प्रदर्शन घटता है, क्योंकि खोज चंक पर अनुक्रमिक रूप से की जाती है। इससे बचने के लिए, चंक्स को एकल में विलय करने की आवश्यकता होती है, जिसे OPTIMIZE INDEX कमांड द्वारा किया जाता है।
The RAM chunk can be also be force to discard on disk with FLUSH RAMCHUNK . RAM(chunk)को डिस्क पर फोर्स से डिक्ट करने के लिए FLUSH RAMCHUNK का भी उपयोग किया जा सकता है। The best performance of a RT index is achieved after flushing the RAM chunk and optimizing the index - the RT index will have all the data in a single chunk and will have same performance as a plain index. RT इंडेक्स की सबसे अच्छी प्रदर्शन तब प्राप्त होती है जब RAM.chunk को फ्लश किया जाता है और इंडेक्स का ऑप्टिमाइजेशन किया जाता है - RT इंडेक्स में सभी डेटा एक ही चंक में होगा और यह एक सामान्य इंडेक्स के समान प्रदर्शन करेगा।

Populating a RealTime can be done in two ways: firing INSERTs or converting a plain index to become RealTime. वास्तविक समय में डेटा भरने के दो तरीके हैं: INSERTs फायर करना या converting सामान्य इंडेक्स को वास्तविक समय में बदलना। An existing data can be inserted by one record at a time or by batching many records into a single insert. एक मौजूदा डेटा को एक समय में एक रिकॉर्ड द्वारा या कई रिकॉर्ड को एक ही INSERT में बैचिंग करके डाला जा सकता है। Multiple parallel workers that insert data will speed up the process, but more CPU will be used. डेटा डाले जाने के लिए कई समानांतर कार्यकर्ताओं का उपयोग प्रक्रिया को तेज करेगा, लेकिन अधिक CPU का उपयोग होगा।

The RAM chunk size influence the speed of updates, a bigger RAM chunk will provide better performance, but it needs to be sized depending on the available memory. RAM चंक का आकार अपडेट की गति को प्रभावित करता है, एक बड़ा RAM चंक बेहतर प्रदर्शन प्रदान करेगा, लेकिन इसे उपलब्ध मेमोरी के अनुसार आकार दिया जाना चाहिए। It must be also noted that rt_mem_limit limits only the size of the RAM chunk. यह भी ध्यान देना चाहिए कि rt_mem_limit केवल RAM चंक का आकार सीमित करता है। Disk chunks (which are pretty much a plain index) will have their own memory requirements (for loading dictionary or attributes). डिस्क चंक्स (जो काफी हद तक एक सामान्य इंडेक्स हैं) की अपनी मेमोरी आवश्यकताएँ होंगी (शब्दकोश या विशेषताओं को लोड करने के लिए)।
The content of the RAM chunk is written to disk during a clean shutdown or periodically , defined by rt_flush_period directive (it can be forced with FLUSH RTINDEX command). RAM.chunk की सामग्री को एक स्वच्छ शटडाउन के दौरान या rt_flush_period निर्देश द्वारा निर्धारित अंतराल पर डिस्क पर लिखा जाता है (इसे FLUSH RTINDEX कमांड के साथ फोर्स किया जा सकता है)। RT index also can use binary logging for recording changes. RT इंडेक्स भी परिवर्तनों को रिकॉर्ड करने के लिए बाइनरी लॉगिंग का उपयोग कर सकता है। The binlog can be replayed at daemon startup for recovery after an unclean shutdown and is cleared after a RAM chunk flushing to disk. बिनलॉग को डेमन स्टार्टअप पर पुन: चलाया जा सकता है अनियमित शटडाउन के बाद रिकवरी के लिए और RAM.chunk को डिस्क पर फ्लश करने के बाद इसे साफ किया जाता है।
The flushing binlog strategy (similar to MySQL’s innodb_flush_log_at_trx_commit) can have an impact on performance. फ्लशिंग बिनलॉग रणनीति (MySQL के innodb_flush_log_at_trx_commit के समान) प्रदर्शन पर प्रभाव डाल सकती है। The binlog can be also disabled (by setting an empty binlog path), but this leave no protection for updates that are not yet flushed to disk. बिनलॉग को भी अक्षम किया जा सकता है (एक खाली बिनलॉग पथ सेट करके), लेकिन यह उन अपडेट्स के लिए कोई सुरक्षा नहीं छोड़ता है जो अभी तक डिस्क पर फ्लश नहीं किए गए हैं।
Local distributed indexes

A distributed index in Manticore Search doesn’t hold any data. Manticore खोज में एक वितरित इंडेक्स कोई डेटा नहीं रखता है। Instead it acts as a ‘master node’ to fire the demanded query on other indexes and provide merged results from the responses it receives from the ‘node’ indexes. इसके बजाय यह दूसरे इंडेक्स पर मांगी गई क्वेरी को फायर करने के लिए ‘मास्टर नोड’ की तरह कार्य करता है और ‘नोड’ इंडेक्स से जो प्रतिक्रियाएँ प्राप्त होती हैं, उनसे समिश्रण परिणाम प्रदान करता है। A distributed index can connect to local indexes or indexes located on other servers. एक वितरित इंडेक्स स्थानीय इंडेक्स या अन्य सर्वरों पर स्थित इंडेक्स से कनेक्ट कर सकता है। In our case, a distributed index would look like: हमारे मामले में, एक वितरित इंडेक्स इस तरह दिखेगा:

index_dist {  
  type = distributed  
  local = index1  
  local = index2  
  ...  

 }

The last step to enable multi-core searches is to define dist_threads in searchd section. मल्टी-कोर खोजों को सक्षम करने के लिए अंतिम चरण searchd अनुभाग में dist_threads को परिभाषित करना है। Dist_threads tells the engine the maximum number of threads it can use for a distributed index. Dist_threads इंजन को बताता है कि वह वितरित इंडेक्स के लिए अधिकतम कितने थ्रेड का उपयोग कर सकता है।
Remote distributed indexes and high availability

index mydist {  
          type = distributed  
          agent = box1:9312:shard1  
          agent = box2:9312:shard2  
          agent = box3:9312:shard3  

          agent = box4:9312:shard4  
}

Here we have split the data over 4 servers, each serving one of the shards. यहां हमने डेटा को 4 सर्वरों पर विभाजित किया है, प्रत्येक एक शार्ड की सेवा कर रहा है। If one of the servers fails, our distributed index will still work, but we would miss the results from the failed shard. यदि सर्वरों में से एक विफल हो जाता है, तो हमारा वितरित इंडेक्स अभी भी काम करेगा, लेकिन हम विफल शार्ड से परिणाम चूक जाएंगे।

index mydist {  
          type = distributed  
          agent = box1:9312|box5:9312:shard1  
          agent = box2:9312:|box6:9312:shard2  
          agent = box3:9312:|box7:9312:shard3  
          agent = box4:9312:|box8:9312:shard4  
}

Now we added mirrors, each shard is found on 2 servers. अब हमने मिरर जोड़े हैं, प्रत्येक शार्ड 2 सर्वरों पर पाया जाता है। By default, the master (the searchd instance with the distributed index) will pick randomly one of the mirrors. डिफ़ॉल्ट रूप से, मास्टर (वितरित इंडेक्स के साथ searchd उदाहरण) मिररो में से एक को यादृच्छिक रूप से चुनता है।
The mode used for picking mirrors can be set with ha_strategy. मिरर चुनने के लिए उपयोग किया जाने वाला मोड ha_strategy के साथ सेट किया जा सकता है। In addition to random, another simple method is to do a round-robin selection ( ha_strategy= roundrobin). यादृच्छिक के अलावा, एक और सरल विधि राउंड-रोबिन चयन करना है (ha_strategy= roundrobin)।
The more interesting strategies are the latency-weighted probabilities based ones. अधिक रुचिकर रणनीतियाँ देरी-भारित संभावनाओं पर आधारित हैं। noerrors and nodeads not only that take out mirrors with issues, but also monitor the response times and do balancing. noerrors और nodeads न केवल मुद्दों वाले मिरर को हटा देते हैं, बल्कि प्रतिक्रिया समय की निगरानी भी करते हैं और संतुलन करते हैं। If a mirror responds slower (for example due to some operations running on it), it will receive less requests. यदि एक मिरर धीमा उत्तर देता है (उदाहरण के लिए, वहाँ चल रहे कुछ ऑपरेशनों के कारण), इसे कम अनुरोध प्राप्त होंगे। When the mirror recovers and provides better times, it will receive more requests. जब मिरर ठीक हो जाता है और बेहतर समय प्रदान करता है, तो इसे अधिक अनुरोध प्राप्त होंगे।