मैंने एक बार एक बहुत बड़े (टेराबाइट+) MySQL डेटाबेस के साथ काम किया था। हमारे पास जो सबसे बड़ी मेज थी वह सचमुच एक अरब पंक्तियों से अधिक थी।
वो कर गया काम. MySQL ने ज्यादातर समय डेटा को सही तरीके से प्रोसेस किया। हालांकि यह बेहद बोझिल था।
बस डेटा का बैकअप लेना और स्टोर करना एक चुनौती थी। यदि आवश्यक हो तो तालिका को पुनर्स्थापित करने में कुछ दिन लगेंगे।
10-100 मिलियन पंक्ति श्रेणी में हमारे पास कई तालिकाएँ थीं। तालिकाओं में कोई भी महत्वपूर्ण जुड़ाव बहुत समय लेने वाला था और हमेशा के लिए ले जाएगा। इसलिए हमने तालिकाओं को 'चलने' के लिए संग्रहीत कार्यविधियाँ लिखीं और प्रक्रिया 'आईडी' की श्रेणियों के विरुद्ध जुड़ती है। इस तरह हम डेटा को एक बार में 10-100,000 पंक्तियों को संसाधित करेंगे (आईडी के 1-100,000 के विरुद्ध फिर 100,001-200,000, आदि से जुड़ें)। यह पूरी तालिका में शामिल होने की तुलना में काफी तेज था।
प्राथमिक कुंजी पर आधारित बहुत बड़ी तालिकाओं पर अनुक्रमणिका का उपयोग करना भी अधिक कठिन है। मैसकल इंडेक्स को दो टुकड़ों में स्टोर करता है - यह इंडेक्स (प्राथमिक इंडेक्स के अलावा) को इंडेक्स के रूप में प्राइमरी की वैल्यू में स्टोर करता है। तो अनुक्रमित लुकअप दो भागों में किया जाता है:पहला MySQL एक इंडेक्स में जाता है और उसमें से प्राथमिक कुंजी मानों को खींचता है जिन्हें इसे खोजने की आवश्यकता होती है, फिर यह प्राथमिक कुंजी इंडेक्स पर दूसरा लुकअप करता है ताकि यह पता लगाया जा सके कि वे मान कहां हैं।
इसका जाल यह है कि बहुत बड़ी तालिकाओं (1-200 मिलियन से अधिक पंक्तियों) के लिए तालिकाओं के विरुद्ध अनुक्रमण अधिक प्रतिबंधात्मक है। आपको कम, सरल अनुक्रमणिका की आवश्यकता है। और यहां तक कि सरल चयन कथन जो सीधे किसी इंडेक्स पर नहीं हैं, वे कभी भी वापस नहीं आ सकते हैं। जहां खंड जरूरी अनुक्रमित करें या इसके बारे में भूल जाएं।
लेकिन यह सब कहा जा रहा है, चीजें वास्तव में काम करती हैं। हम इन बहुत बड़ी तालिकाओं के साथ MySQL का उपयोग करने और गणना करने और सही उत्तर प्राप्त करने में सक्षम थे।
