हामी खुला स्रोत डाटाबेसमा के र किन गर्छौं। Andrey Borodin (Yandex.Cloud)

निम्न डेटाबेसहरूमा Yandex को योगदान समीक्षा गरिनेछ।

• क्लिकहाउस
• Odyssey
• समयको एक बिन्दुमा रिकभरी (WAL-G)
• PostgreSQL (लग त्रुटिहरू, Amcheck, heapcheck सहित)
• ग्रीनप्लम

भिडियो:

नमस्कार संसार! मेरो नाम Andrey Borodin हो। र म Yandex.Cloud मा के गर्छु भनेको Yandex.Cloud र Yandex.Cloud ग्राहकहरूको हितमा खुला रिलेसनल डाटाबेसहरू विकास गर्नु हो।

यस वार्तामा, हामी खुल्ला डाटाबेसहरूको स्तरमा सामना गर्ने चुनौतीहरूको बारेमा कुरा गर्नेछौं। यो किन महत्त्वपूर्ण छ? किनभने लामखुट्टे जस्ता सानातिना समस्याहरू हात्ती बन्छन्। तपाईंसँग धेरै क्लस्टरहरू हुँदा तिनीहरू ठूलो हुन्छन्।

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

तर! खुला डाटाबेसको फाइदा के हो? तथ्य यो हो कि तपाईसँग कुनै पनि समस्याको सामना गर्ने सैद्धान्तिक अवसर छ। तपाईंसँग स्रोत कोड छ, तपाईंसँग प्रोग्रामिङ ज्ञान छ। हामी यसलाई संयोजन गर्छौं र यसले काम गर्छ।

खुला स्रोत सफ्टवेयरमा काम गर्ने तरिकाहरू के के छन्?

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

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

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

Yandex.Cloud मा, हामीले Yandex वस्तु भण्डारणको माथि, अर्थात् क्लाउड भण्डारणको शीर्षमा ClickHouse सिर्जना गर्यौं।

क्लाउडमा यो किन महत्त्वपूर्ण छ? किनभने कुनै पनि डाटाबेसले यो त्रिकोणमा, यो पिरामिडमा, मेमोरी प्रकारहरूको यो पदानुक्रममा काम गर्दछ। तपाईंसँग छिटो तर सानो दर्ताहरू र सस्तो ठूला तर ढिलो SSDs, हार्ड ड्राइभहरू र केही अन्य ब्लक उपकरणहरू छन्। र यदि तपाइँ पिरामिडको शीर्षमा कुशल हुनुहुन्छ भने, तपाइँसँग छिटो डाटाबेस छ। यदि तपाईं यस पिरामिडको फेदमा कुशल हुनुहुन्छ भने, तपाईंसँग स्केल गरिएको डाटाबेस छ। र यस सन्दर्भमा, तलबाट अर्को तह थप्नु भनेको डाटाबेसको स्केलेबिलिटी बढाउनको लागि तार्किक दृष्टिकोण हो।

यो कसरी गर्न सकिन्छ? यो प्रतिवेदनमा महत्वपूर्ण कुरा हो।

• हामीले 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 "IDisk इन्टरफेस संग लग भण्डारण इन्जिन को एकीकरण"
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 को लागि मर्जट्री पूर्ण समर्थन"
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"

यो 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 "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 विकास विभाजन हो। यी केटाहरूले लेनदेन खुला डाटाबेसहरू सुधार गर्न सडक जादू गरिरहेका छन्।

एउटा प्रोजेक्ट, जसको उदाहरण प्रयोग गरेर हामी कसरी र के गर्छौं भन्ने बारे कुरा गर्न सक्छौं, पोस्टग्रेसमा जडान पूलर हो।

Postgres एक प्रक्रिया डाटाबेस हो। यसको मतलब यो हो कि डाटाबेसमा लेनदेन ह्यान्डल गर्ने सकेसम्म कम नेटवर्क जडानहरू हुनुपर्छ।

