🥇ओपन सोर्स डेटाबेस में हम क्या और क्यों करते हैं। एंड्री बोरोडिन (यांडेक्स.क्लाउड)

निम्नलिखित डेटाबेस में यांडेक्स के योगदान की समीक्षा की जाएगी।

क्लिकहाउस
ओडिसी
एक समय में पुनर्प्राप्ति (वाल-जी)
PostgreSQL (लॉगरर्स, एमचेक, हीपचेक सहित)
हरा आलूबुखारा

वीडियो:

हैलो वर्ल्ड! मेरा नाम एंड्री बोरोडिन है। और Yandex.Cloud पर मैं Yandex.Cloud और Yandex.Cloud ग्राहकों के हित में ओपन रिलेशनल डेटाबेस विकसित करता हूं।

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

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

लेकिन! खुले डेटाबेस का क्या फायदा है? सच तो यह है कि आपके पास किसी भी समस्या से निपटने का सैद्धांतिक अवसर है। आपके पास स्रोत कोड है, आपके पास प्रोग्रामिंग ज्ञान है। हम इसे जोड़ते हैं और यह काम करता है।

ओपन सोर्स सॉफ़्टवेयर पर काम करने में क्या दृष्टिकोण हैं?

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

ओपन सोर्स सॉफ्टवेयर के क्षेत्र में सबसे प्रसिद्ध यांडेक्स परियोजनाओं में से एक ClickHouse है। यह एक डेटाबेस है जिसका जन्म Yandex.Metrica के सामने आने वाली चुनौतियों की प्रतिक्रिया के रूप में हुआ था।

और एक डेटाबेस के रूप में, इसे एक पारिस्थितिकी तंत्र बनाने और इसे अन्य डेवलपर्स (न केवल यैंडेक्स के भीतर) के साथ मिलकर विकसित करने के लिए खुले स्रोत में बनाया गया था। और अब ये एक बड़ा प्रोजेक्ट है जिसमें कई अलग-अलग कंपनियां शामिल हैं.

Yandex.Cloud में, हमने Yandex ऑब्जेक्ट स्टोरेज के शीर्ष पर, यानी क्लाउड स्टोरेज के शीर्ष पर ClickHouse बनाया।

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

यह कैसे किया जा सकता है? ये इस रिपोर्ट का अहम बिंदु है.

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

स्वाभाविक रूप से, संपूर्ण ClickHouse पारिस्थितिकी तंत्र को कार्यक्षमता प्रदान करना चाहते हैं और Yandex.Cloud के अंदर आवश्यक कार्य करना चाहते हैं, हमने यह सुनिश्चित करने का निर्णय लिया कि संपूर्ण ClickHouse समुदाय को इससे लाभ होगा। हमने S3 पर ClickHouse लागू किया, MDS पर ClickHouse नहीं। और यह बहुत काम है.

कड़ियाँ:

https://github.com/ClickHouse/ClickHouse/pull/7946 "फ़ाइल सिस्टम अमूर्त परत"
https://github.com/ClickHouse/ClickHouse/pull/8011 "एडब्ल्यूएस एसडीके एस3 एकीकरण"
https://github.com/ClickHouse/ClickHouse/pull/8649 "S3 के लिए IDisk इंटरफ़ेस का आधार कार्यान्वयन"
https://github.com/ClickHouse/ClickHouse/pull/8356 "आईडिस्क इंटरफ़ेस के साथ लॉग स्टोरेज इंजन का एकीकरण"
https://github.com/ClickHouse/ClickHouse/pull/8862 "S3 और SeekableReadBuffer के लिए लॉग इंजन समर्थन"
https://github.com/ClickHouse/ClickHouse/pull/9128 "स्टोरेज स्ट्राइप लॉग S3 समर्थन"
https://github.com/ClickHouse/ClickHouse/pull/9415 "S3 के लिए स्टोरेज मर्जट्री आरंभिक समर्थन"
https://github.com/ClickHouse/ClickHouse/pull/9646 "MergeTree S3 के लिए पूर्ण समर्थन"
https://github.com/ClickHouse/ClickHouse/pull/10126 "S3 पर ReplicationMergeTree का समर्थन करें"
https://github.com/ClickHouse/ClickHouse/pull/11134 "S3 स्टोरेज के लिए डिफ़ॉल्ट क्रेडेंशियल और कस्टम हेडर जोड़ें"
https://github.com/ClickHouse/ClickHouse/pull/10576 "S3 गतिशील प्रॉक्सी कॉन्फ़िगरेशन के साथ"
https://github.com/ClickHouse/ClickHouse/pull/10744 "S3 प्रॉक्सी रिज़ॉल्वर के साथ"

