Manticore Search: Sphinx से फोर्क करने के 3 साल बाद

प्रकाशित: Mar 15, 2021
स्वत: अनुवाद: Manticore Search: 3 years after forking from Sphinx

मई 2017 में हमने Sphinxsearch 2.3.2 का एक फोर्क बनाया, जिसे हमने Manticore Search कहा। नीचे आपको Manticore Search पर एक संक्षिप्त रिपोर्ट मिलेगी जो Sphinx का एक फोर्क है और तब से हमारी उपलब्धियों का विवरण है।

हमने Sphinx को क्यों फोर्क किया?

सबसे पहले, हमने फोर्क क्यों किया? 2016 के अंत में, Sphinxsearch पर कार्य निलंबित हो गया था। उपयोगकर्ता जो Sphinx का उपयोग कर रहे थे और कुछ ग्राहक जिन्होंने परियोजना के विकास का समर्थन किया था, वे इस बारे में चिंतित थे क्योंकि:

बग लंबे समय से ठीक नहीं किए जा रहे थे
नए फीचर्स जो लंबे समय से वादा किए गए थे, वे नहीं बनाए गए थे
Sphinx टीम के साथ संवाद टूटा हुआ था

कई महीनों के बाद स्थिति में कोई बदलाव नहीं आया और जून 2017 के मध्य में, सक्रिय और अनुभवी Sphinx उपयोगकर्ताओं और समर्थन ग्राहकों का एक समूह एकत्र हुआ और Manticore Search नाम के तहत उत्पाद को एक फोर्क के रूप में बनाए रखने की कोशिश करने का निर्णय लिया। हमने पहले की Sphinx टीम के अधिकांश सदस्यों को फिर से इकट्ठा करने में सफलता पाई जो पहले से ही विभिन्न कंपनियों में काम कर रहे थे, निवेश आकर्षित किया और एक छोटी अवधि में परियोजना पर पूरी तरह से काम फिर से शुरू कर दिया।

हमारे उद्देश्य क्या थे?

फोर्क के तीन लक्ष्य थे:

सामान्य कोड समर्थन: बगफिक्सिंग, छोटे और बड़े नए फीचर्स
Sphinx और Manticore उपयोगकर्ताओं का समर्थन
उत्पाद का पहले से अधिक सक्रिय विकास। दुर्भाग्यवश, तब तक Elasticsearch ने कई दृष्टिकोणों में Sphinx को पीछे छोड़ दिया था।

ऐसी चीजें जैसे:

कोई प्रतिकृति नहीं
कोई ऑटो आईडी नहीं
कोई JSON इंटरफेस नहीं
ऑन-द-फ्लाई एक इंडेक्स बनाने/हटाने का कोई तरीका नहीं
कोई दस्तावेज़ संग्रहण नहीं
अपरिपक्व रीयल-टाइम इंडेक्स
सामान्य खोज की तुलना में पूर्ण-टेक्स्ट खोज पर ध्यान केंद्रित करना

ने Sphinx को एक बहुत ही विशिष्ट समाधान बना दिया था जिसमें कई मामलों में इसे मैन्युअल रूप से ट्वीक करने की आवश्यकता होती थी। तब तक कई उपयोगकर्ता पहले ही Elasticsearch में माइग्रेट कर चुके थे। यह शर्म की बात थी, क्योंकि Sphinx में मौलिक डेटा संरचनाएँ और एल्गोरिदम प्रदर्शन में कई मामलों में Elasticsearch से संभावित रूप से और वास्तव में उत्कृष्ट थे। और SQL, जो कि Elasticsearch के मुकाबले Sphinx में बहुत बेहतर विकसित हुआ था, कई लोगों के लिए आकर्षक था।

मौजूदा Sphinx उपयोगकर्ताओं का समर्थन करने के अलावा, Manticore का वैश्विक लक्ष्य उपरोक्त और अन्य सुविधाओं को लागू करना था जो Manticore Search को अधिकांश उपयोग मामलों में Elasticsearch का एक वास्तविक विकल्प बना सके।

