2010-11-23 10 views
49

मेरी टीम किसी तृतीय पक्ष सीएमएस के साथ काम कर रही है जो सोलर को खोज सूचकांक के रूप में उपयोग करती है। मैंने देखा है कि ऐसा लगता है जैसे लेखकों प्रकार में है कि प्रत्येक दस्तावेज़ लौटे का एक डाटाबेस के रूप में प्रयोग कर रहे हैं Solr दो क्षेत्रों में शामिल हैं:डेटाबेस के रूप में सोलर सर्च इंडेक्स का उपयोग करना - क्या यह "गलत" है?

  1. Solr दस्तावेज़ आईडी (मूल रूप से एक classname और डेटाबेस आईडी)
  2. एक एक्सएमएल संपूर्ण वस्तु

का प्रतिनिधित्व तो मूल रूप से यह Solr के खिलाफ एक खोज चलाता है, वस्तु की एक्सएमएल प्रतिनिधित्व डाउनलोड, और फिर बल्कि आईडी का उपयोग कर डेटाबेस में यह देख ऊपर से XML से वस्तु का दृष्टांत।

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

वर्तमान कार्यान्वयन पूरी तरह से ध्वनि है, या इस विचार का समर्थन करने के लिए डेटा है कि यह refactoring के लिए परिपक्व है?

संपादित करें: जब मैं "एक्सएमएल प्रतिनिधित्व" कहता हूं - मेरा मतलब है एक संग्रहित फ़ील्ड जिसमें ऑब्जेक्ट की सभी गुणों की एक्सएमएल स्ट्रिंग है, एकाधिक संग्रहित फ़ील्ड नहीं।

+1

जिज्ञासा से बाहर, सीएमएस क्या है? –

उत्तर

27

एप्लिकेशन के आधार पर, एक डेटाबेस के रूप में सोलर का उपयोग करना उचित है। वास्तव में, यह बहुत अधिक है guardian.co.uk is doing

यह निश्चित रूप से खराब अभ्यास प्रति से है। यह केवल बुरा है यदि आप गलत तरीके से इसका इस्तेमाल करते हैं, किसी भी स्तर पर किसी भी अन्य उपकरण की तरह, यहां तक ​​कि GOTOs।

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

आखिरकार, यह आपके आवेदन की ज़रूरतों पर निर्भर है। सोलर मुख्य रूप से एक टेक्स्ट सर्च इंजन है, लेकिन कई अनुप्रयोगों के लिए नोएसQL डेटाबेस के रूप में भी कार्य कर सकता है।

+0

हमारे पास कई अनुक्रमित फ़ील्ड हैं, लेकिन केवल दो ही वास्तव में संग्रहीत हैं - दस्तावेज़ आईडी और दस्तावेज़ एक्सएमएल।तो हाँ, यह प्रभावी रूप से एक्सएमएल टेक्स्ट की एक बड़ी स्ट्रिंग है जिसका उपयोग हमारे अनुक्रमित ऑब्जेक्ट्स के सभी 1,000,000 के लिए एप्लिकेशन पक्ष पर पुनर्प्राप्त वस्तुओं को तुरंत चालू करने के लिए किया जाता है। –

+0

@ माइक: आईएमओ जो सोलर का दुरुपयोग कर रहा है। इसके बजाय, सोलर स्कीमा में संबंधित फ़ील्ड को परिभाषित करें और उन्हें ठीक से इंडेक्स करें। –

2

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

+0

समस्या प्रदर्शन है ... हमारे पास लगभग 10,000 कोर केवल 1,000,000 रिकॉर्ड हैं। खोज 500ms और 2000ms के बीच ले रही हैं (जो अक्सर होती है)। मुझे लगता है कि यह एक छोटे से कोर के खिलाफ खोज करने और डीबी (10-50ms शीर्ष) से ​​पंक्तियों को खींचने के लिए तेज़ी से होगा। –

+1

@ माइक: आपकी अनुक्रमणिका बहुत बड़ी है, मैं इसे देखकर देखता हूं: http://wiki.apache.org/solr/DistributedSearch –

2

मैंने इसी तरह की चीजें देखी हैं क्योंकि यह बहुत तेज़ लुकअप की अनुमति देती है। हम डीआरवाई सिद्धांतों का पालन करने और सूचकांक के आकार को कम करने के लिए हमारे ल्यूसीन इंडेक्स से डेटा को तेजी से कुंजी-मूल्य स्टोर में ले जा रहे हैं। इस तरह की चीज के लिए एक कठिन और तेज़ नियम नहीं है।

61

