ओपन सोर्स डेटाबेसमध्ये आम्ही काय आणि का करतो. आंद्रे बोरोडिन (Yandex.Cloud)

यांडेक्सच्या खालील डेटाबेसमधील योगदानाचे पुनरावलोकन केले जाईल.

• क्लिकहाऊस
• ओडिसी
• वेळेत पुनर्प्राप्ती (WAL-G)
• PostgreSQL (लॉगएरर, Amcheck, heapcheck सह)
• ग्रीनप्लम

व्हिडिओ:

नमस्कार जग! माझे नाव आंद्रे बोरोडिन आहे. आणि मी Yandex.Cloud वर जे करतो ते Yandex.Cloud आणि Yandex.Cloud क्लायंटच्या हितासाठी खुले रिलेशनल डेटाबेस विकसित करणे आहे.

या चर्चेत, आम्ही मोठ्या प्रमाणावर खुल्या डेटाबेसला तोंड देत असलेल्या आव्हानांबद्दल बोलू. ते महत्त्वाचे का आहे? कारण छोट्या छोट्या समस्या ज्या डासांप्रमाणे मग हत्ती बनतात. जेव्हा तुमच्याकडे अनेक क्लस्टर्स असतात तेव्हा ते मोठे होतात.

पण ती मुख्य गोष्ट नाही. अविश्वसनीय गोष्टी घडतात. दशलक्ष प्रकरणांपैकी एकामध्ये घडणाऱ्या गोष्टी. आणि ढगांच्या वातावरणात, तुम्हाला त्यासाठी तयार राहावे लागेल, कारण जेव्हा एखादी गोष्ट मोठ्या प्रमाणावर अस्तित्वात असते तेव्हा अविश्वसनीय गोष्टी अत्यंत संभाव्य बनतात.

परंतु! खुल्या डेटाबेसचा फायदा काय आहे? वस्तुस्थिती अशी आहे की आपल्याकडे कोणत्याही समस्येचा सामना करण्याची सैद्धांतिक संधी आहे. तुमच्याकडे सोर्स कोड आहे, तुम्हाला प्रोग्रामिंगचे ज्ञान आहे. आम्ही ते एकत्र करतो आणि ते कार्य करते.

ओपन सोर्स सॉफ्टवेअरवर काम करताना कोणते दृष्टिकोन आहेत?

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

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

आणि डेटाबेस म्हणून, एक इकोसिस्टम तयार करण्यासाठी आणि इतर विकसकांसह (केवळ यांडेक्समध्येच नाही) विकसित करण्यासाठी ते मुक्त स्त्रोतामध्ये तयार केले गेले होते. आणि आता हा एक मोठा प्रकल्प आहे ज्यामध्ये विविध कंपन्या गुंतलेल्या आहेत.

Yandex.Cloud मध्ये, आम्ही Yandex ऑब्जेक्ट स्टोरेजच्या शीर्षस्थानी, म्हणजे क्लाउड स्टोरेजच्या शीर्षस्थानी क्लिकहाऊस तयार केले.

मेघमध्ये हे महत्त्वाचे का आहे? कारण कोणताही डेटाबेस या त्रिकोणात, या पिरॅमिडमध्ये, मेमरी प्रकारांच्या या पदानुक्रमात काम करतो. तुमच्याकडे वेगवान पण लहान रजिस्टर्स आणि स्वस्त मोठी पण मंद SSD, हार्ड ड्राइव्ह आणि काही इतर ब्लॉक साधने आहेत. आणि जर तुम्ही पिरॅमिडच्या शीर्षस्थानी कार्यक्षम असाल, तर तुमच्याकडे एक वेगवान डेटाबेस आहे. जर तुम्ही या पिरॅमिडच्या तळाशी कार्यक्षम असाल, तर तुमच्याकडे स्केल केलेला डेटाबेस आहे. आणि या संदर्भात, डेटाबेसची स्केलेबिलिटी वाढवण्यासाठी खालीून आणखी एक स्तर जोडणे हा एक तार्किक दृष्टीकोन आहे.

ते कसे केले जाऊ शकते? हा या अहवालातील महत्त्वाचा मुद्दा आहे.

• आम्ही MDS वर क्लिकहाऊस लागू करू शकतो. MDS एक अंतर्गत Yandex क्लाउड स्टोरेज इंटरफेस आहे. हे सामान्य S3 प्रोटोकॉलपेक्षा अधिक जटिल आहे, परंतु ते ब्लॉक डिव्हाइससाठी अधिक योग्य आहे. डेटा रेकॉर्ड करणे चांगले आहे. यासाठी अधिक प्रोग्रामिंग आवश्यक आहे. प्रोग्रामर प्रोग्राम करतील, ते अगदी चांगले आहे, ते मनोरंजक आहे.
• S3 हा अधिक सामान्य दृष्टीकोन आहे जो विशिष्ट प्रकारच्या वर्कलोड्सशी कमी जुळवून घेण्याच्या खर्चात इंटरफेस सुलभ करतो.

