इस लेख में हम Manticore Search 3.0 में दस्तावेज़ आईडी डेटा प्रकार में बदलाव के बारे में बात कर रहे हैं।

पिछले संस्करणों में दस्तावेज़ आईडी बिना साइन के बड़े पूर्णांक थे। यह 3.0 में बदला गया जब हमने साइन किए गए बड़े पूर्णांक की ओर स्विच किया। इस निर्णय के पीछे का कारण यह था कि दस्तावेज़ आईडी को bigint विशेषताओं के साथ एक समान बनाना था क्योंकि वे साइन किए गए होते हैं, क्योंकि अधिकांश मामलों में साइन किए गए बड़े पूर्णांक पर्याप्त होने चाहिए और anyway हम स्वचालित रूप से जनरेटेड आईडी की ओर बढ़ रहे हैं।

हालांकि, कुछ दुर्लभ मामलों में यह परिवर्तन एक समस्या बन सकता है और इस लेख में हम विस्तार से देखेंगे कि अंतर क्या है और यदि समस्या उत्पन्न होती है तो उसे कैसे हल करें।

बिना साइन के बड़े पूर्णांक 0 और 18,446,744,073,709,551,615 ( 2⁶⁴-1) के बीच के मानों का समर्थन करते हैं, जबकि साइन किए गए बड़े पूर्णांक −9,223,372,036,854,775,808 से 9,223,372,036,854,775,807 ( −2⁶³ से 2⁶³−1) के बीच मान ले सकते हैं। साइन किए गए सकारात्मक सीमा इतनी बड़ी है कि यह बड़े डेटा सेट को समायोजित कर सके (कम से कम कोई ज्ञात Manticore संग्रह 9+ क्वाड्रिलियन दस्तावेजों से अधिक नहीं है)। समस्या तब उत्पन्न होती है जब दस्तावेज़ आईडी एक वृद्धि किए गए मूल्य के रूप में नहीं होती, बल्कि बिना साइन के बड़े पूर्णांक का उपयोग कर एक हैश होती है। उन मामलों के लिए, यदि साइन किए गए प्रकार में समायोजित करने के लिए हैश को स्विच करना संभव नहीं है, तो नीचे बताई गई सरल रूपांतरण का उपयोग करके हैश को संग्रहित और पुनः प्राप्त करने के लिए किया जा सकता है।

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

दोनों डेटा प्रकार का समर्थन क्यों नहीं किया जाए?

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

इस बदलाव से कैसे निपटें?

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

साइन किए गए सकारात्मक सीमा ( 2⁶³ -1) के ऊपर के मानों को नकारात्मक संख्याओं के रूप में बनाया जा सकता है, उन्हें 2⁶⁴ से घटाकर: यह 2⁶³ (साइन की गई सकारात्मक सीमा के ऊपर की पहली संख्या) को -2⁶³ और 2⁶⁴-1 (सबसे बड़ा संभव बिना साइन का बड़ा पूर्णांक) को -1 में परिवर्तित करेगा। यदि आप बिना साइन के बड़े पूर्णांकों को वापस देने वाली हैश फ़ंक्शन के आधार पर आईडी जनरेट कर रहे हैं, तो इसका उपयोग भी किया जा सकता है।

उदाहरण के लिए, MySQL में बिना साइन के बड़े पूर्णांक को एक साइन किए गए बड़े पूर्णांक में फिट करने के लिए हम IF (id>>63, -(~id) - 1,id) का उपयोग कर सकते हैं। “मैप किए गए” साइन किए गए नंबर को बिना साइन में वापस परिवर्तित करने के लिए हम IF(signed_id<0, ~0^~signed_id,signed_id) का उपयोग कर सकते हैं। बिट फ़ंक्शंस का उपयोग करने का कारण यह है कि MySQL केवल 9223372036854775807 (63 बिट्स) से बड़े नंबरों के लिए बिट फ़ंक्शंस का समर्थन करता है।

SELECT id,if (id>>63, -(~id) - 1,id) AS mapped_to_signed,
signed_id, if (signed_id<0, ~0^~signed_id,signed_id)  AS unsigned_from_mapped
FROM test ORDER BY id

यदि आप मजबूत प्रकार की भाषाओं (जैसे .NET) का उपयोग कर रहे हैं, तो आपको कोड की समीक्षा करनी होगी ताकि यह सुनिश्चित हो सके कि यह खोज उत्तरों में दस्तावेज़ आईडी को साइन किए गए और बिना साइन के रूप में अपेक्षित कर रहा है।

हम जानते हैं कि यह परिवर्तन कुछ समस्याएँ पैदा कर सकता है, लेकिन यह एक बार का परिवर्तन है जिसे नवीनतम Manticore Search का आनंद लेने के लिए किया जाना आवश्यक है।