यह ClickHouse में वर्चुअल फ़ाइल सिस्टम को लागू करने के लिए एक पुल अनुरोध सूची है। यह बड़ी संख्या में पुल अनुरोध हैं.

कड़ियाँ:

https://github.com/ClickHouse/ClickHouse/pull/9760 "DiskS3 हार्डलिंक इष्टतम कार्यान्वयन"
https://github.com/ClickHouse/ClickHouse/pull/11522 "S3 HTTP क्लाइंट - प्रतिक्रिया स्ट्रीम को मेमोरी में कॉपी करने से बचें"
https://github.com/ClickHouse/ClickHouse/pull/11561 “S3 HTTP में संपूर्ण प्रतिक्रिया स्ट्रीम को मेमोरी में कॉपी करने से बचें
ग्राहक"
https://github.com/ClickHouse/ClickHouse/pull/13076 "S3 डिस्क के लिए मार्क और इंडेक्स फ़ाइलों को कैश करने की क्षमता"
https://github.com/ClickHouse/ClickHouse/pull/13459 "भागों को डिस्कलोकल से डिस्कS3 तक समानांतर में ले जाएं"

लेकिन काम यहीं ख़त्म नहीं हुआ. सुविधा बनने के बाद, इस कार्यक्षमता को अनुकूलित करने के लिए कुछ और काम की आवश्यकता थी।

कड़ियाँ:

https://github.com/ClickHouse/ClickHouse/pull/12638 "चयनित पंक्तियाँ और चयनितबाइट्स ईवेंट जोड़ें"
https://github.com/ClickHouse/ClickHouse/pull/12464 "S3 अनुरोध से system.events में प्रोफ़ाइलिंग इवेंट जोड़ें"
https://github.com/ClickHouse/ClickHouse/pull/13028 "क्वेरीटाइममाइक्रोसेकंड, सिलेक्टक्वेरीटाइममाइक्रोसेकंड और इंसर्टक्वेरीटाइममाइक्रोसेकंड जोड़ें"

और फिर इसे निदान योग्य बनाना, निगरानी स्थापित करना और इसे प्रबंधनीय बनाना आवश्यक था।

और यह सब इसलिए किया गया ताकि पूरे समुदाय, पूरे क्लिकहाउस इकोसिस्टम को इस काम का परिणाम मिले।

आइए ट्रांजेक्शनल डेटाबेस, ओएलटीपी डेटाबेस की ओर बढ़ते हैं, जो व्यक्तिगत रूप से मेरे करीब हैं।

यह खुला स्रोत DBMS विकास प्रभाग है। ये लोग लेन-देन संबंधी खुले डेटाबेस को बेहतर बनाने के लिए सड़क पर जादू कर रहे हैं।

परियोजनाओं में से एक, जिसके उदाहरण का उपयोग करके हम बात कर सकते हैं कि हम कैसे और क्या करते हैं, पोस्टग्रेज़ में कनेक्शन पूलर है।

पोस्टग्रेज़ एक प्रोसेस डेटाबेस है। इसका मतलब यह है कि डेटाबेस में यथासंभव कम से कम नेटवर्क कनेक्शन होने चाहिए जो लेनदेन को संभाल सकें।

दूसरी ओर, क्लाउड वातावरण में, एक सामान्य स्थिति तब होती है जब एक क्लस्टर में एक साथ एक हजार कनेक्शन आते हैं। और कनेक्शन पूलर का कार्य एक हजार कनेक्शन को कम संख्या में सर्वर कनेक्शन में पैक करना है।

हम कह सकते हैं कि कनेक्शन पूलर टेलीफोन ऑपरेटर है जो बाइट्स को पुनर्व्यवस्थित करता है ताकि वे कुशलतापूर्वक डेटाबेस तक पहुंच सकें।

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

https://pgconf.ru/2017/92899

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

https://pgconf.ru/media/2017/04/03/20170316H1_V.Borodin.pdf

