2010-02-15 12 views
8

मैं एमएस सर्च सर्वर 2010 को कार्यान्वित कर रहा हूं और अब तक यह वास्तव में अच्छा है। मैं अपनी वेब सेवा के माध्यम से खोज क्वेरी कर रहा हूं, लेकिन असंगत results के कारण, मैं परिणाम को कैशिंग करने के बारे में सोच रहा हूं।पेजिंग और सॉर्टिंग के लिए खोज परिणाम संग्रहीत करना

साइट एक छोटा इंट्रानेट (500 कर्मचारी) है, इसलिए यह कोई समस्या नहीं होनी चाहिए, लेकिन मुझे लगता है कि यदि यह एक बड़ी साइट थी तो आप क्या दृष्टिकोण लेंगे।

मैंने abit googled है, लेकिन वास्तव में कुछ भी विशिष्ट पर आ गया है। तो, कुछ प्रश्न:

  • अन्य दृष्टिकोण क्या हैं? और वे बेहतर क्यों हैं?
  • 400-500 पंक्तियों के डेटाव्यू को स्टोर करने के लिए कितना खर्च होता है? क्या आकार संभव हैं?
  • अन्य अंक जिन्हें आप ध्यान में रखना चाहिए।

किसी भी इनपुट का स्वागत है :)

+0

क्या आपने अपाचे सोलर को देखा है? –

उत्तर

2

आपको इसे सफलतापूर्वक खींचने के लिए कई तकनीकों को नियोजित करने की आवश्यकता है।

पहले, आपको किसी प्रकार की दृढ़ता परत की आवश्यकता है। यदि आप एक सादे पुरानी वेबसाइट का उपयोग कर रहे हैं, तो उपयोगकर्ता का सत्र उपयोग करने के लिए सबसे तार्किक परत होगी। यदि आप वेब सेवाओं (अर्थात् सत्र-कम) का उपयोग कर रहे हैं और केवल क्लाइंट के माध्यम से कॉल कर रहे हैं, तो आपको अपनी सेवाओं के लिए अभी भी कुछ प्रकार की एप्लिकेशन लेयर (साझा सत्र का प्रकार) चाहिए। क्यूं कर? यह परत आपके डेटाबेस परिणाम कैश का घर होगा।

दूसरा, आपको जो भी कंटेनर आप उपयोग कर रहे हैं (सत्र या वेब सेवाओं की एप्लिकेशन परत) में अपने परिणामों को कैशिंग करने का एक तरीका चाहिए। आप इसे दो तरीकों से कर सकते हैं ... यदि क्वेरी कुछ ऐसा है जो कोई भी उपयोगकर्ता कर सकता है, तो क्वेरी का एक सरल हैश काम करेगा, और आप इस संग्रहीत परिणाम को अन्य उपयोगकर्ताओं के बीच साझा कर सकते हैं। आप शायद परिणाम के लिए कुछ प्रकार के GUID चाहते हैं, ताकि आप इसे अपने क्लाइंट एप्लिकेशन में पास कर सकें, लेकिन परिणामों से प्रश्नों में हैश लुकअप होना उपयोगी होगा। यदि ये प्रश्न अनूठे हैं तो आप केवल क्वेरी परिणाम के लिए अद्वितीय GUID का उपयोग कर सकते हैं और इसे क्लाइंट एप्लिकेशन के साथ पास कर सकते हैं। ऐसा इसलिए है कि आप अपनी कैशिंग कार्यक्षमता निष्पादित कर सकते हैं ...

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

तीसरा, आप पृष्ठ पर किसी तरह अपने परिणाम वस्तु ... इटरेटर पैटर्न यहाँ अच्छी तरह से काम चाहते करने जा रहे हैं, हालांकि शायद कुछ सरल काम हो सकता है ... की तरह एक्स परिणाम की राशि बिंदु पर शुरू लाने वाई। हालांकि इटरेटर पैटर्न बेहतर होगा क्योंकि आप बाद में अपने कैशिंग तंत्र को हटा सकते हैं और डेटाबेस को सीधे डेटाबेस से हटा सकते हैं यदि आप चाहें तो।

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

इससे आपको कुछ रास्ता मिलना चाहिए ... अगर आप स्पष्टीकरण/किसी विशेष भाग के बारे में अधिक जानकारी चाहते हैं तो मुझे बताएं।

मैं आपको कुछ और सुझावों के साथ छोड़ दूंगा ...

  1. आप क्लाइंट ऐप पर पूरा परिणाम नहीं भेजना चाहते हैं (यदि आप अजाक्स या आईफोन ऐप की तरह कुछ उपयोग कर रहे हैं)। क्यूं कर? ठीक है क्योंकि यह एक बड़ा अपशिष्ट है। उपयोगकर्ता संभवतः सभी परिणामों के माध्यम से पृष्ठ पर नहीं जा रहा है ... अब आपने कुछ भी नहीं के लिए 2 एमबी परिणाम फ़ील्ड भेजे हैं।

  2. जावास्क्रिप्ट एक भयानक भाषा है लेकिन याद रखें कि यह अभी भी एक क्लाइंट साइड स्क्रिप्टिंग भाषा है ... आप अपने अजाक्स क्लाइंट को संभालने के लिए भारी मात्रा में डेटा भेजकर उपयोगकर्ता अनुभव को धीमा नहीं करना चाहते हैं। बस अपने क्लाइंट और अतिरिक्त पेज परिणामों को उपयोगकर्ता पृष्ठों के रूप में प्रीफ़ेटेड परिणाम भेजें।

  3. अमूर्त अमूर्त अमूर्तता ... आप कैश, क्वेरीिंग, पेजिंग, प्रीफेचिंग को दूर करना चाहते हैं ... जितना आप कर सकते हैं उतना ही कर सकते हैं। क्यूं कर? खैर कहें कि आप डेटाबेस स्विच करना चाहते हैं या आप सीधे कैश में परिणाम ऑब्जेक्ट का उपयोग करने के बजाय डेटाबेस से पेज करना चाहते हैं ... ठीक है अगर आप इसे सही करते हैं तो बाद में इसे बदलना बहुत आसान है। साथ ही, यदि वेब सेवाओं का उपयोग करते हैं, तो कई अन्य एप्लिकेशन बाद में इस तर्क का उपयोग कर सकते हैं।

