mysql - बनाना पंक्तियों बनाम कॉलम को प्रदर्शन

Question

मैं एक एनालिटिक्स इंजन है कि मेरे डेटाबेस से कच्चे डेटा के 50-100 पंक्तियों खींचती बनाया (इसे कहते raw_table की सुविधा देता है), पीएचपी में इस पर एक गुच्छा सांख्यिकीय माप चलाता है और उसके बाद बिल्कुल के साथ आता है 140 डेटापॉइंट्स जिन्हें मुझे फिर किसी अन्य तालिका में स्टोर करने की आवश्यकता है (इसे results_table पर कॉल करें)। इन सभी डेटा बिंदुओं में बहुत छोटी चींटियां हैं ("40", "2.23", "- 1024" डेटा के प्रकार के अच्छे उदाहरण हैं)।

मुझे पता है कि mysql के लिए अधिकतम # कॉलम काफी ऊंचे हैं (4000+) लेकिन ऐसा लगता है कि जब तक प्रदर्शन वास्तव में खराब हो जाता है तब तक बहुत सारे ग्रे क्षेत्र होते हैं।

तो कुछ यहाँ सवाल सबसे अच्छा प्रदर्शन प्रथाओं पर:

1) 140 datapoints हो सकता है, अगर यह बेहतर है, एक ही 'experiment_id' कम कॉलम अगर साथ 7 डेटा सभी बिंदुओं के 20 पंक्तियों में टूट बेहतर है। फिर भी मुझे हमेशा सभी 20 पंक्तियों (प्रत्येक 7 कॉलम के साथ, प्लस आईडी, आदि) खींचने की आवश्यकता होगी, इसलिए मुझे नहीं लगता कि यह 140 कॉलम की 1 पंक्ति खींचने से बेहतर प्रदर्शन होगा। तो सवाल: क्या 7-9 कॉलम की 20 पंक्तियों को स्टोर करना बेहतर है (जिसे सभी को एक बार में खींचा जाना चाहिए) या 140-143 कॉलम की 1 पंक्ति?

2) मेरे डेटा उदाहरणों को देखते हुए ("40", "2.23", "- 1024" संग्रहित किए जाने वाले अच्छे उदाहरण हैं) मैं संरचना प्रकार के लिए smallint सोच रहा हूं। वहां कोई प्रतिक्रिया, प्रदर्शन-वार या अन्यथा?

3) mysql प्रदर्शन के मुद्दों या सुझावों पर कोई अन्य प्रतिक्रिया का स्वागत है।

आपके इनपुट के लिए अग्रिम धन्यवाद।

Answer 1

मुझे लगता है कि अधिक पंक्तियों (यानी सामान्यीकृत) के रूप में स्टोर करने का लाभ परिवर्तन के चेहरे में डिजाइन और रखरखाव के विचारों पर निर्भर करता है।

इसके अलावा, यदि 140 कॉलम का एक ही अर्थ है या यदि यह प्रति प्रयोग अलग है - सामान्यीकरण नियमों के अनुसार डेटा को सही तरीके से मॉडलिंग करना - यानी उम्मीदवार कुंजी से संबंधित डेटा कैसा है।

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

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

Answer 2

आप हर बार वापस जाने के लिए एक 140 डेटा आइटम, प्रकार पर दो में से प्रत्येक की है।

यह है कि क्या यह 1x140 या 20x7 या 7x20 या 4x35 आदि यह अतिसूक्ष्म तेज पाठ्यक्रम में से एक आकार के लिए हो सकता है, लेकिन फिर आप PHP कोड में अतिरिक्त जटिलता एक अलग से निपटने के लिए विचार किया है कोई व्यावहारिक फर्क नहीं पड़ता आकार।

आप एक सत्यापित टोंटी है, या यह सिर्फ यादृच्छिक समय से पहले अनुकूलन है?

Answer 3

आपने कोई सुझाव नहीं दिया है कि आप डेटाबेस में बड़े डेटा को स्टोर करना चाहते हैं, लेकिन इस तर्क के प्रयोजनों के लिए, मुझे लगता है कि आपके पास 1 अरब (10^9) डेटा पॉइंट हैं।

यदि आप उन्हें 140 कॉलम में संग्रहीत करते हैं, तो आपके पास केवल 7 मिलियन पंक्तियां होंगी, हालांकि, यदि आप कई प्रयोगों से एक डेटा पॉइंट पुनर्प्राप्त करना चाहते हैं, तो इसे बड़ी संख्या में बहुत व्यापक रूप से प्राप्त करना होगा पंक्तियों।

ये बहुत व्यापक पंक्तियों अपने innodb_buffer_pool में अधिक स्थान ले जाएगा, इसलिए आप इतने सारे कैश करने के लिए सक्षम नहीं होगा; जब आप उन्हें फिर से एक्सेस करेंगे तो यह संभावित रूप से आपको धीमा कर देगा।

यदि आप प्रति पंक्ति एक डेटापॉइंट स्टोर करते हैं, तो बहुत कम कॉलम (प्रयोग_आईडी, डेटापॉइंट_आईडी, वैल्यू) वाली तालिका में आपको छोटी पंक्तियों की संख्या को खींचने की आवश्यकता होगी।

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

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