हम पहले ही क्या कर चुके हैं

बहुत अधिक सक्रिय विकास

अगर आप github कमिट स्टेट्स को देखें, तो आप देख सकते हैं कि जैसे ही फोर्क हुआ (मध्य-2017) विकास की गति बहुत बढ़ गई:

मार्च 2021 तक तीन साल से कुछ अधिक में, हमने 39 नए संस्करण जारी किए हैं। 2020 में, हम हर दो महीने में एक नया संस्करण जारी कर रहे थे।

प्रतिकृति

कई उपयोगकर्ता Sphinx में वर्षों से प्रतिकृति की प्रतीक्षा कर रहे थे। Manticore में हमने बनाए गए पहले बड़े फीचर्स में से एक प्रतिकृति थी। Manticore में सब कुछ की तरह, हमने इसे उपयोग में जितना संभव हो आसान बनाने की कोशिश की। उदाहरण के लिए, किसी क्लस्टर से कनेक्ट करने के लिए, आपको केवल इस तरह का एक कमांड चलाना होगा:

JOIN CLUSTER posts at 'neighbour-server';

जिससे क्लस्टर के इंडेक्स वर्तमान नोड पर दिखाई देने लगेंगे।

Manticore की प्रतिकृति है:

समकालिक
Galera पुस्तकालय पर आधारित है, जो MariaDB और Percona XtraDB में भी उपयोग किया जाता है।

ऑटो आईडी

बिना ऑटो-आईडी , Sphinx / Manticore को आमतौर पर किसी अन्य डेटाबेस (mysql, postgres आदि) का एक एक्सटेंशन माना जाता था क्योंकि कुछ ऐसा होना चाहिए जो IDs उत्पन्न करे। हमने UUID_SHORT एल्गोरिदम पर आधारित ऑटो-आईडी लागू किया। अद्वितीयता प्रति सर्वर 16 मिलियन परिवर्धनों के लिए सुनिश्चित की जाती है जो सभी मामलों में पर्याप्त होना चाहिए।

mysql> create table idx(doc text);
Query OK, 0 rows affected (0.01 sec)

mysql> insert into idx(doc) values('abc def');
Query OK, 1 row affected (0.00 sec)

mysql> select * from idx;
+---------------------+---------+
| id                  | doc     |
+---------------------+---------+
| 1514145039905718278 | abc def |
+---------------------+---------+
1 row in set (0.00 sec)

mysql> insert into idx(doc) values('def ghi');
Query OK, 1 row affected (0.00 sec)

mysql> select * from idx;
+---------------------+---------+
| id                  | doc     |
+---------------------+---------+
| 1514145039905718278 | abc def |
| 1514145039905718279 | def ghi |
+---------------------+---------+
2 rows in set (0.00 sec)

दस्तावेज़ संग्रहण

Sphinx 2.3.2 और इससे पहले, आप केवल मूल दस्तावेज़ों के पाठ को स्ट्रिंग एट्रिब्यूट में सहेज सकते थे, जो (जैसे सभी एट्रिब्यूट) इष्टतम प्रदर्शन के लिए मेमोरी में संग्रहीत होते हैं। कई उपयोगकर्ताओं ने ऐसा किया, अनावश्यक रूप से RAM बर्बाद करते हुए, जो महंगा था और बड़े वॉल्यूम पर अप्रत्याशित प्रदर्शन समस्याओं का कारण बन सकता था। Manticore में हमने एक नई डेटा प्रकार <code>text</code> बनाई है जो पूर्ण-टेक्स्ट अनुक्रमण और डिस्क पर मान को संग्रहीत करने के साथ लेज़ी रीडिंग को जोड़ती है (अर्थात, मान को क्वेरी के अंतिम चरण में ही लाया जाता है)। “स्टोर्ड” फ़ील्ड मान फ़िल्टर योग्य नहीं होते हैं और न ही उन्हें क्रमबद्ध या समूहित किया जा सकता है। वे केवल डिस्क पर संकुचित स्थिति में रहते हैं, इसलिए उन्हें mysql/hbase/postgres और अन्य डेटाबेस में संग्रहीत करने की आवश्यकता नहीं होती (जब तक कि उन्हें वास्तव में वहां जरूरत न हो)। यह एक बहुत ही उपयोगी और सामान्य रूप से उपयोग की जाने वाली सुविधा साबित हुई है। तब से Manticore को किसी भी खोज एप्लिकेशन को लागू करने के लिए केवल अपने आप की आवश्यकता होती है।