अर्कोतर्फ, क्लाउड वातावरणमा, एक सामान्य अवस्था हो जब हजारौं जडानहरू एकै पटकमा एक क्लस्टरमा आउँछन्। र जडान पूलरको कार्य एक हजार जडानहरू थोरै संख्यामा सर्भर जडानहरूमा प्याक गर्नु हो।

हामी भन्न सक्छौं कि जडान पूलर टेलिफोन अपरेटर हो जसले बाइटहरू पुन: व्यवस्थित गर्दछ ताकि तिनीहरू कुशलतापूर्वक डेटाबेसमा पुग्छन्।

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

https://pgconf.ru/2017/92899

हामीले जडान पूलरहरू छान्यौं जुन व्यवस्थित पोस्टग्रेस क्लस्टरको लागि उपयुक्त थियो। र PgBouncer हाम्रो लागि उत्तम विकल्प थियो। तर हामीले PgBouncer सँग धेरै समस्याहरूको सामना गर्यौं। धेरै वर्ष पहिले, Volodya Borodin ले रिपोर्ट दिए कि हामी 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 विकासकर्ताहरूको नजिक छ।

पोस्टग्रेस समुदायसँग काम गर्ने अर्को केस समयको एक बिन्दुमा पुनर्स्थापित हुँदैछ। यो असफलता पछि रिकभरी हो, यो ब्याकअपबाट रिकभरी हो।

त्यहाँ धेरै ब्याकअपहरू छन् र तिनीहरू सबै फरक छन्। लगभग हरेक Postgres विक्रेताको आफ्नै ब्याकअप समाधान छ।

यदि तपाइँ सबै ब्याकअप प्रणालीहरू लिनुभयो भने, एक सुविधा म्याट्रिक्स सिर्जना गर्नुहोस् र मजाक गर्दै यो म्याट्रिक्समा निर्धारक गणना गर्नुहोस्, यो शून्य हुनेछ। यसको मतलब के हो? यदि तपाइँ एक विशिष्ट ब्याकअप फाइल लिनुहुन्छ भने, त्यसपछि यो सबै अन्य को टुक्राहरु बाट भेला गर्न सकिदैन। यो यसको कार्यान्वयनमा अद्वितीय छ, यो यसको उद्देश्यमा अद्वितीय छ, यो यसमा सम्मिलित विचारहरूमा अद्वितीय छ। र तिनीहरू सबै विशिष्ट छन्।

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

हामीले यस मुद्दामा काम गरिरहेको बेला, CitusData ले WAL-G परियोजना सुरु गर्‍यो। यो एक ब्याकअप प्रणाली हो जुन क्लाउड वातावरणमा आँखा राखेर बनाइएको थियो। अब CitusData पहिले नै Microsoft को भाग हो। र त्यो क्षणमा, हामीले WAL-G को प्रारम्भिक रिलीजहरूमा राखिएका विचारहरू मन पराएका थियौं। र हामीले यो परियोजनामा ​​योगदान गर्न थाल्यौं।

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

अब यस परियोजनामा ​​धेरै दर्जन विकासकर्ताहरू छन्, तर WAL-G मा शीर्ष 10 योगदानकर्ताहरू 6 Yandexoids समावेश छन्। हामीले हाम्रा धेरै विचारहरू त्यहाँ ल्याएका छौं। र, निस्सन्देह, हामीले तिनीहरूलाई आफैं लागू गर्यौं, तिनीहरूलाई आफैंले परीक्षण गर्‍यौं, तिनीहरूलाई उत्पादनमा आफैं रोल आउट गर्यौं, हामी आफैं तिनीहरूलाई प्रयोग गर्छौं, हामी आफैंले ठूलो WAL-G समुदायसँग अन्तर्क्रिया गर्दा, अर्को ठाउँमा जाने भनेर पत्ता लगाउँछौं।

