परिचय

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

डिफ़ॉल्ट एट्रिब्यूट संग्रह (पंक्ति-आधारित)

Manticore में, दो अलग-अलग entities हैं: पूर्ण-टेक्स्ट फ़ील्ड, जो केवल पूर्ण-टेक्स्ट क्वेरी का समर्थन करते हैं, और विभिन्न प्रकार के एट्रिब्यूट्स, जो समूहबद्ध करने, сорт करने और फ़िल्टर करने के लिए उपयोग किए जा सकते हैं। डिफ़ॉल्ट स्टोरेज इंजन (engine='rowwise') सभी दस्तावेज़ों के सभी एट्रिब्यूट्स को मेमोरी में संग्रहीत करता है।

एट्रिब्यूट्स को मेमोरी में लोड करने के लिए, mmap का उपयोग किया जाता है, जिसे विकल्पों access_plain_attrs और access_blob_attrs के माध्यम से कॉन्फ़िगर किया जा सकता है। पहला विकल्प .spa फ़ाइलों को लोड करने के लिए जिम्मेदार है, जो सभी निश्चित-लंबाई एट्रिब्यूट्स (integer, bigint, float, आदि) को शामिल करती हैं। दूसरा विकल्प .spb फ़ाइलों को लोड करने के लिए है, जो परिवर्तनशील-लंबाई एट्रिब्यूट्स (string, mva, float_vector, आदि) को शामिल करती हैं। चूंकि mmap केवल तब डेटा को मेमोरी में लोड करता है जब इसे एक्सेस किया जाता है, इसलिए एट्रिब्यूट्स का उपयोग करते समय प्रारंभिक क्वेरी धीमी हो सकती हैं। इस समस्या को दूर करने के लिए, ‘access_plain_attrs’ और ‘access_blob_attrs’ का डिफ़ॉल्ट रूप से ‘mmap_preread’ मोड पर सेट किया जाता है, जिसमें Manticore स्टार्टअप पर बैकग्राउंड थ्रेड द्वारा .spa और .spb फ़ाइलों को पढ़ता है। इसका अर्थ आमतौर पर (लेकिन इसकी गारंटी नहीं) यह है कि एट्रिब्यूट फ़ाइलें मेमोरी में होंगी, जिससे क्वेरी के दौरान डिस्क से डेटा पढ़ने की आवश्यकता खत्म हो जाती है। हालांकि, यदि सिस्टम निर्धारित करता है कि मेमोरी अपर्याप्त है, तो एट्रिब्यूट्स को मेमोरी से आंशिक या पूर्ण रूप से अनलोड किया जा सकता है, जिससे क्वेरी फिर से धीमी हो जाएगी। इससे बचने के लिए, ‘mlock’ को access_plain_attrs / access_blob_attrs में निर्दिष्ट किया जा सकता है। यदि मेमोरी पर्याप्त है, तो एट्रिब्यूट्स को मेमोरी में रहने की गारंटी दी जाएगी, और सिस्टम उन्हें अनलोड नहीं करेगा। हालाँकि, यदि मेमोरी अपर्याप्त है, तो कोई गारंटी नहीं है।

हमें कॉलमरी स्टोरेज की आवश्यकता क्यों है?

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

.spa फ़ाइल की संरचना इस प्रकार है:

.spb फ़ाइल इस प्रकार दिखती है:

जब एक क्वेरी किसी विशेष एट्रिब्यूट द्वारा समूहबद्ध करने को शामिल करती है, तो उस एट्रिब्यूट के लिए प्रत्येक दस्तावेज़ का मान केवल पुनर्प्राप्त करना होता है। हालाँकि, mmap ऐसे काम करता है कि यह व्यक्तिगत बाइट्स को नहीं पढ़ सकता; इसके बजाय, यह एक या एक से अधिक मेमोरी पृष्ठों को लोड करता है, प्रत्येक सामान्यतः 4 KB आकार का होता है। इसका अर्थ है कि जब एक एट्रिब्यूट का मान पढ़ने का प्रयास किया जाता है, तो सिस्टम अक्सर सभी आस-पास के एट्रिब्यूट्स के मान लोड करता है, भले ही वे क्वेरी प्रोसेसिंग के लिए आवश्यक न हों।

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