और हमने काम किया. हमने उन समस्याओं को ठीक किया जिनका हमें सामना करना पड़ा, हमने बाउंसर को पैच किया, और पुल अनुरोधों को अपस्ट्रीम में पुश करने का प्रयास किया। लेकिन बुनियादी सिंगल-थ्रेडिंग के साथ काम करना मुश्किल था।

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

हम इस निष्कर्ष पर पहुंचे कि हमने अपना स्वयं का कनेक्शन पूलर बनाया है, जिसे ओडिसी कहा जाता है। हमने इसे शुरू से लिखा है।

https://www.pgcon.org/2019/schedule/events/1312.en.html

2019 में, PgCon सम्मेलन में, मैंने इस पूलर को डेवलपर समुदाय के सामने प्रस्तुत किया। अब हमारे पास GitHub पर 2 से कुछ कम सितारे हैं, यानी प्रोजेक्ट जीवित है, प्रोजेक्ट लोकप्रिय है।

और यदि आप Yandex.Cloud में एक पोस्टग्रेज क्लस्टर बनाते हैं, तो यह बिल्ट-इन ओडिसी वाला एक क्लस्टर होगा, जो क्लस्टर को आगे या पीछे स्केल करने पर पुन: कॉन्फ़िगर किया जाता है।

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

PgBouncer तेजी से विकसित होने लगा।

और अब अन्य परियोजनाएँ सामने आई हैं। उदाहरण के लिए, pgagroal, जिसे Red Hat डेवलपर्स द्वारा विकसित किया गया है। वे समान लक्ष्यों का पीछा करते हैं और समान विचारों को लागू करते हैं, लेकिन निश्चित रूप से, अपनी विशिष्टताओं के साथ, जो पीजीएग्रोल डेवलपर्स के करीब हैं।

पोस्टग्रेज़ समुदाय के साथ काम करने का एक और मामला समय में एक बिंदु को पुनर्स्थापित करना है। यह विफलता के बाद पुनर्प्राप्ति है, यह बैकअप से पुनर्प्राप्ति है।

कई बैकअप हैं और वे सभी अलग-अलग हैं। लगभग हर पोस्टग्रेज़ विक्रेता के पास अपना स्वयं का बैकअप समाधान होता है।

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

https://www.citusdata.com/blog/2017/08/18/introducing-wal-g-faster-restores-for-postgres/

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

https://github.com/wal-g/wal-g/graphs/contributors

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

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

इसका मतलब क्या है? हम एक काफी बड़े विचार को बढ़ावा दे रहे थे: बैकअप सुरक्षित होना चाहिए, संचालित करने में सस्ता होना चाहिए और जितनी जल्दी हो सके बहाल करना चाहिए।

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

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

और हमने इस सरल विचार को बढ़ावा दिया। और, हमें ऐसा लगता है, हम इसे लागू करने में कामयाब रहे।

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

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

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

Postgres जैसा एक डेटाबेस है। मुझे पोस्टग्रेज कोर सबसे ज्यादा पसंद है। मैं समुदाय के साथ पोस्टग्रेज़ कोर विकसित करने में बहुत समय बिताता हूं।

लेकिन यहां यह अवश्य कहा जाना चाहिए कि Yandex.Cloud में प्रबंधित डेटाबेस की आंतरिक स्थापना है। और यह बहुत समय पहले Yandex.Mail में शुरू हुआ था। जिस विशेषज्ञता के कारण अब पोस्टग्रेज को प्रबंधित किया गया है, वह तब जमा हुई थी जब मेल पोस्टग्रेज में जाना चाहता था।

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

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

अब पोस्टग्रेज की आंतरिक स्थापना में कुछ पेटाबाइट डेटा है। ये प्रति सेकंड कुछ लाखों अनुरोध हैं। ये हजारों क्लस्टर हैं. यह बहुत बड़े पैमाने पर है.

लेकिन एक बारीकियां है. यह फैंसी नेटवर्क ड्राइव पर नहीं, बल्कि काफी सरल हार्डवेयर पर रहता है। और विशेष रूप से दिलचस्प नई चीज़ों के लिए एक परीक्षण वातावरण है।

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

एक अपरिवर्तनीय एक प्रकार का रिश्ता है जिसे हम हमेशा बनाए रखने की उम्मीद करते हैं।