र हाम्रो दृष्टिकोणबाट, अब यो ब्याकअप प्रणाली, हाम्रा प्रयासहरूलाई ध्यानमा राख्दै, क्लाउड वातावरणको लागि इष्टतम भएको छ। यो क्लाउडमा पोस्टग्रेस ब्याकअप गर्ने उत्तम लागत हो।

यसको मतलब के हो? हामीले एकदमै ठूलो विचारलाई प्रवर्द्धन गरिरहेका थियौं: ब्याकअप सुरक्षित, सञ्चालन गर्न सस्तो र पुनर्स्थापना गर्न सकेसम्म छिटो हुनुपर्छ।

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

र जब सबै कुरा बिग्रन्छ, उदाहरणका लागि, प्रशासकले डेटा छोड्यो, केहि गलत भयो, र तपाइँ तुरुन्तै विगतमा फर्किनु पर्छ, तपाइँ सबै पैसा संग पुन: प्राप्ति गर्न आवश्यक छ, किनकि तपाइँ तपाइँको डेटा छिटो र अक्षुण्ण चाहनुहुन्छ।

र हामीले यो सरल विचारलाई बढावा दियौं। र, यो हामीलाई लाग्दछ, हामीले यसलाई कार्यान्वयन गर्न व्यवस्थित गर्यौं।

तर यति मात्र होइन। हामीले अर्को एउटा सानो कुरा चाहियो। हामीले धेरै फरक डाटाबेस चाहन्थ्यौं। हाम्रा सबै ग्राहकहरूले Postgres प्रयोग गर्दैनन्। केही मानिसहरू MySQL, MongoDB प्रयोग गर्छन्। समुदायमा, अन्य विकासकर्ताहरूले FoundationDB लाई समर्थन गरेका छन्। र यो सूची लगातार विस्तार भइरहेको छ।

समुदायले क्लाउडमा व्यवस्थित वातावरणमा डाटाबेस चलाउने विचार मन पराउँछ। र विकासकर्ताहरूले उनीहरूको डाटाबेसहरू कायम राख्छन्, जुन हाम्रो ब्याकअप प्रणालीको साथ Postgres सँग समान रूपमा ब्याकअप गर्न सकिन्छ।

यो कथाबाट हामीले के सिक्यौं? हाम्रो उत्पादन, विकास विभाजनको रूपमा, कोडको लाइनहरू होइन, यो कथनहरू होइन, यो फाइलहरू होइन। हाम्रो उत्पादन पुल अनुरोध छैन। यी विचारहरू हुन् जुन हामीले समुदायलाई बुझाउँछौं। यो प्राविधिक विशेषज्ञता र क्लाउड वातावरण तिर टेक्नोलोजीको आन्दोलन हो।

Postgres को रूपमा यस्तो डाटाबेस छ। मलाई पोस्टग्रेस कोर सबैभन्दा मनपर्छ। म समुदायसँग Postgres कोर विकास गर्न धेरै समय खर्च गर्छु।

तर यहाँ यो भन्नु पर्छ कि Yandex.Cloud मा व्यवस्थित डेटाबेस को आन्तरिक स्थापना छ। र यो Yandex.Mail मा लामो समय पहिले सुरु भयो। विशेषज्ञता जसले अब पोस्टग्रेसलाई व्यवस्थित गर्न नेतृत्व गरेको छ जब मेल पोस्टग्रेसमा सार्न चाहन्थे।

मेल क्लाउडमा धेरै समान आवश्यकताहरू छन्। यसको लागि तपाइँ तपाइँको डेटाको कुनै पनि बिन्दुमा अप्रत्याशित घातीय वृद्धि मापन गर्न सक्षम हुन आवश्यक छ। र मेलमा पहिले नै धेरै संख्यामा धेरै अनुरोध गर्ने प्रयोगकर्ताहरूको केहि सयौं लाखौं मेलबक्सहरूसँग लोड थियो।

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