रीयल-टाइम इंडेक्स

Sphinx 2.3.2 और इससे पहले, कई उपयोगकर्ताओं को रीयल-टाइम इंडेक्स का उपयोग करते समय संघर्ष करना पड़ा, क्योंकि यह अक्सर क्रैश और अन्य दुष्प्रभावों का कारण बनता था। हमने अधिकांश ज्ञात बग और डिजाइन खामियों को ठीक किया है, और हम अभी भी कुछ अनुकूलन (मुख्य रूप से, स्वचालित OPTIMIZE और पढ़ने/लिखने/मर्ज अलगाव से संबंधित) पर काम कर रहे हैं। लेकिन यह पहले से ही कहना सुरक्षित है कि रीयल-टाइम इंडेक्स का उत्पादन में उपयोग किया जा सकता है, जो वास्तव में कई उपयोगकर्ता करते हैं। हमने जो फीचर्स जोड़े हैं उनमें से कुछ का उल्लेख करना:

मल्टीथ्रेडिंग: एकल वास्तविक समय अनुक्रमणिका के कई डिस्क भागों में खोज समानांतर में की जाती है
ऑप्टिमाइज़ सुधार: डिफ़ॉल्ट रूप से भागों को 1 में नहीं, बल्कि सर्वर पर कोर की संख्या * 2 (यह कटऑफ़ विकल्प के माध्यम से समायोजित किया जा सकता है) में विलय किया जाता है।

हम स्वचालित ऑप्टिमाइज़ेशन पर काम कर रहे हैं, ताकि उपयोगकर्ताओं को संकुचन के बारे में बिल्कुल चिंता न हो।

charset_table = cjk, non_cjk

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

mysql> create table idx(doc text);
Query OK, 0 rows affected (0.01 sec)

mysql> insert into idx(doc) values('abc абв öğrenim');
Query OK, 1 row affected (0.00 sec)

mysql> select * from idx where match('abc');
+---------------------+----------------------+
| id                  | doc                  |
+---------------------+----------------------+
| 1514145039905718280 | abc абв öğrenim      |
+---------------------+----------------------+
1 row in set (0.00 sec)

mysql> select * from idx where match('абв');
+---------------------+----------------------+
| id                  | doc                  |
+---------------------+----------------------+
| 1514145039905718280 | abc абв öğrenim      |
+---------------------+----------------------+
1 row in set (0.00 sec)

mysql> select * from idx where match('ogrenim');
+---------------------+----------------------+
| id                  | doc                  |
+---------------------+----------------------+
| 1514145039905718280 | abc абв öğrenim      |
+---------------------+----------------------+
1 row in set (0.00 sec)

आधिकारिक डॉकर छवि

हमने Manticore Search के लिए आधिकारिक डॉकर छवि जारी की है और गतिविधि में रखी है। आप अब कहीं भी मैन्टिकोर को केवल कुछ सेकंड में चला सकते हैं जब तक कि वहां डॉकर उपलब्ध है।

➜  ~ docker run --name manticore --rm -d manticoresearch/manticore && docker exec -it manticore mysql && docker stop manticore

