बादलों में डेटाबेस: किससे और क्यों - डेटा एग्रेट विशेषज्ञों की राय

यह माना जाता है कि भविष्य सेवा के रूप में डीबी के लिए है। क्या सभी के लिए डीबीए को आग लगाना और सार्वजनिक बादल में जाना या कुबेरनेट्स के साथ डोकर पर एक निजी बादल बनाने का प्रयास करना उचित है? #RuPostgres चैनल पर डेटा एग्रेट - एलेक्सी लेसोव्स्की, विक्टर येगोरोव और एंड्री सलनिकोव के तीन विशेषज्ञों ने अपने विचार साझा किए कि किस तरह के प्रोजेक्ट क्लाउड मॉडल के लिए उपयुक्त हैं।

चर्चा के मॉडरेटर और मध्यस्थ निकोले समोखावलोव, Postgres.ai के संस्थापक और RuPostgres.org समुदाय के सह-संस्थापक थे।



कट के तहत - वार्तालाप की प्रतिलिपि।

- आज हम बादलों में Postgres के बारे में बात करेंगे। और मैं एक मुश्किल सवाल के साथ शुरू करूँगा: क्या यह सच है कि आपके पास बादलों में आधे से अधिक ग्राहक हैं?

अलेक्सई: मुझे नहीं लगता। आधे से कम लगता है। हर कोई या तो अपने स्वयं के डेटा केंद्रों में बैठता है, या लोहे के टुकड़े किराए पर लेता है।

लेकिन बादलों के बारे में बात करने से पहले, शर्तों को परिभाषित करते हैं। "क्लाउड" से हमारा क्या तात्पर्य है: अमेज़न, Google क्लाउड, DB सेवा के रूप में?

- मैं क्लाउड को अलग कर दूंगा, अमेज़न ईसी 2 उदाहरण (या Google से एक एनालॉग) पर तैयार किया गया है, जहां आप कर सकते हैं, मोटे तौर पर बोल, ssh के माध्यम से लॉग इन करें और कॉन्फ़िगरेशन को सही करें, और नियंत्रण के तहत पोस्टग्रैज़ (अंग्रेजी में) प्रबंधित करें, जब प्रत्यक्ष पहुंच। फ़ाइल स्तर पर या कोई ssh नहीं है, लेकिन SQL क्वेरीज़ को कनेक्ट और निष्पादित करने की क्षमता है। उन्हें सिद्धांत रूप में अलग से माना जाना चाहिए। और मेरा पहला सवाल प्रबंधित Postgres के बारे में था।

अलेक्सी: ऐसे ग्राहक आधे से भी कम हैं।

विक्टर: ठीक है, पहले मामले में - बादल से हमें क्या महत्वपूर्ण फायदे हैं? बादल का अर्थ क्या है?

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

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

- और आप आभासी मशीनों द्वारा जोड़े गए ओवरहेड के बारे में कैसा महसूस करते हैं (एक आभासी मशीन के अंदर प्रक्रियाओं के लिए जो नंगे धातु, प्रदर्शन ओवरहेड या प्रशासन की कठिनाइयों पर नहीं हैं)? क्या आप में से किसी ने इसे मापा है?

अलेक्सेई: यदि आपके पास हाइपरविजर पर नियंत्रण है तो ओवरहेड को मापा जा सकता है। सार्वजनिक सेवाओं में यह नहीं है - वे जो देते हैं वही आप उपयोग करते हैं।

सामान्य वर्चुअलाइजेशन सिस्टम का ओवरहेड जिसे घर पर (केवीएम, एक्सईएन) में तैनात किया जा सकता है, मैंने पांच साल पहले मापा था, और तब यह लगभग 7-8% था। इसके अलावा, यह वर्चुअल मशीन और वर्कलोड की सेटिंग्स पर निर्भर करता था। उदाहरण के लिए, यूनिकॉर्न की तुलना में रेडिस और पोस्टग्रेज पर बहुत अधिक ओवरहेड था, जो रेल बैकेंड्स का कार्य करता है।