अब Postgres को आन्तरिक स्थापना डाटा को केहि petabytes छ। यी प्रति सेकेन्ड केही लाख अनुरोधहरू हुन्। यी हजारौं क्लस्टरहरू छन्। यो धेरै ठूलो मात्रामा छ।

तर त्यहाँ एक nuance छ। यो फैंसी नेटवर्क ड्राइभहरूमा होइन, तर एकदम सरल हार्डवेयरमा रहन्छ। र त्यहाँ चाखलाग्दो नयाँ चीजहरूको लागि विशेष रूपमा परीक्षण वातावरण छ।

र परीक्षण वातावरणमा एक निश्चित क्षणमा हामीले डाटाबेस अनुक्रमणिकाहरूको आन्तरिक अपरिवर्तनीयहरू उल्लङ्घन भएको संकेत गर्ने सन्देश प्राप्त गर्‍यौं।

एक अपरिवर्तनीय एक प्रकारको सम्बन्ध हो जुन हामीले सधैं राख्ने आशा गर्दछौं।

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

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

र यहाँ एक अवस्था उत्पन्न हुन्छ जसले सुझाव दिन्छ कि त्यहाँ एक परिस्थिति हुन सक्छ जसको लागि हामी तयार नहुन सक्छौं। र हामीले यो अवस्थाको लागि तयारी गर्न थाल्यौं।

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

हामीले गरेको पहिलो कुरा यी हजारौं क्लस्टरहरूबाट लगहरू गाड्नु थियो। हामीले पत्ता लगायौं कि कुन क्लस्टरहरू समस्याग्रस्त फर्मवेयरको साथ डिस्कहरूमा अवस्थित छन् जुन डाटा पृष्ठ अद्यावधिकहरू गुमाउँदै थिए। सबै Postgres डाटा कोड चिन्ह लगाइयो। र हामीले ती सन्देशहरूलाई चिन्ह लगायौं जसले डेटा भ्रष्टाचार पत्ता लगाउन डिजाइन गरिएको कोडको साथ आन्तरिक अपरिवर्तनीयहरूको उल्लङ्घनलाई संकेत गर्छ।

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

यस पछि, हामी बिन्दुमा पुग्यौं कि हामीले लगहरू स्क्यान गर्ने निगरानी गरिरहेका छौं। र शंकास्पद सन्देशहरूको मामलामा, उसले ड्युटी अफिसरलाई जगाउँछ, र ड्यूटी अफिसरले यसलाई मर्मत गर्दछ।

तर! स्क्यानिङ लगहरू एक क्लस्टरमा सस्तो अपरेशन हो र हजारौं क्लस्टरहरूको लागि विनाशकारी रूपमा महँगो।

हामीले एउटा विस्तार लेख्यौं लग त्रुटिहरू। यसले डाटाबेसको दृश्य सिर्जना गर्दछ जसमा तपाइँ सस्तो र द्रुत रूपमा विगतका त्रुटिहरूमा तथ्याङ्कहरू चयन गर्न सक्नुहुन्छ। र यदि हामीले ड्यूटी अफिसरलाई जगाउन आवश्यक छ भने, हामी गीगाबाइट फाइलहरू स्क्यान नगरीकन, तर ह्यास टेबलबाट केही बाइटहरू निकालेर यसको बारेमा पत्ता लगाउनेछौं।

यो विस्तार अपनाएको छ, उदाहरण को लागी, को लागि भण्डार मा CentOS। यदि तपाइँ यसलाई प्रयोग गर्न चाहनुहुन्छ भने, तपाइँ यसलाई आफैं स्थापना गर्न सक्नुहुन्छ। अवश्य पनि यो खुला स्रोत हो।

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

तर यति मात्र होइन। हामीले अनुक्रमणिकामा अपरिवर्तनीय उल्लङ्घनहरू फेला पार्नको लागि समुदाय-निर्मित विस्तार, Amcheck प्रयोग गर्न थाल्यौं।