हमारे लिए बहुत गंभीर स्थिति है. यह इंगित करता है कि कुछ डेटा खो गया होगा। और डेटा हानि बिल्कुल विनाशकारी है।

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

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

https://commitfest.postgresql.org/23/2171/

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

इस पैच को समुदाय द्वारा बिना अधिक चर्चा के व्यावहारिक रूप से स्वीकार कर लिया गया था, क्योंकि प्रत्येक विशिष्ट मामले में यह स्पष्ट था कि कुछ बुरा हुआ था और लॉग को रिपोर्ट करने की आवश्यकता थी।

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

लेकिन! लॉग को स्कैन करना एक क्लस्टर पर एक सस्ता ऑपरेशन है और एक हजार क्लस्टर के लिए बेहद महंगा है।

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

उदाहरण के लिए, इस एक्सटेंशन को रिपॉजिटरी में अपनाया गया है CentOS. यदि आप इसका उपयोग करना चाहते हैं तो आप इसे स्वयं इंस्टॉल कर सकते हैं। निःसंदेह यह खुला स्रोत है।

https://www.postgresql.org/message-id/flat/[ईमेल संरक्षित]

लेकिन वह सब नहीं है। हमने अनुक्रमणिका में अपरिवर्तनीय उल्लंघनों का पता लगाने के लिए एक समुदाय-निर्मित एक्सटेंशन एमचेक का उपयोग करना शुरू किया।

और हमने पाया कि यदि आप इसे बड़े पैमाने पर संचालित करते हैं, तो इसमें बग होते हैं। हमने उन्हें ठीक करना शुरू कर दिया. हमारा सुधार स्वीकार कर लिया गया है.

https://www.postgresql.org/message-id/flat/[ईमेल संरक्षित]

हमने पाया कि यह एक्सटेंशन GiST और GIT इंडेक्स का विश्लेषण नहीं कर सकता है। हमने उन्हें सहारा बनाया. लेकिन इस समर्थन पर अभी भी समुदाय द्वारा चर्चा की जा रही है, क्योंकि यह अपेक्षाकृत नई कार्यक्षमता है और इसमें बहुत सारे विवरण हैं।

https://commitfest.postgresql.org/29/2667/

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

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

https://www.postgresql.org/message-id/flat/38AF687F-8F6B-48B4-AB9E-A60CFD6CC261%40enterprisedb.com#0e86a12c01d967bac04a9bf83cd337cb

लेकिन इंडेक्स के अलावा, ढेर जैसा एक हिस्सा भी होता है, यानी वह स्थान जहां डेटा संग्रहीत किया जाता है। और ऐसे बहुत से अपरिवर्तनीय तत्व नहीं हैं जिनकी जाँच की जा सके।

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

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

https://www.postgresql.org/message-id/flat/fe9b3722df94f7bdb08768f50ee8fe59%40postgrespro.ru

कुछ स्थानों पर, हम इस निष्कर्ष पर भी पहुंचे कि हमारी निगरानी प्रणालियों में गलत सकारात्मकताएँ हैं। उदाहरण के लिए, 1C प्रणाली. डेटाबेस का उपयोग करते समय, पोस्टग्रेज़ कभी-कभी इसमें डेटा लिखता है जिसे वह पढ़ सकता है, लेकिन pg_dump नहीं पढ़ सकता है।

यह स्थिति हमारी समस्या पहचान प्रणाली को भ्रष्टाचार जैसी लग रही थी। ड्यूटी ऑफिसर को जगाया गया. ड्यूटी अधिकारी ने देखा कि क्या हो रहा था। कुछ देर बाद एक ग्राहक आया और बोला कि मुझे दिक्कत है. परिचारक ने बताया कि समस्या क्या थी। लेकिन समस्या पोस्टग्रेज़ कोर में है।

मुझे इस सुविधा के बारे में एक चर्चा मिली। और उन्होंने लिखा कि हमने इस सुविधा का सामना किया और यह अप्रिय था, एक व्यक्ति यह पता लगाने के लिए रात में जाग गया कि यह क्या था।

https://www.postgresql.org/message-id/flat/fe9b3722df94f7bdb08768f50ee8fe59%40postgrespro.ru

समुदाय ने जवाब दिया, "ओह, हमें वास्तव में इसे ठीक करने की ज़रूरत है।"

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

