कैसे हमने Redis और Riak KV से डेटाबेस को PostgreSQL में माइग्रेट किया। भाग 1: प्रक्रिया

यह लेख का पहला भाग है जिसमें मैं इस बारे में बात करूँगा कि हमने एक बड़े डेटाबेस माइग्रेशन प्रोजेक्ट पर काम करने की प्रक्रिया कैसे बनाई: सुरक्षित प्रयोगों, टीम नियोजन और क्रॉस-टीम इंटरैक्शन के बारे में। निम्नलिखित लेखों में मैं उन तकनीकी समस्याओं के बारे में अधिक विस्तार से बात करूंगा जिन्हें हमने हल किया था: पोस्टग्रेसीक्यूएल और लोड परीक्षण की स्केलिंग और गलती सहनशीलता के बारे में।



लंबे समय तक, Miro (पूर्व-रियलटाइम बोर्ड) में मुख्य डेटाबेस रेडिस था। हमने इसमें सभी मूल जानकारी संग्रहीत की है: उपयोगकर्ताओं, खातों, बोर्डों आदि के बारे में डेटा। सब कुछ जल्दी से काम किया, लेकिन हम कई समस्याओं में भाग गए।

रेडिस के साथ समस्या

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

सर्वर पर डेटा की मात्रा में वृद्धि के साथ ये समस्याएं, डेटाबेस के प्रवास का कारण बनीं।

समस्या का बयान

प्रवास पर निर्णय किया गया है। अगला कदम यह समझना है कि कौन सा डेटाबेस हमारे डेटा मॉडल के लिए उपयुक्त है।

हमने अपने लिए इष्टतम डेटाबेस का चयन करने के लिए एक अध्ययन किया, और PostgreSQL पर बस गए। हमारा डेटा मॉडल एक रिलेशनल डेटाबेस के साथ अच्छी तरह से फिट बैठता है: PostgreSQL में डेटा स्थिरता सुनिश्चित करने के लिए अंतर्निहित टूल हैं, एक JSONB प्रकार और JSONB में कुछ क्षेत्रों को अनुक्रमित करने की क्षमता है। यह हमें सूट करता है।

हमारे एप्लिकेशन की सरलीकृत वास्तुकला इस तरह दिखती है: एप्लिकेशन सर्वर हैं जो डेटा परत के माध्यम से Redis और RiakKV तक पहुंचते हैं।

हमारा एप्लिकेशन सर्वर एक अखंड जावा एप्लिकेशन है। व्यापार तर्क को एक फ्रेमवर्क में लिखा गया है जिसे NoSQL के लिए अनुकूलित किया गया है। एप्लिकेशन की अपनी लेनदेन प्रणाली है, जो आपको हमारे किसी भी बोर्ड पर कई उपयोगकर्ता प्रदान करने की अनुमति देती है।

हमने 7 दिनों तक नहीं खुलने वाले आर्काइव बोर्ड के डेटा को स्टोर करने के लिए RiakKV का इस्तेमाल किया।

इस स्कीमा में PostgreSQL जोड़ें। हम नए सर्वर के साथ एप्लिकेशन सर्वर काम करते हैं। Redis और RiakKV से PostgreSQL के डेटा की प्रतिलिपि बनाएँ। समस्या हल हो गई!

कुछ भी जटिल नहीं है, लेकिन बारीकियां हैं:

• हमारे 2.2 मिलियन पंजीकृत उपयोगकर्ता हैं। हर दिन, मिरो 50 हजार उपयोगकर्ताओं को रोजगार देता है, पीक लोड एक ही समय में 14 हजार तक होता है। उपयोगकर्ताओं को हमारे काम के कारण त्रुटियों का सामना नहीं करना चाहिए, उन्हें आम तौर पर नए आधार पर जाने के क्षण पर ध्यान नहीं देना चाहिए।
• डेटाबेस में 1 टीबी डेटा या 410 मिलियन ऑब्जेक्ट।
• अन्य टीमों द्वारा लगातार नई सुविधाओं को जारी करना, जिनके काम में हमें हस्तक्षेप नहीं करना चाहिए।

समस्या को हल करने के लिए विकल्प

हमें डेटा माइग्रेशन के लिए दो विकल्पों का चयन करना पड़ा:

1. सेवा के विकास को रोकें → सर्वर पर कोड को फिर से लिखें → कार्यक्षमता का परीक्षण करें → एक नया संस्करण लॉन्च करें।
2. निर्बाध माइग्रेशन करें: उत्पाद के कुछ हिस्सों को धीरे-धीरे एक नए डेटाबेस में ट्रांसफर करें, दोनों PostgreSQL और Redis का समर्थन करें और नई सुविधाओं के विकास को बाधित न करें।

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


कार्य का मूल्यांकन करते समय, हमने अपने उत्पाद को मुख्य ब्लॉकों में विभाजित किया: उपयोगकर्ता, खाते, बोर्ड, और इसी तरह। अलग से, PostgreSQL बुनियादी ढांचे को बनाने के लिए काम किया गया था। और वे मूल्यांकन में जोखिम डालते हैं अगर कुछ गलत हो जाता है (जिस तरह से हुआ)।

स्प्रिंट और गोल

अगला कदम पांच लोगों की एक टीम बनाना है ताकि हर कोई सही गति से एक सामान्य लक्ष्य की ओर बढ़े।

हमारे पास दो बिंदु हैं: कार्य पर काम की शुरुआत और अंतिम लक्ष्य। आदर्श जब हम लक्ष्य की ओर सीधे तरीके से बढ़ रहे हैं। लेकिन अक्सर ऐसा होता है कि हम सीधे रास्ते पर जाना चाहते हैं, लेकिन यह इस तरह से निकलता है:



उदाहरण के लिए, कठिनाइयों और समस्याओं के कारण जो पहले से पूर्वाभास नहीं कर सकते थे।

एक स्थिति संभव है जिसमें हम लक्ष्य तक नहीं पहुंच पाएंगे। उदाहरण के लिए, यदि हम पूरे आवेदन को फिर से लिखने या फिर से लिखने के लिए जाते हैं।



हम उपरोक्त वर्णित कठिनाइयों को कम करने के लिए कार्य को साप्ताहिक क्षेत्रों में विभाजित करते हैं। यदि टीम अचानक पक्ष में चली जाती है, तो यह परियोजना के लिए कम से कम नुकसान के साथ जल्दी से वापस जा सकती है, क्योंकि कम पुनरावृत्तियों आपको बहुत "गलत तरीके" से जाने की अनुमति नहीं देते हैं।

प्रत्येक पुनरावृत्ति का अपना लक्ष्य होता है, जो टीम को अंतिम बड़े परिणाम पर ले जाता है।



यदि स्प्रिंट के दौरान एक नया कार्य दिखाई देता है, तो हम मूल्यांकन करते हैं कि क्या इसका कार्यान्वयन हमें लक्ष्य के करीब लाता है। हां - अगला स्प्रिंट लें या वर्तमान एक में प्राथमिकताएं बदलें, यदि नहीं - इसे न लें। यदि त्रुटियाँ दिखाई देती हैं, तो हम उन्हें उच्च प्राथमिकता देते हैं और जल्दी से उन्हें ठीक करते हैं।

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

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

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

यह हमारे स्प्रिंट में से एक है। हम Miro बोर्ड पर सब कुछ ले:

मोड और सुरक्षित प्रयोग

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

यह विचार धीरे-धीरे उत्पाद ब्लॉकों को एक नए डेटाबेस में बदलने का था। ऐसा करने के लिए, हम मोड के अनुक्रम के साथ आए।

पहले “Redis Read / Write” मोड में, केवल पुराना डेटाबेस, Redis, काम करता है।



दूसरे "PostgreSQL पैसिव राइट" मोड में, हम यह सुनिश्चित कर सकते हैं कि नए डेटाबेस में लिखना सही है और डेटाबेस सुसंगत हैं।



तीसरा मोड "PostgreSQL रीड / राइट, रेडिस पैसिव राइट" आपको PostgreSQL से डेटा पढ़ने की शुद्धता को सत्यापित करने और यह देखने की अनुमति देता है कि नया डेटाबेस मुकाबला करने की स्थिति में कैसे व्यवहार करता है। इसी समय, रेडिस मुख्य आधार बना हुआ है, जिसने हमें उन बोर्डों के साथ काम करने के विशिष्ट मामलों को खोजने में सक्षम बनाया जो त्रुटियों को जन्म दे सकते थे।



पिछले "PostgreSQL रीड / राइट" मोड में, केवल नया डेटाबेस चल रहा है।



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

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

मोड के साथ प्रयोग शुरू करने की समयरेखा इस प्रकार है:

• जनवरी-फरवरी: रेडिस ने पढ़ा / लिखा
• मार्च-अप्रैल: PostgreSQL निष्क्रिय लेखन
• मई-जून: PostgreSQL पढ़ा / लिखा, मुख्य डेटाबेस - रेडिस
• जुलाई-अगस्त: PostgreSQL पढ़ा / लिखा
• सितंबर-दिसंबर: पूर्ण प्रवास।

यदि त्रुटियां हुईं, तो हमारे पास उन्हें जल्दी ठीक करने का अवसर था, क्योंकि हम स्वयं उन सर्वरों पर रिलीज़ कर सकते थे जहाँ प्रयोग में भाग लेने वाले उपयोगकर्ता काम करते थे। हम मुख्य रिलीज़ पर निर्भर नहीं थे, इसलिए हमने जल्दी और किसी भी समय त्रुटियों को ठीक किया।

क्रॉस-टीम सहयोग

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

ऐसी स्थितियों से बचने के लिए, हमने अन्य टीमों के साथ मिलकर एक एकल किराने का रोडमैप संकलित किया, जिसे कई बार एक चौथाई और कुछ टीमों के साथ साप्ताहिक रूप से सिंक्रनाइज़ किया गया।

निष्कर्ष

इस परियोजना के दौरान हमने क्या सीखा:

1. जटिल परियोजनाओं को लेने से डरो मत। अपघटन, मूल्यांकन और कार्य के दृष्टिकोण के विकास के बाद, जटिल परियोजनाएं असंभव प्रतीत होती हैं।
2. प्रारंभिक अनुमानों, अपघटन और नियोजन पर समय और प्रयास को न छोड़ें। इससे समस्या को गहराई से समझने में मदद मिलती है इससे पहले कि आप उस पर काम करना शुरू करें, और काम की मात्रा और जटिलता को समझें।
3. कठिन तकनीकी और संगठनात्मक परियोजनाओं में जोखिम रखना। काम की प्रक्रिया में, आप निश्चित रूप से एक समस्या का सामना करेंगे जो योजना बनाते समय ध्यान में नहीं रखी गई थी।
4. जब तक आवश्यक न हो, प्रवास न करें।

निम्नलिखित लेखों में मैं उन तकनीकी समस्याओं के बारे में बात करूँगा जो हमने प्रवास के दौरान हल की थीं।