लंबे समय से मांगी गई सुविधाओं में से एक अब नवीनतम कोड में उपलब्ध है: परकोलेट क्वेरीज़।

यदि आप एक इंटरैक्टिव कोर्स के माध्यम से जाना चाहते हैं, तो यहाँ जाएं।

परकोलेट क्वेरीज़ को पर्सिस्टेंट क्वेरीज़, प्रोस्पेक्टिव सर्च, डॉक्यूमेंट राउटिंग, रिवर्स सर्च या इनवर्स सर्च के रूप में भी जाना जाता है।

खोज करने का सामान्य तरीका है उन दस्तावेजों को स्टोर करना जिन्हें हम खोजना चाहते हैं और उनके खिलाफ क्वेरी करना। हालांकि कुछ मामले हैं जब हम एक नए आने वाले दस्तावेज़ पर क्वेरी लागू करना चाहते हैं ताकि मैचिंग का संकेत मिल सके। कुछ परिदृश्य हैं जहां यह वांछित है। उदाहरण के लिए एक मॉनिटरिंग सिस्टम केवल डेटा एकत्र नहीं करता है, बल्कि विभिन्न घटनाओं पर उपयोगकर्ता को सूचित करना भी वांछित होता है। वह किसी मीट्रिक के लिए कुछ थ्रेशोल्ड तक पहुंचना या मॉनिटर किए गए डेटा में दिखाई देने वाला कोई निश्चित मूल्य हो सकता है। एक और समान मामला न्यूज़ एग्रीगेशन है। आप उपयोगकर्ता को किसी भी ताज़ा समाचार के बारे में सूचित कर सकते हैं, लेकिन उपयोगकर्ता केवल कुछ श्रेणियों या विषयों के लिए सूचित होना चाह सकता है। आगे बढ़ते हुए, वे केवल कुछ “कीवर्ड्स” में रुचि रख सकते हैं।

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

एक वर्कअराउंड संभव था रीयल-टाइम इंडेक्स का उपयोग करके जिसमें केवल नए दस्तावेज़ जोड़े गए थे, क्वेरीज़ का परीक्षण किया गया और RT को ट्रंकेट कर दिया गया। लेकिन यह दूर तक एक समाधान नहीं था। अंत में, हम इस कार्यक्षमता को Manticore Search में जोड़ रहे हैं (और इस प्रकार Sphinx Search से अपग्रेड करने वाले किसी भी व्यक्ति के लिए)।

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

क्वेरीज़ का मिलान एक नए स्टेटमेंट के साथ किया जाता है जो इनपुट पर एक दस्तावेज़ या दस्तावेज़ों की सूची लेता है और बताता है कि कौन सी क्वेरीज़ का मिलान हुआ।

कृपया ध्यान दें कि ‘percolate’ इंडेक्स एक मौजूदा इंडेक्स का विकल्प नहीं है, यह दस्तावेज़ों को स्टोर नहीं करता है। एक सामान्य उपयोग के मामले में, दस्तावेज़ अब तक की तरह एक इंडेक्स में डाले जाते हैं। परकोलेट क्वेरीज़ या तो इंसर्ट किए जाने के बाद निष्पादित की जा सकती हैं, उसी वर्कर द्वारा या किसी अन्य वर्कर द्वारा जो इंसर्ट वर्कर से स्वतंत्र रूप से काम करता है (जिसे क्रॉन जॉब द्वारा निष्पादित किया जा सकता है या इंसर्ट द्वारा ट्रिगर किया जा सकता है)। बाद वाला तरीका बेहतर होगा ताकि PQ इंसर्ट की पुष्टि (एंड यूजर को) में देरी न करें, लेकिन यह एप्लिकेशन के वर्कफ्लो पर निर्भर करता है।

परकोलेट क्वेरीज़ को स्टोर करना

जैसा कि ऊपर बताया गया है, परकोलेट क्वेरीज़ को एक विशेष रीयल-टाइम इंडेक्स में स्टोर किया जाता है जिसे percolate प्रकार के रूप में परिभाषित किया गया है।

