क्या बड़ी (100 मिलियन +) तालिका के लिए 5+ कॉलम प्राथमिक कुंजी खराब है?


12

मैं कुछ वास्तविक जीवन DB मुद्दों के बारे में पढ़ रहा था, और एक परियोजना में 100 मिलियन पंक्ति प्लस तालिका थी जिसमें इसके प्राथमिक रूप में 5 कॉलम थे। मैं सोच रहा हूं कि यह बुरा है, लेकिन क्या कोई मुझे बता सकता है कि आखिर क्यों?

तालिका एक माइक्रो रोलअप / एकत्रीकरण तालिका की तरह थी, इसलिए 5 कॉलम जैसे थे (दिन, market_id, product_id ...)। पहले मैंने सोचा था कि एक 5 कॉलम प्राथमिक कुंजी आदर्श नहीं थी, लेकिन जितना मैंने सोचा था, मैं वास्तव में एक अच्छे कारण के साथ नहीं आ सका क्योंकि यह खराब था।

यह कंपनी के आधे इंजीनियरों के साथ देर रात चर्चा में था। किसी ने सिर्फ यह उल्लेख किया कि यह एक बुरा डिज़ाइन था, एक वरिष्ठ इंजीनियर सहमत था, लेकिन कोई भी वास्तव में क्यों कूदता है। इस प्रकार अपने लिए मामले पर शोध करने की कोशिश की जा रही है!


आदर्श रूप से, आप चाहते हैं कि पीके अपेक्षाकृत छोटा हो - कम मेमोरी ओवरहेड। 5 कॉलम पीके के साथ, यह स्वचालित रूप से कम से कम लगभग होने वाला है। 5 INT - जब 1 INT (auto_increment) इसके बजाय कर सकता है।
वेरेस

जवाबों:


9

बहुत जटिल प्राथमिक कुंजी के साथ प्रदर्शन के मुद्दे हैं। और यह नकल के खिलाफ और साथ ही एक सरल प्राथमिक कुंजी का बचाव नहीं हो सकता है।

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

कुछ रिपोर्टिंग डेटाबेस स्टार स्कीमा के पैटर्न की नकल करते हैं भले ही यह स्पष्ट रूप से उस तरह से डिज़ाइन नहीं किया गया हो।

एक तथ्य तालिका के लिए 100 मिलियन + पंक्तियां अधिक बड़ी नहीं हैं, खासकर आज के बड़े आंकड़ों के साथ।


2

विचाराधीन तालिका एक रोलअप / एकत्रीकरण तालिका थी।

तब यह न केवल ठीक है, यह "सही" है।

और यह एक सारांश तालिका की तरह बदबू आ रही है, क्योंकि यह इसके साथ शुरू होती है day

क्या आपके पास कुछ माध्यमिक सूचकांक हैं? ध्यान रखें कि यदि आप InnoDB का उपयोग कर रहे हैं, तो बाकी प्राथमिक कुंजी कॉलम द्वितीयक सूचकांक के अंत में निपटाए जाएंगे। फिर, यह एक समस्या नहीं है।

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

या हो सकता है (सप्ताह, ए, बी, सी, डी) पर स्विच करें, शायद केवल 14M पंक्तियों के लिए अग्रणी। (शायद अधिक।)

विभाजन की सुविधा के लिए विभाजन का उपयोग --- उच्च गति अंतर्ग्रहण --- डेटा वेयरहाउस टिप्स --- सारांश सारणी । ये कई तकनीकें हैं जो मैंने कई DW परियोजनाओं में विकसित की हैं। जैसा कि आप अनुमान लगा सकते हैं, प्रत्येक परियोजना अलग है। सारांश सारणी की 'विशिष्ट' संख्या (मेरे अनुभव में) 3-7 है। सारांश में लक्ष्य 10 तथ्य पंक्तियाँ हैं -> 1 सारांश पंक्ति। (यह एक 'मंझला' हो सकता है।) एक दुर्लभ मामले में, मैंने सारांश तालिका को संक्षेप में प्रस्तुत किया। एक अन्य दुर्लभ मामले में, मैंने अच्छे प्रभाव के लिए एक सारांश तालिका का विभाजन किया; आमतौर पर सारांश सारणी काफी छोटी होती हैं, इसलिए वे UI से सीधी पहुँच के लिए पर्याप्त तेज़ होती हैं।


1

खैर, वास्तव में 5+ कॉलम के साथ पीके होना अपने आप में बुरा नहीं है।

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

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

प्रदर्शन-वार यह बुरा होगा जब पीके को एक इंडेक्स के रूप में उपयोग किया जाता है - इसे केवल टेबल के भीतर या एफके के साथ संयोजन के रूप में रहने दें - एक बड़ी पीके-कुंजी के साथ जिसमें 5+ कॉलम अधिक स्थान लेगा, इस प्रकार कम प्रविष्टियां होंगी एक पृष्ठ के भीतर फिट और इसलिए सूचकांक का विश्लेषण करने के लिए और अधिक पृष्ठों को पढ़ने की आवश्यकता है।

कहा कि - वास्तव में ऐसा करने के लिए हमेशा एक अच्छा कारण हो सकता है, जैसे कि एक तथ्य तालिका। इसलिए सबसे अच्छा जवाब वास्तव में ज्यादातर मामलों में होगा: यह निर्भर करता है!

सादर डेनिस


-2

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

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

इसलिए संक्षिप्त सारांश, सिनेटिक प्राथमिक कुंजी (ऑटो इंक्रीमेंट, गाइड, ..) बनाए रखने के लिए सरल है, प्रतिलिपि, ...

इसलिए मैं आपके द्वारा उल्लिखित 5 कॉलमों के लिए सिंटैटिक प्राथमिक कुंजी और एक अन्य कुंजी पर विचार करता हूं।

अंत में, यदि तालिका केवल समुच्चय है, और कभी भी किसी को कुंजी द्वारा पंक्ति को संदर्भित करने की आवश्यकता नहीं होगी (लेकिन दुनिया बदलती है, मुझ पर विश्वास करो, कम से कम मेरे लिए यह स्थायी रूप से बदल जाएगा), मैं शायद इसे ऐसे ही छोड़ दूंगा (प्राथमिक पाँच पंक्तियों के साथ कुंजी), लेकिन अगर हमारे पास होता था, तो इससे बहुत परेशानी होती है। तो मैंने आपको बताया।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.