हाँ, आप एक डेटाबेस के रूप में SOLR उपयोग कर सकते हैं लेकिन कुछ वास्तव में गंभीर चेतावनियां हैं:

  1. SOLR की सबसे आम का उपयोग पैटर्न, जो http does not को बैच क्वेरी किए जाने के लिए विशेष रूप से अच्छी तरह से प्रतिक्रिया खत्म हो गया है।इसके अलावा, एसओएलआर डेटा स्ट्रीम नहीं करता --- इसलिए आप एक समय में लाखों रिकॉर्ड के माध्यम से आलसी ढंग से पुन: प्रयास नहीं कर सकते हैं। इसका मतलब है कि जब आप एसओएलआर के साथ बड़े पैमाने पर डेटा एक्सेस पैटर्न तैयार करते हैं तो आपको बहुत विचारशील होना चाहिए।

  2. SOLR प्रदर्शन मापता क्षैतिज हालांकि (अधिक मशीनों, अधिक कोर, आदि ..) के साथ-साथ खड़ी (अधिक रैम, बेहतर मशीनों, आदि), अपनी क्वेरी क्षमताओं गंभीर रूप से एक परिपक्व RDBMS के रहने वालों की तुलना सीमित हैं। उस ने कहा, कुछ उत्कृष्ट कार्य हैं, जैसे फील्ड आंकड़े प्रश्न, जो काफी सुविधाजनक हैं।

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

  4. "enterprisy" उपकरण है कि उन्नत सत्र प्रबंधन और statefull संस्थाओं कई उन्नत वेब चौखटे (रूबी, हाइबरनेट, ...) की पेशकश करना होगा कि के लिए अनुमति देने के लिए पूरी तरह खिड़की बाहर फेंक दिया जाना है।

  5. रिलेशनल डेटाबेस जटिल डेटा और रिश्तों से निपटने के लिए हैं - और इस प्रकार वे कला मेट्रिक्स और स्वचालित विश्लेषण उपकरण की स्थिति के साथ हैं। एसओएलआर में, मैंने खुद को ऐसे टूल लिखने और मैन्युअल रूप से तनाव-परीक्षण बहुत कुछ पाया है, जो एक समय सिंक हो सकता है।

  6. शामिल होना: यह बड़ा हत्यारा है। रिलेशनल डेटाबेस सरल भविष्यवाणियों के आधार पर टुपल्स में शामिल होने वाले विचारों और प्रश्नों के निर्माण और अनुकूलन के तरीकों का समर्थन करते हैं। एसओएलआर में, सूचकांक में डेटा में शामिल होने के लिए कोई मजबूत तरीका नहीं है।

  7. लचीलापन: उच्च उपलब्धता के लिए, सोलरक्लाउड (यानी एचसीएफएस) के नीचे एक वितरित फ़ाइल सिस्टम का उपयोग करता है। यह मॉडल एक रिलेशनल डेटाबेस की तुलना में काफी अलग है, जो आमतौर पर गुलामों और मालिकों, या RAID का उपयोग करके लचीलापन करता है, और इसी तरह। तो आपको लचीला बुनियादी ढांचा प्रदान करने के लिए तैयार रहना होगा एसओएलआर की आवश्यकता है यदि आप क्लाउड स्केलेबल और प्रतिरोधी होना चाहते हैं।

कहा - कुछ कार्यों के लिए SOLR के लिए स्पष्ट लाभ बहुत सारे हैं: (http://wiki.apache.org/solr/WhyUseSolr देखें) - ढीला प्रश्नों ज्यादा चलाने के लिए और सार्थक परिणाम देने के लिए आसान कर रहे हैं। इंडेक्सिंग डिफ़ॉल्ट रूप से किया जाता है, इसलिए अधिकांश मनमानी प्रश्न बहुत प्रभावी ढंग से चलते हैं (आरडीबीएमएस के विपरीत, जहां आपको अक्सर तथ्य के बाद ऑप्टिमाइज़ करना और सामान्य बनाना होता है)।

निष्कर्ष: भले ही आप एक RDBMS के रूप में SOLR का उपयोग कर सकते हैं, आप पा सकते (जैसा कि मैंने किया है) अंत में है कि "कोई मुफ्त भोजन" - और सुपर शांत Lucene पाठ खोजों और उच्च की लागत बचत -प्रदर्शन, इन-मेमोरी इंडेक्सिंग, अक्सर कम लचीलापन और नए डेटा एक्सेस वर्कफ़्लो को अपनाने के लिए भुगतान किया जाता है।

+3

बैच पूछताछ: बस कई HTTP अनुरोधों को एक साथ भेजें। स्ट्रीमिंग: आप पेजिनेशन का उपयोग करके इसे छोटा रूप से अनुकरण कर सकते हैं। सत्र प्रबंधन/राज्यव्यापी संस्थाएं: यह केवल लेनदेन संबंधी अनुप्रयोगों के लिए मान्य है। तनाव परीक्षण: सोलरमीटर का उपयोग करें, इसे 'मैन्युअल' करने की आवश्यकता नहीं है। शामिल हो रहा है: यह ऐसा है (अधिकांश?) NoSQL डेटाबेस के लिए। –

+0

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

+0

धन्यवाद। मैं मोंगोडीबी से बहुत परिचित नहीं हूं, लेकिन दस्तावेज कहता है, "मोंगोडीबी शामिल होने का समर्थन नहीं करता है और इसलिए, कभी-कभी, कुछ असामान्यता की आवश्यकता होती है" (http://www.mongodb.org/display/DOCS/MongoDB+Data+Modeling + और + रेल)। पृष्ठांकन के साथ स्ट्रीमिंग अनुकरण करने के लिए कोड लिखना मामूली है, कम से कम .NET (~ 15 LoC) में, हालांकि आप सही हैं कि यह मानता है कि सूचकांक अनुरोधों के बीच नहीं बदलता है। –

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

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