एक साधारण PQ इंडेक्स के लिए केवल प्रकार और पथ को परिभाषित करने की आवश्यकता है:

index pq {
    type = percolate
    path = /var/lib/sphinxsearch/pq
}

इसे उपलब्ध कराने के लिए, बस RELOAD INDEXES कमांड जारी करें:

MySQL [(none)]> RELOAD INDEXES; SHOW TABLES LIKE 'pq';
Query OK, 0 rows affected (0.00 sec)

+-------+-----------+
| Index | Type      |
+-------+-----------+
| pq    | percolate |
+-------+-----------+
1 row in set (0.00 sec)

दस्तावेज़ आईडी ऑटो इंक्रीमेंटेशन का समर्थन करती है, इंसर्ट करते समय, आपको सामान्य RT इंडेक्स की तरह आईडी जनरेट करने की आवश्यकता नहीं है। एक नई क्वेरी को इंसर्ट करने के लिए एक अनिवार्य ‘query’ टेक्स्ट फील्ड की आवश्यकता होती है, जिसमें फुल-टेक्स्ट सर्च एक्सप्रेशन होता है।

MySQL [(none)]> INSERT INTO pq(query) VALUES('catch me');
Query OK, 1 rows affected (0.00 sec)

MySQL [(none)]> SELECT * FROM pq;
+------+----------+------+---------+
| UID  | Query    | Tags | Filters |
+------+----------+------+---------+
|    1 | catch me |      |         |
+------+----------+------+---------+
1 row in set (0.00 sec)

विशेष उपयोग के साथ 2 वैकल्पिक विशेषताएं हैं।

पहली ’tags’ है, जो स्ट्रिंग्स के बैग का समर्थन करती है (स्ट्रिंग MVA के बारे में सोचें)। टैग का उपयोग SELECT या DELETE करते समय PQ को फ़िल्टर करने के लिए किया जा सकता है, परकोलेट खोज करते समय उनकी कोई भूमिका नहीं होती है।

MySQL [(none)]> insert into pq(query,tags) values('catch me if','tag1');
Query OK, 1 rows affected (0.00 sec)

MySQL [(none)]> SELECT * FROM pq WHEREtags='tag1';
+------+-------------+------+---------+
| UID  | Query       | Tags | Filters |
+------+-------------+------+---------+
|    2 | catch me if | tag1 |         |
+------+-------------+------+---------+
2 rows in set (0.00 sec)

दूसरी ‘filters’ में अतिरिक्त क्वेरी नियम हैं जिनमें आप SphinxQL प्रारूप में विशेषता फ़िल्टरिंग स्टोर कर सकते हैं। यहां उपयोग की जाने वाली विशेषताओं को RT इंडेक्स में विशेषताओं की तरह इंडेक्स कॉन्फ़िगरेशन में घोषित किया जाना चाहिए। एक नई विशेषता को सक्षम करने के लिए हम बस ALTER RTINDEX RECONFIGURE का उपयोग कर सकते हैं।

index pq {
    type = percolate
     path = /var/lib/sphinxsearch/pq
     rt_attr_uint = catId
}

MySQL [(none)]> ALTER RTINDEX pq RECONFIGURE;
Query OK, 0 rows affected (0.00 sec)

MySQL [(none)]> INSERT INTO pq(query,tags,filters) VALUES('catch me','tag2,tag1','catId=10');
Query OK, 1 rows affected (0.00 sec)

MySQL [(none)]> select * from pq;
+------+-------------+-----------+-----------+
| UID  | Query       | Tags      | Filters   |
+------+-------------+-----------+-----------+
|    3 | catch me    |           |           |
|    4 | catch me if | tag1      |           |
|    5 | catch me    | tag2,tag1 |  catid=10 |
+------+-------------+-----------+-----------+
3 rows in set (0.00 sec)

यदि हम प्रति फील्ड टेक्स्ट खोज को सक्षम करना चाहते हैं, तो हमें इंडेक्स कॉन्फ़िगरेशन में फुल-टेक्स्ट फील्ड को परिभाषित करने और रीकॉन्फ़िगर जारी करने की आवश्यकता है।