कॉलमरी स्टोरेज (engine='columnar') विशेष रूप से उन स्थितियों के लिए विकसित किया गया था जहां सभी एट्रिब्यूट्स को लोड करने के लिए पर्याप्त मेमोरी नहीं है। यह भंडारण प्रारूप निम्नलिखित लाभ प्रदान करता है:

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

सांकेतिक रूप से, कॉलमरी स्टोरेज में डेटा संरचना को निम्नलिखित रूप में प्रस्तुत किया जा सकता है:

कॉलमरी स्टोरेज को MCL (Manticore Columnar Library) नामक एक अलग पुस्तकालय में वितरित किया जाता है। यह पुस्तकालय संग्रह बनाने, डेटा पैकेजिंग और पढ़ने के लिए जिम्मेदार है।
इसके अतिरिक्त, एट्रिब्यूट्स के साथ कार्य करने के लिए खोज डेमन में काफी संख्या में कोड जोड़ा गया, कॉलमरी स्टोरेज की विशिष्टताओं पर विचार करते हुए।

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

यहाँ कुछ उदाहरण दिए गए हैं कि कॉलमरी स्टोरेज के साथ काम करने के लिए डेमन में क्या जोड़ा गया:

• कॉलमरी सॉर्टर
  Manticore की आर्किटेक्चर में, पूर्ण-टेक्स्ट खोज के माध्यम से पाए गए दस्तावेज़ तुरंत उन चीज़ों के पास भेजे जाते हैं जिसे सॉर्टर कहा जाता है। सॉर्टर या तो सरलता से сорт कर सकता है, या यह दस्तावेज़ों को समूहबद्ध कर सकता है, एग्रीगेट्स की गणना कर सकता है, और बहुत कुछ। हालाँकि, कॉलमरी स्टोरेज में एट्रिब्यूट्स तक पहुँच धीमी है क्योंकि मान एक-एक करके पुनर्प्राप्त किए जाते हैं।
  यदि एक क्वेरी अपेक्षाकृत हल्की है - जिसका अर्थ है कि पूर्ण-पाठ खोज तेजी से होती है या बिल्कुल भी उपस्थित नहीं होती - तो एक समय में संग्रहण से गुणधर्मों को निकालना प्रदर्शन पर महत्वपूर्ण प्रभाव डाल सकता है। इसलिए, कुछ मामलों में, मानक Sorter के ऊपर एक अतिरिक्तSorter का उपयोग करना फायदेमंद होता है। यह अतिरिक्त Sorter क्रमबद्ध नहीं करता है बल्कि दस्तावेज़ों को संचित करता है और कॉलमयुक्त गुणधर्मों को एक साथ प्राप्त करता है, इससे पहले कि दस्तावेज़ों को अंतिम प्रसंस्करण के लिए मुख्य Sorter को पास किया जाए, जो कि काफी तेज होता है।

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

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

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

MCL में क्या शामिल है?

MCL पुस्तकालय के सीधे भाग के रूप में, दो मुख्य समूहों को विशेष रूप से पहचाना जा सकता है:

1. बिल्डर
   डेमन से कच्चे डेटा को प्राप्त करने और कॉलमयुक्त संग्रहण का निर्माण करने के लिए जिम्मेदार।

2. एक्सेसर्स
   डेटा पहुंच के लिए जिम्मेदार। दो मुख्य प्रकार हैं:

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

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

निष्कर्ष

इस लेख में, हमने Manticore कॉलमयुक्त संग्रहण के सिद्धांतों और इसके Manticore खोज डेमन में एकीकरण के कुछ विवरणों को व्यापक रूप से कवर किया है।