v 3.2.0 से Manticore Search ने एक नई विशेषता पेश की - दस्तावेज़ भंडारण।

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

खोज कार्यप्रवाह को Manticore में पूर्ण-पाठ खोज प्रदर्शन करने के लिए बनाया गया था और परिणाम सेट के आधार पर डेटा के मूल स्रोत (या तो डेटाबेस या फ़ाइलें) में अतिरिक्त रूप से जानकारी प्राप्त करने के लिए जो सामग्री केवल Manticore में अनुक्रमित की गई थी। कुछ मामलों में, अतिरिक्त लुकअप आवश्यक है केवल ‘गायब’ पाठों को पुनः प्राप्त करने के लिए बल्कि अन्य डेटा प्राप्त करने के लिए जो अनुक्रमण में शामिल नहीं है क्योंकि इसे खोज संचालन में उपयोग नहीं किया जाता है और वह डेटा अनुक्रमण आकार को (अनावश्यक रूप से) बढ़ाता रहेगा। लेकिन कई ऐसे मामले हैं जब लुकअप का एकमात्र उद्देश्य ‘गायब’ पाठों को प्राप्त करना है, जिसे एक अतिरिक्त चरण के रूप में देखा जाता है जिसे समाप्त करना अच्छा होगा - क्योंकि इसका मतलब है आवेदन कोड को सरल बनाना, अतिरिक्त लोड, संसाधन खपत से बचना और डेटा भंडारण से विफलता का एक अन्य बिंदु।

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

• एक कंपनी चाहती है कि वह कार्यालय दस्तावेजों में पाठों की खोज कर सके, जैसे कि Word या PDFs - ये आंतरिक उपकरणों या वैज्ञानिक, कानूनी या तकनीकी पत्रों की पेशकश करने वाले पोर्टल का हिस्सा हो सकते हैं।
• डेटा एक वेब सेवा से या क्रॉल की गई पृष्ठों से आ रहा है
• स्ट्रीमिंग डेटा जो लॉग, संदेश या ईमेल हो सकते हैं। इनसे स्रोतों से पढ़ना कठिन हो सकता है क्योंकि कई मामलों में इन्हें वितरित प्रणालियों में संग्रहीत किया गया है और क्वेरी समय पर इन्हें पढ़ना आवेदन कोड को जटिल बना देता है।

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

अब यह संभव है कि मूल पाठों को संग्रहीत करें और उन्हें वापस परिणामों में पुनः प्राप्त करें।

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

इस समय भंडारण के लिए कोई एन्क्रिप्शन नहीं है। संवेदनशील या महत्वपूर्ण डेटा, जैसे उपयोगकर्ता प्रमाणपत्र या पेमेंट लेनदेन, को Manticore में संग्रहीत करने के लिए उपयुक्त नहीं माना जाता। इसके अलावा, पारंपरिक डेटाबेस की कुछ विशेषताएँ, जैसे JOINs, अभी तक समर्थित नहीं हैं। लेकिन हम भविष्य के संस्करणों में इस पर काम करेंगे।

फिर भी, कई ऐसे मामले हैं जहाँ केवल डेटा को संग्रहीत करने या संग्रहीत करने और अतिरिक्त लुकअप नहीं करने के लिए Manticore का उपयोग करना बहुत समझदारी से भरा है।

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

उपयोग

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

index myindex {
   type     = rt
   path     = /path/to/myindex
   rt_field  = title
   rt_field = short_description
   rt_field = long_description
   rt_attr_string = title
   rt_attr_uint   = group_id
   stored_fields  = short_description, long_description
}

बिना संग्रहीत फ़ील्ड के परिणाम इस तरह दिखाई देगा:

mysql> SELECT * FROM myindex WHERE ....\G
*************************** 1. row ***************************
      id: 11
   title: यहाँ एक शीर्षक है
group_id:100
*************************** 2. row ***************************
...

संग्रहीत फ़ील्ड के साथ:

mysql> SELECT * FROM myindex WHERE ....\G
*************************** 1. row ***************************
               id: 11
            title: यहाँ एक शीर्षक है
short_description: एक संक्षिप्त पाठ वर्णन
यहाँ जाता है
 long_description: एक लंबा पाठ विवरण
यहां पाया जा सकता है
         group_id:100
*************************** 2. row ***************************
...

दस्तावेज़ भंडारण के साथ और बिना अनुक्रमण में प्रदर्शन एक शोकेस हमारे पाठ्यक्रम पर docstore में देखा जा सकता है।

उन्नत ट्यूनिंग

पाठ डिस्क पर एक अलग फ़ाइल में संग्रहीत होते हैं। डिफ़ॉल्ट रूप से, इन्हें lz4 एल्गोरिदम का उपयोग करके संकुचित किया जाता है। एक वैकल्पिक lz4hc एल्गोरिदम उपलब्ध है या संकुचन को ’none’ सेट करके अक्षम किया जा सकता है ‘docstore_compression’ अनुक्रम निर्देश द्वारा। ’lz4hc’ एल्गोरिदम के लिए, संकुचन स्तर को docstore_compression_level अनुक्रम निर्देश के साथ ट्यून किया जा सकता है जो 1 से 12 (डिफ़ॉल्ट 9) के बीच मान ले सकता है। पाठों को डिस्क पर ब्लॉकों के रूप में संकुचित किया जाता है। ब्लॉक आकार को docstore_block_size निर्देश के साथ ट्यून किया जा सकता है। डिफ़ॉल्ट मान 16k है। ब्लॉक आकार बढ़ाने से संकुचन अनुपात में सुधार होगा और अधिक डिस्क स्थान बचाएगा जबकि ब्लॉक आकार को कम करने से पहुँच गति में सुधार होना चाहिए।

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