र हामीले पत्ता लगायौं कि यदि तपाईंले यसलाई स्केलमा सञ्चालन गर्नुभयो भने, त्यहाँ बगहरू छन्। हामीले तिनीहरूलाई मिलाउन थाल्यौं। हाम्रा सुधारहरू स्वीकार गरिएको छ।

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

हामीले पत्ता लगायौं कि यो विस्तारले GiST र GIT अनुक्रमणिकाहरू विश्लेषण गर्न सक्दैन। हामीले उनीहरुलाई सपोर्ट गर्यौं । तर यो समर्थन अझै पनि समुदाय द्वारा छलफल भइरहेको छ, किनभने यो एक अपेक्षाकृत नयाँ कार्यक्षमता हो र त्यहाँ धेरै विवरणहरू छन्।

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

र हामीले यो पनि पत्ता लगायौं कि प्रतिकृति नेतामा उल्लङ्घनको लागि अनुक्रमणिका जाँच गर्दा, मास्टरमा, सबै कुरा राम्रोसँग काम गर्दछ, तर प्रतिकृतिहरूमा, अनुयायीमा, भ्रष्टाचारको खोजी त्यति प्रभावकारी छैन। सबै invariants जाँच गरिएको छैन। र एक अपरिवर्तनीयले हामीलाई धेरै सतायो। र हामीले प्रतिकृतिहरूमा यो जाँच सक्षम गर्न समुदायसँग कुराकानी गर्न डेढ वर्ष बितायौं।

हामीले कोड लेख्यौं जुन सबै गर्न सक्छ ... प्रोटोकलहरू पालना गर्नुपर्छ। हामीले यस प्याचलाई क्रन्ची डाटाबाट पिटर गगनसँग केही समयको लागि छलफल गर्यौं। यो प्याच स्वीकार गर्नको लागि उसले पोष्टग्रेसमा अवस्थित बी-ट्रीलाई थोरै परिमार्जन गर्नुपर्‍यो। उहाँलाई स्वीकार गरियो। र अब हामीले सामना गरेका उल्लङ्घनहरू पत्ता लगाउन प्रतिकृतिहरूमा अनुक्रमणिकाहरू जाँच गर्न पनि पर्याप्त प्रभावकारी भएको छ। त्यो हो, यी उल्लङ्घनहरू हुन् जुन डिस्क फर्मवेयरमा त्रुटिहरू, पोस्टग्रेसमा बगहरू, लिनक्स कर्नेलमा बगहरू, र हार्डवेयर समस्याहरूका कारण हुन सक्छन्। समस्याहरूको स्रोतहरूको एकदम विस्तृत सूची जसको लागि हामीले तयारी गरिरहेका थियौं।

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

तर अनुक्रमणिका बाहेक, त्यहाँ हिप जस्तै एक भाग छ, अर्थात् डाटा भण्डारण गरिएको ठाउँ। र त्यहाँ धेरै अपरिवर्तनीयहरू छैनन् जुन जाँच गर्न सकिन्छ।

हामीसँग Heapcheck भनिने विस्तार छ। हामीले यसलाई विकास गर्न थाल्यौं। र समानान्तरमा, हामीसँगै, EnterpriseDB कम्पनीले पनि मोड्युल लेख्न थाल्यो, जसलाई तिनीहरूले Heapcheck भनिन्छ। केवल हामीले यसलाई PgHeapcheck भन्यौं, र तिनीहरूले यसलाई Heapcheck भने। तिनीहरूसँग समान प्रकार्यहरू छन्, अलिकति फरक हस्ताक्षर, तर एउटै विचारहरूसँग। तिनीहरूले तिनीहरूलाई केही ठाउँहरूमा अलि राम्रो कार्यान्वयन गरे। र तिनीहरूले यसलाई पहिले खुला स्रोतमा पोस्ट गरे।

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

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

