-
क्या MySQL यथोचित रूप से अरबों पंक्तियों पर प्रश्न कर सकता है? - MySQL अरबों पंक्तियों को 'हैंडल' कर सकता है। "यथोचित" प्रश्नों पर निर्भर करता है; आइए उन्हें देखते हैं।
-
क्या InnoDB (MySQL 5.5.8) बहु-अरब पंक्तियों के लिए सही विकल्प है? -- 5.7 में कुछ सुधार हैं, लेकिन 5.5 काफी अच्छा है, <स्ट्राइक>करीब 6 होने के बावजूद 8 साल का, और <स्ट्राइक>के कगार पर अब समर्थित नहीं है।
-
अरबों पंक्तियों के लिए सर्वश्रेष्ठ डेटा स्टोर -- यदि आपका मतलब 'इंजन' से है, तो InnoDB।
-
प्रदर्शन शुरू होने से पहले एक MySQL डेटाबेस कितना बड़ा हो सकता है - फिर, यह प्रश्नों पर निर्भर करता है। मैं आपको एक 1K पंक्ति तालिका दिखा सकता हूँ जो पिघल जाएगी; मैंने अरबों-पंक्ति तालिकाओं के साथ काम किया है जो साथ-साथ चलती हैं।
-
MySQL बड़ी तालिकाओं के साथ धीमा क्यों हो सकता है? -- रेंज स्कैन I/O की ओर ले जाता है, जो कि धीमा हिस्सा है।
-
क्या मैसकल उन तालिकाओं को संभाल सकता है जिनमें लगभग 300 मिलियन रिकॉर्ड होंगे? - फिर, हाँ। सीमा कहीं न कहीं एक खरब पंक्तियों के आसपास है।
-
(InnoDB तालिकाओं के लिए जो मेरा मामला है) innodb_buffer_pool_size (जैसे, 80% तक RAM) बढ़ाना। इसके अलावा, मुझे यहाँ Percona ब्लॉग में कुछ अन्य MySQL प्रदर्शन ट्यूनिंग सेटिंग्स मिलीं - हाँ
-
मेज पर उचित अनुक्रमणिका (प्रश्नों पर EXPLAIN का उपयोग करके) -- ठीक है, आइए उन्हें देखते हैं। इस गंभीर . में बहुत सी गलतियां की जा सकती हैं क्षेत्र।
-
तालिका का विभाजन -- "विभाजन रामबाण नहीं है!" मैं उस पर मेरे ब्लॉग में वीणा देता हूं
-
MySQL शेयरिंग -- वर्तमान में यह DIY है
-
MySQL क्लस्टरिंग - वर्तमान में सबसे अच्छा उत्तर कुछ गैलेरा-आधारित विकल्प (पीएक्ससी, मारियाडीबी 10, DIY डब्ल्यू/ओरेकल) है। Oracle का "समूह प्रतिकृति" एक व्यवहार्य दावेदार है।
-
विभाजन
FOREIGN KEYका समर्थन नहीं करता या "वैश्विक"UNIQUE। -
यूयूआईडी, जिस पैमाने की आप बात कर रहे हैं, वह न केवल सिस्टम को धीमा करेगा, बल्कि वास्तव में इसे खत्म कर देगा। टाइप 1 UUIDs एक समाधान हो सकता है।
-
सम्मिलित करें और अनुक्रमणिका-निर्माण गति -- एक उत्तर देने के लिए बहुत अधिक विविधताएँ हैं। आइए देखते हैं आपका संभावित
CREATE TABLEऔर आप किस तरह से डेटा को फीड करने का इरादा रखते हैं। -
बहुत सारे जुड़ते हैं - "सामान्य करें, लेकिन अति-सामान्यीकृत न करें।" विशेष रूप से, डेटाटाइम्स या फ्लोट्स या अन्य "निरंतर" मानों को सामान्य न करें।
-
प्रति दिन 2,3 मिलियन लेनदेन -- यदि वह 2.3M सम्मिलित . है (30/सेकंड), तो प्रदर्शन की कोई समस्या नहीं है। यदि अधिक जटिल है, तो RAID, SSD, बैचिंग, आदि आवश्यक हो सकते हैं।
-
डेटा की इस तरह की मात्रा से निपटें - यदि अधिकांश गतिविधि "हाल की" पंक्तियों के साथ है, तो बफ़र_पूल गतिविधि को अच्छी तरह से 'कैश' करेगा, जिससे I/O से बचा जा सकेगा। यदि गतिविधि "यादृच्छिक" है, तो MySQL (या कोई भी अन्य) में I/O समस्याएँ होंगी।
-
डेटाटाइप को सिकोड़ने से आपकी जैसी तालिका में मदद मिलती है। मुझे संदेह है कि अगर आपको
fuel_typeनिर्दिष्ट करने के लिए 4 बाइट्स की आवश्यकता है . कई 1-बाइट दृष्टिकोण हैं।