साहजिकच, संपूर्ण ClickHouse इकोसिस्टमला कार्यक्षमता प्रदान करून Yandex.Cloud मध्ये आवश्यक असलेले कार्य करू इच्छित असल्यामुळे, संपूर्ण ClickHouse समुदायाला त्याचा फायदा होईल याची खात्री करण्याचे आम्ही ठरवले. आम्ही क्लिकहाऊस S3 वर लागू केले, MDS वर क्लिकहाऊस नाही. आणि हे खूप काम आहे.

दुवे:

https://github.com/ClickHouse/ClickHouse/pull/7946 "फाइलसिस्टम अॅब्स्ट्रॅक्शन लेयर"
https://github.com/ClickHouse/ClickHouse/pull/8011 "AWS SDK S3 एकत्रीकरण"
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 साठी स्टोरेज MergeTree प्रारंभिक समर्थन"
https://github.com/ClickHouse/ClickHouse/pull/9646 "S3 साठी MergeTree पूर्ण समर्थन"
https://github.com/ClickHouse/ClickHouse/pull/10126 "S3 वर ReplicatedMergeTree ला सपोर्ट करा"
https://github.com/ClickHouse/ClickHouse/pull/11134 "s3 स्टोरेजसाठी डीफॉल्ट क्रेडेन्शियल आणि सानुकूल शीर्षलेख जोडा"
https://github.com/ClickHouse/ClickHouse/pull/10576 "डायनॅमिक प्रॉक्सी कॉन्फिगरेशनसह S3"
https://github.com/ClickHouse/ClickHouse/pull/10744 "प्रॉक्सी रिझोल्व्हरसह S3"

क्लिकहाऊसमध्ये व्हर्च्युअल फाइल सिस्टम कार्यान्वित करण्यासाठी ही पुल विनंती सूची आहे. ही मोठ्या प्रमाणात पुल विनंती आहे.

दुवे:

https://github.com/ClickHouse/ClickHouse/pull/9760 "डिस्कएस 3 हार्डलिंक इष्टतम अंमलबजावणी"
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 "DiskLocal वरून DiskS3 वर समांतर भाग हलवा"

पण काम तिथेच संपले नाही. वैशिष्ट्य बनविल्यानंतर, ही कार्यक्षमता ऑप्टिमाइझ करण्यासाठी आणखी काही काम करणे आवश्यक होते.

दुवे:

https://github.com/ClickHouse/ClickHouse/pull/12638 "SelectedRows आणि SelectedBytes इव्हेंट जोडा"
https://github.com/ClickHouse/ClickHouse/pull/12464 "S3 विनंतीवरून system.events मध्ये प्रोफाइलिंग इव्हेंट जोडा"
https://github.com/ClickHouse/ClickHouse/pull/13028 "QueryTimeMicroseconds, SelectQueryTimeMicroseconds आणि InsertQueryTimeMicroseconds जोडा"

आणि मग ते निदान करण्यायोग्य बनवणे, मॉनिटरिंग सेट करणे आणि ते व्यवस्थापित करणे आवश्यक होते.

आणि हे सर्व केले गेले जेणेकरून संपूर्ण समुदायाला, संपूर्ण क्लिकहाऊस इकोसिस्टमला या कार्याचे फळ मिळाले.

चला ट्रान्झॅक्शनल डेटाबेसेस, OLTP डेटाबेसेसकडे जाऊया, जे वैयक्तिकरित्या माझ्या जवळ आहेत.

हा मुक्त स्रोत DBMS विकास विभाग आहे. हे लोक ट्रान्झॅक्शनल ओपन डेटाबेस सुधारण्यासाठी स्ट्रीट मॅजिक करत आहेत.

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

पोस्टग्रेस हा प्रोसेस डेटाबेस आहे. याचा अर्थ डेटाबेसमध्ये शक्य तितके कमी नेटवर्क कनेक्शन असावेत जे व्यवहार हाताळतात.

दुसरीकडे, क्लाउड वातावरणात, एक सामान्य परिस्थिती असते जेव्हा एका क्लस्टरमध्ये एकाच वेळी हजार कनेक्शन येतात. आणि कनेक्शन पूलरचे कार्य एक हजार कनेक्शन्स थोड्या संख्येने सर्व्हर कनेक्शनमध्ये पॅक करणे आहे.