कतिपय ठाउँमा, हामी हाम्रो अनुगमन प्रणालीमा गलत सकारात्मकताहरू छन् भन्ने निष्कर्षमा पनि पुग्यौं। उदाहरणका लागि, 1C प्रणाली। डाटाबेस प्रयोग गर्दा, Postgres ले कहिलेकाहीँ यसमा डाटा लेख्छ कि यसले पढ्न सक्छ, तर pg_dump पढ्न सक्दैन।

यो अवस्था हाम्रो समस्या पत्ता लगाउने प्रणालीमा भ्रष्टाचार जस्तो देखिन्थ्यो। ड्युटी अफिसर ब्यूँझियो । ड्युटी अफिसरले के भइरहेको थियो हेरे। केही समयपछि एकजना ग्राहक आएर मलाई समस्या भएको बताए । परिचारकले समस्या के हो भनेर बताए। तर समस्या Postgres कोर मा छ।

मैले यो सुविधाको बारेमा छलफल भेट्टाएँ। र उनले लेखे कि हामीले यो सुविधाको सामना गर्यौं र यो अप्रिय थियो, एक व्यक्ति यो के हो भनेर पत्ता लगाउन राती उठ्यो।

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

समुदायले जवाफ दियो, "ओह, हामीले वास्तवमै यसलाई ठीक गर्न आवश्यक छ।"

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

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

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

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

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

र ग्रीनप्लमसँग रोचक कार्यक्षमता छ - अनुकूलित तालिकाहरू संलग्न गर्नुहोस्। यी तालिकाहरू छन् जुन तपाईं छिट्टै थप्न सक्नुहुन्छ। तिनीहरू या त स्तम्भ वा पङ्क्ति हुन सक्छन्।

तर त्यहाँ कुनै क्लस्टरिङ थिएन, अर्थात् त्यहाँ कुनै प्रकार्यता थिएन जहाँ तपाइँ तालिकामा रहेको डेटालाई अनुक्रमणिकाहरू मध्ये एकमा रहेको क्रम अनुसार व्यवस्थित गर्न सक्नुहुन्छ।

ट्याक्सीका केटाहरू मकहाँ आए र भने: "एन्ड्रे, तपाईलाई पोस्टग्रेस थाहा छ। र यहाँ यो लगभग समान छ। 20 मिनेटमा स्विच गर्नुहोस्। तपाईं यसलाई लिनुहोस् र यो गर्नुहोस्।" मैले सोचे कि हो, मलाई पोस्टग्रेस थाहा छ, २० मिनेटको लागि स्विच गर्दै - मलाई यो गर्न आवश्यक छ।

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

तर होइन, यो २० मिनेट थिएन, मैले यसलाई महिनौंमा लेखें। PgConf.Russia सम्मेलनमा, मैले Pivotal बाट Heikki Linakangas लाई सम्पर्क गरें र सोधें: "यसमा कुनै समस्या छ? किन त्यहाँ कुनै अप्टिमाइज गरिएको तालिका क्लस्टरिङ छैन?" उहाँ भन्नुहुन्छ: "तपाईले डाटा लिनुहोस्। तपाइँ क्रमबद्ध गर्नुहोस्, तपाइँ पुन: व्यवस्थित गर्नुहोस्। यो त एउटा काम मात्र हो।" म: "ओह, हो, तपाईले यसलाई लिनु पर्छ र यो गर्नु पर्छ।" उनी भन्छन्: "हो, हामीलाई यो गर्न स्वतन्त्र हात चाहिन्छ।" मैले यो पक्कै गर्नुपर्छ भन्ने सोचेको थिएँ।

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

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 को लागि Greenplum संस्करणमा प्राप्त गर्न आवश्यक छ। त्यो हो, 20-मिनेट साहसिक नयाँ रोचक साहसिक संग जारी छ। हालको विकासलाई छुनु रोचक थियो, जहाँ समुदायले नयाँ र सबैभन्दा महत्त्वपूर्ण सुविधाहरू काटिरहेको छ। यो जमेको छ।

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

