एक MySQL अनुकूलन का इतिहास

यह MySQL डेटाबेस में अनुकूलन के बारे में होगा।

यह तब हुआ जब हमने ईमेल न्यूज़लेटर्स के लिए एक सिस्टम बनाया। हमारी प्रणाली को एक दिन में दसियों लाख पत्र भेजने थे। एक पत्र भेजना एक आसान काम नहीं है, हालांकि सब कुछ बहुत सुंदर दिखता है:

1. HTML रचनात्मक से एक पत्र ले लीजिए, व्यक्तिगत डेटा स्थानापन्न करें।
2. संदेश देखने वाला पिक्सेल जोड़ें, क्लिक के ट्रैक करने के लिए संदेश के सभी लिंक को अपने साथ बदलें -।
3. यह भेजने से पहले जांचें कि ईमेल काली सूची में नहीं है।
4. किसी विशिष्ट पूल को एक ईमेल भेजें।

मैं आपको दूसरे पैराग्राफ के बारे में अधिक बताऊंगा:
Microservice मेल-बिल्डर भेजने के लिए एक पत्र तैयार कर रहा है:

• पत्र में सभी लिंक पाता है;
• प्रत्येक लिंक के लिए एक अद्वितीय 32-वर्ण uuid उत्पन्न होता है;
• मूल लिंक को एक नए के साथ बदल देता है और डेटाबेस में डेटा को बचाता है।

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

समस्या नंबर 1

हम में पीढ़ी की पीढ़ी टाइमस्टैम्प पर निर्भर थी।

चूंकि मेलिंग आमतौर पर एक निश्चित अवधि में होती है और एक पत्र को असेंबल करने के लिए माइक्रो सर्विस के कई उदाहरण लॉन्च किए जाते हैं, यह पता चला है कि कुछ uuids बहुत समान थे। इसने कम चयनात्मकता दी। यूपीडी: क्योंकि डेटा समान था, द्वि-वृक्ष के साथ काम करना बहुत प्रभावी नहीं था।

हमने इस समस्या को अजगर में uuid मॉड्यूल का उपयोग करके हल किया, जहां कोई समय निर्भरता नहीं है।
इस तरह की एक अंतर्निहित चीज ने अनुक्रमित की गति को कम कर दिया।

स्टोरेज कैसा चल रहा है?

तालिका की संरचना इस प्रकार थी:

CREATE TABLE IF NOT EXISTS `Messages` ( `UUID` varchar(32) NOT NULL, `Message` json NOT NULL, `Inserted` DATE NOT NULL, PRIMARY KEY (`UUID`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; 

निर्माण के समय, सब कुछ तार्किक लग रहा था:
UUID एक प्राथमिक कुंजी है, और एक क्लस्टर इंडेक्स भी है। जब हम इस क्षेत्र पर चयन करते हैं, तो हम केवल रिकॉर्ड का चयन करते हैं, क्योंकि सभी मान वहीं जमा होते हैं। यह एक जानबूझकर किया गया फैसला था। क्लस्टर इंडेक्स के बारे में अधिक जानें।

मेज के बढ़ने तक सब कुछ बहुत अच्छा था।

समस्या संख्या 2

यदि आप क्लस्टर इंडेक्स के बारे में अधिक पढ़ते हैं, तो आप इस बारीकियों के बारे में जान सकते हैं:

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

इस प्रकार, बढ़ते भार के साथ, सम्मिलन का समय बढ़ गया।

समाधान एक अलग तालिका संरचना का उपयोग करना था।

 CREATE TABLE IF NOT EXISTS `Messages` ( `ID` int(11) NOT NULL AUTO_INCREMENT, `UUID` varchar(32) NOT NULL, `Message` json NOT NULL, `Inserted` DATE NOT NULL, PRIMARY KEY (`ID`), UNIQUE KEY `UUID` (`UUID`, `Inserted`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; 

चूँकि प्राथमिक कुंजी अब ऑटो-इन्क्रिमेंटिंग है, और mysql पिछले सम्मिलन स्थान के कैश को संग्रहीत करता है, अब प्रविष्टि हमेशा अंत में होती है, अर्थात् इनोडब क्रमिक रूप से बढ़ते मूल्यों को लिखने के लिए अनुकूलित है।

मुझे इस अनुकूलन का विवरण पोस्टग्रेज सोर्स कोड में मिला। Mysql बहुत समान अनुकूलन लागू करता है।
बेशक, मुझे एक अनूठी कुंजी जोड़ना था ताकि कोई संघर्ष न हो, लेकिन हमने सम्मिलन की गति बढ़ा दी।

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

इसलिए, हमने अपनी तालिका को विभाजन में विभाजित करने का निर्णय लिया।
1 दिन - 1 विभाजन, समय आने पर पुराने अपने आप गिर जाते हैं।

समस्या संख्या 3

हमें पुराने डेटा को हटाने का अवसर मिला, लेकिन हमें वांछित विभाजन से चुनने का अवसर नहीं मिला, क्योंकि select`e के साथ हम केवल uuid निर्दिष्ट करते हैं, mysql को यह नहीं पता होता है कि हमें किस पार्टीशन में दिखना चाहिए और वह सभी में दिख रहा है।

समाधान # 1 समस्या से पैदा हुआ था - उत्पन्न uuid में टाइमस्टैम्प जोड़ें। केवल इस बार हमने थोड़ा अलग किया: हमने शुरुआत में या अंत में लाइन पर एक यादृच्छिक स्थान पर टाइमस्टैम्प डाला; पहले और बाद में उन्होंने एक डैश प्रतीक जोड़ा ताकि इसे एक नियमित अभिव्यक्ति के साथ प्राप्त किया जा सके।

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

इसके अलावा, ROW_FORMAT = COMPRESSED और एन्कोडिंग को लैटिन 1 में बदलने जैसी चीजों के लिए धन्यवाद, हमने हार्ड ड्राइव पर और भी अधिक जगह बचाई।