आम्ही असे म्हणू शकतो की कनेक्शन पूलर हा टेलिफोन ऑपरेटर आहे जो बाइट्सची पुनर्रचना करतो जेणेकरून ते डेटाबेसपर्यंत कार्यक्षमतेने पोहोचतील.

दुर्दैवाने, कनेक्शन पूलरसाठी कोणताही चांगला रशियन शब्द नाही. कधीकधी याला मल्टीप्लेक्सर कनेक्शन म्हणतात. कनेक्शन पूलरला काय म्हणायचे हे आपल्याला माहित असल्यास, मला नक्की सांगा, मला योग्य रशियन तांत्रिक भाषा बोलण्यात खूप आनंद होईल.

https://pgconf.ru/2017/92899

आम्ही व्यवस्थापित पोस्टग्रेस क्लस्टरसाठी योग्य असलेल्या कनेक्शन पूलर्सची तपासणी केली. आणि PgBouncer हा आमच्यासाठी सर्वोत्तम पर्याय होता. परंतु आम्हाला 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 मध्ये Postgres क्लस्टर तयार केले तर ते अंगभूत Odyssey सह क्लस्टर असेल, जे क्लस्टरला मागे किंवा पुढे स्केल करताना पुन्हा कॉन्फिगर केले जाते.

या प्रकल्पातून आपण काय शिकलो? प्रतिस्पर्धी प्रकल्प लाँच करणे हे नेहमीच एक आक्रमक पाऊल असते, जेव्हा आपण असे म्हणतो की अशा समस्या आहेत ज्या लवकर सोडवल्या जात नाहीत, आपल्यासाठी योग्य वेळेच्या अंतराने सोडवल्या जात नाहीत. पण हा एक प्रभावी उपाय आहे.

PgBouncer वेगाने विकसित होऊ लागला.

आणि आता इतर प्रकल्प दिसू लागले आहेत. उदाहरणार्थ, pgagroal, जे Red Hat विकसकांद्वारे विकसित केले जाते. ते समान ध्येयांचा पाठपुरावा करतात आणि समान कल्पना अंमलात आणतात, परंतु, अर्थातच, त्यांच्या स्वतःच्या वैशिष्ट्यांसह, जे pgagroal विकासकांच्या जवळ आहेत.

पोस्टग्रेस समुदायासह काम करण्याचे आणखी एक प्रकरण वेळेत पुनर्संचयित होत आहे. ही अपयशानंतरची पुनर्प्राप्ती आहे, ही बॅकअपमधून पुनर्प्राप्ती आहे.

बरेच बॅकअप आहेत आणि ते सर्व भिन्न आहेत. जवळजवळ प्रत्येक पोस्टग्रेस विक्रेत्याचे स्वतःचे बॅकअप समाधान असते.

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

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

आम्ही या समस्येवर काम करत असताना, CitusData ने WAL-G प्रकल्प लाँच केला. ही एक बॅकअप प्रणाली आहे जी क्लाउड वातावरणाकडे लक्ष देऊन बनविली गेली आहे. आता CitusData आधीच मायक्रोसॉफ्टचा भाग आहे. आणि त्या क्षणी, WAL-G च्या सुरुवातीच्या प्रकाशनांमध्ये मांडलेल्या कल्पना आम्हाला खरोखर आवडल्या. आणि आम्ही या प्रकल्पात योगदान देऊ लागलो.

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

आता या प्रकल्पात अनेक डझनभर विकसक आहेत, परंतु WAL-G मध्ये शीर्ष 10 योगदानकर्त्यांमध्ये 6 Yandexoids समाविष्ट आहेत. आम्ही आमच्या अनेक कल्पना तिथे आणल्या. आणि अर्थातच, आम्ही त्यांची स्वतः अंमलबजावणी केली, त्यांची स्वतः चाचणी केली, त्यांना स्वतः उत्पादनात आणले, आम्ही ते स्वतः वापरतो, मोठ्या WAL-G समुदायाशी संवाद साधताना आम्ही स्वतःच पुढे कुठे जायचे हे शोधून काढतो.

आणि आमच्या दृष्टिकोनातून, आता ही बॅकअप प्रणाली, आमचे प्रयत्न लक्षात घेऊन, क्लाउड वातावरणासाठी इष्टतम बनली आहे. क्लाउडमध्ये पोस्टग्रेसचा बॅकअप घेण्याची ही सर्वोत्तम किंमत आहे.

याचा अर्थ काय? आम्ही एका मोठ्या कल्पनेचा प्रचार करत होतो: बॅकअप सुरक्षित, ऑपरेट करण्यासाठी स्वस्त आणि पुनर्संचयित करण्यासाठी शक्य तितक्या जलद असावा.