तर यो त्यहाँ समाप्त भएन। सबै कुरा पछि, यो बाहिर भयो कि हामीले यी सबैको लागि कागजात लेख्न आवश्यक छ।

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

र यहाँ, यस्तो देखिन्छ, साहसिक समाप्त भयो। अनि त्यसपछि के भयो थाहा छ ? ट्याक्सीका केटाहरू मसँग आए र भने: "अझै दुईवटा साहसिक कार्यहरू छन्, प्रत्येक १० मिनेटको लागि।" र मैले तिनीहरूलाई के भन्नु पर्छ? मैले भने कि अब म स्केलमा रिपोर्ट दिन्छु, त्यसपछि हामी तपाईंको साहसिक कार्यहरू हेर्नेछौं, किनकि यो एक रोचक काम हो।

यो घटनाबाट हामीले के सिक्यौं? किनभने खुला स्रोतसँग काम गर्नु भनेको सधैं एक विशिष्ट व्यक्तिसँग काम गर्नु हो, यसले सधैं समुदायसँग काम गरिरहेको हुन्छ। किनभने हरेक चरणमा मैले केही विकासकर्ता, केही परीक्षक, केही ह्याकर, केही वृत्तचित्रकार, केही वास्तुकारसँग काम गरें। मैले ग्रीनप्लमसँग काम गरेन, मैले ग्रीनप्लम वरपरका मानिसहरूसँग काम गरें।

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

यति नै। प्रश्नहरूमा जाऔं।

प्रश्न सत्र

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

WAL-G मा ब्याकअप प्रणाली Go मा लेखिएको छ। यो हामीले काम गरेका नयाँ परियोजनाहरू मध्ये एक हो। उहाँ शाब्दिक रूपमा मात्र 3 वर्षको हुनुहुन्छ। र डाटाबेस अक्सर विश्वसनीयता को बारे मा छ। र यसको मतलब यो हो कि डाटाबेसहरू धेरै पुरानो छन् र तिनीहरू सामान्यतया C मा लेखिएका छन्। Postgres परियोजना लगभग 30 वर्ष पहिले सुरु भयो। त्यसपछि C89 सही विकल्प थियो। र यसमा Postgres लेखिएको छ। क्लिकहाउस जस्ता थप आधुनिक डाटाबेसहरू सामान्यतया C++ मा लेखिन्छन्। सबै प्रणाली विकास C र C++ वरपर आधारित छ।

हाम्रो वित्तीय प्रबन्धकबाट एउटा प्रश्न, जो क्लाउडमा खर्चहरूको लागि जिम्मेवार छ: "क्लाउडले खुला स्रोतलाई समर्थन गर्न किन पैसा खर्च गर्छ?"

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

अर्को प्रश्न: "के Yandex.Cloud मा बस्ने बाह्य प्रयोगकर्ताहरूको आवश्यकताहरू आन्तरिक क्लाउडमा बस्ने आन्तरिक प्रयोगकर्ताहरू भन्दा फरक छन्?"

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

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

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

तपाईंले म्याराथनको बारेमा धेरै कुरा गर्नुभयो। मलाई थाहा छ तपाईंले मस्कोमा म्याराथन दौडिनुभयो। फलस्वरूप? PostgreSQL बाट केटाहरूलाई ओभरटेक?

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

के तपाईं क्लिकहाउसमा कुनै धावकहरू छैनन् भनी भन्नुहुन्छ?

मलाई थाहा छ कि तिनीहरू त्यहाँ छन्। ClickHouse पनि एक डाटाबेस हो। वैसे, ओलेग अब मलाई लेख्दै छ: "के हामी रिपोर्ट पछि दौडन जान्छौं?" यो एक महान विचार हो।

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

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

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

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

स्रोत: www.habr.com