Придонесот на Yandex во следните бази на податоци ќе биде разгледан.
- Кликни куќа
- Одисеја
- Закрепнување до одреден момент во времето (WAL-G)
- PostgreSQL (вклучувајќи логеррори, Amcheck, heapcheck)
- Зелена слива
Видео:
Здраво свету! Јас се викам Андреј Бородин. И она што го правам во Yandex.Cloud е развивање отворени релациони бази на податоци во интерес на клиентите Yandex.Cloud и Yandex.Cloud.
Во овој разговор, ќе зборуваме за предизвиците со кои се соочуваат отворените бази на податоци во обем. Зошто е важно? Бидејќи мали, мали проблеми кои, како комарци, потоа стануваат слонови. Тие стануваат големи кога имате многу кластери.
Но, тоа не е главната работа. Се случуваат неверојатни работи. Работи кои се случуваат во еден од милион случаи. И во облачно опкружување, мора да бидете подготвени за тоа, бидејќи неверојатните работи стануваат многу веројатни кога нешто постои во обем.
Но! Која е предноста на отворените бази на податоци? Факт е дека имате теоретска можност да се справите со секој проблем. Го имаш изворниот код, имаш програмско знаење. Го комбинираме и делува.
Кои пристапи постојат во работата на софтвер со отворен код?
- Наједноставниот пристап е да се користи софтвер. Ако користите протоколи, ако користите стандарди, ако користите формати, ако пишувате прашања во софтвер со отворен код, тогаш веќе го поддржувате.
- Го правите неговиот екосистем поголем. Ја зголемувате веројатноста за рано откривање на грешка. Ја зголемувате доверливоста на овој систем. Ја зголемувате достапноста на програмерите на пазарот. Вие го подобрувате овој софтвер. Веќе сте соработник ако штотуку сте допреле да стекнете стил и сте се покосиле со нешто таму.
- Друг разбирлив пристап е спонзорирање на софтвер со отворен код. На пример, добро познатата програма Google Summer of Code, кога Google им плаќа на голем број студенти од целиот свет разбирливи пари за да развијат отворени софтверски проекти кои исполнуваат одредени барања за лиценцирање.
- Ова е многу интересен пристап бидејќи му овозможува на софтверот да се развива без да го оддалечи фокусот од заедницата. Google, како технолошки гигант, не вели дека ја сакаме оваа функција, сакаме да ја поправиме оваа грешка и тука треба да копаме. Google вели: „Правете го она што го правите. Само продолжете да работите како што работевте и сè ќе биде добро“.
- Следниот пристап за учество во софтвер со отворен код е учеството. Кога имате проблем во софтверот со отворен код и има програмери, вашите програмери почнуваат да ги решаваат проблемите. Тие почнуваат да ја прават вашата инфраструктура поефикасна, вашите програми побрзи и посигурни.
Еден од најпознатите проекти на Yandex во областа на софтверот со отворен код е ClickHouse. Ова е база на податоци што се роди како одговор на предизвиците со кои се соочува Yandex.Metrica.
И како база на податоци, таа беше направена во отворен код со цел да се создаде екосистем и да се развие заедно со други програмери (не само во рамките на Yandex). И сега ова е голем проект во кој се вклучени многу различни компании.
Во Yandex.Cloud, создадовме ClickHouse на врвот на Yandex Object Storage, односно на врвот на складирањето на облакот.
Зошто е ова важно во облакот? Бидејќи секоја база на податоци работи во овој триаголник, во оваа пирамида, во оваа хиерархија на типови меморија. Имате брзи, но мали регистри и евтини големи, но бавни SSD, хард дискови и некои други блок уреди. И ако сте ефикасни на врвот на пирамидата, тогаш имате брза база на податоци. ако сте ефикасни на дното на оваа пирамида, тогаш имате намалена база на податоци. И во овој поглед, додавањето на уште еден слој одоздола е логичен пристап за зголемување на приспособливоста на базата на податоци.
Како би можело да се направи тоа? Ова е важна точка во овој извештај.
- Можеме да го имплементираме ClickHouse преку MDS. MDS е внатрешен интерфејс за складирање облак Yandex. Тој е покомплексен од заедничкиот протокол S3, но е посоодветен за блок-уред. Подобро е за снимање податоци. Потребно е повеќе програмирање. Програмерите ќе програмираат, дури е добро, интересно е.
- S3 е почест пристап кој го прави интерфејсот поедноставен по цена на помала адаптација на одредени видови оптоварувања.
Секако, сакајќи да обезбедиме функционалност на целиот екосистем на ClickHouse и да ја извршиме задачата што е потребна во Yandex.Cloud, решивме да се увериме дека целата заедница на ClickHouse ќе има корист од тоа. Го имплементиравме ClickHouse преку S3, а не ClickHouse преку MDS. И ова е многу работа.
Референци:
„Слој за апстракција на датотечен систем“
„Интеграција на AWS SDK S3“
„Основна имплементација на интерфејсот IDisk за S3“
„Интеграција на мотори за складирање дневници со интерфејс IDisk“
„Поддршка на моторот за евиденција за S3 и SeekableReadBuffer“
„Поддршка за Storage Stripe Log S3“
„Складирање MergeTree почетна поддршка за S3“
„Целосна поддршка MergeTree за S3“
„Поддржете ReplicatedMergeTree преку S3“
„Додајте стандардни ингеренции и сопствени заглавија за складирање на s3“
„S3 со динамична конфигурација на прокси“
„S3 со прокси-решител“
Ова е список со барања за повлекување за имплементација на виртуелен датотечен систем во ClickHouse. Ова е голем број барања за повлекување.
Референци:
„Оптимална имплементација на тврди врски на DiskS3“
„S3 HTTP клиент - Избегнувајте копирање на протокот на одговор во меморијата“
„Избегнувајте копирање на целиот тек на одговор во меморијата во S3 HTTP
клиент"
„Способност за кеширање ознаки и индексирање датотеки за S3 диск“
„Паралелно преместувајте делови од DiskLocal во DiskS3“
Но, работата не заврши тука. Откако беше направена функцијата, беше потребна уште малку работа за да се оптимизира оваа функционалност.
Референци:
„Додај настани од SelectedRows и SelectedBytes“
„Додај настани за профилирање од барање S3 во system.events“
„Додај QueryTimeMicroseconds, SelectQueryTimeMicroseconds и InsertQueryTimeMicroseconds“
И тогаш беше неопходно да се направи дијагноза, да се постави мониторинг и да се направи податлив.
И сето тоа беше направено така што целата заедница, целиот екосистем на ClickHouse, го доби резултатот од оваа работа.
Да преминеме на трансакциските бази на податоци, на базите на OLTP, кои ми се поблиски лично.
Ова е оддел за развој на DBMS со отворен код. Овие момци прават улична магија за да ги подобрат трансакциските отворени бази на податоци.
Еден од проектите, користејќи пример за кој можеме да зборуваме за тоа како и што правиме, е Connection Pooler во Postgres.
Postgres е процесна база на податоци. Ова значи дека базата на податоци треба да има што е можно помалку мрежни конекции кои се справуваат со трансакциите.
Од друга страна, во облачно опкружување, типична ситуација е кога илјада врски доаѓаат во еден кластер одеднаш. А, задачата на спојувачот за поврзување е да спакува илјада врски во мал број серверски врски.
Можеме да кажеме дека спојувачот за поврзување е телефонскиот оператор кој ги преуредува бајтите така што тие ефикасно да стигнат до базата на податоци.
За жал, не постои добар руски збор за спојувач на врски. Понекогаш тоа се нарекува мултиплексер врски. Ако знаете како да го наречете спојувачот за поврзување, тогаш не заборавајте да ми кажете, ќе бидам многу среќен да зборувам на правилен руски технички јазик.
Ги истражувавме спојувачите на поврзување кои беа погодни за управуван постгрес кластер. И PgBouncer беше најдобриот избор за нас. Но, наидовме на голем број проблеми со PgBouncer. Пред многу години, Володија Бородин даде извештаи дека користиме PgBouncer, ни се допаѓа сè, но има нијанси, има на што да работиме.
И работевме. Ги поправивме проблемите што ги наидовме, го закрпивме Bouncer и се обидовме да ги туркаме барањата за повлекување нагоре. Но, беше тешко да се работи со основните единечни нишки.
Моравме да собираме каскади од закрпени Bouncers. Кога имаме многу Bouncers со една нишка, врските на горниот слој се пренесуваат во внатрешниот слој на Bouncers. Ова е лошо управуван систем кој е тешко да се изгради и да се зголеми напред-назад.
Дојдовме до заклучок дека создадовме сопствен здружувач за поврзување, кој се нарекува Одисеја. Го напишавме од нула.
Во 2019 година, на конференцијата PgCon, го претставив овој здружувач на заедницата на програмери. Сега имаме нешто помалку од 2 ѕвезди на GitHub, т.е. проектот е жив, проектот е популарен.
И ако креирате кластер Postgres во Yandex.Cloud, тогаш тоа ќе биде кластер со вградена Одисеја, што се реконфигурира при скалирање на кластерот напред или назад.
Што научивме од овој проект? Лансирањето на конкурентен проект е секогаш агресивен чекор, тоа е екстремна мерка кога велиме дека има проблеми кои не се решаваат доволно брзо, не се решаваат во временските интервали кои би ни одговарале. Но, ова е ефикасна мерка.
PgBouncer почна да се развива побрзо.
А сега се појавија и други проекти. На пример, pgagroal, кој е развиен од развивачите на Red Hat. Следат слични цели и имплементираат слични идеи, но, се разбира, со свои специфики, кои се поблиску до развивачите на pgagroal.
Друг случај на работа со постгрес заедницата се враќа во одреден момент. Ова е закрепнување по неуспех, ова е враќање од резервна копија.
Има многу резервни копии и сите се различни. Речиси секој продавач на Postgres има свое резервно решение.
Ако ги земете сите резервни системи, креирате матрица на карактеристики и на шега пресметате ја детерминантата во оваа матрица, таа ќе биде нула. Што значи тоа? Што ако земете одредена резервна датотека, тогаш таа не може да се состави од парчиња од сите други. Таа е единствена во својата имплементација, единствена е по својата цел, единствена е по идеите што се вградени во неа. И сите се специфични.
Додека работевме на ова прашање, CitusData го започна проектот WAL-G. Ова е резервен систем кој е направен со внимание на околината на облакот. Сега CitusData е веќе дел од Microsoft. И во тој момент навистина ни се допаднаа идеите што беа поставени во првичните изданија на WAL-G. И почнавме да придонесуваме за овој проект.
Сега има многу десетици програмери во овој проект, но првите 10 соработници на WAL-G вклучуваат 6 Yandexoids. Донесовме многу наши идеи таму. И, се разбира, ние самите ги имплементиравме, самите ги тестиравме, самите ги пуштивме во производство, самите ги користиме, самите сфаќаме каде да се движиме понатаму, додека комуницираме со големата WAL-G заедница.
И од наша гледна точка, сега овој резервен систем, вклучително и земајќи ги предвид нашите напори, стана оптимален за опкружување облак. Ова е најдобрата цена за резервна копија на Postgres во облакот.
Што значи тоа? Промовиравме прилично голема идеја: резервната копија треба да биде безбедна, евтина за работа и што е можно побрзо да се обнови.
Зошто треба да биде евтино да се работи? Кога ништо не е скршено, не треба да знаете дека имате резервни копии. Сè работи добро, трошите што е можно помалку процесор, користите што е можно помалку од вашите ресурси на дискот и испраќате што е можно помалку бајти на мрежата за да не се мешате во товарот на вашите вредни услуги.
И кога ќе се расипе, на пример, администраторот ги испуштил податоците, нешто тргнало наопаку, и итно треба да се вратите во минатото, се опоравувате со сите пари, бидејќи сакате вашите податоци да се вратат брзо и недопрени.
И ја промовиравме оваа едноставна идеја. И, ни се чини, успеавме да го спроведеме.
Но, тоа не е се. Сакавме уште една мала работа. Сакавме многу различни бази на податоци. Не сите наши клиенти користат Postgres. Некои луѓе користат MySQL, MongoDB. Во заедницата, други програмери го поддржаа FoundationDB. И оваа листа постојано се проширува.
На заедницата и се допаѓа идејата базата на податоци да се извршува во управувана средина во облакот. И програмерите ги одржуваат своите бази на податоци, кои може да се поддржат подеднакво заедно со Postgres со нашиот резервен систем.
Што научивме од оваа приказна? Нашиот производ, како развоен оддел, не е линии на код, не се изјави, не се датотеки. Нашиот производ не е повлекување барања. Ова се идеите што ги пренесуваме до заедницата. Ова е технолошка експертиза и движење на технологијата кон средина на облак.
Постои таква база на податоци како Postgres. Најмногу ми се допаѓа јадрото на Postgres. Поминувам многу време во развојот на јадрото на Postgres со заедницата.
Но, тука мора да се каже дека Yandex.Cloud има внатрешна инсталација на управувани бази на податоци. И започна многу одамна во Yandex.Mail. Експертизата што сега доведе до управуван Postgres беше акумулирана кога поштата сакаше да се пресели во Postgres.
Поштата има многу слични барања како облакот. Потребно е да бидете во можност да скалирате до неочекуван експоненцијален раст во која било точка од вашите податоци. А поштата веќе имаше оптоварување со неколку стотици милиони поштенски сандачиња на огромен број корисници кои постојано упатуваат многу барања.
И ова беше доста сериозен предизвик за тимот што го развиваше Postgres. Тогаш, сите проблеми на кои наидовме беа пријавени во заедницата. И овие проблеми беа поправени и коригирани од заедницата на некои места дури и на ниво на платена поддршка за некои други бази на податоци и уште подобро. Односно, можете да испратите писмо до хакерот PgSQL и да добиете одговор во рок од 40 минути. Платената поддршка во некои бази на податоци може да мисли дека има поприоритетни работи од вашата грешка.
Сега внатрешната инсталација на Postgres е неколку петабајти податоци. Ова се неколку милиони барања во секунда. Ова се илјадници кластери. Тој е многу голем.
Но, постои една нијанса. Не живее на фенси мрежни дискови, туку на прилично едноставен хардвер. И има тест средина специјално за интересни нови работи.
И во одреден момент во околината за тестирање добивме порака која укажува дека внатрешните инваријанти на индексите на базата на податоци се прекршени.
Непроменлива е некаква врска што очекуваме секогаш да ја држиме.
Многу критична ситуација за нас. Тоа покажува дека некои податоци можеби се изгубени. А загубата на податоци е нешто сосема катастрофално.
Општата идеја што ја следиме во управуваните бази на податоци е дека дури и со напор, ќе биде тешко да се изгубат податоците. Дури и ако намерно ги отстраните, сепак ќе треба да го игнорирате нивното отсуство долго време. Безбедноста на податоците е религија што ја следиме доста вредно.
И тука настанува ситуација која сугерира дека може да има ситуација за која можеби не сме подготвени. И почнавме да се подготвуваме за оваа ситуација.
Првото нешто што го направивме беше да ги закопаме трупците од овие илјадници кластери. Откривме кои од кластерите се наоѓаат на дискови со проблематичен фирмвер што ги губат ажурирањата на страницата со податоци. Означени сите кодови на податоци на Postgres. И ние ги означивме оние пораки што укажуваат на прекршување на внатрешните непроменливи со код кој е дизајниран да открие расипување на податоците.
Овој лепенка беше практично прифатен од заедницата без многу дискусија, бидејќи во секој конкретен случај беше очигледно дека нешто лошо се случило и требаше да се пријави во дневникот.
После ова, дојдовме до точка дека имаме мониторинг кој ги скенира дневниците. И во случај на сомнителни пораки го буди дежурниот, а дежурниот го поправа.
Но! Скенирањето на дневниците е евтина операција на еден кластер и катастрофално скапа за илјада кластери.
Напишавме продолжување наречено . Создава приказ на базата на податоци во која можете евтино и брзо да изберете статистика за минатите грешки. И ако треба да го разбудиме дежурниот, тогаш ќе дознаеме за ова без да скенираме гигабајтни датотеки, туку со извлекување неколку бајти од табелата за хаш.
Оваа екстензија е усвоена, на пример, во складиштето за . Ако сакате да го користите, можете сами да го инсталирате. Се разбира, тоа е со отворен код.
Но, тоа не е се. Почнавме да користиме Amcheck, екстензија изградена во заедницата, за да најдеме непроменливи прекршувања во индексите.
И дознавме дека ако го работиш во обем, има грешки. Почнавме да ги поправаме. Нашите корекции се прифатени.
Откривме дека оваа екстензија не може да ги анализира индексите GiST и GIT. Ги натеравме да поддржат. Но, заедницата сè уште ја дискутира оваа поддршка, бидејќи ова е релативно нова функционалност и таму има многу детали.
И, исто така, откривме дека при проверка на индексите за прекршување на лидерот за репликација, на главниот, сè работи добро, но на репликите, на следбеникот, потрагата по корупција не е толку ефикасна. Не се проверуваат сите непроменливи. И една непроменлива многу ни пречеше. И поминавме година и пол во комуникација со заедницата за да ја овозможиме оваа проверка на репликите.
Напишавме код кој треба да ги следи сите конзерва... протоколи. Долго време разговаравме за овој лепенка со Питер Гаган од Crunchy Data. Тој мораше малку да го измени постоечкото Б-дрво во Постгрес за да ја прифати оваа лепенка. Тој беше прифатен. И сега проверката на индексите на репликите стана доволно ефикасно за откривање на прекршувањата што ги наидовме. Односно, ова се прекршувањата што можат да бидат предизвикани од грешки во фирмверот на дискот, грешки во Postgres, грешки во кернелот на Linux и проблеми со хардверот. Доста обемна листа на извори на проблеми за кои се подготвувавме.
Но, покрај индексите, постои и таков дел како грамада, односно местото каде што се чуваат податоците. И нема многу непроменливи што би можеле да се проверат.
Имаме екстензија наречена Heapcheck. Почнавме да го развиваме. Паралелно, заедно со нас, компанијата EnterpriseDB исто така почна да пишува модул, кој на ист начин го нарекоа Heapcheck. Само ние го нарековме PgHeapcheck, а тие само го нарекоа Heapcheck. Го имаат со слични функции, малку поинаков потпис, но со исти идеи. Малку подобро ги спроведоа на некои места. И претходно го објавија во отворен код.
И сега го развиваме нивното проширување, бидејќи тоа веќе не е нивно проширување, туку проширување на заедницата. И во иднина, ова е дел од кернелот што ќе им биде доставен на сите за да можат однапред да знаат за идните проблеми.
На некои места дури и дојдовме до заклучок дека имаме лажни позитиви во нашите системи за следење. На пример, системот 1C. Кога користи база на податоци, Postgres понекогаш запишува податоци во неа што може да ги чита, но pg_dump не може да ги чита.
Оваа ситуација изгледаше како корупција за нашиот систем за откривање проблеми. Дежурниот бил разбуден. Дежурниот погледна што се случува. По некое време дојде клиент и рече дека имам проблеми. Службеникот објасни што е проблемот. Но, проблемот е во јадрото на Postgres.
Најдов дискусија за оваа функција. И напиша дека наидовме на оваа карактеристика и беше непријатна, човек се разбуди ноќе за да сфати што е тоа.
Заедницата одговори: „О, навистина треба да го поправиме“.
Имам едноставна аналогија. Ако одите во чевел во кој има зрно песок, тогаш, во принцип, можете да продолжите понатаму - нема проблем. Ако продавате чизми на илјадници луѓе, тогаш ајде да направиме чизми без песок воопшто. И ако некој од корисниците на вашите чевли ќе трча маратон, тогаш сакате да направите многу добри чевли, а потоа да ги размерите на сите ваши корисници. И таквите неочекувани корисници се секогаш во околината на облакот. Секогаш има корисници кои го искористуваат кластерот на некој оригинален начин. Секогаш мора да се подготвите за ова.
Што научивме овде? Научивме едноставна работа: најважно е да и објасниме на заедницата дека има проблем. Ако заедницата го препознала проблемот, тогаш се јавува природна конкуренција за да се реши проблемот. Затоа што секој сака да реши важен проблем. Сите продавачи, сите хакери разбираат дека тие самите можат да стапнат на ова гребло, па сакаат да ги елиминираат.
Ако работите на некој проблем, но тој не пречи никому освен вас, туку го работите систематски и на крајот се смета за проблем, тогаш вашето барање за повлекување дефинитивно ќе биде прифатено. Вашиот лепенка ќе биде прифатен, вашите подобрувања или дури барања за подобрувања ќе бидат разгледани од заедницата. На крајот на денот, ја правиме базата на податоци подобра еден за друг.
Интересна база на податоци е Greenplum. Тоа е многу паралелна база на податоци заснована на базата на кодови на Postgres, со која сум многу запознаена.
И Greenplum има интересна функционалност - приложувајте оптимизирани табели. Ова се табели на кои можете брзо да ги додадете. Тие можат да бидат или колонообразни или редици.
Но, немаше кластерирање, односно немаше функционалност каде што можете да ги распоредите податоците лоцирани во табелата во согласност со редоследот што е во еден од индексите.
Момците од таксито дојдоа кај мене и ми рекоа: „Андреј, знаеш Постгрес. И тука е речиси исто. Префрлете се на 20 минути. Земете го и направете го тоа“. Мислев дека да, го познавам Постгрес, менувајќи се 20 минути - треба да го направам ова.
Но не, не беа 20 минути, го пишував со месеци. На конференцијата PgConf.Russia, му пријдов на Хеики Линакангас од Пивотал и прашав: „Дали има проблеми со ова? Зошто нема додаток оптимизирано групирање табели?“ Тој вели: „Земете ги податоците. Подредуваш, преуредуваш. Тоа е само работа“. Јас: „О, да, само треба да го земеш и да го направиш“. Тој вели: „Да, ни требаат слободни раце за да го направиме ова“. Мислев дека дефинитивно треба да го направам ова.
И неколку месеци подоцна поднесов барање за повлекување што ја имплементира оваа функционалност. Ова барање за повлекување беше разгледано од Pivotal заедно со заедницата. Се разбира, имаше грешки.
Но, најинтересно е што кога ова барање за повлекување беше споено, беа пронајдени грешки во самиот Гринплум. Откривме дека табелите со купишта понекогаш ја нарушуваат трансакциската состојба кога се групирани. И ова е нешто што треба да се поправи. И таа е на местото кое штотуку го допрев. И мојата природна реакција беше - во ред, дозволете ми да го направам и ова.
Ја поправив оваа грешка. Испрати барање за повлекување до фиксаторите. Тој беше убиен.
По што се покажа дека оваа функционалност треба да се добие во верзијата Greenplum за PostgreSQL 12. Односно, 20-минутната авантура продолжува со нови интересни авантури. Беше интересно да се допре сегашниот развој, каде заедницата ги намалува новите и најважните карактеристики. Замрзнато е.
Но, не заврши тука. После се, испадна дека за сето ова треба да напишеме документација.
Почнав да пишувам документација. За среќа дојдоа документарците од Пивотал. Англискиот им е мајчин јазик. Ми помогнаа околу документацијата. Всушност, тие самите го препишаа тоа што го предложив на вистински англиски.
И тука, се чини, авантурата заврши. И знаете ли што се случи тогаш? Момците од таксито дојдоа кај мене и ми рекоа: „Има уште две авантури, секоја по 10 минути“. И што да им кажам? Реков дека сега ќе дадам извештај во обем, па ќе ги видиме вашите авантури, бидејќи ова е интересна работа.
Што научивме од овој случај? Бидејќи работата со отворен код е секогаш работа со одредена личност, тоа е секогаш работа со заедницата. Затоа што во секоја фаза работев со некој развивач, некој тестер, некој хакер, некој документарец, некој архитект. Јас не работев со Гринплум, работев со луѓе околу Гринплам.
Но! Постои уште една важна точка - тоа е само работа. Односно доаѓаш, пиеш кафе, пишуваш код. Работат секакви едноставни непроменливи. Направете го тоа нормално - ќе биде добро! И тоа е доста интересна работа. Има барање за оваа работа од клиенти на Yandex.Cloud, корисници на нашите кластери и внатре и надвор од Yandex. И мислам дека ќе се зголеми бројот на проекти во кои учествуваме и ќе се зголеми и длабочината на нашата вклученост.
Тоа е се. Да преминеме на прашањата.
Сесија за прашања
Здраво! Имаме уште една сесија со прашања и одговори. И во студиото Андреј Бородин. Ова е личноста која штотуку ви кажа за придонесот на Yandex.Cloud и Yandex за софтвер со отворен код. Нашиот извештај сега не е целосно за Облакот, но во исто време се базираме на такви технологии. Без она што го направивте внатре во Yandex, немаше да има услуга во Yandex.Cloud, затоа ви благодарам лично од мене. И првото прашање од емитувањето: „На што е напишан секој од проектите што ги споменавте?
Резервниот систем во WAL-G е напишан во Go. Ова е еден од поновите проекти на кои работевме. Буквално има само 3 години. И базата на податоци често е за доверливост. А тоа значи дека базите на податоци се прилично стари и обично се напишани во C. Проектот Postgres започна пред околу 30 години. Тогаш C89 беше вистинскиот избор. И на него пишува Postgres. Повеќе модерни бази на податоци како што е ClickHouse обично се пишуваат во C++. Целиот развој на системот се базира на C и C++.
Прашање од нашиот финансиски менаџер, кој е одговорен за трошоците во Cloud: „Зошто Cloud троши пари за поддршка на отворен код?
Овде има едноставен одговор за финансискиот менаџер. Ова го правиме за да ги подобриме нашите услуги. На кои начини можеме да направиме подобро? Можеме да ги правиме работите поефикасно, побрзо и да ги направиме работите поскалабилни. Но, за нас, оваа приказна е првенствено за веродостојноста. На пример, во резервниот систем прегледуваме 100% од закрпи кои се однесуваат на него. Знаеме што е кодот. И поудобно ни е да пласираме нови верзии во производство. Тоа е, пред сè, се работи за доверба, за подготвеност за развој и за доверливост
Друго прашање: „Дали барањата на надворешните корисници кои живеат во Yandex.Cloud се разликуваат од внатрешните корисници кои живеат во внатрешниот Cloud?
Профилот на оптоварување е, се разбира, различен. Но, од гледна точка на мојот оддел, сите посебни и интересни случаи се создаваат на нестандардно оптоварување. Програмерите со имагинација, програмерите кои го прават неочекуваното, веројатно ќе се најдат и внатрешно и надворешно. Во овој поглед, сите сме приближно исти. И, веројатно, единствената важна карактеристика во работата на Yandex на базите на податоци ќе биде тоа што внатре Yandex имаме настава. Во одреден момент, одредена зона на достапност целосно оди во сенка, и сите услуги на Yandex мора некако да продолжат да функционираат и покрај тоа. Ова е мала разлика. Но, тоа создава многу развој на истражување на интерфејсот на базата на податоци и мрежниот стек. Во спротивно, надворешните и внатрешните инсталации генерираат исти барања за карактеристики и слични барања за подобрување на доверливоста и перформансите.
Следното прашање: „Како се чувствувате вие лично за фактот дека голем дел од она што го правите го користат други облаци? Нема да именуваме конкретни, но многу проекти што се направени во Yandex.Cloud се користат во облаците на другите луѓе.
Ова е кул. Прво, тоа е знак дека сме направиле нешто како што треба. И го чеша егото. И ние сме посигурни дека ја донесовме вистинската одлука. Од друга страна, ова е надежта дека во иднина ова ќе ни донесе нови идеи, нови барања од трети корисници. Повеќето прашања на GitHub се креирани од индивидуални системски администратори, индивидуални DBA, индивидуални архитекти, индивидуални инженери, но понекогаш доаѓаат луѓе со систематско искуство и велат дека во 30% од одредени случаи го имаме овој проблем и да размислиме како да го решиме. Ова е она што најмногу го очекуваме. Со нетрпение очекуваме да споделиме искуства со други платформи за облак.
Многу зборувавте за маратонот. Знам дека истрчавте маратон во Москва. Како резултат? Ги претекна момците од PostgreSQL?
Не, Олег Бартунов трча многу брзо. Заврши еден час пред мене. Генерално, задоволен сум од тоа колку далеку стигнав. За мене, самото завршување беше достигнување. Генерално, изненадувачки е што има толку многу тркачи во постгрес заедницата. Ми се чини дека постои некаква врска помеѓу аеробните спортови и желбата за системско програмирање.
Сакаш да кажеш дека нема тркачи во ClickHouse?
Сигурно знам дека се таму. ClickHouse е исто така база на податоци. Патем, Олег сега ми пишува: „Дали да трчаме по извештајот? Ова е одлична идеја.
Друго прашање од преносот од Никита: „Зошто сами ја поправивте грешката во Гринплум и не им ја дадовте на јуниорите? Навистина, не е многу јасно што е грешката и во која услуга, но веројатно се мисли на онаа за која зборувавте.
Да, во принцип, можеше некому да се даде. Тоа беше само кодот што штотуку го сменив. И природно беше да се продолжи со тоа веднаш. Во принцип, идејата за споделување експертиза со тимот е добра идеја. Дефинитивно ќе ги споделиме задачите на Гринплум меѓу сите членови на нашиот оддел.
Бидејќи зборуваме за јуниори, еве едно прашање. Лицето одлучи да го создаде првиот commit во Postgres. Што треба да направи за да ја направи првата обврска?
Ова е интересно прашање: „Каде да почнеме? Обично е доста тешко да се започне со нешто во кернелот. Во Postgres, на пример, постои листа на задачи. Но, всушност, ова е лист од она што тие се обиделе да го направат, но не успеале. Тоа се сложени работи. И обично можете да најдете некои комунални услуги во екосистемот, некои екстензии што може да се подобрат, кои привлекуваат помалку внимание од развивачите на кернелот. И, соодветно, таму има повеќе поени за раст. На програмата за кодови на Google Summer, секоја година постгрес заедницата поставува многу различни теми кои би можеле да се решат. Оваа година имавме, мислам, тројца студенти. Еден дури пишуваше во WAL-G за теми што се важни за Yandex. Во Greenplum, сè е поедноставно отколку во заедницата Postgres, бидејќи хакерите на Greenplum многу добро ги третираат барањата за повлекување и почнуваат веднаш да ги разгледуваат. Испраќањето лепенка до Postgres е прашање на месеци, но Гринплум ќе дојде за еден ден и ќе види што сте направиле. Друга работа е што Гринплум треба да ги реши тековните проблеми. Greenplum не е широко користен, така што наоѓањето на вашиот проблем е доста тешко. И пред сè, треба да ги решиме проблемите, се разбира.
Извор: www.habr.com