ते ऑपरेट करणे स्वस्त का असावे? जेव्हा काहीही तुटलेले नसते, तेव्हा तुम्हाला माहित नसावे की तुमच्याकडे बॅकअप आहेत. सर्व काही ठीक चालते, तुम्ही शक्य तितक्या कमी CPU वाया घालवता, तुम्ही तुमच्या डिस्क संसाधनांचा शक्य तितका कमी वापर करता आणि तुमच्या मौल्यवान सेवांच्या पेलोडमध्ये व्यत्यय आणू नये म्हणून तुम्ही शक्य तितक्या कमी बाइट नेटवर्कला पाठवता.

आणि जेव्हा सर्वकाही खंडित होते, उदाहरणार्थ, प्रशासकाने डेटा टाकला, काहीतरी चूक झाली आणि आपल्याला त्वरित भूतकाळात परत जाण्याची आवश्यकता आहे, आपण सर्व पैशांनी पुनर्प्राप्त कराल, कारण आपल्याला आपला डेटा त्वरित आणि अखंड हवा आहे.

आणि आम्ही या साध्या कल्पनेचा प्रचार केला. आणि, आम्हाला असे दिसते की आम्ही ते अंमलात आणण्यात व्यवस्थापित केले.

पण एवढेच नाही. आम्हाला आणखी एक छोटी गोष्ट हवी होती. आम्हाला अनेक भिन्न डेटाबेस हवे होते. आमचे सर्व क्लायंट पोस्टग्रेस वापरत नाहीत. काही लोक MySQL, MongoDB वापरतात. समुदायामध्ये, इतर विकासकांनी FoundationDB ला समर्थन दिले आहे. आणि ही यादी सतत विस्तारत आहे.

क्लाउडमधील व्यवस्थापित वातावरणात डेटाबेस चालवण्याची कल्पना समुदायाला आवडते. आणि डेव्हलपर त्यांचे डेटाबेस राखून ठेवतात, ज्याचा बॅकअप आमच्या बॅकअप सिस्टमसह पोस्टग्रेससह समानपणे घेतला जाऊ शकतो.

या कथेतून आपण काय शिकलो? आमचे उत्पादन, विकास विभाग म्हणून, कोडच्या ओळी नाहीत, ते विधाने नाहीत, फाइल्स नाहीत. आमचे उत्पादन पुल विनंत्या नाही. हेच विचार आपण समाजापर्यंत पोहोचवतो. हे तंत्रज्ञानाचे कौशल्य आणि क्लाउड वातावरणाकडे तंत्रज्ञानाची हालचाल आहे.

Postgres सारखा डेटाबेस आहे. मला पोस्टग्रेस कोर सर्वात जास्त आवडतो. मी समुदायासह पोस्टग्रेस कोर विकसित करण्यात बराच वेळ घालवतो.

परंतु येथे असे म्हटले पाहिजे की Yandex.Cloud मध्ये व्यवस्थापित डेटाबेसची अंतर्गत स्थापना आहे. आणि ते Yandex.Mail मध्ये खूप पूर्वी सुरू झाले. ज्या कौशल्यामुळे आता पोस्टग्रेस व्यवस्थापित केले गेले आहे ते जमा झाले जेव्हा मेलला पोस्टग्रेसमध्ये हलवायचे होते.

मेलची क्लाउडशी खूप समान आवश्यकता आहे. तुमच्या डेटाच्या कोणत्याही टप्प्यावर तुम्ही अनपेक्षित घातांकीय वाढ मोजण्यास सक्षम असणे आवश्यक आहे. आणि मेलमध्ये आधीपासूनच अनेक लाखो मेलबॉक्सेसचा भार आहे जे सतत अनेक विनंत्या करतात.

आणि पोस्टग्रेस विकसित करणार्‍या संघासाठी हे एक गंभीर आव्हान होते. त्यानंतर, आम्हाला आलेल्या कोणत्याही समस्या समुदायाला कळवल्या गेल्या. आणि या समस्या दुरुस्त केल्या गेल्या, आणि काही ठिकाणी समुदायाद्वारे दुरुस्त केल्या गेल्या अगदी काही इतर डेटाबेसेससाठी सशुल्क समर्थनाच्या पातळीवर आणि त्याहूनही चांगले. म्हणजेच, तुम्ही PgSQL हॅकरला पत्र पाठवू शकता आणि 40 मिनिटांच्या आत प्रतिसाद प्राप्त करू शकता. काही डेटाबेसमध्‍ये सशुल्‍क सपोर्ट असे वाटू शकते की आपल्‍या बगपेक्षा अधिक प्राधान्यपूर्ण गोष्टी आहेत.