अब, मैंने शायद आपको आवश्यकतानुसार एक अधिक इंजीनियर समाधान का सुझाव दिया है :)। लेकिन, यदि आप सभी सही तकनीकों का उपयोग करके इसे खींच सकते हैं, तो आप एक टन सीखेंगे और यदि आप कार्यक्षमता को विस्तारित करना चाहते हैं या इस कोड का पुन: उपयोग करना चाहते हैं तो बहुत अच्छा आधार प्राप्त करें।

यदि आपके कोई प्रश्न हैं तो मुझे बताएं।

+0

मैं जवाब देना भूल गया। माफ़ कीजिये। मैंने वेब सेवा कॉल के लिए वेब सेवा कॉल और सत्र के लिए कैशिंग का उपयोग किया था। व्यापक उत्तर के लिए धन्यवाद, वास्तव में सहायक! – Mattias

0

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

लॉजिक को पुरानी अस्थायी तालिकाओं की जांच करने और उन्हें हटाने के लिए जगह में रखा जाना चाहिए। यह काफी आसान है और मैंने SQL सर्वर को उस कार्यक्षमता को संभालने दिया है। आखिरकार तर्क जब मूल क्वेरी बदलता है (महत्वपूर्ण परिधि परिवर्तन) के लिए तर्क दिया जाना चाहिए ताकि आगे के पूछताछ के लिए एक नया डेटा सेट खींचा जा सके और एक नई temp तालिका में रखा जा सके। यह सब अपेक्षाकृत सरल है।

उपयोगकर्ताओं को Google जैसे स्थानों से दूसरे रिटर्न टाइम्स को विभाजित करने के लिए उपयोग किया जाता है और यह मॉडल मुझे वास्तव में प्राप्त करने के लिए पर्याप्त लचीलापन देता है जो कि वे उपयोग किए जाने वाले विशेष सॉफ़्टवेयर और हार्डवेयर की आवश्यकता के बिना।

उम्मीद है कि यह थोड़ा सा मदद करता है।

0

टिम का जवाब चीजों को संभालने का एक शानदार तरीका है यदि आपके पास दूसरे थ्रेड में प्रारंभिक क्वेरी चलाने की क्षमता है और परिणामों पर लागू होने के लिए तर्क (पेजिंग/सॉर्टिंग/फ़िल्टरिंग) सर्वर पर कार्रवाई की आवश्यकता है .. ... अन्यथा ....

यदि आप AJAX का उपयोग कर सकते हैं, तो 500 पंक्ति परिणाम सेट को पृष्ठ में बुलाया जा सकता है और क्लाइंट पर पर्ज या सॉर्ट किया जा सकता है। इससे कुछ वाकई दिलचस्प विशेषताएं हो सकती हैं .... प्रेरणा के लिए jQueryUI और Dojo से डेटाग्रिड समाधान देखें!

और वास्तव में गहन सुविधाओं जैसे मनमाने ढंग से regex फ़िल्टर और ड्रैग-एंड-ड्रॉप कॉलम पुन: ऑर्डर करने के लिए आप पूरी तरह से सर्वर को मुक्त कर सकते हैं।

ब्राउज़र में डेटा को एक बार में लोड करना आपको उपयोगकर्ता को "अनुरोध" के रूप में समर्थन डेटा (पृष्ठ पूर्वावलोकन आदि) में कॉल करने देता है ....

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

संभावनाएं अनंत हैं :)

+0

लेकिन उम्मीद है कि, आपकी खोज एल्गोरिदम प्रारंभिक परिणाम लाती है, इसलिए आप 490 परिणाम और पृष्ठ पूर्वावलोकन छवियां लोड कर रहे होंगे अनावश्यक रूप से –

1

यह खोज की धीमी गति से भाग की तरह लगता है पूर्ण पाठ खोज, नहीं परिणाम पुनः प्राप्ति है। परिणामी संसाधन रिकॉर्ड आईडी कैशिंग के बारे में कैसे? साथ ही, चूंकि यह सच हो सकता है कि खोज क्वेरी अक्सर डुप्लिकेट की जाती हैं, खोज क्वेरी, क्वेरी और मिलान संसाधनों का हैश स्टोर करें। फिर आप आईडी के परिणामों के अगले पृष्ठ को पुनर्प्राप्त कर सकते हैं। AJAX के साथ भी काम करता है।

चूंकि यह एक इंट्रानेट है और आप खोजे गए संसाधनों को नियंत्रित कर सकते हैं, तो आप निष्क्रिय समय के दौरान लोकप्रिय प्रश्नों के लिए एक नया या अद्यतन संसाधन मिलान भी पूर्व-गणना कर सकते हैं।

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