हमने यहां क्या सीखा है? हमने एक साधारण बात सीखी: सबसे महत्वपूर्ण बात समुदाय को यह समझाना है कि कोई समस्या है। यदि समुदाय ने समस्या को पहचान लिया है, तो समस्या को हल करने के लिए स्वाभाविक प्रतिस्पर्धा पैदा हो जाती है। क्योंकि हर कोई एक महत्वपूर्ण समस्या का समाधान करना चाहता है। सभी विक्रेता, सभी हैकर्स समझते हैं कि वे स्वयं इस रेक पर कदम रख सकते हैं, इसलिए वे उन्हें खत्म करना चाहते हैं।

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

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

https://greenplum.org/greenplum-database-tables-compression/

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

लेकिन कोई क्लस्टरिंग नहीं थी, यानी ऐसी कोई कार्यक्षमता नहीं थी जहां आप तालिका में स्थित डेटा को किसी एक इंडेक्स में मौजूद क्रम के अनुसार व्यवस्थित कर सकें।

टैक्सी के लोग मेरे पास आये और बोले: “आंद्रे, तुम पोस्टग्रेज़ को जानते हो। और यहाँ भी लगभग वैसा ही है. 20 मिनट पर स्विच करें. तुम इसे लो और करो।” मैंने सोचा कि हाँ, मैं पोस्टग्रेज़ जानता हूँ, 20 मिनट के लिए स्विच करना - मुझे यह करने की ज़रूरत है।

https://github.com/greenplum-db/gpdb/commit/179feb77a034c2547021d675082aae0911be40f7

लेकिन नहीं, यह 20 मिनट का नहीं था, मैंने इसे महीनों में लिखा था। PgConf.Russia सम्मेलन में, मैंने पिवोटल से हेइकी लिनकांगस से संपर्क किया और पूछा: “क्या इसमें कोई समस्या है? कोई परिशिष्ट अनुकूलित तालिका क्लस्टरिंग क्यों नहीं है?" वह कहते हैं: “आप डेटा ले लीजिए। आप क्रमबद्ध करते हैं, आप पुनर्व्यवस्थित करते हैं। यह सिर्फ एक नौकरी है।" मैं: "ओह, हाँ, आपको बस इसे लेने और करने की ज़रूरत है।" वह कहते हैं: "हां, हमें ऐसा करने के लिए स्वतंत्र हाथों की ज़रूरत है।" मैंने सोचा कि मुझे ये जरूर करना चाहिए.

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

https://github.com/greenplum-db/gpdb/issues/10150

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

https://github.com/greenplum-db/gpdb/pull/10290

मैंने यह बग ठीक कर दिया है. फिक्सर्स को पुल अनुरोध भेजा गया। उसकी हत्या की गई थी।

https://github.com/greenplum-db/gpdb-postgres-merge/pull/53

जिसके बाद यह पता चला कि इस कार्यक्षमता को PostgreSQL 12 के लिए ग्रीनप्लम संस्करण में प्राप्त करने की आवश्यकता है। यानी, 20 मिनट का रोमांच नए दिलचस्प रोमांच के साथ जारी है। वर्तमान विकास को छूना दिलचस्प था, जहां समुदाय नई और सबसे महत्वपूर्ण सुविधाओं में कटौती कर रहा है। यह जम गया है।

https://github.com/greenplum-db/gpdb/pull/10565

लेकिन बात यहीं ख़त्म नहीं हुई. सब कुछ के बाद, यह पता चला कि हमें इस सब के लिए दस्तावेज़ लिखने की ज़रूरत है।

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

और यहीं, ऐसा प्रतीत होता है, साहसिक कार्य समाप्त हो गया। और क्या आप जानते हैं फिर क्या हुआ? टैक्सी वाले मेरे पास आए और बोले: "अभी भी दो रोमांच बाकी हैं, प्रत्येक 10 मिनट के लिए।" और मुझे उन्हें क्या बताना चाहिए? मैंने कहा कि अब मैं पैमाने पर एक रिपोर्ट दूंगा, फिर हम आपके कारनामे देखेंगे, क्योंकि यह एक दिलचस्प काम है।