आता पोस्टग्रेसची अंतर्गत स्थापना डेटाचे काही पेटाबाइट्स आहे. या प्रति सेकंद काही लाखो विनंत्या आहेत. हे हजारो क्लस्टर्स आहेत. ते खूप मोठ्या प्रमाणात आहे.

पण एक बारकावे आहे. हे फॅन्सी नेटवर्क ड्राइव्हवर नाही तर अगदी साध्या हार्डवेअरवर जगते. आणि विशेषत: मनोरंजक नवीन गोष्टींसाठी चाचणी वातावरण आहे.

आणि चाचणी वातावरणात एका विशिष्ट क्षणी आम्हाला एक संदेश प्राप्त झाला जो सूचित करतो की डेटाबेस निर्देशांकांच्या अंतर्गत अपरिवर्तनीयांचे उल्लंघन झाले आहे.

अपरिवर्तनीय असा एक प्रकारचा संबंध आहे जो आपण नेहमी ठेवण्याची अपेक्षा करतो.

आमच्यासाठी एक अतिशय गंभीर परिस्थिती. हे सूचित करते की काही डेटा गमावला गेला असावा. आणि डेटा गमावणे ही काहीतरी आपत्तीजनक आहे.

आम्ही व्यवस्थापित डेटाबेसमध्ये अनुसरण करतो ती सामान्य कल्पना अशी आहे की प्रयत्न करूनही, डेटा गमावणे कठीण होईल. जरी तुम्ही त्यांना मुद्दाम काढून टाकले, तरीही तुम्हाला त्यांच्या दीर्घ कालावधीसाठी त्यांच्या अनुपस्थितीकडे दुर्लक्ष करावे लागेल. डेटा सुरक्षितता हा एक धर्म आहे ज्याचे पालन आपण खूप मेहनतीने करतो.

आणि येथे अशी परिस्थिती उद्भवते जी सूचित करते की अशी परिस्थिती असू शकते ज्यासाठी आपण तयार नसू शकतो. आणि आम्ही या परिस्थितीसाठी तयारी करू लागलो.

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

या हजारो क्लस्टर्समधील नोंदी पुरणे ही पहिली गोष्ट आम्ही केली. आम्हाला आढळले की कोणते क्लस्टर समस्याग्रस्त फर्मवेअर असलेल्या डिस्कवर आहेत जे डेटा पृष्ठ अद्यतने गमावत आहेत. सर्व पोस्टग्रेस डेटा कोड चिन्हांकित केले. आणि आम्‍ही ते संदेश चिन्हांकित केले जे डेटा करप्‍शन शोधण्‍यासाठी डिझाईन करण्‍यात आलेल्‍या कोडसह अंतर्गत अपरिवर्तनीयांचे उल्लंघन दर्शवतात.

हा पॅच समाजाने फारशी चर्चा न करता व्यावहारिकरित्या स्वीकारला होता, कारण प्रत्येक विशिष्ट प्रकरणात काहीतरी वाईट घडले आहे हे स्पष्ट होते आणि लॉगला कळवणे आवश्यक होते.

यानंतर, आम्ही या मुद्द्यावर आलो की आमच्याकडे लॉग स्कॅन करण्याचे निरीक्षण आहे. आणि संशयास्पद संदेशांच्या बाबतीत, तो कर्तव्य अधिकाऱ्याला जागे करतो आणि कर्तव्य अधिकारी त्याची दुरुस्ती करतो.

परंतु! लॉग स्कॅन करणे हे एका क्लस्टरवर स्वस्त ऑपरेशन आहे आणि हजार क्लस्टरसाठी आपत्तीजनकदृष्ट्या महाग आहे.

आम्ही नावाचा विस्तार लिहिला लॉगरर. हे डेटाबेसचे एक दृश्य तयार करते ज्यामध्ये आपण मागील त्रुटींवरील आकडेवारी स्वस्त आणि द्रुतपणे निवडू शकता. आणि जर आपल्याला कर्तव्य अधिकाऱ्याला जागे करण्याची आवश्यकता असेल तर आपण गीगाबाईट फायली स्कॅन न करता, परंतु हॅश टेबलमधून काही बाइट्स काढून याबद्दल शोधू.

हा विस्तार स्वीकारला गेला आहे, उदाहरणार्थ, साठी रेपॉजिटरीमध्ये CentOS. आपण ते वापरू इच्छित असल्यास, आपण ते स्वतः स्थापित करू शकता. अर्थात ते ओपन सोर्स आहे.

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

पण एवढेच नाही. इंडेक्सेसमध्ये अपरिवर्तनीय उल्लंघन शोधण्यासाठी आम्ही Amcheck, एक समुदाय-निर्मित विस्तार वापरण्यास सुरुवात केली.