525aa92aa0bcef3e6f745ddeb11fc95040858d19cde4c9118b47f0f414324a79
mysql> create table idx(f text);
mysql> desc idx;
+-------+--------+----------------+
| Field | Type   | Properties     |
+-------+--------+----------------+
| id    | bigint |                |
| f     | text   | indexed stored |
+-------+--------+----------------+

इसके अलावा, manticore:dev टैग हमेशा Manticore Search के नवीनतम विकास संस्करण को दर्शाता है।

पैकेज रिपॉजिटरी

सभी नए रिलीज़ और ताजगी विकास संस्करण यहां पाए जा सकते हैं।

वहां से आप YUM और APT के माध्यम से Manticore को आसानी से इंस्टॉल कर सकते हैं। हम Homebrew का भी समर्थन करते हैं और विंडोज़ के लिए बिल्ड बनाए रखते हैं।

एनएलपी: नैचुरल लैंग्वेज प्रोसेसिंग

एनएलपी पक्ष में, हमने निम्नलिखित सुधार किए हैं:

चीनी विभाजन ICU पुस्तकालय का उपयोग करके
अधिकांश भाषाओं के लिए डिफ़ॉल्ट स्टॉप शब्द:

mysql> create table idx(doc text) stopwords='en';
Query OK, 0 rows affected (0.05 sec)

mysql> call keywords('to be or not to be that is the question', 'idx');
+------+-----------+------------+
| qpos | tokenized | normalized |
+------+-----------+------------+
| 10   | question  | question   |
+------+-----------+------------+
1 row in set (0.01 sec)

अधिक भाषाओं के लिए स्नोबॉल 2.0 समर्थन
आसान सिनटैक्स हाईलाईटिंग:

mysql> insert into idx(doc) values('Polly wants a cracker');
Query OK, 1 row affected (0.09 sec)

mysql> select highlight() from idx where match('polly cracker');
+-------------------------------------+
| highlight()                         |
+-------------------------------------+
| <b>Polly</b> wants a <b>cracker</b> |
+-------------------------------------+
1 row in set (0.10 sec)

नया मल्टीटास्किंग मोड

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

WHERE में OR समर्थन

Sphinx 2/3 में, आप पूरी तरह से फ़िल्टर नहीं कर सकते हैं, जो एक बड़ी सीमा है। हमने इसे Manticore में ठीक किया है:

mysql> select i, s from t where i = 1 or s = 'abc';
+------+------+
| i    | s    |
+------+------+
|    1 | abc  |
|    1 | def  |
|    2 | abc  |
+------+------+
3 rows in set (0.00 sec)

Sphinx 3:
mysql> select * from t where i = 1 or s = 'abc';
ERROR 1064 (42000): sphinxql: syntax error, unexpected OR, expecting $end near 'or s = 'abc''

HTTP के माध्यम से JSON प्रोटोकॉल समर्थन

SQL शानदार है। हम SQL को पसंद करते हैं। और Sphinx / Manticore में प्रश्न सिंटैक्स के बारे में सब कुछ SQL के माध्यम से किया जा सकता है। लेकिन ऐसी स्थितियाँ हैं जहाँ सबसे अच्छा समाधान JSON इंटरफ़ेस का उपयोग करना है, जैसे कि Elasticsearch में। SQL प्रश्न डिज़ाइन के लिए उत्कृष्ट है, जबकि JSON उस समय सहायक है जब आपको अपने ऐप्लिकेशन में एक जटिल प्रश्न एकीकृत करने की आवश्यकता होती है।

इसके अलावा, HTTP कई दिलचस्प चीजें करने की अनुमति देता है: बाहरी HTTP लोड संतुलक और प्रॉक्सी का उपयोग करना, जो प्रमाणीकरण, RBAC, आदि को लागू करने की अनुमति देता है।

अधिक भाषाओं के लिए नए ग्राहक

