मैंने पिछली नौकरी में इस अवधारणा के साथ थोड़ा प्रयोग किया था, जहां हमें MySQL सर्वर के बीच स्कीमा की प्रतिलिपि बनाने की एक तेज़ विधि की आवश्यकता थी।
जब आप द्वितीयक अनुक्रमणिका वाली तालिकाओं में सम्मिलित करते हैं तो वास्तव में एक प्रदर्शन ओवरहेड होता है। इन्सर्ट को क्लस्टर्ड इंडेक्स (टेबल उर्फ) को अपडेट करना होगा, और सेकेंडरी इंडेक्स को भी अपडेट करना होगा। एक टेबल में जितने अधिक इंडेक्स होते हैं, वह इंसर्ट के लिए उतना ही अधिक ओवरहेड होता है।
InnoDB में बफ़र बदलें जो इंडेक्स अपडेट को स्थगित करके थोड़ी मदद करता है, लेकिन उन्हें अंततः विलय करना पड़ता है।
बिना किसी द्वितीयक अनुक्रमणिका वाली तालिका में सम्मिलित करना तेज़ होता है, इसलिए जैसा कि आप वर्णन करते हैं, आपका डेटा लोड होने तक अनुक्रमणिका निर्माण को स्थगित करने का प्रयास करना आकर्षक है।
पेरकोना सर्वर, MySQL की एक शाखा, ने एक mysqldump --optimize-keys के साथ प्रयोग किया। विकल्प। जब आप इस विकल्प का उपयोग करते हैं, तो यह mysqldump के आउटपुट को बिना किसी इंडेक्स के टेबल बनाने के लिए बदल देता है, फिर सभी डेटा डालें, फिर डेटा लोड होने के बाद इंडेक्स जोड़ने के लिए टेबल को बदलें। देखें https://www.percona.com/doc/ percona-server/LATEST/management/innodb_expanded_fast_index_creation.html
लेकिन मेरे अनुभव में, प्रदर्शन में शुद्ध सुधार छोटा था। बिना अनुक्रमणिका वाली तालिकाओं के लिए भी, बहुत सारी पंक्तियाँ सम्मिलित करने में अभी भी कुछ समय लगता है। फिर पुनर्स्थापना को अनुक्रमणिका बनाने के लिए ALTER TABLE चलाने की आवश्यकता होती है। एक बड़ी मेज के लिए इसमें कुछ समय लगता है। जब आप INSERTs के समय और अनुक्रमणिका बनाने के लिए अतिरिक्त समय की गणना करते हैं, तो यह अनुक्रमणिका वाली तालिका में पारंपरिक तरीके से सम्मिलित करने की तुलना में केवल कुछ (कम एकल-अंक) प्रतिशत तेज़ होता है।
इस पोस्ट-प्रोसेसिंग इंडेक्स निर्माण का एक अन्य लाभ यह है कि इंडेक्स अधिक कॉम्पैक्ट रूप से संग्रहीत होते हैं, इसलिए यदि आपको डिस्क स्थान बचाने की आवश्यकता है, तो यह इस तकनीक का उपयोग करने का एक बेहतर कारण है।
मैंने समानांतर में कई तालिकाओं को लोड करके . को पुनर्स्थापित करने के लिए प्रदर्शन के लिए इसे और अधिक फायदेमंद पाया .
- नया MySQL 8.0 टूल mysqlpump बहु-थ्रेडेड डंप का समर्थन करता है।
- ओपन-सोर्स टूल mydumper
बहु-थ्रेडेड डंप का समर्थन करता है, और इसमें एक बहु-थ्रेडेड पुनर्स्थापना उपकरण भी है, जिसे
myloaderकहा जाता है . mydumper/myloader का सबसे बुरा पहलू यह है कि दस्तावेज़ीकरण वस्तुतः अस्तित्वहीन है, इसलिए इसे चलाने का तरीका जानने के लिए आपको एक निडर शक्ति उपयोगकर्ता होने की आवश्यकता है।
एक अन्य रणनीति mysqldump --tab . का उपयोग करना है SQL स्क्रिप्ट के बजाय CSV फ़ाइलों को डंप करने के लिए। डेटा को पुनर्स्थापित करने के लिए SQL स्क्रिप्ट निष्पादित करने की तुलना में बल्क-लोडिंग CSV फ़ाइलें बहुत तेज़ हैं। खैर, यह तालिका परिभाषा के लिए एक SQL फ़ाइल और डेटा आयात करने के लिए एक CSV को डंप करता है। यह प्रत्येक तालिका के लिए अलग-अलग फाइलें बनाता है। आपको सभी SQL फ़ाइलों को लोड करके तालिकाओं को मैन्युअल रूप से फिर से बनाना होगा (यह त्वरित है), और फिर mysqlimport
CSV डेटा फ़ाइलों को लोड करने के लिए। Mysqlimport टूल में एक --use-threads . भी है समानांतर निष्पादन के लिए विकल्प।
समानांतर धागों की विभिन्न संख्याओं के साथ सावधानीपूर्वक परीक्षण करें। मेरा अनुभव है कि 4 धागे सबसे अच्छे हैं। अधिक समानता के साथ, InnoDB एक अड़चन बन जाता है। लेकिन आपका अनुभव MySQL के संस्करण और आपके सर्वर हार्डवेयर की प्रदर्शन क्षमता के आधार पर भिन्न हो सकता है।
जब आप किसी भौतिक बैकअप टूल का उपयोग करते हैं तो सबसे तेज़ पुनर्स्थापना विधि है, सबसे लोकप्रिय है पेरकोना एक्स्ट्राबैकअप . यह तेजी से बैकअप और यहां तक कि तेजी से पुनर्स्थापित करने की अनुमति देता है। बैकअप की गई फ़ाइलें सचमुच जगह में कॉपी करने के लिए तैयार हैं और लाइव टेबलस्पेस फ़ाइलों के रूप में उपयोग की जाती हैं। नकारात्मक पक्ष यह है कि पुनर्स्थापना करने के लिए आपको अपने MySQL सर्वर को बंद करना होगा।