आणि आम्हाला आढळले की जर तुम्ही ते स्केलवर चालवले तर त्यात बग आहेत. आम्ही त्यांना दुरुस्त करायला सुरुवात केली. आमच्या दुरुस्त्या स्वीकारल्या गेल्या आहेत.

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

आम्हाला आढळले की हा विस्तार GIS आणि GIT निर्देशांकांचे विश्लेषण करू शकत नाही. आम्ही त्यांना आधार दिला. परंतु या समर्थनाची अजूनही समुदायाद्वारे चर्चा केली जात आहे, कारण ही तुलनेने नवीन कार्यक्षमता आहे आणि तेथे बरेच तपशील आहेत.

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

आणि आम्हाला हे देखील आढळले की प्रतिकृती लीडरवर, मास्टरवर उल्लंघनासाठी निर्देशांक तपासताना, सर्वकाही चांगले कार्य करते, परंतु प्रतिकृतींवर, अनुयायींवर, भ्रष्टाचाराचा शोध तितका प्रभावी नाही. सर्व अपरिवर्तनीय तपासले जात नाहीत. आणि एका अपरिवर्तनीयाने आम्हाला खूप त्रास दिला. आणि प्रतिकृतींवर ही तपासणी सक्षम करण्यासाठी आम्ही समुदायाशी संवाद साधण्यात दीड वर्ष घालवले.

आम्ही कोड लिहिला ज्याने सर्व कॅन... प्रोटोकॉलचे पालन केले पाहिजे. आम्ही या पॅचवर क्रंची डेटामधील पीटर गगन यांच्याशी काही काळ चर्चा केली. हा पॅच स्वीकारण्यासाठी त्याला पोस्टग्रेसमधील सध्याच्या बी-ट्रीमध्ये थोडासा बदल करावा लागला. तो स्वीकारला गेला. आणि आता प्रतिकृतींवर अनुक्रमणिका तपासणे देखील आम्हाला आढळलेल्या उल्लंघनांचा शोध घेण्यासाठी पुरेसे प्रभावी झाले आहे. म्हणजेच, हे असे उल्लंघन आहेत जे डिस्क फर्मवेअरमधील त्रुटी, पोस्टग्रेसमधील बग, लिनक्स कर्नलमधील बग आणि हार्डवेअर समस्यांमुळे होऊ शकतात. समस्यांच्या स्त्रोतांची एक विस्तृत यादी ज्यासाठी आम्ही तयारी करत होतो.

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

परंतु निर्देशांकांव्यतिरिक्त, ढीग सारखा एक भाग आहे, म्हणजे जिथे डेटा संग्रहित केला जातो. आणि तपासले जाऊ शकणारे बरेच अपरिवर्तनीय नाहीत.

आमच्याकडे Heapcheck नावाचा विस्तार आहे. आम्ही ते विकसित करण्यास सुरुवात केली. आणि समांतर, आमच्याबरोबर, एंटरप्राइजडीबी कंपनीने देखील एक मॉड्यूल लिहायला सुरुवात केली, ज्याला त्यांनी त्याच प्रकारे 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 परिषदेत, मी Pivotal मधील Heikki Linakangas यांच्याशी संपर्क साधला आणि विचारले: “यामध्ये काही समस्या आहेत का? ऑप्टिमाइझ केलेले टेबल क्लस्टरिंग संलग्न का नाही?” तो म्हणतो: “तुम्ही डेटा घ्या. आपण क्रमवारी लावा, आपण पुनर्रचना करा. हे फक्त एक काम आहे." मी: "अरे, हो, तुला फक्त ते घ्यावे लागेल आणि ते करावे लागेल." तो म्हणतो: "होय, हे करण्यासाठी आम्हाला मोकळे हात हवे आहेत." मला वाटले की मला हे नक्कीच करावे लागेल.

आणि काही महिन्यांनंतर मी एक पुल विनंती सबमिट केली ज्याने ही कार्यक्षमता लागू केली. या पुल विनंतीचे समुदायासह पिव्होटलने पुनरावलोकन केले. अर्थात, बग होते.

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 वर्षांचा आहे. आणि डेटाबेस बहुतेकदा विश्वासार्हतेबद्दल असतो. आणि याचा अर्थ असा की डेटाबेस बरेच जुने आहेत आणि ते सहसा C मध्ये लिहिलेले असतात. पोस्टग्रेस प्रकल्प सुमारे 30 वर्षांपूर्वी सुरू झाला. मग C89 ही योग्य निवड होती. आणि त्यावर पोस्टग्रेस लिहिलेले आहे. अधिक आधुनिक डेटाबेस जसे की क्लिकहाऊस सहसा C++ मध्ये लिहिलेले असतात. सर्व प्रणाली विकास C आणि C++ वर आधारित आहे.

