2008-11-15 15 views
8

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

यह सामान्य रूप से एक बड़ी समस्या है, और मैं यह जानना चाहता हूं कि कौन से विकल्प उपलब्ध हैं। डाटाबेस शेर्डिंग और विभाजन रणनीतियों के लिए वहां कौन से संसाधन हैं (किताबें, श्वेतपत्र, वेब साइट)?

+0

क्या आपका मतलब "है लगभग 10 मिलियन पंक्तियों तक उगाया गया "? 10 मिलियन टेबल थोड़ा सा लगता है। –

+0

हां मैंने किया। टिप्पणी के लिए धन्यवाद, मैंने मूल प्रश्न को सही किया है। –

उत्तर

10

मैं अन्य उत्तरों से सहमत हूं कि आपको शेडिंग का उपयोग करने से पहले अपनी स्कीमा और इंडेक्स देखना चाहिए । किसी भी प्रमुख डेटाबेस इंजन की क्षमताओं के भीतर 10 मिलियन पंक्तियां अच्छी तरह से हैं।

लेकिन यदि आप sharding के विषय के बारे में सीखने के लिए कुछ संसाधन चाहते हैं तो इन की कोशिश:

+4

+1। –

1

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

बेशक सभी IMHO।

+0

उत्तर के लिए धन्यवाद, माइक। मैंने आपके अवलोकन को दर्शाने के लिए प्रश्न अपडेट किया है। जैसा कि आपने बताया है, मौजूदा वॉल्यूम इंडेक्सिंग और क्वेरी ऑप्टिमाइज़ेशन ठीक काम कर रहे हैं। हम भविष्य में बड़े डेटासेट के लिए योजना बनाने की तलाश में हैं। वास्तव में प्रश्न का उत्तर देने के लिए –

2

मैं माइक वुडहाउस के अवलोकन से सहमत हूं कि वर्तमान आकार एक मुद्दा नहीं होना चाहिए - और प्रश्नकर्ता सहमत हैं।

अधिकांश वाणिज्यिक डीबीएमएस कुछ नामों या कई अन्य लोगों के लिए खंडित तालिकाओं के लिए समर्थन प्रदान करते हैं। मुख्य प्रश्नों में से एक यह है कि डेटा को टुकड़ों में विभाजित करने का एक समझदार तरीका है या नहीं। एक आम तरीका एक तारीख के आधार पर ऐसा करना है, इसलिए, नवंबर 2008 के लिए सभी मूल्य एक खंड में जाते हैं, जो अक्टूबर 2008 के लिए दूसरे में हैं, और इसी तरह। पुराने डेटा को हटाने का समय आने पर इसका लाभ होता है। आप अन्य टुकड़ों को प्रभावित किए बिना अक्टूबर 2001 (सात वर्ष डेटा प्रतिधारण) से डेटा युक्त टुकड़े को छोड़ सकते हैं। इस तरह के विखंडन 'खंड उन्मूलन' के साथ भी मदद कर सकते हैं; यदि क्वेरी को किसी दिए गए खंड से डेटा को पढ़ने की आवश्यकता नहीं है, तो इसे अपठित छोड़ा जाएगा, जो आपको एक शानदार प्रदर्शन लाभ प्रदान कर सकता है। (उदाहरण के लिए, यदि ऑप्टिमाइज़र जानता है कि क्वेरी अक्टूबर 2008 में एक तारीख के लिए है, तो यह अक्टूबर 2008 से डेटा रखने वाले सभी टुकड़ों को अनदेखा कर देगा।)

अन्य विखंडन तकनीकें हैं - राउंड रॉबिन वितरित करता है एकाधिक डिस्क में लोड करें, लेकिन इसका मतलब है कि आप खंड उन्मूलन से लाभ नहीं उठा सकते हैं।

1

मेरे अनुभव में, बड़ी टेबल हमेशा आपको I/O पक्ष पर दबाती हैं। सबसे सस्ता समाधान पर्याप्त मल्टी-कॉलम इंडेक्स जोड़ना है ताकि आपके सभी प्रश्न मुख्य डेटा पृष्ठों को लोड किए बिना सीधे इंडेक्स से डेटा प्राप्त कर सकें। यह आपके आवेषण और अद्यतन I/O गहन बनाता है, लेकिन यह ठीक हो सकता है। अगले आसान विकल्प यह आपके सर्वर में रैम अधिकतम है। यदि आपका डेटाबेस बड़ा है तो 32 जीबी से कम होने का कोई कारण नहीं है। लेकिन अंत में आप अभी भी I/O बाध्य पाएंगे, और आप बहुत सी हार्ड ड्राइव खरीदने और जटिल विभाजन योजना को बनाए रखने की तलाश करेंगे, जो हार्डवेयर और श्रम के बीच एक भाग्य खर्च करता है। मुझे उम्मीद है कि इन दिनों एक बेहतर विकल्प है - डेटाबेस को हार्ड ड्राइव कताई से एसएलसी ठोस राज्य ड्राइव में ले जाएं - इससे आपको यादृच्छिक पढ़ना चाहिए और लाइन एसएएस ड्राइव के शीर्ष से सौ गुना तेज लिखना चाहिए, और I/O को हटाएं टोंटी। एसएसडी $ 10 प्रति गीगाबाइट से शुरू होते हैं, इसलिए आप कुछ भव्य खर्च करने जा रहे हैं लेकिन यह अभी भी SANs से बहुत सस्ता है, आदि

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