शायद अब संख्या अलग है।

यहां तक ​​कि विक्टर के बारे में बात करने वाले प्लसस की तुलना में 5-7% एक स्वीकार्य ओवरहेड है।

और आप ग्राहकों की संरचना को कैसे बदलते हैं: क्या प्रबंधित-ठिकानों की ओर कोई आंदोलन है?



एलेक्सी: नहीं। प्रवृत्ति इसके विपरीत है। आरडीएस जैसी चीजों के साथ काम करने वाले लोगों में प्रशासन और प्रबंधन के लिए लचीलेपन की कमी होती है। नतीजतन, हमें "पालतू जानवरों की तरह" समान रवैया मिलता है, लेकिन ईसी 2 उदाहरणों में।

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

- क्या इसके लिए Amazon RDS का इस्तेमाल किया गया है?

एलेक्सी: हमारे ग्राहक, इसके विपरीत, आरडीएस से इनकार करते हैं। कारण, जैसा कि मैंने कहा, प्रबंधन में लचीलेपन की कमी है।

उदाहरणों में दुर्घटना होती है, और कुछ मामलों में केवल लोहे के अधिक शक्तिशाली टुकड़े को किराए पर लेने से समस्या हल नहीं होती है।

आप कई समस्याओं को स्वयं हल नहीं कर सकते हैं - केवल समर्थन की सहायता से।

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

एलेक्सी: ओपनएससीजी, बेशक, पेशेवरों की एक टीम है। लेकिन ऐसी टीम को खरीदना संभावित परिस्थितियों के 100% को बंद नहीं करता है। ऐसी समस्याएं हैं जो पहली बार चेहरे का समर्थन करती हैं। हमारे साथ भी ऐसा होता है।

उत्तरार्द्ध में से एक, PostgreSQL 10.6 प्रतिकृतियों में से एक पर, होस्ट पर ग्राहक का लोड औसत अचानक 30-40 इकाइयों की वृद्धि हुई, हालांकि कोई लोड नहीं है। ऐसी अतृप्त भूमिगत दस्तक। यह बहुत प्रभावित नहीं करता है, लेकिन लोड औसत उछल की बहुत तस्वीर समझ से बाहर है। और वह ग्राहक के प्रवेश की घोषणा करता है। हमारे पास कुछ परिकल्पनाएं हैं, इसका क्या कारण है, लेकिन अभी तक हम उनका परीक्षण नहीं कर पाए हैं, क्योंकि सिस्टम उत्पादक है और वहां सब कुछ जल्दी से नहीं किया जा सकता है।

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



एंड्रयू: मैं RDS और EC2 उदाहरणों की तुलना के बारे में जोड़ना चाहूंगा।
हमारे पास आरडीएस पर उत्पादन के साथ एक ग्राहक था। उसने सलाह मांगी। देव-सर्किट Microsoft Azure में स्थित था, जाहिरा तौर पर, Azure को शुरू में मुख्य क्लाउड सेवा के रूप में माना जाता था।

मैंने EC2 में उत्पादन के करीब जाने के लिए एज़्योर से अमेज़ॅन तक के देव-सर्किट बेस को घसीटा, और पूर्वानुमान समस्याओं को उत्पाद डेटाबेस के करीब मिला।

हालांकि R2 इंस्टेंसेस के तहत EC2 सर्वर दोगुना सरल था, और मेरे लोड के बाद देव सर्किट में उत्पाद की तुलना में परीक्षण लोड अधिक था, परिणाम उत्पादन पर आरडीएस उदाहरण पर अमेज़ॅन की तुलना में बहुत बेहतर थे।

मुझे संदेह है कि ग्राहक की कंपनी के भीतर PostgreSQL विशेषज्ञता की कमी के कारण, RDS का उपयोग डिफ़ॉल्ट कॉन्फ़िगरेशन के साथ किया गया था। हम सभी सेटिंग्स को ट्विस्ट करते हैं।

