2011-06-23 12 views
5

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

अतिरिक्त अतिरिक्त एसएसक्यूएल समाधान (लुसीन के अलावा) मैं इस स्थिति में लाभ उठा सकता हूं?

कुछ विकल्प मैं सोच रहा हूँ कर रहे हैं:

  1. उपयोग हाइबरनेट दूसरे स्तर के लिए ehcache (टेराकोटा) वितरित मशीनों के लिए अधिक स्मृति का लाभ उठाने और डुप्लिकेट कैश (अभी प्रत्येक वी एम का अपना कैश है) कम करने के लिए।

  2. एच 2 जैसे स्मृति SQL डेटाबेस में पूरी तरह से उपयोग करने के लिए, लेकिन दुर्भाग्यवश उन समाधानों को एकल वीएम में 100+ एमएलएन टेबल लोड करने की आवश्यकता है।

  3. आईडी द्वारा इकाई लुकअप के लिए पूछताछ और बिगटेबल (या वितरित हैशप) के लिए ल्यूसीन का उपयोग करें। इसके लिए क्या बिगटेबल कार्यान्वयन उपयुक्त होगा? मैं एचबीएस पर विचार कर रहा था।

  4. डेटा संग्रह करने और आईडी द्वारा पूछताछ और लुकअप के लिए मोंगोडीबी का उपयोग करें।

+1

क्या आप डेटा को शेड कर सकते हैं? –

+2

यदि आईडी द्वारा लुकअप बिगटेबल या मोंगोडीबी के साथ एक संभावित विकल्प है, तो एसक्यूएल के साथ यह संभावित विकल्प क्यों नहीं है? –

+0

आपका डेटा कैसा दिखता है ..? – NightWolf

उत्तर

0

आप कर सकते थे समूह & उन्हें डेटा का एक सेट & एक भी है (या सर्वर के एक समूह) प्रक्रिया है कि, यहाँ आप डेटा के प्रदर्शन में सुधार करने के लिए कैश में उपलब्ध हो सकता है के लिए विशिष्ट विभाजित अनुरोध करता है।

जैसे

कहते हैं, कर्मचारी & उपलब्धता डेटा 10 तालिकाओं का उपयोग नियंत्रित किया जाता है, इन सर्वर (रों) के एक छोटे समूह ख संभाला जा सकता है जब आप हाइबरनेट कैश कॉन्फ़िगर & संभाल अनुरोध लोड करने के लिए।

इस काम के लिए आपको लोड बैलेंसर (जो व्यापार परिदृश्य से लोड संतुलन) की आवश्यकता है।

यह सुनिश्चित नहीं है कि इसमें कितना कार्यान्वित किया जा सकता है।

6

एक स्केलेबल सिस्टम के लिए लोचदार खोज के साथ कैसंद्रा की सिफारिश (100 मिलियन उनके लिए कुछ भी नहीं है)। विज्ञापन और भौगोलिक प्रश्नों के लिए अपने सभी डेटा और ईएस के लिए कैसंद्रा का प्रयोग करें। फिर आप अपने पूरे विरासत ढेर को मार सकते हैं। आपको कैस के बीच डेटा सिंक के लिए rabbitmq जैसे एमक्यू सिस्टम की आवश्यकता हो सकती है। और ईएस।

0

100 एम रिकॉर्ड पर आपकी बाधा संभवतः हाइबरनेट, ओरेकल नहीं है। हमारे ग्राहकों को नियमित रूप से हमारे ओरेकल आधारित डेटा वेयरहाउस की व्यक्तिगत तथ्य सारणी में अरबों रिकॉर्ड हैं और यह उन्हें ठीक से संभालता है।

आप अपनी मेज पर किस प्रकार के प्रश्न निष्पादित करते हैं?

+0

यहां मेमरी डेटाबेस में उपयोग करने के लिए संशोधित एक ही विधि के रनटाइम का एक उदाहरण है, ओरेकल के लिए सभी तरह से जा रहा है: 116,201ms बनाम 20ms (116201ms oracle.jdbc.driver.OraclePreparedStatement.executeQuery() पर आपकेकिट के अनुसार खर्च किया जाता है)। मेरा लक्ष्य 20ms के करीब जितना संभव हो उतना आना है। – tsolakp

+0

@ टोलोलक पेट्रोसियन: यदि आपका प्रदर्शन लक्ष्य मामूली बड़ी 100 एम रिकॉर्ड तालिका पर खोजों के लिए मिलीसेकंड के दसियों का है, तो आपको शायद नोएसक्यूएल की बजाय इन-मेमोरी डेटाबेस या कैश पर विचार करना चाहिए। – Olaf

0

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

1

आपको लिली प्रोजेक्ट (lilyproject.org) भी देखना चाहिए। उन्होंने सोलर के साथ एचबीएस एकीकृत किया है। आंतरिक रूप से वे एचबीएस के साथ सिंक में सोलर रखने के लिए संदेश कतार का उपयोग करते हैं। इससे उन्हें अत्यधिक विश्वसनीय डेटा स्टोरेज सिस्टम द्वारा समर्थित सोलर इंडेक्सिंग (शेर्डिंग और प्रतिकृति) की गति मिलती है।

2

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

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

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

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

एक अन्य पथ जिसे अब तक कोई भी उल्लेख नहीं किया गया है वह न्यूएसक्यूएल है - यानी क्षैतिज स्केलेबल आरडीबीएमएस ... वहाँ कुछ ऐसे हैं जो MySQL क्लस्टर (मुझे लगता है) और वोल्टडीबी जैसे हैं जो आपके कारण के अनुरूप हो सकते हैं।

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

मेरी सलाह वास्तव में कुछ अलग प्रणालियों के साथ खेलना होगा।की ओर देखें;

MongoDB - दस्तावेज़ - सीपी

CouchDB - दस्तावेज़ - एपी

Redis - स्मृति की-वैल्यू (स्तंभ नहीं परिवार) में - सीपी

कैसेंड्रा - कॉलम परिवार - उपलब्ध & विभाजन टोलरेंट (एपी)

HBase - स्तंभ परिवार - लगातार & विभाजन सहिष्णु (सीपी)

Hadoop/हाइव

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

कोई भी तरीका है कि मेरे 2 सी। सिस्टम के साथ खेलना वास्तव में एकमात्र तरीका है जिसे आप यह पता लगाने जा रहे हैं कि वास्तव में आपके मामले के लिए क्या काम करता है।

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