मामूली विशेषताओं के बावजूद क्या ध्यान आकर्षित किया?
1. वास्तविक समय अनुक्रमण की संभावना।
2. दस्तावेज़ की विशेषताओं की उपस्थिति और परिणाम की खोज और छँटाई में उनका उपयोग।
3. उपयोग में आसानी और कॉम्पैक्ट, स्पष्ट प्रलेखन (यह अध्ययन करने में कुछ दिनों का समय लगा, वास्तव में डॉक के विकर्ण के साथ एक सरसरी नज़र और उत्पाद के अधिक विस्तृत अध्ययन के लिए प्रेरणा था)।
हाइपर एस्ट्रायर के मेरे इंप्रेशन:
यह खोज इंजन फाललैब्स पेन का है, जिसका एक उत्पाद मैंने हाल ही में परीक्षण किया है । एक लघु उपयोगकर्ता गाइड (एक लैपटॉप पर 34 स्क्रीन, जिनमें से दो-तिहाई सेटिंग्स और कॉन्फ़िगरेशन का वर्णन है) के साथ कुछ दिलचस्प सुविधाओं के विवरण ने प्रयोग को बहकाया।
व्यक्तिगत रूप से, मैंने विवरण का अध्ययन करने में कुछ दिन बिताए, स्थापित करने के लिए कुछ मिनट, साथ ही आधे घंटे या एक घंटे के लिए सबसे सरल विकल्प का पता लगाने के लिए, तीन दस्तावेजों को अनुक्रमित करना और परिणामों के साथ खेलना।
क्लाइंट-सर्वर आर्किटेक्चर के अध्ययन और परीक्षण के लिए उसके प्रदर्शन का मूल्यांकन करने और परीक्षण करने के लिए डेटा के पहले से ही काम कर रहे वॉल्यूम को अनुक्रमित करने के लिए एक कार्यक्रम "मेरे घुटने पर" लिखने के लिए मैंने एक और दिन बिताया।
डिफ़ॉल्ट मापदंडों के साथ मानक स्थापना:
$ ./configure
$ बना
$ स्थापित करें
उपलब्धता की आवश्यकता:
- लिबीकॉनव - ग्लिबक का हिस्सा;
- zlib - डेटा संपीड़न के लिए
- QDBM एक ही FalLabs, एक एम्बेडेड डेटाबेस का एक उत्पाद है। ऊपर एक ही योजना के अनुसार स्थापना।
अनुक्रमण।
अनुक्रमण के लिए, दस्तावेज़ को "दस्तावेज़ प्रारूप" प्रारूप में प्रस्तुत किया जाना चाहिए - इसका अपना प्रारूप, वैचारिक रूप से http प्रोटोकॉल के प्रारूप के करीब है - शीर्ष / रिक्त पंक्ति / पाठ।
शीर्ष लेख प्रारूप "@ विशेषता = मान" में विशेषताओं को सूचीबद्ध करता है। एक पंक्ति - एक विशेषता।
पाठ सादा सादा पाठ है। Utf-8 एन्कोडेड फ़ाइल।
कार्य करें।
1. सबसे सरल विकल्प कमांड लाइन है।
Estcmd उपयोगिता एक खोज सूचकांक बनाती है, इसे प्रबंधित करती है और आपको खोज करने की अनुमति देती है। -Vh विकल्प को निर्दिष्ट करते समय, खोज परिणाम काफी पठनीय होता है, इसे मल्टीपार्ट प्रारूप में स्निपेट्स के साथ प्रदर्शित किया जाता है। पहली पंक्ति एक ब्लॉक विभाजक है। पहला ब्लॉक हेडिंग है, अनुरोध का परिणाम है - कितने दस्तावेज़ कुल हैं, खोज समय, प्रत्येक शब्द के लिए दस्तावेजों की संख्या आदि। ऐसे आउटपुट को पार्स करना आसान और सुखद है।
इस विकल्प के लिए, पैकेज में एक सरल cgi- स्क्रिप्ट है, आप ब्राउज़र के माध्यम से अधिक परिचित तरीके से खोज सकते हैं।
यदि आपको अपने डिजाइन में कुछ और सुंदर की आवश्यकता है - तो आपके लिए सुविधाजनक किसी भी उपकरण के साथ आउटपुट पार्स करें।
2. एक अधिक जटिल विकल्प क्लाइंट-सर्वर है।
यह खोज इंजन डेटाबेस के साथ बहु-उपयोगकर्ता कार्यों के लिए वांछनीय है। साथ ही, यदि पहले संस्करण में, प्रत्येक बार डेटाबेस को खोलने में कुछ समय लगता है, तो इस मामले में हम इस ऑपरेशन को बचाते हैं, और निश्चित रूप से, नवीनतम अनुरोधों को कैच करने से बार-बार कॉल जारी करने में काफी तेजी आती है।
इस विकल्प की खोज में रुकावट:
- सी के लिए एपीआई (सरलतम उदाहरणों के साथ प्रलेखन);
- वेब इंटरफ़ेस - सरल खोज और डेटाबेस प्रबंधन;
- estcall कमांड लाइन उपयोगिता - वास्तव में सर्वर को एक ही http अनुरोध भेजता है, खोज परिणाम पिछले पैराग्राफ में वर्णित समान हैं।
काम की गति।
पिछली बार के रूप में एक ही सर्वर पर परीक्षण हुआ - ओप्टरन -2218, 2.6GHz, 8G ओपी, HDD 73G + 143G sas।
इस बार सभी काम 143-गीगाबाइट ड्राइव में से एक पर किया गया था।
प्रारंभिक डेटा - एक परियोजना के मंचों से 3224992 पोस्ट, लगभग 700 एमबी की कुल मात्रा के साथ।
अनुक्रमण डेटा। डेटा 5000 फ़ाइलों के बैचों में डाउनलोड किया गया था, जिसे utf-8 में बदल दिया गया और अनुक्रमित किया गया।
- पहला विकल्प, कमांड लाइन - 6 घंटे, लगभग एक मिनट प्रति मिनट;
- दूसरा विकल्प - फाइलें व्यक्तिगत रूप से सर्वर को खिलाया गया - लगभग 10.5 घंटे।
धीरे धीरे? हां। स्फिंक्स की तुलना में - एक कछुआ। लेकिन सूचकांक के प्रारंभिक भरने के लिए, समय काफी स्वीकार्य है। और क्या हमारे पास ऐसे संस्करणों के साथ कई परियोजनाएं हैं? और नए दस्तावेजों के साथ सूचकांक की वर्तमान पुनःपूर्ति के लिए, ऐसी गति पर्याप्त से अधिक है। मुझे LiveJournal डेटा नहीं मिला, Liveinternet.ru के मुख्य पृष्ठ पर इस समय (11:47, 01/03/2011) डायरियाँ कहती हैं - "अंतिम समय में 4518 पोस्ट" - यह प्रति सेकंड लगभग 75 पोस्ट है, प्राप्त इंडेक्सिंग गति के लगभग बराबर है। दूसरे विकल्प के अनुसार (प्रति सेकंड 85 पोस्ट)। यह खोज इंजन LiRu के लिए उपयुक्त नहीं है, लेकिन क्या समान ट्रैफ़िक वाली कई साइटें हैं?
डिस्क संसाधन:
- पहले विकल्पों द्वारा प्राप्त सूचकांक डिस्क पर लगभग 5.3 Gb लेता है;
- दूसरे विकल्प द्वारा प्राप्त सूचकांक लगभग 6.3 Gb है।
ऐसा क्यों - समझ में नहीं आया। शायद यह किसी भी तरह कई अनुक्रमित सर्वर के एक साथ संचालन की संभावना पर निर्भर करता है, आंतरिक नाम "नोड" (नोड) है।
खोज की गति।
दुर्भाग्य से, मैं अभी तक इस मुद्दे पर अधिक या कम विस्तृत आंकड़े एकत्र नहीं कर पाया हूं। मैंने अनुरोधों के साथ बड़े पैमाने पर बमबारी की व्यवस्था नहीं की। मैं व्यक्तिपरक भावनाओं को साझा कर सकता हूं:
1. एक नवनिर्मित सूचकांक पर पहले प्रश्नों को एक लंबे समय के लिए संसाधित किया गया है - लगभग डेढ़ सेकंड।
2. बार-बार एक ही अनुरोध, साथ ही दिए गए अनुरोध के पृष्ठों के बीच आंदोलन - एक सेकंड के 1 सौवें से अधिक नहीं।
3. क्रिया संबंधी प्रश्नों को संसाधित होने में अधिक समय लगता है। उदाहरण के लिए, 5 शब्दों का अनुरोध (अंतिम स्पैम मेलिंग के अवशेष की तलाश में) ने पेजिंग पर लगभग 0.17 सेकंड का समय भी लगाया।
मैंने खोज इंजन सर्वर के वेब इंटरफेस के माध्यम से सभी अनुरोध किए।
निष्कर्ष।
- इस खोज इंजन की शक्ति अधिकांश साइटों के लिए काफी है, अपवाद के साथ, शायद, बड़े मीडिया, लाइवजर्नल स्तर और इस तरह के ब्लॉग।
- इसके साथ स्थापना, विन्यास और संचालन काफी सरल है और इसमें उच्च योग्यता और एक व्यक्ति की आवश्यकता नहीं है।
- वास्तव में, हाइपर एस्ट्रायर के साथ आप किसी भी दस्तावेज़ को अनुक्रमित कर सकते हैं जहां आप पाठ आकर्षित कर सकते हैं। प्रलेखन में अन्य प्रारूपों के कुछ पार्सर कार्यक्रमों के लिंक दिए गए हैं। वेब पेजों को अनुक्रमित करने के लिए इसका अपना क्रॉलर भी है।
मैं इसे प्रतिदिन 10-20 हज़ार पोस्ट / टिप्पणियों के ट्रैफ़िक वाले मंचों के समूह पर चलाने जा रहा हूं।
पुनश्च। मैंने हाइपर एस्ट्रायर की सभी विशेषताओं पर विचार नहीं किया। अगर मैं सही तरीके से समझूं, तो कई इंडेक्स-नोड्स को एक साथ खोजना संभव है, साथ ही साथ काम का एक बहु-मशीन संस्करण भी। इसलिए यह संभव है कि इंजन की वास्तविक "शक्ति" जो मैं प्राप्त कर सकता हूं उससे काफी अधिक हो सकता है। प्रशंसकों के परीक्षण के लिए, काम तड़पा रहा :)