परिणामस्वरूप, ग्राहक बहुत प्रभावित हुआ। मैंने सरल उदाहरण लेने और कॉन्फ़िगर करने के लिए आरडीएस के बजाय एक प्रस्ताव के साथ प्रबंधन का रुख किया।

- वैसे, कैसे मापा गया, जो बेहतर है, जो बदतर है?

एंड्रयू: क्लाइंट ने अपने एप्लिकेशन के मेट्रिक्स को देखा, कितनी जल्दी डेटा डाउनलोड और संसाधित किया गया था।

- हम अब आरडीएस डांट रहे हैं, लेकिन इसके बड़े फायदे हैं - यह तैनाती, बैकअप, प्रतिकृति के साथ जुड़े सिरदर्द को दूर करता है। क्या आप सहमत हैं?

एंड्रयू: हाँ। और, सबसे अधिक संभावना है, क्लाइंट के आरडीएस में बने रहने का मुख्य कारण पोस्टग्रेक्यूएल विशेषज्ञता के उल्लेखित अभाव में ठीक था। उन्हें आरडीएस के साथ वे सब कुछ मिलता है, जो वे सिर्फ उदाहरणों के लिए अधिक भुगतान करते हैं।

- अमेज़ॅन आरडीएस के अलावा, अन्य क्लाउड-आधारित प्रबंधित पोस्टग्रेज हैं। क्या आपने उदाहरण के लिए, यैंडेक्स सेवा का सामना किया है?

आंद्रेई: मैं उनकी आभासी मशीनों में आया था और मैं वास्तव में उनकी तरह नहीं था - NVMe ड्राइव बहुत ईमानदार नहीं हैं। वास्तव में, एक नेटवर्क पर ड्राइव जुड़े हुए हैं।

- ईमानदार NVMe (स्थानीय ड्राइव) भी एक समस्या है। Google और Amazon के पास NVMe है, लेकिन ड्राइव अल्पकालिक हैं। यदि आप आवृत्ति को पुनरारंभ करते हैं, तो आप सभी डेटा खो देते हैं क्योंकि आपको एक और वर्चुअल मशीन दी जाती है।

आंद्रेई: उन्होंने यैंडेक्स क्लाउड पर मुझ पर टिप्पणी की कि उनके पास सेवा के रूप में डीबी में ईमानदार NVMe है, लेकिन मुझे अभी तक इस सेवा का सामना नहीं करना पड़ा। जाहिर है, संसाधन प्रावधान के स्तर पर थोड़ा अलग वास्तुकला है।

वे DB पर सेवा के रूप में बहुत मेहनत करते हैं, क्योंकि वे इसे अपनी सेवाओं के लिए उपयोग करते हैं। यह सिर्फ इतना है कि बाहरी ग्राहकों और आंतरिक उपयोग के लिए अलग-अलग प्रवेश बिंदु हैं।

- और आपको क्या लगता है, क्या क्लाउड में रूसी पोस्टग्रेज के लिए कोई संभावनाएं हैं? उतारेंगे या नहीं उतारेंगे?

एंड्रयू:

Yandex के पास एक उत्कृष्ट टीम है, जो काफी अनुभवी है, अच्छी विशेषज्ञता के साथ। मुझे लगता है कि वे हट जाएंगे।

सबसे पहले, वे खुद बहुत सारे पोस्टग्रेज (अपनी परियोजनाओं पर 1000 से अधिक डेटाबेस) का संचालन करते हैं, और तब से शोषण, सभी शंकु और गले में धब्बे बाहर काम करेंगे और तेजी से ठीक करेंगे। मुझे लगता है कि ग्राहक को अच्छी गुणवत्ता की अंतिम सेवा प्रदान की जाएगी।

और ऐसे समाधानों की मांग है। एक स्टार्टअप लें जो शुरुआत में विभिन्न कारणों से पोस्टग्रेज में आवश्यक विशेषज्ञता नहीं रख सकता है: महंगा, वे इस बिंदु को नहीं देखते हैं, विभिन्न तकनीकों का प्रयास करें। उसके लिए, यह एक अच्छा समाधान है, क्योंकि ऐसी सेवाओं में सीमित "ट्विस्ट" होते हैं जिन्हें घुमाया नहीं जाना चाहिए, और यदि ऐसा है, तो मुझे लगता है, तकनीकी समर्थन होगा।

