2014-09-17 10 views
7

मैं कैसंड्रा/सौर एकीकरण के लिए डीएसई का उपयोग कर रहा हूं ताकि डेटा कैसंद्रा में संग्रहीत हो और सोलर में अनुक्रमित हो। सीआरयूडी ऑपरेशन को संभालने के लिए कैसंद्रा का उपयोग करना बहुत स्वाभाविक है और क्रमशः पूर्ण पाठ खोज के लिए सोलर का उपयोग करें, और डीएसई कैसंड्रा और सोलर के बीच डेटा सिंक्रनाइज़ेशन को वास्तव में सरल बना सकता है।डीएसई में कैसंड्रा बनाम सोलर का उपयोग कब करें?

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

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

मैं इसे संभाल करने के लिए तीन अलग अलग तरीकों के बारे में सोच सकते हैं:

  1. प्रचार 'अनुक्रमित = सच' दोनों श्रेणी और like_count क्षेत्र और Solr में क्वेरी के लिए Solr स्कीमा में
  2. साथ कैसेंड्रा में एक denormalized तालिका बनाएं प्राथमिक कुंजी (श्रेणी, like_count, आईडी)
  3. ऐसे स्पार्क/तूफान के रूप में कैसेंड्रा में एक denormalized तालिका बनाएं प्राथमिक कुंजी (श्रेणी, आदेश, आईडी) के साथ और प्रयोग एक बाहरी घटक, like_count द्वारा आइटम सॉर्ट करने के लिए

पहली विधि लागू करने और बनाए रखने के लिए सबसे सरल प्रतीत होता है। मैं बस कुछ मामूली सोलर एक्सेसिंग कोड लिखता हूं और शेष भारी उठाने को सोलर/डीएसई खोज द्वारा नियंत्रित किया जाता है।

दूसरी विधि को बनाने और अद्यतन पर मैन्युअल denormalization की आवश्यकता है। मुझे एक अलग टेबल बनाए रखने की भी आवश्यकता है। मकबरे के मुद्दे भी हैं क्योंकि like_count को अक्सर अद्यतन किया जा सकता है। अच्छा हिस्सा यह है कि पढ़ना तेज हो सकता है (यदि कोई अत्यधिक मकबरे नहीं हैं)।

तीसरा तरीका सॉर्टिंग के लिए एक अतिरिक्त घटक की लागत पर टॉम्बस्टोन मुद्दे को कम कर सकता है।

आपको कौन सी विधि सबसे अच्छा विकल्प लगता है? प्रदर्शन में अंतर क्या है?

उत्तर

21

कैसेंड्रा माध्यमिक अनुक्रमित उपयोग के मामलों तक ही सीमित है:

  1. नहीं अनुक्रमित स्तंभों की एक जोड़ी से अधिक है।
  2. किसी क्वेरी में केवल एक ही अनुक्रमित कॉलम।
  3. उच्च प्रमुखता डेटा (अपेक्षाकृत अद्वितीय स्तंभ मान) के लिए बहुत ज्यादा अंतर-नोड यातायात
  4. कम प्रमुखता डेटा के लिए बहुत ज्यादा अंतर-नोड यातायात (पंक्तियों के उच्च प्रतिशत से मेल खाएगी)
  5. प्रश्नों पहले से जाना जाने की जरूरत है तो डेटा मॉडल उनके चारों ओर अनुकूलित किया जा सकता है।

इन सीमाओं के कारण, ऐप्स के लिए "इंडेक्स टेबल" बनाने के लिए आम बात है जो जो भी कॉलम वांछित है, द्वारा अनुक्रमित किया जाता है। इसके लिए या तो डेटा को प्रत्येक तालिका तालिका में मुख्य तालिका से डुप्लिकेट किया जाना चाहिए, या इंडेक्स तालिका को पढ़ने के लिए अतिरिक्त क्वेरी की आवश्यकता होगी और फिर इंडेक्स तालिका से मुख्य कुंजी पढ़ने के बाद मुख्य तालिका से वास्तविक पंक्ति को पढ़ें। एकाधिक कॉलम पर क्वेरी को मैन्युअल रूप से अग्रिम रूप से अनुक्रमित करना होगा, जिससे विज्ञापन समस्याएं समस्याग्रस्त हो जाएंगी। और किसी भी डुप्लीकेट को प्रत्येक इंडेक्स तालिका में ऐप द्वारा मैन्युअल रूप से अपडेट करना होगा।

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

  1. कॉलम की एक मध्यम संख्या इंडेक्स किए गए:

    दिल्ली शेयर बाजार/Solr के लिए बेहतर है।

  2. संदर्भित कई कॉलम/फ़ील्ड के साथ जटिल प्रश्न - ल्यूसीन समांतर में एक क्वेरी में सभी निर्दिष्ट फ़ील्ड से मेल खाता है। ल्यूसीन प्रत्येक नोड पर डेटा अनुक्रमणित करता है, इसलिए नोड्स समानांतर में क्वेरी करता है।
  3. आम तौर पर सामान्य प्रश्न, जहां सटीक प्रश्न अग्रिम में ज्ञात नहीं हैं।
  4. कीवर्ड खोज, वाइल्डकार्ड, अस्पष्ट/जैसे, रेंज, असमानता जैसे रिच टेक्स्ट प्रश्न।

वहाँ Solr अनुक्रमण का उपयोग कर के लिए एक प्रदर्शन और क्षमता लागत है, इसलिए अवधारणा कार्यान्वयन का एक सबूत, मूल्यांकन करने के लिए कितना अतिरिक्त रैम, भंडारण, और नोड्स की जरूरत है की सिफारिश की है, जिस पर निर्भर करता है कि कितने कॉलम आप सूचकांक, अनुक्रमित पाठ की मात्रा, और किसी भी पाठ फ़िल्टरिंग जटिलता (उदाहरण के लिए, एन-ग्राम की आवश्यकता होती है।) सभी कॉलम अनुक्रमित होने पर यह अपेक्षाकृत कम संख्या में अनुक्रमित कॉलम के लिए 25% की वृद्धि हो सकती है। इसके अलावा, आपको पर्याप्त नोड्स की आवश्यकता है ताकि एसएसडी का उपयोग करते समय प्रति-नोड सोलर इंडेक्स रैम में फिट हो या ज्यादातर रैम में फिट हो। और वर्तमान में सोलर डेटा केंद्रों के लिए vnodes की अनुशंसा नहीं की जाती है।

+0

+1 शानदार उत्तर। और मैं सीमित उपयोग मामलों वाले माध्यमिक इंडेक्स से पूरी तरह से सहमत हूं। शायद कैसंद्रा में शायद सबसे गलत समझा उपकरण। – Aaron

+0

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

+0

महान उत्तर !! आप कैसे कहेंगे एसएएसआई सूचकांक डीएसई/सौर से तुलना करते हैं। वास्तव में आपकी राय सुनना अच्छा लगेगा। – taylorcressy

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