इस लेख में हम चर्चा करेंगे कि मैन्टिकोर सर्च 3 में किल-लिस्ट कैसे काम कर रही है।

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

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

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

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

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

<img src="killlists-v2-optimized.webp" alt="img"> 2.x में किल-लिस्ट

मैन्टिकोर 3 ने अनुक्रमणिका संग्रहण इंजन में बड़े पैमाने पर अपग्रेड करके एक तोड़ने का परिवर्तन पेश किया। किल-लिस्ट को भी एक परिवर्तन की आवश्यकता थी।

यह दो कारणों से था: किल-लिस्ट का मौजूदा तरीका कुछ किनारे के मामलों में समस्याग्रस्त साबित हुआ और यह नए संग्रहण इंजन के साथ ठीक से मेल नहीं खाता था।

तो हर बार एक प्रश्न किए जाने पर किल-लिस्ट लागू करने के बजाय, क्यों न इसे एक बार किया जाए? v3 में, डेल्टा अनुक्रमणिका के स्रोतों में हम अभी भी किल-लिस्ट के लिए एक स्रोत परिभाषित करते हैं (sql_query_killlist), लेकिन अनुक्रमणिका कॉन्फ़िगरेशन में हमें किल-लिस्ट के लक्ष्य परिभाषित करने की आवश्यकता होती है।

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

<img src="killlists-v3-optimized.webp" alt="img"> किल-लिस्ट लक्ष्य को killlist_target अनुक्रमणिका निर्देश में परिभाषित किया गया है। निर्देश अपेक्षाकृत अनुक्रमणिकाओं की सूची और लागू किल-लिस्ट के एक मोड की अपेक्षा करता है। वर्तमान में 3 मोड समर्थित हैं:

• kl - परिभाषित किल-लिस्ट (sql_query_killlist द्वारा) से दस्तावेज़ आईडी दमन के लिए उपयोग की जाएगी

• id - अनुक्रमणिका से दस्तावेज़ आईडी इसके बजाय उपयोग की जाती हैं (और कोई भी परिभाषित sql_query_killlist को नजरअंदाज किया जाएगा)

• या डिफ़ॉल्ट रूप से यदि आप ‘kl’ या ‘id’ निर्दिष्ट नहीं करते हैं तो अनुक्रमणिका से दस्तावेज़ आईडी और sql_query_killlist दोनों का उपयोग किया जाएगा

उदाहरण

index delta {
  ...
  killlist_target = index_one:kl, index_two:id
  ...

}

लक्षित निर्देश का उपयोग ALTER TABLE कमांड द्वारा बदला जा सकता है, लेकिन इसे लागू करने के लिए, लक्षित अनुक्रमणिकाओं को फिर से लोड करना होगा। इसके अलावा ALTER लक्षित अनुक्रमणिका पर पहले से हटा दिए गए आईडी को ‘अक्षम’ नहीं कर सकता (लक्षित सूची से अनुक्रमणिका को निकालकर)।

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