क्या बड़े डेटासेट के लिए MySQL से MongoDB या Cassandra बेहतर है?

Question

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

समवर्ती रूप से, ग्राहक सेवा उसी डेटाबेस के प्रतिकृति दास पर चलती है।

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

हम क्लाउड में काम नहीं करते हैं, बजाय हमारे सर्वर रूम में दो भौतिक सर्वरों का उपयोग करके संचालित करने के लिए चुनते हैं।

यह सब देखते हुए, डेटाबेस के लिए हमारा सबसे अच्छा विकल्प क्या है?

Answer 1

मुझे लगता है कि आप समस्या के बारे में गलत तरीके से जा रहे हैं।

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

आपके पास क्षणिक हार्डवेयर से चिपके हुए और एक मोनोलिथिक डेटा स्टोरेज का उपयोग करना स्केलेबल नहीं है और जैसा आपने देखा - वास्तविक समय में कुछ करने के लिए प्रभाव डालने पर प्रभाव पड़ता है।

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

तेजी से एचडीडी सबसिस्टम लागू करने से आपकी आवश्यकताओं में सहायता मिलेगी (FusionIO यदि आपके पास संसाधन प्राप्त करने के लिए संसाधन हैं)।

अपने अंत में अधिक जानकारी (क्या सर्वर सेटअप है, तो आप क्या MySQL संस्करण का उपयोग कर रहे हैं और क्या भंडारण इंजन + डेटा आकार आप के साथ काम कर रहे हैं), यह सब अटकलें है बिना

।

Answer 2

कैसेंड्रा अभी भी MapReduce के लिए Hadoop जरूरत है, और MongoDB MapReduce के संबंध में संगामिति सीमित है ...

... इसलिए ...

... 120 Mio रिकॉर्ड है न कि ज्यादा, और MySQL आसानी से इसे संभालने में सक्षम होना चाहिए। मेरा अनुमान एक आईओ बाधा है, या आप अनुक्रमिक पढ़ने के बजाय बहुत सारे यादृच्छिक पढ़ रहे हैं। मैं एक नए समाधान में निवेश करने के बजाय, अपनी स्कीमा और प्रश्नों को ट्यून करने के लिए एक महीने या उससे भी अधिक के लिए एक MySQL तकनीक तैयार करना चाहता हूं।

यदि आप अपने क्लस्टर के बारे में अधिक जानकारी प्रदान करते हैं, तो हम आपकी मदद करने में सक्षम हो सकते हैं। स्वयं द्वारा "नोएसक्यूएल" आपकी समस्या का समाधान नहीं है।

Answer 3

जितना मैं MySQL के एक प्रशंसक एक बार अपने डेटा बड़े हो जाता है नहीं कर रहा हूँ, मैं कहना है कि आप एक NoSQL समाधान के लिए स्थानांतरित करने के लिए की आवश्यकता होगी, के पास कहीं भी नहीं कर रहे हैं की है। 120 एम पंक्तियां एक बड़ा सौदा नहीं है: जिस डेटाबेस में मैं वर्तमान में काम कर रहा हूं वह अकेले एक टेबल में ~ 600 एम है और हम इसे कुशलतापूर्वक पूछते हैं। एक ओप परिप्रेक्ष्य से इतना डेटा प्रबंधित करना समस्या है; पूछताछ यह नहीं है।

यह उचित सूचकांक और उनमें शामिल होने पर सही उपयोग के बारे में है, और दूसरी बार स्मृति सेटिंग्स। अपने धीमे प्रश्नों को ढूंढें (mysql धीमी क्वेरी लॉग FTW!), और कीवर्ड को समझने के लिए सीखें कि वे धीमे हैं। फिर अपनी अनुक्रमणिका को ट्विक करें ताकि आपके प्रश्न कुशल हों। इसके अलावा, सुनिश्चित करें कि आप MySQL की मेमोरी सेटिंग्स को समझते हैं। डॉक्स में महान पृष्ठ हैं जो बताते हैं कि वे कैसे काम करते हैं, और उन्हें समझना मुश्किल नहीं है।

यदि आपने उन दोनों चीजों को किया है और आपको अभी भी समस्याएं हैं, तो सुनिश्चित करें कि डिस्क I/O कोई समस्या नहीं है। फिर यदि आपको यह है तो अपने डेटा से पूछताछ के लिए आपको किसी अन्य समाधान में देखना चाहिए।

कैसंद्रा जैसे नोएसक्यूएल समाधानों में बहुत सारे लाभ हैं। डेटा लिखने पर कैसंद्रा शानदार है। अपने लेखन स्केलिंग बहुत आसान है - बस अधिक नोड्स जोड़ें! लेकिन ट्रेडऑफ यह है कि डेटा को वापस लेना मुश्किल है। एक लागत परिप्रेक्ष्य से, यदि आपके पास माईएसक्यूएल में विशेषज्ञता है, तो संभवतः अपने अंतर्निहित आर्किटेक्चर को स्विच करने से पहले सीमा को हिट करने तक यह आपके वर्तमान समाधान को मापने के लिए बेहतर है।