Even easier than using the JSON over HTTP is to to use a client for a specific programming language your application is written in. We’ve implemented new clients for php , python , java , javascript , elixir , go . Most of them are based on the new JSON interface and their code is generated automatically, allowing us to add new features to the clients much faster.

HTTPS support

Security matters. We’ve made HTTPS support available out of the box. It’s still better not to expose Manticore Search instance to the internet as there is no built-in authentication, but it’s now safer to transfer queries and results from a client to Manticore Search over the LAN. SSL for mysql-interface is also supported.

FEDERATED support

In addition to SphinxSE (a built-in mysql engine that allows you to integrate Sphinx/Manticore more closely with mysql) you can now use MySQL’s FEDERATED engine which is available in MySQL and MariaDB.

ProxySQL support

ProxySQL is also supported and you can use it to make quite interesting things that expand capabilities of Manticore Search.

RT mode

One of the main changes we’ve made was the imperative (i.e. via CREATE/ALTER/DROP table) way of working with Manticore. As you can see from the SQL examples above you don’t need to define an index in config any more. As in other databases, you can now create, alter and delete indexes in Manticore on the fly without the need to edit config, restart the instance, delete real-time index files and all that hassle. Data schema is now completely separated from server’s settings. And that is the default mode. We call it RT mode.

But the declarative mode (we call it Plain mode) is still supported as well. We do not consider it a rudiment and do not plan to get rid of that. Just as you can communicate with Kubernetes the both ways either via yaml files or via specific commands, you can communicate with Manticore similarly too:

you can describe everything in a config and benefit the possibility of easy config porting and faster indexes deployment,
or you can create indexes on the fly which allows to integrate it easier to your application

It is not possible and not in plans to mix the use of modes.

Percolate index

The normal way of doing searches is to store documents we want to search and perform queries against them. However there are cases when we want to apply a query to an incoming new document to signal the matching. There are some scenarios where this is wanted. For example a monitoring system doesn’t just collect data, but it’s also desired to notify user on different events. That can be reaching some threshold for a metric or a certain value that appears in the monitored data. Another similar case is news aggregation. You can notify the user about any fresh news, but user might want to be notified only about certain categories or topics. Going further, they might be only interested about certain “keywords”. All this is now possible in Manticore if you use a percolate index.

mysql> create table t(f text, j json) type='percolate';
mysql> insert into t(query,filters) values('abc', 'j.a=1');
mysql> call pq('t', '[{"f": "abc def", "j": {"a": 1}}, {"f": "abc ghi"}, {"j": {"a": 1}}]', 1 as query);
+---------------------+-------+------+---------+
| id                  | query | tags | filters |
+---------------------+-------+------+---------+
| 8215503050178035714 | abc   |      | j.a=1   |
+---------------------+-------+------+---------+

Works faster than in Elasticsearch .

New user-friendly documentation - https://manual.manticoresearch.com

For key Manticore Search functionality there are examples for most supported clients. Search in the manual of course uses Manticore Search as a backend. What else:

Smart search results highlighting in search results
HTTP examples can be copied in one click directly as a curl command with parameters
In addition, we have specially registered short domain mnt.cr, so that you can very quickly find info on smth you need right now by CTRL-T/CMD-T in your browswer and typing for example mnt.cr/proximity , mnt.cr/quorum , mnt.cr/percolate .

Interactive Courses - https://play.manticoresearch.com

To make it easier to get started with Manticore Search we’ve made the platform for interactive courses https://play.manticoresearch.com and of course the courses themselves, that you can take right from your browser without installing anything at all. In few seconds you can see how Manticore Search replication works or how to highlight search results

Github as a bug tracker

We use Github as a public bug/task tracker.

Sphinx 3

Sphinx 3.0.1 was released in December 2017. Until October 2018 there were three more releases and another one in July 2020 (3.3.1, the last version as of March 2021). Many interesting features appeared, including secondary indexes and some machine learning capabilities. So what’s the problem? Why do people need Manticore at all? One of the reasons is that, unfortunately, neither the first release of Sphinx 3 nor the last one is currently open source:

