MySQL में 300 मिलियन रिकॉर्ड्स के भौतिक विलोपन की कहानी

परिचय

नमस्ते। मैं ningenMe, वेब डेवलपर हूं।

जैसा कि शीर्षक में कहा गया है, मेरी कहानी MySQL में 300 मिलियन रिकॉर्ड को भौतिक रूप से हटाने की कहानी है।

मुझे इसमें दिलचस्पी हो गई, इसलिए मैंने एक अनुस्मारक (निर्देश) बनाने का फैसला किया।

होम - चेतावनी

मैं जिस बैच सर्वर का उपयोग और रखरखाव करता हूं, उसकी एक नियमित प्रक्रिया है जो पिछले महीने का डेटा MySQL से दिन में एक बार एकत्र करती है।

आमतौर पर यह प्रक्रिया लगभग 1 घंटे के भीतर पूरी हो जाती है, लेकिन इस बार यह 7 या 8 घंटे तक पूरी नहीं हुई और अलर्ट आना बंद नहीं हुआ...

कारण ढूँढना

मैंने प्रक्रिया को पुनः आरंभ करने और लॉग देखने का प्रयास किया, लेकिन मुझे कुछ भी गलत नहीं दिखा।
क्वेरी सही ढंग से अनुक्रमित की गई थी. लेकिन जब मैंने सोचा कि क्या गलत हो रहा है, तो मुझे एहसास हुआ कि डेटाबेस का आकार काफी बड़ा है।

hoge_table | 350'000'000 |

350 मिलियन रिकॉर्ड. ऐसा लग रहा था कि अनुक्रमण सही ढंग से काम कर रहा है, बस बहुत धीमी गति से।

प्रति माह आवश्यक डेटा संग्रह लगभग 12 रिकॉर्ड था। ऐसा लगता है कि चयन आदेश में काफी समय लग गया और लेनदेन लंबे समय तक निष्पादित नहीं हुआ।

DB

यह मूलतः एक तालिका है जिसमें प्रतिदिन लगभग 400 प्रविष्टियाँ बढ़ती हैं। डेटाबेस को केवल पिछले महीने के लिए डेटा एकत्र करना था, इसलिए, यह उम्मीद की गई थी कि यह डेटा की इतनी मात्रा का सामना करेगा, लेकिन, दुर्भाग्य से, रोटेट ऑपरेशन शामिल नहीं था।

यह डेटाबेस मेरे द्वारा विकसित नहीं किया गया था. मैंने इसे किसी अन्य डेवलपर से ले लिया, इसलिए यह अभी भी तकनीकी ऋण जैसा महसूस हुआ।

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

और फिर मैं हरकत में आया.

सुधार

तर्क को बदलने की तुलना में डेटाबेस के आकार को कम करना और इसे संसाधित करने के समय को कम करना अधिक तर्कसंगत था।

यदि आप 300 मिलियन रिकॉर्ड मिटा देते हैं तो स्थिति में उल्लेखनीय बदलाव आना चाहिए, इसलिए मैंने ऐसा करने का निर्णय लिया... एह, मैंने सोचा कि यह निश्चित रूप से काम करेगा।

क्रिया 1

एक विश्वसनीय बैकअप तैयार करने के बाद, मैंने अंततः अनुरोध भेजना शुरू कर दिया।

「अनुरोध भेजा जा रहा है」

DELETE FROM hoge_table WHERE create_time <= 'YYYY-MM-DD HH:MM:SS';

「...」

「...」

“हम्म… कोई जवाब नहीं. हो सकता है कि इस प्रक्रिया में लंबा समय लगे?” - मैंने सोचा, लेकिन बस मामले में, मैंने ग्राफाना को देखा और देखा कि डिस्क लोड बहुत तेज़ी से बढ़ रहा था।
"खतरनाक," मैंने फिर सोचा और तुरंत अनुरोध रोक दिया।

क्रिया 2

हर चीज़ का विश्लेषण करने के बाद, मुझे एहसास हुआ कि डेटा की मात्रा एक बार में सब कुछ हटाने के लिए बहुत बड़ी थी।

मैंने एक ऐसी स्क्रिप्ट लिखने का निर्णय लिया जो लगभग 1 रिकॉर्ड हटा सके और इसे लॉन्च किया।

「मैं स्क्रिप्ट लागू करता हूं」

"अब यह निश्चित रूप से काम करेगा," मैंने सोचा।

क्रिया 3