index pq {
    type = percolate
    path = /var/lib/sphinxsearch/pq
    rt_field = subject
    rt_field = content
    rt_attr_uint = catId
}

MySQL [(none)]>  ALTER RTINDEX pq RECONFIGURE;
Query OK, 0 rows affected (0.00 sec)

MySQL [(none)]> INSERT INTO pq(query,tags,filters) VALUES('@subject match by field','tag2,tag3','catId=10');
Query OK, 1 rows affected (0.00 sec)

MySQL [(none)]> INSERT INTO pq(query,tags,filters) VALUES('@subject  match by field','tag2,tag3','catId=20');
Query OK, 1 rows affected (0.00 sec)

परकोलेट क्वेरीज़ का प्रदर्शन

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

डिफ़ॉल्ट रूप से, CALL PQ JSON प्रारूप में दस्तावेज़ों की अपेक्षा करता है, इसलिए यदि हम सबसे बुनियादी उदाहरण प्रदर्शित करना चाहते हैं, तो हमें 0 as docs_json पास करने की आवश्यकता है। इसके अलावा डिफॉल्ट परिणाम सेट में केवल क्वेरी आईडी शामिल होती है, लेकिन हम स्टोर की गई सभी जानकारी दिखाने के लिए query विकल्प का उपयोग कर सकते हैं

MySQL [(none)]> CALL PQ('pq','catch me',0 AS docs_json,1 AS query);
+------+----------+------+---------+
| UID  | Query    | Tags | Filters |
+------+----------+------+---------+
|    6 | catch me |      |         |
+------+----------+------+---------+
1 row in set (0.00 sec)

प्रति फील्ड मैचिंग या अतिरिक्त विशेषता फिल्टरिंग करने के लिए हमें दस्तावेजों को json ऑब्जेक्ट के रूप में पास करने की आवश्यकता है।

MySQL [(none)]> CALL PQ('pq','{"subject":"expect to match by field","content":"here is some content","catid":20}',1 AS query);
+------+--------------------------+-----------+-----------+
| UID  | Query                    | Tags      | Filters   |
+------+--------------------------+-----------+-----------+
|   10 | @subject  match by field | tag2,tag3 |  catid=20 |
+------+--------------------------+-----------+-----------+
1 row in set (0.00 sec)

CALL PQ के 2 और रनटाइम विकल्प हैं: ‘docs’ विकल्प तब उपयोगी होता है जब आपके पास इनपुट में एक से अधिक दस्तावेज़ हों, क्योंकि यह आपको बताएगा कि किस दस्तावेज़ ने खोज से मेल खाया (इंडेक्स 1 से शुरू)।

MySQL [(none)]> CALL PQ('pq',('catch me if can','catch me'),0 AS docs_json,1 AS docs,1 AS verbose);
+------+-----------+-------------+------+---------+
| UID  | Documents | Query       | Tags | Filters |
+------+-----------+-------------+------+---------+
|    6 | 1,2       | catch me    |      |         |
|    7 | 1         | catch me if | tag1 |         |
+------+-----------+-------------+------+---------+
2 rows in set (0.00 sec)

CALL PQ चलाते समय, SHOW META निष्पादित फंक्शन के बारे में जानकारी प्रदान करता है, जैसे निष्पादन समय, क्वेरी और दस्तावेज़ मिलान की संख्या, स्टोर की गई कुल क्वेरी।
जब CALL PQ में ‘verbose’ सेट किया जाता है, तो कुछ अतिरिक्त जानकारी प्रदर्शित की जाती है जैसे प्रत्येक क्वेरी में खर्च किया गया समय।

MySQL [(none)]> SHOW META;
+-------------------------+-----------+
| Name                    | Value     |
+-------------------------+-----------+
| Total                   | 0.000 sec |
| Setup                   | 0.000 sec |
| Queries matched         | 2         |
| Document matches        | 2         |
| Total queries stored    | 6         |
| Term only queries       | 6         |
| Fast rejected queries   | 3         |
| Time per query          | 32, 21    |
| Time of matched queries | 53        |
+-------------------------+-----------+
9 rows in set (0.00 sec)

प्रतिक्रिया

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