क्या MySQL क्लस्टर एक टेराबाइट डेटाबेस

Question

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

मैं माईएसक्यूएल क्लस्टर को देख रहा हूं जो उनकी एचए पेशकश है। डेटा की मात्रा के कारण मुझे डिस्क आधारित स्टोरेज का उपयोग करना होगा। वास्तव में मुझे लगता है कि केवल टाइमस्टैम्प स्मृति में हो सकते हैं और अन्य सभी डेटा डिस्क पर संग्रहीत करने की आवश्यकता होगी।

क्या किसी को इस पैमाने के डेटाबेस पर MySQL क्लस्टर का उपयोग करने का अनुभव है? क्या यह भी व्यवहार्य है? डिस्क आधारित स्टोरेज प्रदर्शन को कैसे प्रभावित करता है?

मैं डेटा के इस वॉल्यूम के लिए वांछित उपलब्धता को प्राप्त करने के लिए अन्य सुझावों के लिए भी खुला हूं। उदाहरण के लिए, मानक MySQL उदाहरणों के क्लस्टरिंग को संभालने के लिए Sequoia जैसे किसी तृतीय पक्ष की libary का उपयोग करना बेहतर होगा? या MySQL प्रतिकृति के आधार पर एक और सीधे आगे समाधान?

एकमात्र शर्त यह है कि यह एक MySQL आधारित समाधान होना चाहिए। मुझे नहीं लगता कि MySQL डेटा के लिए जाने का सबसे अच्छा तरीका है जिसके साथ हम काम कर रहे हैं लेकिन यह एक कठिन आवश्यकता है।

Answer 1

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

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

Answer 2

ठीक है, मैं mySQL के बारे में एक कठिन आवश्यकता होने के बारे में हिस्सा पढ़ता हूं।

तो इसके साथ, मुझे पहले यह बताएं कि आप जिस वर्कलोड के बारे में बात कर रहे हैं - 2500 आवेषण/सेक, दुर्लभ प्रश्न, पूरे डेटा सेट के 10 प्रतिशत तक परिणाम सेट होने की संभावना है - किसी भी संबंधपरक डेटा बेस सिस्टम के लिए बस निराशाजनक है।

(यह मुझे एक परियोजना की याद दिलाता है, बहुत पहले, जहां मुझे 300 सेकंड से भी कम समय में 9600 बॉड आरएस -422 लाइन (एक कठिन आवश्यकता) पर 100 मेगाबाइट प्रोग्राम डेटा लोड करने की हार्ड आवश्यकता थी (भी एक कठिन आवश्यकता।) तथ्य यह है कि 1KByte/सेकंड × 300 सेकंड = 300kbytes संवाद करने के लिए नहीं मालूम था।)

तो फिर वहाँ के बारे में हिस्सा है "शामिल अप करने के लिए 30 तैरता है।" वाक्यांश कम से कम सुझाव देता है कि प्रति सम्मिलित नमूने की संख्या परिवर्तनीय है, जो कुछ सामान्यीकरण मुद्दों को बदलने में सुझाव देती है - या फिर प्रत्येक पंक्ति 30 प्रविष्टियों को व्यापक बनाने और एनयूएलएल का उपयोग करने की आवश्यकता है।

लेकिन सभी ने कहा कि, ठीक है, आप लगभग 300 किलोबाइट/सेकंड और 2500 टीपीएस के बारे में बात कर रहे हैं (यह मानते हुए कि यह वास्तव में असंबंधित नमूने का अनुक्रम है)। यह set of benchmarks, कम से कम, सुझाव देता है कि यह संभावना के दायरे से बाहर नहीं है।

Answer 3

This article एक बड़े MySQL डेटाबेस को धीमा कर सकता है यह पहचानने में वास्तव में सहायक है।

Answer 4

संभवतः हाइबरनेट शॉर्ट्स को आज़माएं और 10/2 टेडबाइट के साथ 10 नोड्स पर MySQL चलाएं ताकि आप 5 टेराबाइट्स को संभाल सकें;) आपकी सीमा से अच्छी तरह से मुझे लगता है?