MySQL मा 300 मिलियन रेकर्डहरूको भौतिक मेटाउने कथा

परिचय

नमस्ते। म ningenMe, वेब विकासकर्ता हुँ।

शीर्षकले भन्छ, मेरो कथा MySQL मा 300 मिलियन रेकर्डहरू भौतिक रूपमा मेटाउने कथा हो।

मलाई यसमा चासो भयो, त्यसैले मैले एउटा रिमाइन्डर (निर्देशन) बनाउने निर्णय गरें।

गृह - अलर्ट

मैले प्रयोग गर्ने र मर्मत गर्ने ब्याच सर्भरमा नियमित प्रक्रिया छ जसले MySQL बाट एक दिनमा एक पटक गत महिनाको डाटा सङ्कलन गर्छ।

सामान्यतया यो प्रक्रिया लगभग 1 घण्टा भित्र पूरा हुन्छ, तर यस पटक यो 7 वा 8 घण्टा सम्म पूरा भएन, र सतर्कता पप अप रोकिएन ...

कारण खोज्दै

मैले प्रक्रिया पुन: सुरु गर्न र लगहरू हेर्ने प्रयास गरें, तर मैले केहि गलत देखेको छैन।
क्वेरी सही रूपमा अनुक्रमित गरिएको थियो। तर जब मैले के गलत हुँदैछ भनेर सोचें, मैले महसुस गरें कि डाटाबेस साइज एकदम ठूलो छ।

hoge_table | 350'000'000 |

350 मिलियन रेकर्ड। अनुक्रमणिका सही रूपमा काम गरिरहेको जस्तो देखिन्थ्यो, केवल धेरै ढिलो।

प्रति महिना आवश्यक डाटा संग्रह लगभग 12 रेकर्ड थियो। यस्तो देखिन्छ कि चयन आदेशले लामो समय लियो र लेनदेन लामो समयसम्म कार्यान्वयन भएन।

DB

यो अनिवार्य रूपमा एक तालिका हो जुन हरेक दिन लगभग 400 प्रविष्टिहरू बढ्छ। डाटाबेसले गत महिनाको लागि मात्र डाटा सङ्कलन गर्नु पर्ने थियो, त्यसैले, यो अपेक्षा गरिएको थियो कि यसले ठ्याक्कै डाटाको यो मात्रालाई सामना गर्नेछ, तर, दुर्भाग्यवश, घुमाउने अपरेशन समावेश गरिएको थिएन।

यो डाटाबेस म द्वारा विकसित गरिएको छैन। मैले यसलाई अर्को विकासकर्ताबाट लिए, त्यसैले यो अझै पनि प्राविधिक ऋण जस्तो लाग्यो।

त्यहाँ एक बिन्दु आयो जब दैनिक सम्मिलित डाटाको मात्रा ठूलो भयो र अन्ततः यसको सीमामा पुग्यो। यो मानिन्छ कि डाटा को यति ठूलो मात्रा संग काम गर्दा, यो तिनीहरूलाई अलग गर्न आवश्यक हुनेछ, तर यो, दुर्भाग्यवश, गरिएन।

अनि म क्रियामा आएँ ।

सुधार

तर्क आफैं परिवर्तन गर्नु भन्दा डाटाबेसको आकार घटाउनु र यसलाई प्रशोधन गर्नको लागि समय कम गर्नु अधिक तर्कसंगत थियो।

यदि तपाईंले 300 मिलियन रेकर्डहरू मेटाउनुभयो भने स्थिति महत्त्वपूर्ण रूपमा परिवर्तन हुनुपर्दछ, त्यसैले मैले त्यसो गर्ने निर्णय गरे... एह, मैले सोचें कि यसले निश्चित रूपमा काम गर्नेछ।

कार्य १

भरपर्दो ब्याकअप तयार गरिसकेपछि, मैले अन्ततः अनुरोधहरू पठाउन थालें।

'अनुरोध पठाउँदै'

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

"…"

"…"

