MySQL में विभाजन तालिकाएँ। अच्छा अभ्यास?

14

मैंने एक मौजूदा परियोजना पर काम करना शुरू कर दिया है और पिछले डेवलपर ने समान स्कीमा लेकिन अलग-अलग डेटा के साथ 10 अलग-अलग तालिकाओं में एक तालिका को विभाजित किया था।

टेबल इस तरह दिखते हैं:

[tableName_0]
[tableName_1]
[tableName_2]
[tableName_3]
[tableName_4]
[tableName_5]
[tableName_6]
[tableName_7]
[tableName_8]
[tableName_9]

प्राथमिक कुंजी एक पूर्णांक idफ़ील्ड है। idलुकअप करते समय एप्लिकेशन को कौन सी तालिका का उपयोग करना है, यह जानने के लिए हैश एल्गोरिथ्म ( मॉड 10) का उपयोग करता है । उदाहरण के लिए id= 10 का परिणाम होगा [tableName_0]।

संयुक्त, तालिकाओं में संभवतः 100,000 पंक्तियां हैं और विकास दर अपेक्षाकृत कम है।

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

mysql database-design best-practices

— गुलाबी मौसमी
स्रोत

17

मुझे लगता है कि हर कोई इसे जटिल कर रहा है। यहाँ मुख्य बिंदु यह है:

संयुक्त, तालिकाओं में संभवतः 100,000 पंक्तियां हैं और विकास दर अपेक्षाकृत कम है।

यह किसी भी RDBMS को संभालने के लिए केक का एक टुकड़ा है । एक तालिका के साथ जाएं, इसे ठीक से अनुक्रमित करें, और इसे हल की गई समस्या पर विचार करें।

आपको विभाजन पर विचार करने की आवश्यकता नहीं है, चाहे "होममेड" या अन्यथा, जब तक आप डेटा के बहुत बड़े संस्करणों को संभालना शुरू न करें - अरबों पंक्तियों और ऊपर का विचार करें।

— निक चामस
स्रोत

3

आप मर्ज तालिकाओं का उपयोग कर सकते हैं, हालांकि वे 4.x संस्करणों से अधिक प्राचीन हैं। यह देखते हुए कि आपके आवेदन को मैन्युअल रूप से विभाजित किया गया है क्योंकि यह या तो एक है) आप एक बहुत पुराना संस्करण चला रहे हैं या ख) मूल डेवलपर को तालिका विभाजन के बारे में पता नहीं था।

संक्षेप में अगर आप 5.1+ चला रहे हैं तो आप mysql को आपके लिए यह विभाजन करने दे सकते हैं। Http://dev.mysql.com/doc/refman/5.1/en/partitioning.html देखें। यदि आप 5.5 का उपयोग कर रहे हैं, तो आपको उन विशिष्ट डॉक्स की जांच करनी चाहिए, क्योंकि आपको कुछ अंतर मिलेंगे।

विभाजन के कई फायदे हैं। हालाँकि यह वास्तव में हाथ में डेटासेट, एक्सेस पैटर्न और यह कैसे अनुक्रमित किया जाना है पर निर्भर करता है। इसके अलावा, ध्यान रखें कि मेरी निम्नलिखित टिप्पणियाँ mysql 5+ विभाजन के संदर्भ में हैं, पुराने mysql मर्ज तालिकाएँ नहीं हैं; हालांकि उन्हें कभी-कभी विभाजन के संदर्भ में चर्चा की जाती है।

कुछ उदाहरण:

अक्सर प्राप्त होने वाली लुकिंग कुंजी के आधार पर सीधे बकेटिंग (या हैशिंग)। यदि आप बहुत अधिक हमेशा एक प्राथमिक या अन्य अद्वितीय कुंजी द्वारा देख रहे हैं तो mysql आपके पास कितने विभाजन के कारक द्वारा खोज स्थान को काट सकता है। ध्यान दें कि यह हानिकारक हो सकता है यदि आप एक कुंजी से विभाजन करते हैं और फिर दूसरी कुंजी द्वारा अक्सर खोज करते हैं। यदि आप किसी कुंजी द्वारा खोजते हैं तो डेटा का विभाजन नहीं होता है, तो उसे लुकअप पर अधिक खोज करनी होगी (प्रत्येक विभाजन के लिए एक, b / c स्पष्ट रूप से, यह नहीं पता है कि डेटा कहां है)
विचार करें कि क्या आपके पास रिकॉर्ड्स का एक अस्थायी सेट है जो कि तारीख से बढ़ता है और आप समय-समय पर पिछले महीने को बाहर निकालते हैं। यदि आप तिथि से विभाजन कर रहे हैं, तो आप बस एक विभाजन को छोड़ सकते हैं जो तालिका को छोड़ने के समान तेज़ है, चाहे कितना भी बड़ा हो। यदि आप तारीखों के आधार पर ऐसी तालिका को पसंद करते हैं, तो आपको एक या एक से अधिक प्रश्नों को जारी करना होगा जहां प्रत्येक व्यक्तिगत पंक्ति हटा दी जाती है। इस परिदृश्य में आपके द्वारा अधिकतम तारीख तक पहुँचने के बाद, इसके लिए mysql स्वचालित रूप से नए विभाजन नहीं बनाता है; आपको अपनी ज़रूरतों के लिए अतिरिक्त रखरखाव स्क्रिप्ट्स को अपनी आवश्यकता के अनुसार विभाजन जोड़ने की आवश्यकता है।
यदि आप मायसम चेक का उपयोग कर रहे हैं और रिकवरी बहुत तेज है। एक 100G myisam तालिका पर विचार करें। यदि आप एक दुर्घटनाग्रस्त तालिका को पुनर्प्राप्त करना चाहते हैं, तो आपको कम से कम 100G अतिरिक्त डिस्क स्थान की आवश्यकता होगी। यदि इसे समान आकार के 10 अलग-अलग हिस्सों में विभाजित किया गया था, तो आपको केवल 10G स्थान की आवश्यकता होती है (और तेजी से पुनर्प्राप्ति के लिए कम key_sort_buffer मेमोरी); लेकिन प्रत्येक विभाजन के लिए एक पुनरावृत्ति करने की आवश्यकता होगी।

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

मैं उन स्थितियों की कल्पना कर सकता हूं जहां वांछित विभाजन बहुत विशिष्ट है और आवेदन परत में बैठे उस तर्क के लिए बेहतर अनुकूल होगा। हालांकि आपके सीधे मापांक 10 विवरण को देखते हुए ऐसा मामला नहीं लगता है।

संपादित करें

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

— atxdba
स्रोत

3

पिछले डेवलपर ने आपके लिए जो किया है वह विभाजन-दर-हश के अपने स्वयं के कार्यान्वयन के लिए बनाया गया है। MySQL शाब्दिक रूप से MySQL 5.1 से इस मूल का समर्थन करता है:

http://dev.mysql.com/doc/refman/5.1/en/partitioning-hash.html

मैं एक अच्छे कारण के बारे में नहीं सोच सकता हूँ इसलिए अपने स्वयं के विभाजन को लागू करें, न कि देशी संस्करण [1] पर भरोसा करने के बजाय। स्कीमा परिवर्तन करना एक बुरा सपना होगा।

मैं शायद ही कभी विभाजन-दर-हश (मूल कार्यान्वयन) की सिफारिश करता हूं। मुझे लगता है कि यह उपयोगी होगा यदि आप इसका उपयोग एक बार में प्रत्येक विभाजन को समानांतर खोज करने के लिए कर सकते हैं (जो MySQL नहीं करेगा)। यदि आपको कई विभाजनों में खोज करने की आवश्यकता है, तो आपके द्वारा वर्णित योजना अक्सर धीमी हो जाएगी।

