Приносът на Yandex към следните бази данни ще бъде прегледан.
- Щракнете върху Къща
- Одисея
- Възстановяване до определен момент (WAL-G)
- PostgreSQL (включително logerrors, Amcheck, heapcheck)
- Зелена слива
Video:
Здравей свят! Казвам се Андрей Бородин. И това, което правя в 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“
„Първоначална поддръжка на Storage 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 базите данни, които лично на мен са ми по-близки.
Това е подразделението за разработка на СУБД с отворен код. Тези момчета правят улична магия, за да подобрят транзакционните отворени бази данни.
Един от проектите, използвайки пример за който можем да говорим за това как и какво правим, е Connection Pooler в Postgres.
Postgres е база данни за процеси. Това означава, че базата данни трябва да има възможно най-малко мрежови връзки, които обработват транзакции.
От друга страна, в облачна среда типична ситуация е, когато хиляда връзки идват към един клъстер наведнъж. И задачата на пулера на връзки е да опакова хиляда връзки в малък брой сървърни връзки.
Можем да кажем, че свързващият пул е телефонният оператор, който пренарежда байтовете, така че те ефективно да достигат до базата данни.
За съжаление, няма добра руска дума за свързване пулър. Понякога се нарича мултиплексорни връзки. Ако знаете как да наречете пулера за свързване, не забравяйте да ми кажете, ще се радвам да говоря правилния руски технически език.
Изследвахме пулери за свързване, които бяха подходящи за управляван postgres клъстер. И PgBouncer беше най-добрият избор за нас. Но срещнахме редица проблеми с PgBouncer. Преди много години Володя Бородин съобщи, че използваме PgBouncer, харесваме всичко, но има нюанси, има върху какво да работим.
И работихме. Поправихме проблемите, на които се натъкнахме, закърпихме Bouncer и се опитахме да изпратим заявки за изтегляне нагоре. Но фундаменталната еднонишкова работа беше трудна за работа.
Трябваше да събираме каскади от закърпени Bouncers. Когато имаме много еднонишкови Bouncers, връзките на горния слой се прехвърлят към вътрешния слой на Bouncers. Това е лошо управлявана система, която е трудна за изграждане и мащабиране напред и назад.
Стигнахме до извода, че създадохме собствен пул за свързване, който се нарича Odyssey. Написахме го от нулата.
През 2019 г. на конференцията PgCon представих този пулер на общността на разработчиците. Сега имаме малко по-малко от 2 звезди в GitHub, т.е. проектът е жив, проектът е популярен.
И ако създадете Postgres клъстер в Yandex.Cloud, тогава той ще бъде клъстер с вграден Odyssey, който се преконфигурира при мащабиране на клъстера напред или назад.
Какво научихме от този проект? Стартирането на конкурентен проект винаги е агресивна стъпка, крайна мярка е, когато кажем, че има проблеми, които не се решават достатъчно бързо, не се решават в интервалите от време, които биха ни устройвали. Но това е ефективна мярка.
PgBouncer започна да се развива по-бързо.
А сега се появиха и други проекти. Например pgagroal, който е разработен от разработчиците на Red Hat. Те преследват подобни цели и реализират сходни идеи, но, разбира се, със собствени специфики, които са по-близки до разработчиците на pgagroal.
Друг случай на работа с postgres общността е възстановяването до даден момент. Това е възстановяване след повреда, това е възстановяване от резервно копие.
Има много резервни копия и всички те са различни. Почти всеки доставчик на Postgres има свое собствено решение за архивиране.
Ако вземете всички резервни системи, създадете матрица на характеристиките и на шега изчислите детерминантата в тази матрица, тя ще бъде нула. Какво означава това? Ами ако вземете конкретен архивен файл, той не може да бъде сглобен от части от всички останали. Уникален е с изпълнението си, уникален е с предназначението си, уникален е с идеите, които са заложени в него. И всички те са специфични.
Докато работехме по този проблем, CitusData стартира проекта WAL-G. Това е система за архивиране, която е създадена с поглед към облачната среда. Сега CitusData вече е част от Microsoft. И в този момент наистина харесахме идеите, които бяха заложени в първоначалните версии на WAL-G. И започнахме да допринасяме за този проект.
Сега има много десетки разработчици в този проект, но 10-те най-добри участници в WAL-G включват 6 Yandexoids. Донесохме много от нашите идеи там. И, разбира се, сами ги внедрихме, сами ги тествахме, сами ги внедрихме в производство, сами ги използваме, сами измисляме накъде да продължим, докато взаимодействаме с голямата WAL-G общност.
И от наша гледна точка сега тази система за архивиране, включително като се вземат предвид нашите усилия, стана оптимална за облачна среда. Това е най-добрата цена за архивиране на Postgres в облака.
Какво означава? Популяризирахме една доста голяма идея: архивирането трябва да бъде сигурно, евтино за работа и възможно най-бързо за възстановяване.
Защо трябва да е евтин за работа? Когато нищо не е счупено, не трябва да знаете, че имате резервни копия. Всичко работи добре, губите възможно най-малко CPU, използвате възможно най-малко дискови ресурси и изпращате възможно най-малко байтове към мрежата, за да не пречите на полезния товар на вашите ценни услуги.
И когато всичко се счупи, например администраторът е изпуснал данните, нещо се е объркало и трябва спешно да се върнете в миналото, възстановявате се с всички пари, защото искате вашите данни обратно бързо и непокътнати.
И ние популяризирахме тази проста идея. И, струва ни се, успяхме да го реализираме.
Но това не е всичко. Искахме още едно малко нещо. Искахме много различни бази данни. Не всички наши клиенти използват Postgres. Някои хора използват MySQL, MongoDB. В общността други разработчици са подкрепили FoundationDB. И този списък непрекъснато се разширява.
Общността харесва идеята базата данни да се изпълнява в управлявана среда в облака. И разработчиците поддържат своите бази данни, които могат да бъдат архивирани равномерно заедно с Postgres с нашата система за архивиране.
Какво научихме от тази история? Нашият продукт, като отдел за разработка, не е редове код, не са изявления, не са файлове. Нашият продукт не е изтегляне на заявки. Това са идеите, които предаваме на общността. Това е технологична експертиза и движението на технологиите към облачна среда.
Има такава база данни като Postgres. Най-много харесвам ядрото на Postgres. Прекарвам много време в разработване на ядрото на Postgres с общността.
Но тук трябва да се каже, че Yandex.Cloud има вътрешна инсталация на управлявани бази данни. И започна много отдавна в Yandex.Mail. Експертният опит, който сега доведе до управляван Postgres, беше натрупан, когато пощата искаше да се премести в Postgres.
Mail има много подобни изисквания към облака. Необходимо е да можете да мащабирате до неочакван експоненциален растеж във всяка точка на вашите данни. И пощата вече беше заредена с няколко стотици милиони пощенски кутии на огромен брой потребители, които постоянно правят много заявки.
И това беше доста сериозно предизвикателство за екипа, който разработваше Postgres. Тогава всички проблеми, които срещнахме, бяха докладвани на общността. И тези проблеми бяха коригирани и коригирани от общността на някои места дори на ниво платена поддръжка за някои други бази данни и дори по-добре. Тоест можете да изпратите писмо до PgSQL хакер и да получите отговор в рамките на 40 минути. Платената поддръжка в някои бази данни може да смята, че има по-приоритетни неща от вашата грешка.
Сега вътрешната инсталация на Postgres е няколко петабайта данни. Това са няколко милиона заявки в секунда. Това са хиляди клъстери. Той е много мащабен.
Но има един нюанс. Той живее не на фантастични мрежови устройства, а на доста прост хардуер. Има и тестова среда специално за интересни нови неща.
И в определен момент в тестовата среда получихме съобщение, което показва, че вътрешните инварианти на индексите на базата данни са нарушени.
Инвариантът е някакъв вид връзка, която очакваме да поддържаме винаги.
Много критична ситуация за нас. Това показва, че някои данни може да са загубени. А загубата на данни е нещо направо катастрофално.
Общата идея, която следваме в управляваните бази данни е, че дори с усилия, ще бъде трудно да загубите данни. Дори ако съзнателно ги премахнете, пак ще трябва да игнорирате отсъствието им за дълъг период от време. Сигурността на данните е религия, която следваме доста усърдно.
И тук възниква ситуация, която подсказва, че може да има ситуация, за която може да не сме подготвени. И започнахме да се подготвяме за тази ситуация.
Първото нещо, което направихме, беше да заровим трупите от тези хиляди клъстери. Открихме кои от клъстерите са разположени на дискове с проблемен фърмуер, които губят актуализации на страници с данни. Маркира целия код на данни на Postgres. И маркирахме тези съобщения, които показват нарушения на вътрешните инварианти с код, който е предназначен да открива повреда на данните.
Този пач беше практически приет от общността без много обсъждане, тъй като във всеки конкретен случай беше очевидно, че се е случило нещо лошо и трябваше да бъде докладвано в дневника.
След това стигнахме до момента, в който имаме мониторинг, който сканира регистрационни файлове. И при съмнителни съобщения, той събужда дежурния, а дежурният го ремонтира.
Но! Сканирането на регистрационни файлове е евтина операция на един клъстер и катастрофално скъпа за хиляда клъстера.
Написахме разширение, наречено . Той създава изглед на базата данни, в който можете евтино и бързо да избирате статистически данни за минали грешки. И ако трябва да събудим дежурния, тогава ще разберем за това, без да сканираме гигабайтови файлове, а като извлечем няколко байта от хеш-таблицата.
Това разширение е прието, например, в хранилището за . Ако искате да го използвате, можете да го инсталирате сами. Разбира се, че е с отворен код.
Но това не е всичко. Започнахме да използваме Amcheck, разширение, създадено от общността, за да намираме инвариантни нарушения в индексите.
И открихме, че ако го управлявате в мащаб, има грешки. Започнахме да ги оправяме. Нашите корекции са приети.
Открихме, че това разширение не може да анализира GiST и GIT индекси. Накарахме ги да подкрепят. Но тази поддръжка все още се обсъжда от общността, защото това е сравнително нова функционалност и има много подробности.
И също така открихме, че когато проверяваме индексите за нарушения на лидера на репликация, на главния, всичко работи добре, но на репликите, на последователя, търсенето на повреда не е толкова ефективно. Не всички инварианти се проверяват. И една инварианта много ни притесняваше. И прекарахме година и половина в комуникация с общността, за да позволим тази проверка на реплики.
Написахме код, който трябва да следва всички can... протоколи. Обсъждахме този пач от доста време с Peter Gaghan от Crunchy Data. Той трябваше леко да модифицира съществуващото B-дърво в Postgres, за да приеме тази корекция. Той беше приет. И сега проверката на индексите на реплики също стана достатъчно ефективна за откриване на нарушенията, на които се натъкнахме. Тоест, това са нарушенията, които могат да бъдат причинени от грешки във фърмуера на диска, грешки в Postgres, грешки в ядрото на Linux и хардуерни проблеми. Доста обширен списък от източници на проблеми, за които се подготвяхме.
Но освен индексите, има такава част като heap, т.е. мястото, където се съхраняват данните. И няма много инварианти, които могат да бъдат проверени.
Имаме разширение, наречено Heapcheck. Започнахме да го развиваме. И паралелно, заедно с нас, компанията EnterpriseDB също започна да пише модул, който те нарекоха Heapcheck по същия начин. Само ние го нарекохме PgHeapcheck, а те просто го нарекоха Heapcheck. Имат го с подобни функции, малко по-различен подпис, но със същите идеи. Приложиха ги малко по-добре на места. И те го публикуваха в отворен код преди.
И сега ние развиваме тяхната експанзия, защото вече не е тяхната експанзия, а разширяването на общността. И в бъдеще това е част от ядрото, което ще бъде предоставено на всички, така че да могат да знаят за бъдещи проблеми предварително.
На някои места дори стигнахме до заключението, че имаме фалшиви положителни резултати в нашите системи за наблюдение. Например системата 1C. Когато използва база данни, Postgres понякога записва в нея данни, които може да прочете, но pg_dump не може да прочете.
Тази ситуация изглеждаше като повреда в нашата система за откриване на проблеми. Дежурният бил събуден. Дежурният погледна какво става. След известно време дойде клиент и каза, че имам проблеми. Дежурният обясни какъв е проблемът. Но проблемът е в ядрото на Postgres.
Намерих дискусия за тази функция. И той пише, че сме се сблъскали с тази функция и е неприятно, човек се събужда през нощта, за да разбере какво е това.
Общността отговори: „О, наистина трябва да го поправим.“
Имам проста аналогия. Ако ходите с обувка, в която има песъчинка, тогава по принцип можете да продължите - няма проблем. Ако продавате ботуши на хиляди хора, тогава нека да направим ботуши без пясък изобщо. И ако един от потребителите на вашите обувки ще бяга маратон, тогава искате да направите много добри обувки и след това да ги мащабирате за всички ваши потребители. И такива неочаквани потребители винаги са в облачната среда. Винаги има потребители, които експлоатират клъстера по някакъв оригинален начин. Винаги трябва да се подготвяте за това.
Какво научихме тук? Научихме едно просто нещо: най-важното е да обясним на общността, че има проблем. Ако общността е осъзнала проблема, тогава възниква естествена конкуренция за решаването на проблема. Защото всеки иска да реши важен проблем. Всички доставчици, всички хакери разбират, че те самите могат да стъпят на този рейк, така че искат да ги елиминират.
Ако работите върху проблем, но той не притеснява никого освен вас, но работите върху него систематично и в крайна сметка се счита за проблем, тогава вашата заявка за изтегляне определено ще бъде приета. Вашата корекция ще бъде приета, вашите подобрения или дори заявки за подобрения ще бъдат прегледани от общността. В крайна сметка ние правим базата данни по-добра един за друг.
Интересна база данни е Greenplum. Това е много паралелна база данни, базирана на кодовата база на Postgres, с която съм много запознат.
И Greenplum има интересна функционалност - добавяне на оптимизирани таблици. Това са таблици, към които можете бързо да добавяте. Те могат да бъдат колонни или редови.
Но нямаше групиране, т.е. нямаше функционалност, където можете да подредите данните, разположени в таблицата, в съответствие с реда, който е в един от индексите.
Момчетата от таксито дойдоха при мен и казаха: „Андрей, познаваш Postgres. И тук е почти същото. Превключете на 20 минути. Вземете го и го направете. Помислих си, че да, знам Postgres, превключване за 20 минути - трябва да направя това.
Но не, не бяха 20 минути, писах го с месеци. На конференцията PgConf.Russia се обърнах към Heikki Linakangas от Pivotal и попитах: „Има ли някакви проблеми с това? Защо няма клъстериране на оптимизирана таблица за добавяне?“ Той казва: „Вземете данните. Сортирате, пренареждате. Това е просто работа“. Аз: „О, да, просто трябва да го вземеш и да го направиш.“ Той казва: „Да, имаме нужда от свободни ръце, за да направим това.“ Мислех, че определено трябва да направя това.
И няколко месеца по-късно изпратих заявка за изтегляне, която реализира тази функционалност. Тази заявка за изтегляне беше прегледана от Pivotal заедно с общността. Разбира се, имаше бъгове.
Но най-интересното е, че когато тази заявка за изтегляне беше обединена, бяха открити грешки в самия Greenplum. Открихме, че таблиците на купчина понякога нарушават транзакционността, когато са групирани. И това е нещо, което трябва да се поправи. И тя е на мястото, което току-що докоснах. И естествената ми реакция беше – добре, нека и аз да направя това.
Поправих този бъг. Изпрати заявка за изтегляне до фиксаторите. Той беше убит.
След което се оказа, че тази функционалност трябва да се получи във версията на Greenplum за PostgreSQL 12. Тоест 20-минутното приключение продължава с нови интересни приключения. Беше интересно да се докоснем до текущото развитие, където общността изрязва нови и най-важни функции. Замръзнало е.
Но не свърши дотук. След всичко се оказа, че трябва да напишем документация за всичко това.
Започнах да пиша документация. За щастие дойдоха документалистите от Pivotal. Английският е техният роден език. Помогнаха ми с документацията. Всъщност те сами пренаписаха предложеното от мен на истински английски.
И тук, изглежда, приключението приключи. И знаете ли какво се случи тогава? Момчетата от таксито дойдоха при мен и казаха: „Има още две приключения, всяко по 10 минути.“ И какво да им кажа? Казах, че сега ще дам доклад в мащаб, тогава ще видим вашите приключения, защото това е интересна работа.
Какво научихме от този случай? Тъй като работата с отворен код винаги е работа с конкретен човек, винаги е работа с общността. Защото на всеки един етап работих с някой разработчик, някой тестер, някой хакер, някой документалист, някой архитект. Не съм работил с Greenplum, работих с хора около Greenplum.
Но! Има още един важен момент - това е просто работа. Тоест идваш, пиеш кафе, пишеш код. Всички видове прости инварианти работят. Направи го нормално - ще се оправи! И това е доста интересна работа. Има заявка за тази работа от клиенти на 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, различни ли са от вътрешните потребители, които живеят във вътрешния облак?“
Профилът на натоварване, разбира се, е различен. Но от гледна точка на моя отдел всички специални и интересни случаи се създават при нестандартно натоварване. Разработчици с въображение, разработчици, които правят неочакваното, има голяма вероятност да бъдат намерени както вътрешно, така и външно. В това отношение всички сме приблизително еднакви. И вероятно единствената важна характеристика в работата на базите данни на Yandex ще бъде, че вътре в Yandex имаме учение. В един момент някои зони на достъпност напълно преминават в сянка и всички услуги на Yandex трябва по някакъв начин да продължат да функционират въпреки това. Това е малка разлика. Но това създава много изследователски разработки на интерфейса на базата данни и мрежовия стек. В противен случай външните и вътрешните инсталации генерират едни и същи заявки за функции и подобни заявки за подобряване на надеждността и производителността.
Следващ въпрос: „Вие лично как се чувствате относно факта, че голяма част от това, което правите, се използва от други облаци?“ Няма да назовем конкретни, но много проекти, направени в Yandex.Cloud, се използват в облаците на други хора.
Това е готино. Първо, това е знак, че сме направили нещо правилно. И чеше егото. И сме по-уверени, че сме взели правилното решение. От друга страна, това е надеждата, че в бъдеще това ще ни донесе нови идеи, нови заявки от потребители на трети страни. Повечето проблеми в GitHub са създадени от отделни системни администратори, отделни DBA, отделни архитекти, отделни инженери, но понякога идват хора със систематичен опит и казват, че в 30% от определени случаи имаме този проблем и нека помислим как да го разрешим. Това е, което очакваме с най-голямо нетърпение. Очакваме с нетърпение да споделим опит с други облачни платформи.
Говорихте много за маратона. Знам, че сте участвали в маратон в Москва. Като резултат? Изпревари момчетата от PostgreSQL?
Не, Олег Бартунов бяга много бързо. Той завърши един час преди мен. Като цяло съм доволен от това докъде стигнах. За мен самото завършване беше постижение. Като цяло е изненадващо, че има толкова много бегачи в postgres общността. Струва ми се, че има някаква връзка между аеробните спортове и желанието за системно програмиране.
Искате да кажете, че в ClickHouse няма бегачи?
Знам със сигурност, че ги има. ClickHouse също е база данни. Между другото, Олег сега ми пише: „Да отидем ли да тичаме след доклада?“ Това е страхотна идея.
Друг въпрос от предаването от Никита: „Защо сам поправихте грешката в Greenplum и не я дадохте на младши?“ Вярно, не е много ясно какъв е бъгът и в коя услуга, но вероятно означава този, за който говорихте.
Да, по принцип можеше да се подари на някого. Просто промених кода. И беше естествено да продължа да го правя веднага. По принцип идеята за споделяне на опит с екипа е добра идея. Определено ще споделим задачите на Greenplum между всички членове на нашия отдел.
Тъй като говорим за юноши, ето един въпрос. Човекът реши да създаде първия комит в Postgres. Какво трябва да направи, за да направи първия ангажимент?
Това е интересен въпрос: „Откъде да започна?“ Обикновено е доста трудно да започнете с нещо в ядрото. В Postgres например има списък със задачи. Но всъщност това е лист от това, което те се опитаха да направят, но не успяха. Това са сложни неща. И обикновено можете да намерите някои помощни програми в екосистемата, някои разширения, които могат да бъдат подобрени, които привличат по-малко внимание от разработчиците на ядрото. И съответно там има повече точки за растеж. В програмата Google Summer of code всяка година общността на postgres предлага много различни теми, които могат да бъдат разгледани. Тази година имахме, мисля, трима ученици. Един дори пише в WAL-G по теми, които са важни за Yandex. В Greenplum всичко е по-просто, отколкото в общността на Postgres, защото хакерите на Greenplum третират заявките за изтегляне много добре и започват да преглеждат веднага. Изпращането на корекция до Postgres е въпрос на месеци, но Greenplum ще дойде след ден и ще види какво сте направили. Друго нещо е, че Greenplum трябва да реши текущи проблеми. Greenplum не се използва широко, така че намирането на вашия проблем е доста трудно. И на първо място трябва да решим проблемите, разбира се.
Източник: www.habr.com