"हम्म... जवाफ छैन। सायद प्रक्रिया धेरै समय लाग्छ?" - मैले सोचें, तर केवल केसमा, मैले ग्राफानालाई हेरे र डिस्क लोड धेरै छिटो बढिरहेको देखे।
"खतरनाक," मैले फेरि सोचें र तुरुन्तै अनुरोध रोकें।

कार्य १

सबै कुराको विश्लेषण गरेपछि, मैले महसुस गरें कि डाटाको भोल्युम एकैचोटि सबै मेटाउन धेरै ठूलो थियो।

मैले लगभग 1 रेकर्डहरू मेटाउन सक्ने स्क्रिप्ट लेख्ने निर्णय गरें र यसलाई सुरू गरें।

'म स्क्रिप्ट कार्यान्वयन गर्छु'

"अब यो पक्कै काम गर्नेछ," मैले सोचें।

कार्य १

दोस्रो विधिले काम गर्यो, तर धेरै श्रम-गहन भयो।
सबै कुरा सावधानीपूर्वक गर्न, अनावश्यक तंत्रिका बिना, लगभग दुई हप्ता लाग्नेछ। तर अझै, यो परिदृश्यले सेवा आवश्यकताहरू पूरा गर्न सकेन, त्यसैले हामीले यसबाट टाढा जानुपर्‍यो।

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

तालिका प्रतिलिपि गर्नुहोस् र यसलाई पुन: नामाकरण गर्नुहोस्

अघिल्लो चरणबाट, मैले महसुस गरें कि यति ठूलो मात्रामा डाटा मेटाउँदा समान रूपमा ठूलो भार सिर्जना हुन्छ। त्यसोभए मैले इन्सर्ट प्रयोग गरेर स्क्र्याचबाट नयाँ तालिका सिर्जना गर्ने निर्णय गरें र म यसमा मेटाउन गइरहेको डाटा सार्न।

| 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';

"…"
"…"
"उम्...?"

कार्य १

मैले सोचे कि अघिल्लो विचारले काम गर्नेछ, तर सम्मिलित अनुरोध पठाए पछि, धेरै त्रुटिहरू देखा पर्यो। MySQL क्षमाशील छैन।

म पहिल्यै धेरै थाकेको थिएँ कि मैले सोच्न थाले कि म अब यो गर्न चाहन्न।

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

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

तालिका पुन: नामाकरण गर्दै

यहाँ भाग्य मेरो पक्षमा थियो: सबै कुरा सजिलै संग गयो।

अलर्ट हराएको छ

ब्याच प्रशोधन गति बढेको छ।

पहिले यो प्रक्रिया करिब एक घन्टा लाग्थ्यो, अहिले करिब २ मिनेट लाग्छ।

सबै समस्याहरू हल भइसकेका छन् भन्ने पक्का भएपछि मैले ३० करोड रेकर्डहरू छोडेँ। मैले टेबल हटाएँ र पुनर्जन्म महसुस गरें।

सारांश

मैले महसुस गरें कि ब्याच प्रशोधनमा रोटेशन प्रशोधन हराइरहेको थियो, र त्यो मुख्य समस्या थियो। यस प्रकारको वास्तु त्रुटिले समयको बर्बादी निम्त्याउँछ।

के तपाइँ डाटाबेसबाट रेकर्डहरू मेटाउँदा डाटा प्रतिकृतिको समयमा लोडको बारेमा सोच्नुहुन्छ? MySQL ओभरलोड नगरौं।

डाटाबेसमा राम्रोसँग जान्नेहरूले निश्चित रूपमा त्यस्तो समस्याको सामना गर्दैनन्। तपाईं बाँकी को लागी, मलाई आशा छ कि यो लेख उपयोगी थियो।

पढ्नु भएकोमा धन्यवाद!

यदि तपाइँ हामीलाई यो लेख मन पर्यो कि, अनुवाद स्पष्ट छ कि, यो तपाइँको लागि उपयोगी थियो कि भनेर बताउनुभयो भने हामी धेरै खुसी हुनेछौं?

स्रोत: www.habr.com