सच है, यैंडेक्स क्लाउड अभी भी शुरुआत में है, और इस समय इतनी कार्यक्षमता प्रस्तुत नहीं की गई है।

- हमारे पास चैट रूम से प्रश्न हैं: आप इस तथ्य के बारे में क्या सोचते हैं कि वर्चुअल मशीन जारी करते समय, कोई व्यक्ति शारीरिक रूप से इस मशीन पर बैठ सकता है (थ्रॉटलिंग, चोरी समय)।



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

- और क्या करें, क्या अमेज़ॅन में एक समान प्रभाव है? क्या यह निर्धारित करने के लिए कोई तरीका है कि आप "निचोड़ा हुआ" हैं? pgbench ड्राइव करने के लिए?

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

- मुझे लगता है कि आप वास्तव में प्रबंधित पोस्टग्रेज पसंद नहीं करते हैं। क्या यह इस तथ्य के कारण है कि आरडीएस आपका काम लेता है?

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

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

- पहुंच वाले मुद्दे को हल किया जा रहा है। प्रबंधित पोस्टग्रैज हैं जो ssh एक्सेस (और यहां तक ​​कि पूरी तरह से रूट) प्रदान करते हैं, उदाहरण के लिए, फिनलैंड की एक छोटी कंपनी Aiven। डिफ़ॉल्ट रूप से, वे रूट एक्सेस नहीं देंगे, लेकिन संस्थापक (और मैंने उनसे एक-दो बार बात की) अनुरोध पर पहुंच प्रदान करने के लिए उनकी तत्परता के बारे में बात की।

एंड्रयू: मुद्दा केवल पहुंच नहीं है। हम शुद्ध ग्रंथियों के साथ बेहतर क्यों हैं? क्योंकि हमारे पास बहुत से अलग ग्राहक हैं, और प्रत्येक का अपना बुनियादी ढांचा है। और इन्फ्रास्ट्रक्चर अभी तक अलग हैं कि सामान्य कार्यप्रणाली जो हर जगह समान है, हम बस नहीं कर सकते हैं। क्योंकि ऐसे लोग हैं जिनके पास खुद का हार्डवेयर है, और वे बस कहीं नहीं होस्ट कर सकते हैं (अपने स्वयं के नियमों और प्रतिबंधों के अनुसार), और ऐसे लोग हैं जो बादलों में हैं।

- आप यह कहना चाहते हैं कि अप्रयुक्त इंडेक्स की परिभाषा लोहे के टुकड़े पर निर्भर करती है? या कुछ अन्य सामान्य बातें?

एंड्रयू: प्रशासन के दृष्टिकोण से, यह डेटाबेस स्कीमा और अप्रयुक्त अनुक्रमित की परिभाषा है कि बादल उनके हार्डवेयर से अलग नहीं हैं। सब कुछ एकीकृत है।

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

- दर्शकों से एक और सवाल: कर्नेल सेटिंग्स के बारे में क्या?

विक्टर: EC2 में, ऐसी चीजें अनुकूलन योग्य हैं।

- सामान्य अमेज़ॅन और Google के अलावा, प्रसिद्ध विक्रेताओं से "प्रबंधित पोस्टग्रेज" वर्ग के लिए नए समाधान हैं। उदाहरण के लिए, न्यूट्रिनिक्स और एसएपी ने 2018 में पोस्टग्रेज-आधारित समाधान के निर्माण की घोषणा की। क्या आपको नहीं लगता कि ये सभी लोग हमें कुछ फैसलों के उद्भव के लिए प्रेरित करते हैं जो कि वही करेंगे, लेकिन केवल आपके लोहे के टुकड़े पर? ताकि आप बटन पर क्लिक कर सकें और नए पोस्टग्रेज को तैनात कर सकें, जहां बैकअप और प्रतिकृति पहले से ही कॉन्फ़िगर हैं।

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

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

