मैं खरोंच से एक छोटे से खोज इंजन लेखन में इस सवाल का इस्तेमाल करेंगे कुछ अनुभव साझा करने के (कोई खोज-विशिष्ट पुस्तकालयों का उपयोग किया गया था) काफी छोटे डेटासेट के लिए (यह वास्तव में स्टैक ओवरफ्लो की खोज करता है क्योंकि यह न तो बहुत छोटा था और न ही एक सर्वर पर काम करने के लिए बहुत बड़ा था)। Check it out। नीचे विषय पर मेरे निष्कर्ष हैं।
क्रॉलर
पहले, क्रॉलर करने के लिए एक कठिन बात है। वास्तविक समस्या डिस्क पर डेटा लिख रही है जितनी जल्दी आप वेब पेज प्राप्त करते हैं। मुख्य डेटा संरचना एक उलटा इंडेक्स है और इसलिए जब आपको "केला" शब्द मिलता है तो आपको डिस्क से "केले" इंडेक्स (दस्तावेजों की सूची जहां यह होता है - दस्तावेज़ में स्थितियों के साथ) को नए रिकॉर्ड के साथ जोड़ना पड़ता है और इसे वापस लिखो। जैसे-जैसे सूची बढ़ती है, इसे वापस खींचकर लिखना धीमा हो रहा है। तो एक चाल उलटा इंडेक्स (और दस्तावेजों) को विभाजन में टुकड़ा करना होगा, पहले विभाजन में 1-1000 दस्तावेज कहें और इसी तरह। अन्य "चाल" स्मृति में इंडेक्स को रखने के लिए विभाजन को क्रॉल करते समय और विभाजन को पूरा होने पर डिस्क पर फ़्लश करते समय होती है।
महत्वपूर्ण बिट: डेटा स्टोर करने के लिए क्या उपयोग करना है? कई विकल्प हैं और कई प्रयोगों के बाद मुझे लेवलडबी आज के रूप में सबसे अच्छा विकल्प मिल गया है। और एसएसडी डिस्क मत भूलना!
तो, सभी में, एक मशीन (4 जीबी रैम) का उपयोग करके इस तरह से अधिकांश स्टैक ओवरफ्लो (~ 13 000 000 पेज) को क्रॉल करना लगभग 2 महीने लगते हैं। और परिणामी डेटा (उलटा इंडेक्स, कच्चा पटा हुआ पाठ, आदि) - लगभग 80 जीबी डिस्क स्पेस।
खोजें
लक्ष्य यह तेजी से और उच्च गुणवत्ता के साथ क्या करना है। एहसास करने की एक बात यह है कि यदि आप इसे तेज करना चाहते हैं, तो आप पूरे डेटासेट को नहीं खोज सकते हैं। सौभाग्य से, मेरे पास सब कुछ विभाजित था इसलिए खोज पहले 100 विभाजन लेती है जहां कीवर्ड प्रकट होते हैं (उस के लिए अलग इंडेक्स) और यदि यह "पर्याप्त पर्याप्त" परिणाम पाता है - बंद हो जाता है, यदि नहीं - तो एक और 100 लेता है।
सबसे धीमा हिस्सा डिस्क से इंडेक्स पढ़ रहा है और इसे deserialising है।लेवलडब तेजी से अनुक्रमिक पढ़ने का समर्थन करता है, इसलिए डेटा को इस तरह से संग्रहीत करने की आवश्यकता है कि इसे अधिकतर अनुक्रमिक रूप से पढ़ा जा सके। एक बार मेमोरी सेट चौराहे में बहुत तेज है।
अब गुणवत्ता। यह सबसे कठिन और कभी भी अच्छा नहीं है। मेरा प्रारंभिक प्रयास न केवल टेक्स्ट के लिए उलटा इंडेक्स रखना था, बल्कि शीर्षक, लिंक टेक्स्ट और यूआरएल के लिए भी था। इनमें से प्रत्येक हिट दस्तावेज़ में कुछ बिंदु जोड़ती है। एक और बात यह है कि समानार्थी शब्दों का उपयोग करके क्वेरी को दोबारा दोहराएं और किसी भी तरह से जांचें कि कौन सी क्वेरी सबसे अच्छी तरह से काम करती है। यह शायद अपने आप में एक पद का हकदार होगा।
वैसे भी, मुझे आशा है कि यह उपयोगी पठन होगा!
धन्यवाद! मैंने इसे एक बार देखा था लेकिन भूल गया था कि यह कहां था। – davemackey