both in a sense that Sphinx 3 code is not available
और एक व्यापक अर्थ में ओपन सोर्स के संदर्भ में। डाउनलोड पृष्ठ पर यह कहा गया है कि Sphinx अब “डिले्ड FOSS” लाइसेंस के तहत उपलब्ध है। यह लाइसेंस वास्तव में क्या है और इसे कहाँ पाया जा सकता है यह स्पष्ट नहीं है। यह स्पष्ट नहीं है:
क्या यह अभी भी GPLv2 है (यानी “डिलेड FOSS” का मतलब डिलेड GPLv2 है), चूंकि कोड शायद Sphinx 2 पर आधारित है, जो GPLv2 है (जैसे Manticore)। लेकिन तब स्रोत कोड कहाँ है?
या यह GPLv2 नहीं है, क्योंकि बाइनरी के साथ कोई लाइसेंस नहीं जुड़ा है और यह अज्ञात है कि कोड वास्तव में Sphinx 2 पर आधारित है या नहीं? क्या GPLv2 के प्रतिबंध लागू होते हैं? क्या यह ठीक है कि आप अपनी इच्छानुसार Sphinx 3 बाइनरी वितरित करें, चूंकि कोई लाइसेंस पाठ नहीं है?
जुलाई 2020 के बाद से कोई रिलीज़ नहीं हुई। वहाँ बग की भरमार है , जिसमें प्रमुख क्रैश शामिल हैं। इसे कब ठीक किया जाएगा?

बहुत सारे प्रश्न हैं और कोई उत्तर नहीं है। यह सब इसे Sphinx 3 का उपयोग करने के लिए कंपनियों और व्यक्तियों के लिए बहुत जोखिम भरा बनाता है जो चीजों के कानूनी पक्ष और परियोजना की स्थिरता के बारे में चिंतित हैं। बहुत सी कंपनियों के पास परियोजना में अपने कर्मचारियों के समय का निवेश करने की संभावना नहीं है, जो ठंडा दिखती है और जिसकी लाइसेंस बहुत स्पष्ट नहीं है।

सभी मिलाकर Sphinx 3 को अब बहुत विशिष्ट लक्ष्यों के लिए सीमित उपयोगकर्ताओं के लिए एक स्वामित्व समाधान माना जा सकता है। यह दुख की बात है कि ओपन सोर्स दुनिया ने Sphinx को खो दिया है। हम केवल आशा कर सकते हैं कि भविष्य में कुछ बदलेगा।

कोई बेंचमार्क?

हाँ! चलिए डेटासेट का परीक्षण करते हैं जिसमें HackerNews से 1M+ टिप्पणियाँ और न्यूमैरिक विशेषताएँ हैं।

परीक्षण के बारे में अधिक जानकारी:

डेटासेट से बनाया गया प्लेन इंडेक्स। इंडेक्स फ़ाइलों का आकार लगभग 1 गीगाबाइट है
विभिन्न क्वेरीज़ का सेट (132 अनुरोध) पूर्ण-पाठ खोज से फ़िल्टरिंग और समूह बनाने तक
विभिन्न मेमोरी सीमाओं के साथ एक बARE-मेटल सर्वर पर चलने वाले डॉकर्स
हम प्रश्नों को जारी करने के लिए एक PHP स्क्रिप्ट से mysqli क्लाइंट पर SQL का उपयोग करते हैं
प्रत्येक नए प्रश्न से पहले हम सभी कैश को साफ़ करते हैं, जिसमें OS कैश और डॉकर्स को पुनरारंभ करते हैं, फिर हम 5 प्रयास करते हैं, सबसे कम प्रतिक्रिया समय सांख्यिकी में जाता है।

परिणाम:

100 मेगाबाइट्स की सीमा:

500 मेगाबाइट्स की सीमा:

1000 मेगाबाइट्स की सीमा:

Manticore Search का भविष्य

तो, हमारे पास पहले से ही स्पष्ट ओपन सोर्स लाइसेंस GPLv2 के तहत एक सक्रिय रूप से विकसित उत्पाद है जिसमें प्रतिकृति, ऑटो-आईडी, ठीक से काम करने वाले रीयल-टाइम इंडेक्स, JSON इंटरफेस, अच्छी दस्तावेज़ीकरण, इंटरएक्टिव कोर्स और बहुत कुछ है। अब क्या? हमारी रोडमैप है:

नया Manticore इंजन

2020 की शुरुआत से, हम एक कॉलम संग्रहण और प्रसंस्करण लाइब्रेरी पर काम कर रहे हैं जिसमें डिफ़ॉल्ट इंडेक्सिंग (किसी अन्य की तुलना में, जैसे Clickhouse की) है। Manticore और Sphinx उपयोगकर्ताओं के लिए यह निम्नलिखित समस्याओं को हल करेगा:

दस्तावेजों और विशेषताओं के एक बड़े संग्रह में तेजी से खोजने के लिए बड़ी मात्रा में RAM की आवश्यकता
उप-इष्टतम समूह प्रदर्शन
उन विशेषताओं के लिए उप-इष्टतम फ़िल्टरिंग प्रदर्शन जो RAM में नहीं फिट होती हैं

हमारे पास बीटा संस्करण तैयार है और यहाँ कुछ पहले परिणाम हैं जो Manticore Columnar Library + Manticore Search बनाम Elasticsearch की तुलना करते हैं उसी डेटासेट पर जैसे ऊपर (पूर्ण-पाठ प्रश्नों को छोड़कर, यानी ज्यादातर समूह प्रश्न):

अभी भी करने के लिए बहुत सारा काम बाकी है। लाइब्रेरी एक अधिक उदार ओपन सोर्स लाइसेंस Apache 2.0 के तहत उपलब्ध है और इसे Manticore Search में और अन्य परियोजनाओं में (अगर वे चाहें तो Sphinx में भी) उपयोग किया जा सकता है।

ऑटो ऑप्टिमाइज़

हम समझते हैं कि रीयल-टाइम इंडेक्स संकुचन के लिए मैन्युअल रूप से OPTIMIZE कॉल करना कितना असुविधाजनक है। हम इसे हल करने पर काम कर रहे हैं और आशा करते हैं कि इसे अगले रिलीज़ में शामिल किया जाएगा। हमें twitter पर फॉलो करें ताकि आप इसे मिस न करें।

Kibana के साथ एकीकरण

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

Logstash एकीकरण

Manticore Search में पहले से ही JSON प्रोटोकॉल है। हम PUT और POST विधियों को बेहतर बनाने की योजना बना रहे हैं ताकि उन्हें INSERT/REPLACE प्रश्नों के लिए Elasticsearch के साथ संगत बनाया जा सके। इसके अलावा, हम यह संभव बनाने की योजना बना रहे हैं कि पहले डाले गए दस्तावेज़ों के आधार पर उड़ान पर एक इंडेक्स बनाया जा सके। यह सब आपको Logstash, Fluentd, Beats आदि से Elasticsearch के बजाय Manticore Search में डेटा लिखने की अनुमति देगा।

स्वचालित श्रेडिंग

यह एक और प्रोजेक्ट प्रगति में है। हम पहले से ही समझते हैं कि हमें किन प्रकार की कठिनाइयों का सामना करना पड़ेगा और उन्हें हल करने के लिए लगभग कैसे। हम दूसरे तिमाही की योजना बना रहे हैं।

Logstash के लिए वैकल्पिक

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

यदि आपको हमारी गतिविधियाँ पसंद हैं, तो हमारे साथ बने रहें: