मैंने सुना है कि MySQL या PostgreSQL जैसे नॉन-शार्प्ड रिलेशनल डेटाबेस का प्रदर्शन 10 टीबी से आगे "टूटता" है।
मुझे संदेह है कि इस तरह की सीमाएं मौजूद हैं क्योंकि कोई भी नेट्ज़्ज़ा, ग्रीनप्लम, या वर्टिका, आदि के साथ नहीं आएगा, हालांकि मैं पूछना चाहता हूं कि क्या यहां किसी के पास किसी शोध पत्र या औपचारिक मामले के अध्ययन का संदर्भ है जहां ये सीमाएं निर्धारित हैं।
जवाबों:
आपके प्रश्न का कोई सरल उत्तर नहीं है, लेकिन यहां कुछ बातें सोचने के लिए हैं।
सबसे पहले, स्केल केवल चिंता करने की बात नहीं है। आप अपने डेटा के साथ क्या करते हैं। यदि आपके पास 500 टेबल 30 टीबी डेटा है, और आप बहुत कम रिपोर्टिंग के साथ सरल ओएलटीपी कर रहे हैं, तो मुझे नहीं लगता कि आपको बहुत अधिक समस्याएं होंगी। वहाँ बाहर PostgreSQL पर 32TB डेटाबेस हैं। हालांकि, एक ही समय में प्रदर्शन कुछ हद तक कम हो जाएगा क्योंकि यह सब पर डिस्क को हिट करने के लिए है। इसी तरह अगर आपके पास 50TB है अगर डेटा लेकिन आमतौर पर लगभग 100GB का हिट सेट है, तो आप मेमोरी में db के उस हिस्से को रखने के लिए पर्याप्त RAM वाला सर्वर बना सकते हैं और आप सुनहरे हैं।
दूसरी ओर यदि आप 1TB डेटा में से मोड (सबसे सामान्य मूल्य) लेने की कोशिश कर रहे हैं, तो इससे कोई फर्क नहीं पड़ता कि आप किस सिस्टम का उपयोग कर रहे हैं, यह शार्पिंग के साथ या इसके बिना दर्दनाक होने वाला है । (संपादित करें: साझा करना, वास्तव में, इस समस्या को बदतर बना सकता है। )
MySQL और PostgreSQL पर विशाल db के साथ चलने वाली प्रमुख समस्याएं इस तथ्य को शामिल करती हैं कि न तो अंतर समानता का समर्थन करता है। दूसरे शब्दों में एक क्वेरी को एक सिंगल थ्रेड द्वारा सिंगल ब्लॉक के रूप में चलाया जाता है, और इसे टुकड़ों में नहीं तोड़ा जा सकता है और अलग से चलाया जा सकता है। बड़ी मात्रा में डेटा पर बड़े विश्लेषणात्मक प्रश्नों को चलाने के दौरान यह अक्सर एक मुद्दा होता है। यह वह जगह है जहां पोस्टग्रेज-एक्ससी और ग्रीन प्लम बचाव में आते हैं क्योंकि वे निष्पादन से अलग भंडारण करते हैं, और समन्वयक स्तर पर ऐसा कर सकते हैं। ध्यान दें कि Postgres-XC और ग्रीन प्लम अनिवार्य रूप से आंतरिक रूप से पैनापन का उपयोग करते हैं, लेकिन समन्वयक वैश्विक रूप से सभी स्थिरता को लागू करते हैं।
इंट्राक्वेरी समानता के साथ आप क्वेरी को तोड़ सकते हैं, अलग-अलग प्रोसेसर / डिस्क I / O चैनल इसके कुछ हिस्सों को चलाते हैं, और परिणाम के टुकड़ों को इकट्ठा करने के लिए सेट कर दिया जाता है और आवेदन पर वापस भेज दिया जाता है। फिर, यह आमतौर पर लेनदेन प्रसंस्करण भार के बजाय विश्लेषणात्मक में सबसे अधिक सहायक होता है।
दूसरी बात यह है कि कुछ प्रणालियाँ, जैसे कि वर्टिका या ग्रीनप्लम सूचनाओं के स्तंभों को एक साथ संग्रहीत करती हैं। यह सिस्टम को ओएलटीपी के नजरिए से उपयोग करने के लिए कठिन बनाता है और वहां प्रदर्शन को कम करता है, लेकिन यह बड़े विश्लेषणात्मक भार को बढ़ाता है। तो यह एक वर्कलोड-विशिष्ट ट्रेडऑफ़ है।
तो इसका उत्तर यह है कि एक बार जब आप 1-2 टीबी से ऊपर हो जाते हैं तो आप अपने आप को सिस्टम और वर्कलोड के बीच कई ट्रेडऑफ के साथ सामना कर सकते हैं। फिर से यह डेटाबेस, वर्किंग सेट के आकार आदि के लिए विशिष्ट है, हालांकि इस बिंदु पर आपको वास्तव में स्नोफ्लेक सिस्टम के साथ जाना होगा, अर्थात अद्वितीय और आपके कार्यभार के अनुरूप।
यह निश्चित रूप से इसका मतलब है कि सीमाएं आमतौर पर मात्रात्मक नहीं हैं।
संपादित करें : मैंने अब 9TB डेटाबेस के साथ काम किया है, जो पोस्टग्रेक्यूएल में निर्णय समर्थन और लेनदेन प्रसंस्करण कार्यभार के मिश्रण को संभालता है। सबसे बड़ी चुनौती यह है कि यदि आपके पास ऐसे प्रश्न हैं जो डेटा सेट के बड़े हिस्से से टकराते हैं, तो आपको उत्तर के लिए थोड़ी प्रतीक्षा करनी होगी।
हालाँकि बुनियादी बातों पर ध्यान देने के साथ (अनुक्रमणिका, ऑटोवैक्युम सहित, ये निम्न स्तर पर कैसे काम करते हैं, आदि) और पर्याप्त कंप्यूटिंग संसाधन, ये पूरी तरह से प्रबंधनीय हैं (और मेरा अनुमान है कि Pg में 30TB रेंज में अच्छी तरह से प्रबंधनीय होगा)।
Edit2 : एक बार जब आप 100TB पर पहुंच जाते हैं, तो क्या काम आपके डेटा सेट पर निर्भर करेगा। मैं अभी एक सीमा पर काम कर रहा हूं जो इस सीमा में नहीं बढ़ेगा क्योंकि यह पहले PostgreSQL में 32TB प्रति तालिका सीमा से टकराएगा।