क्लाउडवरील खर्चासाठी जबाबदार असलेल्या आमच्या आर्थिक व्यवस्थापकाचा प्रश्न: "क्लाउड ओपन सोर्सला सपोर्ट करण्यासाठी पैसे का खर्च करते?"

येथे आर्थिक व्यवस्थापकासाठी एक सोपे उत्तर आहे. आमच्या सेवा अधिक चांगल्या करण्यासाठी आम्ही हे करतो. कोणत्या मार्गांनी आपण अधिक चांगले करू शकतो? आम्ही गोष्टी अधिक कार्यक्षमतेने, जलद करू शकतो आणि गोष्टी अधिक स्केलेबल बनवू शकतो. परंतु आमच्यासाठी, ही कथा प्रामुख्याने विश्वासार्हतेबद्दल आहे. उदाहरणार्थ, बॅकअप सिस्टममध्ये आम्ही त्यावर लागू होणाऱ्या पॅचचे १००% पुनरावलोकन करतो. कोड काय आहे हे आम्हाला माहीत आहे. आणि आम्ही उत्पादनासाठी नवीन आवृत्त्या आणण्यास अधिक सोयीस्कर आहोत. म्हणजेच, सर्व प्रथम, ते आत्मविश्वास, विकासासाठी तयारी आणि विश्वासार्हतेबद्दल आहे

दुसरा प्रश्न: "Yandex.Cloud मध्ये राहणार्‍या बाह्य वापरकर्त्यांच्या गरजा अंतर्गत क्लाउडमध्ये राहणार्‍या अंतर्गत वापरकर्त्यांपेक्षा वेगळ्या आहेत का?"

लोड प्रोफाइल, अर्थातच, भिन्न आहे. परंतु माझ्या विभागाच्या दृष्टिकोनातून, सर्व विशेष आणि मनोरंजक प्रकरणे नॉन-स्टँडर्ड लोडवर तयार केली जातात. कल्पनाशक्ती असलेले विकसक, अनपेक्षित काम करणारे विकासक आंतरिक आणि बाह्य दोन्ही ठिकाणी आढळण्याची शक्यता असते. या संदर्भात, आम्ही सर्व अंदाजे समान आहोत. आणि, बहुधा, डेटाबेसच्या यांडेक्स ऑपरेशनमधील एकमेव महत्त्वाचे वैशिष्ट्य म्हणजे यांडेक्समध्ये आम्हाला एक शिकवण आहे. काही क्षणी, काही उपलब्धता क्षेत्र पूर्णपणे सावलीत जाते आणि सर्व Yandex सेवा असे असूनही कार्य करत राहणे आवश्यक आहे. हा एक छोटासा फरक आहे. परंतु हे डेटाबेस आणि नेटवर्क स्टॅकच्या इंटरफेसवर भरपूर संशोधन विकास तयार करते. अन्यथा, बाह्य आणि अंतर्गत स्थापना वैशिष्ट्यांसाठी समान विनंत्या आणि विश्वासार्हता आणि कार्यप्रदर्शन सुधारण्यासाठी समान विनंत्या तयार करतात.

पुढील प्रश्न: "तुम्ही जे काही करता त्यातील बरेच काही इतर क्लाउडद्वारे वापरले जाते या वस्तुस्थितीबद्दल तुम्हाला वैयक्तिकरित्या कसे वाटते?" आम्ही विशिष्ट नाव देणार नाही, परंतु Yandex.Cloud मध्ये केलेले अनेक प्रकल्प इतर लोकांच्या क्लाउडमध्ये वापरले जातात.

हे मस्त आहे. प्रथम, हे एक चिन्ह आहे की आपण काहीतरी योग्य केले आहे. आणि अहंकाराला ओरबाडतो. आणि आम्हाला अधिक विश्वास आहे की आम्ही योग्य निर्णय घेतला आहे. दुसरीकडे, ही आशा आहे की भविष्यात हे आम्हाला नवीन कल्पना, तृतीय-पक्ष वापरकर्त्यांकडून नवीन विनंत्या आणेल. GitHub वरील बहुतेक समस्या वैयक्तिक सिस्टम प्रशासक, वैयक्तिक DBA, वैयक्तिक आर्किटेक्ट, वैयक्तिक अभियंते यांनी तयार केल्या आहेत, परंतु कधीकधी पद्धतशीर अनुभव असलेले लोक येतात आणि म्हणतात की 30% विशिष्ट प्रकरणांमध्ये आम्हाला ही समस्या आहे आणि ती कशी सोडवायची याचा विचार करूया. याचीच आपण सर्वाधिक वाट पाहत आहोत. आम्ही इतर क्लाउड प्लॅटफॉर्मसह अनुभव सामायिक करण्यास उत्सुक आहोत.

