2008-11-19 14 views
5

हमारे पास एक होस्ट किया गया एप्लिकेशन है जो सामग्री के पृष्ठों का प्रबंधन करता है। प्रत्येक पृष्ठ में कई अनुकूलित फ़ील्ड हो सकते हैं, और कुछ मानक फ़ील्ड (टाइमस्टैम्प, उपयोगकर्ता नाम, उपयोगकर्ता ईमेल इत्यादि) हो सकते हैं।कुशल फ़िल्टरिंग/खोज

सिस्टम का उपयोग कर संभावित रूप से सैकड़ों विभिन्न साइटों के साथ - फ़िल्टरिंग/खोज को संभालने का एक प्रभावी तरीका क्या है? एक ग्रिड व्यू को चित्रित करें जिसे आप संकुचित करना चाहते हैं। आप विशिष्ट फ़ील्ड (उपयोगकर्ता आईडी, दिनांक) पर फ़िल्टर कर सकते हैं या आप एक पूर्ण-पाठ खोज दर्ज कर सकते हैं।

उदाहरण के लिए, "उपयोगकर्ता आईडी 10 द्वारा शुरू किए गए सभी पृष्ठ" एक MySQL डेटाबेस के खिलाफ एक बहुत तेज़ क्वेरी होगी। लेकिन चीजें जैसे "सभी उपयोगकर्ता द्वारा शुरू किए गए सभी पृष्ठ जिनके उपयोगकर्ता आईडी 10 हैं और [कुछ खोज क्वेरी] मेल खाते हैं" डेटाबेस के खिलाफ चूसेंगे, इसलिए यह ल्यूसीन जैसे खोज इंजन के लिए उपयुक्त है।

असल में मैं सोच रहा हूं कि अन्य बड़ी साइटें इस तरह की चीज कैसे करती हैं। क्या वे सभी प्रकार के फ़िल्टरिंग के लिए 100% खोज इंजन का उपयोग करते हैं? क्या वे एक खोज इंजन के साथ डेटाबेस क्वेरीज मिश्रण करते हैं?

यदि हम केवल एक खोज इंजन का उपयोग करते हैं, तो खोज सूचकांक में एक नई/अद्यतन ऑब्जेक्ट में दिखाई देने में देरी के समय में कोई समस्या है। यही है, मैंने पढ़ा है कि सूचकांक तुरंत अद्यतन करने के लिए स्मार्ट नहीं है, और इसके बजाय बैचों में ऐसा करने के लिए। यहां तक ​​कि यदि हर 5 मिनट का मतलब है, तो उपयोगकर्ता भ्रमित हो जाएंगे जब हाल ही में जोड़ा गया पृष्ठ तत्काल सूचीबद्ध नहीं होता है जब वे एक साधारण पृष्ठ सूची देखते हैं ("श्रेणी: 5" की खोज क्वेरी कहें)।

हम MySQL का उपयोग कर रहे हैं और खोज के लिए लुसेन में बारीकी से देख रहे हैं। क्या कोई और तकनीक है जिसके बारे में मुझे नहीं पता?

मेरा विचार एक साधारण फ़िल्टरिंग पृष्ठ प्रदान करना है जो मूल फ़ील्ड पर फ़िल्टर करने के लिए MySQL का उपयोग करता है। फिर एक अलग पूर्ण टेक्स्ट खोज पृष्ठ प्रदान करें जो Google के समान परिणाम प्रस्तुत करेगा। क्या यह एकमात्र तरीका है?

उत्तर

2

सोलर या घास के मैदान दोनों लुसीन को थोड़ा अधिक अमूर्त इंटरफेस प्रदान करते हैं।

उसने कहा: हाँ। यदि आप मुख्य रूप से सामग्री संचालित साइट हैं, तो आपके डेटा पर पूर्ण टेक्स्ट खोज प्रदान करते हुए, LIKE से परे कुछ खेल है। जबकि MySQL की FULLTEXT अनुक्रमणिका सही नहीं हैं, यह अंतरिम में स्वीकार्य प्लेसहोल्डर हो सकती है।

मान लीजिए कि आप ल्यूसीन इंडेक्स बनाते हैं, ल्यूसीन दस्तावेज़ों को आपके रिलेशनल ऑब्जेक्ट्स से जोड़ना बहुत सरल है, बस इंडेक्स टाइम पर दस्तावेज़ में संग्रहीत संपत्ति जोड़ें (यह संपत्ति यूआरएल, आईडी, GUID इत्यादि हो सकती है।) फिर, खोज एक 2 चरण प्रणाली हो जाता है: 1) Lucene indexies (शीर्षक की तरह साधारण परिणाम प्रदर्शित) 2) करने के लिए जारी करना क्वेरी द्वारा अपने रिलेशनल दुकानों से वस्तु के बारे में और विस्तृत जानकारी प्राप्त उसके प्रमुख

दस्तावेजों की इन्स्टेन्शियशन के बाद से ल्यूसीन में अपेक्षाकृत महंगा है, आप केवल लुसेन इंडेक्स में खोजे गए फ़ील्ड को स्टोर करना चाहते हैं, क्योंकि आपके संबंधपरक वस्तुओं के पूर्ण क्लोन के विपरीत। http://www.sphinxsearch.com/

हम एक ही समस्या हो रही है और संभव समाधान के रूप में स्फिंक्स और Lucene पर विचार:

0

MySQL को इतनी आसानी से लिखना न भूलें!

डेटाबेस का उपयोग करके इसे लागू करें उदा। जहां-खंड या जो भी हो, 'जैसे' के साथ चयन करें।

प्रोफ़ाइल, अगर आवश्यक हो तो इंडेक्स जोड़ें। बीटा को रोल करें, इसलिए आपको उपयोगकर्ता के वास्तविक डेटा पैटर्न से वास्तविक संख्या मिलती है - सभी कॉलमों के बाद समान रूप से पूछा नहीं जा सकता है, आदि

यदि प्रदर्शन चूसता है, तो जब आप अन्य विकल्पों पर विचार करते हैं। आप अपने एसक्यूएल, अपने डेटाबेस, डेटाबेस को चालू करने वाली मशीन, और आखिरकार एक और तकनीक स्टैक का उपयोग करने पर विचार कर सकते हैं ...

0

आप MySQL या PostgreSQL, एक खुला स्रोत समाधान है कि यह साथ अच्छा काम करता है का उपयोग करना चाहते मामले में स्फिंक्स है।

संबंधित मुद्दे