दूसरी विधि काम कर गई, लेकिन बहुत श्रम-गहन निकली।
अनावश्यक घबराहट के बिना, सब कुछ सावधानी से करने में लगभग दो सप्ताह लगेंगे। लेकिन फिर भी, यह परिदृश्य सेवा आवश्यकताओं को पूरा नहीं करता था, इसलिए हमें इससे दूर जाना पड़ा।

तो यहाँ मैंने क्या करने का निर्णय लिया है:

तालिका की प्रतिलिपि बनाएँ और उसका नाम बदलें

पिछले चरण से, मुझे एहसास हुआ कि इतनी बड़ी मात्रा में डेटा हटाने से उतना ही बड़ा भार पैदा होता है। इसलिए मैंने इन्सर्ट का उपयोग करके स्क्रैच से एक नई तालिका बनाने और उस डेटा को स्थानांतरित करने का निर्णय लिया जिसे मैं हटाने जा रहा था।

| hoge_table     | 350'000'000|
| tmp_hoge_table |  50'000'000|

यदि आप नई तालिका को उपरोक्त आकार के समान बनाते हैं, तो डेटा प्रोसेसिंग गति भी 1/7 तेज हो जानी चाहिए।

तालिका बनाने और उसका नाम बदलने के बाद, मैंने इसे मास्टर तालिका के रूप में उपयोग करना शुरू कर दिया। अब अगर मैं 300 मिलियन रिकॉर्ड वाली तालिका छोड़ दूं तो सब कुछ ठीक हो जाना चाहिए।
मुझे पता चला कि ट्रंकेट या ड्रॉप डिलीट की तुलना में कम ओवरहेड बनाता है और इस पद्धति का उपयोग करने का निर्णय लिया।

क्रियान्वयन

「अनुरोध भेजा जा रहा है」

INSERT INTO tmp_hoge_table SELECT FROM hoge_table create_time > 'YYYY-MM-DD HH:MM:SS';

「...」
「...」
"उन्हें...?"

क्रिया 4

मैंने सोचा था कि पिछला विचार काम करेगा, लेकिन सम्मिलित अनुरोध भेजने के बाद, कई त्रुटियाँ सामने आईं। MySQL क्षमाशील नहीं है.

मैं पहले से ही इतना थक गया था कि मुझे लगने लगा कि मैं अब यह नहीं करना चाहता।

मैंने बैठकर सोचा और महसूस किया कि शायद एक बार के लिए बहुत अधिक सम्मिलित प्रश्न थे...
मैंने उस डेटा की मात्रा के लिए एक सम्मिलित अनुरोध भेजने का प्रयास किया जिसे डेटाबेस को 1 दिन में संसाधित करना चाहिए। घटित!

खैर, उसके बाद हम उतनी ही मात्रा में डेटा के लिए अनुरोध भेजना जारी रखते हैं। चूँकि हमें एक महीने का डेटा हटाने की आवश्यकता है, इसलिए हम इस ऑपरेशन को लगभग 35 बार दोहराते हैं।

किसी तालिका का नाम बदलना

यहाँ भाग्य मेरे साथ था: सब कुछ सुचारू रूप से चला गया।

अलर्ट गायब हो गया

बैच प्रोसेसिंग गति में वृद्धि हुई है.

पहले इस प्रक्रिया में लगभग एक घंटा लगता था, अब इसमें लगभग 2 मिनट लगते हैं।

जब मुझे यकीन हो गया कि सभी समस्याएं हल हो गई हैं, तो मैंने 300 मिलियन रिकॉर्ड हटा दिए। मैंने तालिका हटा दी और पुनर्जन्म महसूस किया।

सारांश

मुझे एहसास हुआ कि बैच प्रोसेसिंग में रोटेशन प्रोसेसिंग गायब थी, और यही मुख्य समस्या थी। इस प्रकार की वास्तु संबंधी त्रुटि से समय की बर्बादी होती है।

क्या आप डेटाबेस से रिकॉर्ड हटाते समय डेटा प्रतिकृति के दौरान लोड के बारे में सोचते हैं? आइए MySQL को ओवरलोड न करें।

जो लोग डेटाबेस के अच्छे जानकार हैं उन्हें निश्चित रूप से ऐसी समस्या का सामना नहीं करना पड़ेगा। आपमें से बाकी लोगों के लिए, मुझे आशा है कि यह लेख उपयोगी होगा।

पढ़ने के लिए धन्यवाद!

हमें बहुत खुशी होगी अगर आप हमें बताएं कि क्या आपको यह लेख पसंद आया, क्या अनुवाद स्पष्ट है, क्या यह आपके लिए उपयोगी था?

स्रोत: www.habr.com