[१] हालाँकि, कुछ अन्य विभाजन प्रकारों के लिए यह आपके स्वयं के विभाजन को रोल करने के लिए समझ में आता है। MySQL आपको अपनी विभाजन कुंजी को अपनी प्राथमिक कुंजी और सभी अद्वितीय अनुक्रमित का हिस्सा बनाने के लिए मजबूर करता है।

— मॉर्गन Tocker
स्रोत

2

प्रश्न के उत्तर में:

यह एक व्यवहार्य समाधान है या नहीं

IMHO, यह अनावश्यक ओवरहेड की तरह लगता है। जब तक विवरण में कुछ अन्य जानकारी सामने न आए तब तक आप किसी एकल तालिका को ठीक से अनुक्रमित और विभाजित कर सकते हैं।

प्रश्न के उत्तर में:

... अगर यह किसी भी स्थिति में एक अच्छा अभ्यास है

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

उदाहरण के लिए एक वेब लॉग टेबल को फॉर्म में रख सकते हैं:

datetime TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
uri VARCHAR(1024),
host VARCHAR(255),
user_agent VARCHAR(255),
etc...

आपका समाधान वेबलॉग डेटाबेस में आवश्यकतानुसार तालिका बनाता है:

weblogs.20120301
weblogs.20120302
weblogs.20120303

आदि।

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

आपके द्वारा प्रस्तुत किए गए परिदृश्य में आप वैसे भी किसी संरचना में बंद हैं, तो इस उद्देश्य के लिए किसी एकल तालिका का उपयोग क्यों न करें? पंक्तियों का एल्गोरिथ्म आधारित भंडारण स्केच और त्रुटि प्रवण लगता है।

— randomx
स्रोत

0

यदि कोई क्वेरी भारी डेटा को लक्षित करती है, तो क्वेरी शर्तों द्वारा डेटा का विभाजन प्रदर्शन का एक उल्लेखनीय सुधार होगा। लेकिन ऐसा विभाजन, जैसा कि आपने देखा है, कुछ प्रोग्रामिंग मुद्दों को लाता है।

तो सवाल यह है कि क्या प्रदर्शन के लिए यह मूल्य अलग है, या यह प्रदर्शन को नुकसान पहुंचाता है?

यदि आपके पास एक लेन-देन है जिसे कई तालिकाओं पर कई पंक्तियों को लॉक करने की आवश्यकता है और इस पर समस्याएं हैं (उदाहरण के लिए, गतिरोध या लेन-देन टाइमआउट), तो आप उन्हें एकल तालिका में जोड़ सकते हैं और समस्याओं को सुधारने के लिए SQL को फिर से लिख सकते हैं।

जब मुझे लगता है कि क्या विभाजन तालिका के बारे में, मैं प्रदर्शन लाभ और प्रोग्रामिंग जटिलता के बीच व्यापार बंद पर विचार करता था।

आपकी स्थिति में, मौजूदा कोड के संशोधन से कोड को बनाए रखना आसान बनाने के लिए दीर्घकालिक समाधान हो सकता है। मैं मेटा-प्रोग्रामिंग की कोशिश करना चाहूँगा। उदाहरण के लिए, गतिशील रूप से SQL उत्पन्न करने के लिए StringTemplate का उपयोग करना । मुझे मेटा-प्रोग्रामिंग इंजन से एसक्यूएल उत्पन्न करना पसंद है यदि मौजूदा कोड का संशोधन बहुत कठिन है।

— माइक लू
स्रोत

0

जब आपको तालिका में फ़ाइलों को संग्रहीत करने की आवश्यकता होती है, तो इस मेटोडोलॉजी का उपयोग निर्यात, मरम्मत और बहाल करने में मदद करता है।

मेरे पास 10 तालिकाओं में विभाजित> 30 जीबी वाले टेबल हैं। इन तालिकाओं में केवल ID - BLOB और मेरे पास रखने के लिए आसानी से है। और मैं INNODB बफर को बचाने के लिए MyISAM का उपयोग करता हूं।

— मार्सेलो बस
स्रोत