इस मामले से हमने क्या सीखा? क्योंकि खुले स्रोत के साथ काम करना हमेशा एक विशिष्ट व्यक्ति के साथ काम करना होता है, यह हमेशा समुदाय के साथ काम करना होता है। क्योंकि हर एक चरण में मैंने कुछ डेवलपर, कुछ परीक्षक, कुछ हैकर, कुछ वृत्तचित्र निर्माता, कुछ वास्तुकार के साथ काम किया। मैंने ग्रीनप्लम के साथ काम नहीं किया, मैंने ग्रीनप्लम के आसपास के लोगों के साथ काम किया।

लेकिन! एक और महत्वपूर्ण बिंदु है - यह सिर्फ काम है। यानी आप आएं, कॉफी पिएं, कोड लिखें। सभी प्रकार के सरल अपरिवर्तनीय कार्य करते हैं। इसे सामान्य रूप से करें - यह ठीक रहेगा! और यह काफी दिलचस्प काम है. इस कार्य के लिए Yandex.Cloud ग्राहकों, Yandex के अंदर और बाहर दोनों ही हमारे क्लस्टर के उपयोगकर्ताओं से अनुरोध है। और मुझे लगता है कि जिन परियोजनाओं में हम भाग लेंगे उनकी संख्या बढ़ेगी और हमारी भागीदारी की गहराई भी बढ़ेगी।

बस इतना ही। चलिए सवालों की ओर बढ़ते हैं।

प्रश्न सत्र

नमस्ते! हमारे पास एक और प्रश्न और उत्तर सत्र है। और स्टूडियो में आंद्रेई बोरोडिन। यह वही व्यक्ति है जिसने आपको ओपन सोर्स में Yandex.Cloud और Yandex के योगदान के बारे में बताया था। अब हमारी रिपोर्ट पूरी तरह से क्लाउड के बारे में नहीं है, लेकिन साथ ही हम ऐसी प्रौद्योगिकियों पर आधारित हैं। आपने Yandex के अंदर जो किया उसके बिना Yandex.Cloud में कोई सेवा नहीं होती, इसलिए मेरी ओर से व्यक्तिगत रूप से धन्यवाद। और प्रसारण से पहला प्रश्न: "जिन परियोजनाओं का आपने उल्लेख किया है उनमें से प्रत्येक किस पर लिखी गई है?"

WAL-G में बैकअप सिस्टम Go में लिखा गया है। यह उन नई परियोजनाओं में से एक है जिन पर हमने काम किया है। वह वस्तुतः केवल 3 वर्ष का है। और डेटाबेस अक्सर विश्वसनीयता के बारे में होता है। और इसका मतलब है कि डेटाबेस काफी पुराने हैं और वे आमतौर पर सी में लिखे गए हैं। पोस्टग्रेज परियोजना लगभग 30 साल पहले शुरू हुई थी। तब C89 सही विकल्प था। और उस पर Postgres लिखा हुआ है. ClickHouse जैसे अधिक आधुनिक डेटाबेस आमतौर पर C++ में लिखे जाते हैं। सारा सिस्टम विकास C और C++ पर आधारित है।

हमारे वित्तीय प्रबंधक, जो क्लाउड पर खर्चों के लिए जिम्मेदार है, से एक प्रश्न: "क्लाउड ओपन सोर्स के समर्थन पर पैसा क्यों खर्च करता है?"

यहां वित्तीय प्रबंधक के लिए एक सरल उत्तर है। हम अपनी सेवाओं को बेहतर बनाने के लिए ऐसा करते हैं। हम किन तरीकों से बेहतर कर सकते हैं? हम चीजों को अधिक कुशलतापूर्वक, तेजी से कर सकते हैं और चीजों को अधिक स्केलेबल बना सकते हैं। लेकिन हमारे लिए, यह कहानी मुख्य रूप से विश्वसनीयता के बारे में है। उदाहरण के लिए, एक बैकअप सिस्टम में हम उस पर लागू होने वाले 100% पैच की समीक्षा करते हैं। हम जानते हैं कि कोड क्या है. और हम उत्पादन के लिए नए संस्करण पेश करने में अधिक सहज हैं। यानी, सबसे पहले, यह आत्मविश्वास के बारे में है, विकास के लिए तत्परता के बारे में है और विश्वसनीयता के बारे में है