तुम्ही मॅरेथॉनबद्दल खूप बोललात. मला माहित आहे की तू मॉस्कोमध्ये मॅरेथॉन धावलीस. परिणामी? PostgreSQL मधील मुलांना मागे टाकले?

नाही, ओलेग बार्टुनोव्ह खूप वेगाने धावतो. तो माझ्यापेक्षा एक तास पुढे संपला. एकंदरीत, मी किती पुढे गेलो याबद्दल मी आनंदी आहे. माझ्यासाठी फक्त फिनिशिंग ही एक उपलब्धी होती. एकूणच, पोस्टग्रेस समुदायात इतके धावपटू आहेत हे आश्चर्यकारक आहे. मला असे वाटते की एरोबिक स्पोर्ट्स आणि सिस्टम प्रोग्रामिंगची इच्छा यांच्यात एक प्रकारचा संबंध आहे.

क्लिकहाऊसमध्ये कोणतेही धावपटू नाहीत असे तुम्ही म्हणत आहात?

मला खात्री आहे की ते तिथे आहेत. क्लिकहाऊस देखील एक डेटाबेस आहे. तसे, ओलेग आता मला लिहित आहे: "आम्ही अहवालानंतर धावायला जाऊ का?" ही एक उत्तम कल्पना आहे.

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

होय, तत्त्वतः, ते एखाद्याला दिले जाऊ शकते. मी नुकताच बदललेला कोड होता. आणि लगेच करत राहणे स्वाभाविक होते. तत्वतः, कार्यसंघासह कौशल्य सामायिक करण्याची कल्पना चांगली आहे. आम्ही आमच्या विभागातील सर्व सदस्यांमध्ये ग्रीनप्लमची कामे नक्कीच शेअर करू.

आम्ही कनिष्ठांबद्दल बोलत असल्याने, येथे एक प्रश्न आहे. व्यक्तीने पोस्टग्रेसमध्ये प्रथम कमिट तयार करण्याचा निर्णय घेतला. प्रथम वचनबद्ध करण्यासाठी त्याला काय करण्याची आवश्यकता आहे?

हा एक मनोरंजक प्रश्न आहे: "कोठे सुरू करावे?" कर्नलमधील एखाद्या गोष्टीसह प्रारंभ करणे सहसा खूप कठीण असते. पोस्टग्रेसमध्ये, उदाहरणार्थ, एक करण्याची यादी आहे. पण प्रत्यक्षात त्यांनी काय प्रयत्न केले, पण यश आले नाही, याचे हे पत्रक आहे. या गुंतागुंतीच्या गोष्टी आहेत. आणि सामान्यत: तुम्हाला इकोसिस्टममध्ये काही उपयुक्तता सापडतील, काही विस्तार जे सुधारले जाऊ शकतात, जे कर्नल डेव्हलपर्सचे कमी लक्ष वेधून घेतात. आणि, त्यानुसार, तेथे वाढीसाठी अधिक गुण आहेत. Google समर ऑफ कोड प्रोग्राममध्ये दरवर्षी, पोस्टग्रेस समुदाय अनेक भिन्न विषय पुढे ठेवतो ज्यांना संबोधित केले जाऊ शकते. या वर्षी आमच्याकडे तीन विद्यार्थी होते. एकाने WAL-G मध्ये यांडेक्ससाठी महत्त्वाच्या विषयांवर लिहिले. ग्रीनप्लममध्ये, पोस्टग्रेस समुदायापेक्षा सर्व काही सोपे आहे, कारण ग्रीनप्लम हॅकर्स पुल विनंत्या चांगल्या प्रकारे हाताळतात आणि लगेच पुनरावलोकन सुरू करतात. पोस्टग्रेसला पॅच पाठवणे ही काही महिन्यांची बाब आहे, परंतु ग्रीनप्लम एका दिवसात येईल आणि आपण काय केले ते पहा. दुसरी गोष्ट म्हणजे ग्रीनप्लमला सध्याच्या समस्यांचे निराकरण करणे आवश्यक आहे. ग्रीनप्लमचा मोठ्या प्रमाणावर वापर केला जात नाही, त्यामुळे तुमची समस्या शोधणे खूप कठीण आहे. आणि सर्व प्रथम, आपल्याला नक्कीच समस्या सोडवण्याची गरज आहे.

स्त्रोत: www.habr.com