स्ट्रिंग गुणों से भिन्नताएँ

Manticore Search पहले से ही एक data type प्रस्तुत करता है जो परिणाम सेट टेक्स्ट को संग्रहीत और पुनर्प्राप्त करने में सक्षम है और इसे तुलना,regex फ़िल्टरिंग,排序 और समेकन संचालन के लिए भी इस्तेमाल किया जा सकता है। यहां तक कि, वास्तविक समय के अनुक्रमण के मामले में पूर्ण-टेक्स्ट फ़ील्ड और स्ट्रिंग विशेषता के लिए एक ही नाम का उपयोग करना संभव है। संग्रहीत फ़ील्ड के उद्देश्यों के बारे में एक प्रश्न है।

स्ट्रिंग विशेषताएँ Manticore Search 3 अनुक्रमण के बब्ल घटक में संग्रहीत होती हैं, जो JSON और MVA विशेषताओं को भी रखती है। बब्ल घटक से पढ़ाई mmap() के साथ प्रबंधित की जाती है और इसे डिस्क पर छोड़कर आवश्यकतानुसार पढ़ा जा सकता है, अनुक्रमण लोड के समय पूरी तरह से पढ़ा और लोड किया जा सकता है या पढ़ा, लोड किया और मेमोरी में लॉक किया जा सकता है। स्ट्रिंग विशेषताओं में टेक्स्ट बिना संकुचित के रूप में संग्रहीत होते हैं। यदि इस तरीके से संग्रहीत टेक्स्ट लंबे हैं (जैसे विवरण, लेख की सामग्री) तो वे अंततः बहुत अधिक डिस्क स्थान का उपयोग कर सकते हैं और वे दस्तावेज़ के बब्ल घटक द्वारा उपयोग की जाने वाली मेमोरी को भी बढ़ा देंगे। एक अनुक्रमण जो पहले पूरी तरह से RAM में नहीं फिट हो रहा था, उसमें स्ट्रिंग विशेषताओं के रूप में लंबे टेक्स्ट जोड़ने का मतलब है कम परिवर्तनीय लंबाई की विशेषताएँ (स्ट्रिंग, JSON, MVA) जो RAM में कैश हो सकती हैं, जिससे कम इच्छित प्रदर्शन होता है। बब्ल घटक को मेमोरी में लॉक करना (access_blob_attrs=mlock) बढ़ी हुई आकार के कारण संभव नहीं हो सकता। स्ट्रिंग विशेषताओं का उपयोग उन छोटे टेक्स्ट के लिए किया जाना चाहिए जिन पर गैर-पूर्ण-टेक्स्ट फ़िल्टरिंग, समूहबद्ध और排序 संचालन करने की उम्मीद की जाती है, केवल पुनर्प्राप्ति के अलावा।

दूसरी ओर, संग्रहीत फ़ील्ड एक अलग घटक हैं। टेक्स्ट केवल डिस्क से पढ़े जाते हैं और यदि RAM उपलब्ध है तो docstore_cache_size को RAM में संग्रहीत फ़ील्ड को कैश करने के लिए उच्च मान (GBs) पर सेट किया जा सकता है। इसके अलावा, बाय डिफ़ॉल्ट संग्रहीत फ़ील्ड संकुचित होते हैं, जो स्ट्रिंग विशेषताओं की तुलना में संग्रहण पर कम स्थान लेते हैं। कुछ मामलों में ऐसे भी हैं जहाँ टेक्स्ट अनुक्रमण में संग्रहीत होने की आवश्यकता है और उनका उपयोग केवल आउटपुट पर होता है और कभी भी फ़िल्टरिंग/क्लस्टरिंग/सॉर्टिंग के लिए नहीं किया जाता। संसाधन प्रबंधन की दृष्टि से, उन्हें बब्ल में रखना अनुकूल नहीं है। ऐसे स्ट्रिंग्स के उदाहरण उत्पाद कोड या UUID हो सकते हैं (जो अद्वितीय होने चाहिए और उनके ऊपर सॉर्टिंग करना ज्यादा मायने नहीं रखता)। उन्हें संग्रहीत फ़ील्ड में स्थानांतरित करना बब्ल को छोटा करेगा, जिसका अर्थ है कि कम RAM का उपयोग किया जाएगा, स्टार्टअप पर तेजी से लोड हो रहा होगा और, स्थिति के आधार पर, mlocking की अनुमति देगा। यहां एक ‘समस्या’ जो उठ सकती है वह यह है कि नए फ़ील्ड पूर्ण-टेक्स्ट मेलों में भूमिका निभा सकते हैं जो विशिष्ट फ़ील्ड में खोज नहीं करते हैं, इसलिए उन्हें खोज से बाहर रखने के लिए ignore field search operator का उपयोग करना एक अच्छा विचार हो सकता है।