एक अन्य प्रश्न: "क्या Yandex.Cloud में रहने वाले बाहरी उपयोगकर्ताओं की आवश्यकताएं आंतरिक क्लाउड में रहने वाले आंतरिक उपयोगकर्ताओं से भिन्न हैं?"

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

अगला प्रश्न: "आप व्यक्तिगत रूप से इस तथ्य के बारे में कैसा महसूस करते हैं कि आप जो भी करते हैं उसका अधिकांश उपयोग अन्य क्लाउड द्वारा किया जाता है?" हम विशिष्ट लोगों का नाम नहीं लेंगे, लेकिन Yandex.Cloud में किए गए कई प्रोजेक्ट अन्य लोगों के क्लाउड में उपयोग किए जाते हैं।

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

आपने मैराथन के बारे में बहुत सारी बातें कीं। मुझे पता है कि आपने मॉस्को में मैराथन दौड़ लगाई थी। नतीजतन? PostgreSQL के लोगों से आगे निकल गए?

नहीं, ओलेग बार्टुनोव बहुत तेज़ दौड़ता है। उसने मुझसे एक घंटा पहले काम पूरा कर लिया। कुल मिलाकर, मैं जितना आगे आया उससे खुश हूँ। मेरे लिए, बस समापन करना एक उपलब्धि थी। कुल मिलाकर, यह आश्चर्यजनक है कि पोस्टग्रेज समुदाय में इतने सारे धावक हैं। मुझे ऐसा लगता है कि एरोबिक खेलों और सिस्टम प्रोग्रामिंग की इच्छा के बीच किसी प्रकार का संबंध है।

क्या आप कह रहे हैं कि ClickHouse पर कोई धावक नहीं हैं?

मैं निश्चित रूप से जानता हूं कि वे वहां हैं। ClickHouse भी एक डेटाबेस है. वैसे, ओलेग अब मुझे लिख रहा है: "क्या हमें रिपोर्ट के बाद दौड़ने जाना चाहिए?" यह एक महान विचार है।

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

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

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

यह एक दिलचस्प सवाल है: "कहां से शुरू करें?" कर्नेल में किसी चीज़ से शुरुआत करना आमतौर पर काफी कठिन होता है। उदाहरण के लिए, पोस्टग्रेज़ में करने योग्य एक सूची होती है। लेकिन वास्तव में, यह उस चीज़ की एक शीट है जो उन्होंने करने की कोशिश की, लेकिन सफल नहीं हुए। ये जटिल चीजें हैं. और आमतौर पर आप पारिस्थितिकी तंत्र में कुछ उपयोगिताएँ, कुछ एक्सटेंशन पा सकते हैं जिन्हें बेहतर बनाया जा सकता है, जो कर्नेल डेवलपर्स का कम ध्यान आकर्षित करते हैं। और, तदनुसार, वहाँ विकास के लिए और अधिक बिंदु हैं। Google समर ऑफ़ कोड प्रोग्राम में, हर साल पोस्टग्रेज़ समुदाय कई अलग-अलग विषयों को सामने रखता है जिन्हें संबोधित किया जा सकता है। मुझे लगता है, इस साल हमारे पास तीन छात्र थे। एक ने WAL-G में उन विषयों पर भी लिखा जो Yandex के लिए महत्वपूर्ण हैं। ग्रीनप्लम में, पोस्टग्रेज समुदाय की तुलना में सब कुछ सरल है, क्योंकि ग्रीनप्लम हैकर्स पुल अनुरोधों को बहुत अच्छी तरह से मानते हैं और तुरंत समीक्षा करना शुरू कर देते हैं। पोस्टग्रेज को पैच भेजना कुछ महीनों की बात है, लेकिन ग्रीनप्लम एक दिन में आएगा और देखेगा कि आपने क्या किया है। दूसरी बात यह है कि ग्रीनप्लम को मौजूदा समस्याओं का समाधान करने की जरूरत है। ग्रीनप्लम का व्यापक रूप से उपयोग नहीं किया जाता है, इसलिए आपकी समस्या का पता लगाना काफी कठिन है। और निःसंदेह, सबसे पहले हमें समस्याओं का समाधान करना होगा।

स्रोत: www.habr.com

हम ओपन सोर्स डेटाबेस में क्या और क्यों करते हैं। एंड्री बोरोडिन (Yandex.Cloud)