एलेक्सी: यह पता चला है कि काफी प्रबंधित नहीं है।

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

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

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

विक्टर: हम इस तथ्य के बारे में बात करना शुरू कर रहे हैं कि हमारे पास बुनियादी ढांचे की एक अतिरिक्त परत है जिसे प्रबंधित करने की आवश्यकता है - इस कुबेरनेट्स को ऑर्केस्ट्रेट करने के लिए।

मैं इस बात से सहमत नहीं हूं कि वह हमेशा एक बटन के क्लिक पर जादुई तरीके से काम करेगा जिस तरह से हम चाहते हैं। प्रासंगिक विशेषज्ञों को रखना आवश्यक है।

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

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

यदि ग्राहक क्लाउड में रहना चाहता है और उसके पास विशेषज्ञता है, तो हमारे पास इसके खिलाफ कुछ भी नहीं है। मुख्य बात यह है कि हमारे पास अवसर है, जब डेटाबेस बहुत अच्छा नहीं होता है, चढ़ाई (अधिमानतः ssh द्वारा), सब कुछ जांचें और सभी आंकड़ों तक पहुंच प्राप्त करें।

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

सीधे कनेक्ट करना और देखना बहुत आसान है, अपनी कुछ परिकल्पनाओं का परीक्षण करें और उनसे आगे कार्य करें।

- क्या आपके पास ऐसे कोई सक्रिय उदाहरण हैं जहां कुबेरनेट्स पहले से ही उपयोग किया जाता है और इसमें पोस्टग्रैज रहते हैं?

अलेक्सी: दुर्भाग्य से, मैं नहीं करता। लेकिन मैं वास्तव में करना चाहूंगा। मुझे वास्तव में कुबेरनेट्स पसंद हैं, मैं उनकी अवधारणा और दर्शन के करीब हूं।

मेरी राय में, कुबेरनेट्स एक ऐसी चीज है जो लोगों को बुनियादी ढांचे की आंतरिक संरचना जैसी साइड चीजों के बारे में सोचने के बिना, अधिक कार्यक्रम बनाने के लिए प्रोत्साहित करती है।

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

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

, , . — , , . .

– , ?

: , . , . - , . , , Kubernetes. Kubernetes . CNCF . , .

– - kubernetes_ru. github, Kubernetes: . Postgres, .

, , , . , Kubernetes – , . - IT.

– , Amazon Aurora PostgreSQL Serverless ? , , . , . .. .

:

. .

, . , , . : , . , - . .

– . . , , .

: . , . , , – . , , , , .

यानी . – , , 70% . . .

, , « », .

– . , , DBA : - , - — , ?

: , , , – DBA, SQL-developer. Oracle SQL-developer, , , , . , Oracle. . DBA , - .

DBA — - «» , .

Kubernetes. , . . , Kubernetes . , volume . यानी , . , .

– ?

: .

, . , , . , Postgres ( ). Postgres - . यानी (, ), .

, .

, , . . . .

– ?

: - . , , .

, Cassandra. . यानी — , Kubernetes.

, , . , , .

यानी . DBA, , – . , , - – .

– ?

: . , . , , , Kubernetes . , , , , - - Kubernetes ( ).

: Kubernetes. – patroni. Zalando Kubernetes. , , ( – , Amazon , ). , – . , – . – - Kubernetes.

– RDS. EC2 Postgres . patroni ( https://github.com/zalando/patroni ), .

: , , - high availability.

– . — , ?

: , - .
Zalando DBA, patroni. यानी , Kubernetes , DBA .

– . DBA, DBA «» «».

: , . . , , .

– - Kubernetes? ?

: - , . Kubernetes – , . Kubernetes - . . DBA. Kubernetes (, Kubernetes , , ).

- , , - - -.

: ( Kubernetes ), - . , — — . - , , , , , , .

:

. Kubernetes , . , . .

, — . , Postgres- , , . .

: …

– .. : - — dev environment, production – Kubernetes. ...

: latency , , . .

– , . .
, HighLoad++ .

PS .