Буде розглянуто внесок Яндекса до наступних баз даних.
- Натисніть Будинок
- Одіссея
- Відновлення на точку часу (WAL-G)
- PostgreSQL (включаючи logerrors, Amcheck, heapcheck)
- Зелена слива
Відео:
Hello world! Мене звуть Андрій Бородін. І я в Яндекс.Хмарі займаюся тим, що розвиваю відкриті реляційні бази даних на користь Яндекс.Хмари та клієнтів Яндекс.Хмари.
У цій доповіді ми поговоримо про те, які проблеми виникають у відкритих баз даних у масштабі. Чому це важливо? Тому що маленькі маленькі проблемки, які, як комарики, потім стають слонами. Вони стають більшими, коли у вас багато кластерів.
Але це не головне. Бувають неймовірні речі. Речі, які відбуваються в одному на мільйон випадки. І в хмарному оточенні ви повинні бути готові до цього, тому що неймовірні речі стають дуже ймовірними, коли щось існує в масштабі.
Але! У чому плюс відкритих баз даних? Те, що у вас є теоретична можливість з будь-якою проблемою боротися. Ви маєте вихідний код, у вас є знання програмування. Поєднуємо та працює.
Які підходи в роботі над відкритим програмним забезпеченням?
- Найзрозуміліший підхід – це використання програмного забезпечення. Якщо ви використовуєте протоколи, якщо ви використовуєте стандарти, якщо ви використовуєте формати, якщо ви пишете запити на програмне забезпечення з open source, то ви його підтримуєте.
- Ви робите його екосистему більше. Ви робите ймовірність раннього виявлення бага більше. Ви підвищуєте надійність цієї системи. Ви збільшуєте доступність розробників на ринку. Ви покращуєте це програмне забезпечення. Ви вже контриб'ютор, якщо ви просто зробили up getting style і щось там поколупали.
- Інший зрозумілий підхід – це спонсорування відкритого програмного забезпечення. Наприклад, усім відома програма Google Summer of Code, коли Google платить великій кількості студентів з усього світу зрозумілі гроші за те, щоб вони розвивали відкриті програмні проекти, які відповідають певним вимогам щодо ліцензії.
- Це дуже цікавий підхід, тому що він дозволяє розвивати програмне забезпечення, не зміщуючи фокус із спільноти. Google, як технологічний гігант, не говорить про те, що ми хочемо ось цю фічі, хочемо відремонтувати ось цей баг і ось там потрібно копати. Google каже: «Робіть те, що ви робите. Просто продовжуйте працювати так, як працювали, і все буде добре».
- Наступний підхід участі у open source – це співучасть. Коли у вас є проблема у відкритому програмному забезпеченні і є розробники, ваші розробники починають проблеми вирішувати. Вони починають робити вашу інфраструктуру ефективнішою, ваші програми швидшими та надійнішими.
Один з найвідоміших яндексових проектів у галузі СПО – це ClickHouse. Це база даних, яка народилася як відповідь на дзвінки, що стоять перед Яндекс.Метрикою.
І як база даних вона була зроблена в Open Source для того, щоб створювати екосистему і спільно з іншими розробниками (не тільки всередині Яндекса) її розвивати. І зараз це великий проект, у якому бере участь багато різних компаній.
В Яндекс.Хмарі ми зробили ClickHouse поверх Yandex Object Storage, тобто поверх хмарного сховища.
Чому це важливо саме у хмарі? Тому що будь-яка база даних працює у цьому трикутнику, у цій піраміді, у цій ієрархії типів пам'яті. У вас є швидкі, але маленькі регістри та дешеві великі, але повільні SSD-диски, жорсткі диски та якісь ще блокові пристрої. І якщо ви ефективні згори піраміди, то у вас швидка база даних. якщо ви ефективні знизу цієї піраміди, у вас масштабована база даних. І в цьому плані додавання ще одного шару знизу – це логічний підхід щодо збільшення масштабованості бази даних.
Як її можна було зробити? Це важливий момент у цій доповіді.
- Ми могли реалізувати ClickHouse over MDS. MDS – це внутрішній яндексовий інтерфейс хмарного сховища. Він складніший, ніж поширений протокол S3, але він більше підходить для блокового пристрою. Він найкраще підходить для запису даних. Він потребує більше програмування. Програмісти програмуватимуть, це навіть добре, цікаво.
- S3 – найпоширеніший підхід, який робить більш простий інтерфейс ціною меншою адаптацією під деякі типи навантажень.
Звичайно, бажаючи надати функціональність всій екосистемі ClickHouse і зробити ту задачу, яка потрібна всередині Яндекс.Хмари, ми вирішили зробити так, щоб ефект від неї одержала вся спільнота ClickHouse. Ми реалізували ClickHouse over S3, а не ClickHouse over MDS. А це велика кількість роботи.
Посилання:
"Filesystem abstraction layer"
"AWS SDK S3 integration"
"Base implementation of IDisk interafce for S3"
«Integration of log storage engines with IDisk interface»
"Log engine support for S3 and SeekableReadBuffer"
"Storage Stripe Log S3 support"
«Storage MergeTree initial support for S3»
"MergeTree full support for S3"
«Support ReplicatedMergeTree over S3»
«Add default credentials and custom headers for s3 storage»
«S3 with dynamic proxy configuration»
"S3 with proxy resolver"
Це список pull request для реалізації віртуальної файлової системи в ClickHouse. Це багато pull requests.
Посилання:
"DiskS3 hardlinks optimal implementation"
"S3 HTTP client - Avoid copying response stream into memory"
«Avoid copying whole response stream до пам'яті в S3 HTTP
client»
"Ability to cache mark and index files for S3 disk"
«Move parts from DiskLocal to DiskS3 in parallel»
Але на цьому робота не закінчилась. Після того, як фіча була зроблена, знадобилася ще якась кількість роботи для того, щоб оптимізувати цю функціональність.
Посилання:
«Add SelectedRows and SelectedBytes events»
«Add profiling events from S3 request to system.events»
"Add QueryTimeMicroseconds, SelectQueryTimeMicroseconds and InsertQueryTimeMicroseconds"
І потім потрібно було зробити її діагностованою, налагодити моніторинги і зробити її керованою.
І все це було зроблено так, щоб вся спільнота, вся екосистема ClickHouse результат цієї роботи отримала.
Давайте перейдемо до транзакційних баз даних, до OLTP баз даних, які особисто мені ближчі.
Ось цей підрозділ розробки СУБД із відкритим кодом. Ось ці хлопці роблять вуличну магію щодо покращення трансакційних відкритих баз даних.
Один із проектів, на прикладі якого можна розповісти, про те, як і що ми робимо, це Пулер з'єднань у Postgres.
Postgres – це процесна база даних. Це означає, що до бази даних має входити якнайменше мережевих з'єднань, які працюють із транзакціями.
З іншого боку, у хмарному оточенні типова ситуація, коли в один кластер прийшла одразу тисяча з'єднань. І завдання пулера з'єднання тисячу з'єднань запакувати в невелику кількість серверних з'єднань.
Можна сказати, що пулер з'єднання – телефоніст, який перекладає байтики так, щоб вони ефективно доїхали до бази даних.
На жаль, немає хорошого російського слова позначення пулера сполук. Іноді його називають multiplexer з'єднань. Якщо ви знаєте, як назвати connection pooler, то обов'язково мені скажіть, я дуже радий говорити правильною російською технічною мовою.
Ми досліджували кулери сполук, які підходили для керованого postgres'ного кластера. І найкраще нам підходив PgBouncer. Але ми стикалися з рядом проблем у PgBouncer. Багато років тому Володя Бородін робив доповіді про те, що ми використовуємо PgBouncer, нам все подобається, але є нюанси, над чим працювати.
І ми працювали. Ті проблеми, з якими ми стикалися, ми лагодили, ми патчили Bouncer, намагалися відносити pull request у upstream. Але з фундаментальною однопоточністю важко було працювати.
Нам довелося збирати каскади з патчених Bouncers. Коли у нас багато однопотокових Bouncers, то на верхньому шарі переводять з'єднання у внутрішній шар Bouncers. Це погано керована, складна у побудові та масштабуванні туди й назад система.
Ми дійшли того, що ми створили свій пулер з'єднань, який називається Odyssey. Ми написали його з нуля.
У 2019 році на конференції PgCon я представляв цей пулер спільноті розробників. Зараз у нас трохи менше 2 зірочок на GitHub, тобто проект живе, проект популярний.
І якщо ви створюєте кластер Postgres в Яндекс.Хмарі, то це буде кластер із вбудованим Odyssey, який переналаштовується при масштабуванні кластера туди чи назад.
Чого ми навчилися у цьому проекті? Запуск конкуруючого проекту – це завжди агресивний крок, це крайній захід, коли ми говоримо, що є проблеми, які не вирішуються досить швидко, не вирішуються в ті проміжки часу, які б нас влаштували. Але це ефективний захід.
PgBouncer почав розвиватися швидше.
І зараз з'явилися інші проекти. Наприклад, pgagroal, що розвивається розробниками Red Hat. Вони переслідують схожі цілі та реалізують схожі ідеї, але, звичайно, зі своєю специфікою, яка ближча розробникам pgagroal.
Ще один випадок роботи з postgres'ною спільнотою – це відновлення на точку в часі. Це відновлення після збою, це відновлення з бекапу.
Бекапілок багато і всі вони різні. Майже кожен вендор Postgres має своє бекапне рішення.
Якщо взяти всі системи резервного копіювання, скласти матрицю фіч і жартома порахувати визначник у цій матриці, то він буде нульовим. Що це означає? Що, якщо взяти якусь конкретну бекапілку, то її не можна зібрати зі шматків решти. Вона унікальна у своїй реалізації, вона унікальна у своєму призначенні, вона є унікальною в ідеях, які закладені в неї. І всі вони є специфічними.
Коли ми займалися цим питанням, компанія CitusData запустила проект WAL-G. Це система резервного копіювання, яка була зроблена із прицілом на хмарне оточення. Зараз CitusData - це вже частина Microsoft. А в той момент ідеї, які були закладені на початкових релізах WAL-G, нам дуже сподобалися. І ми почали контриб'ютити у цей проект.
Зараз у цьому проекті багато десятків розробників, але до топ-10 контриб'юторів WAL-G входять 6 яндексоїдів. Ми багато своїх ідей принесли туди. І, звичайно, самі їх реалізували, самі їх протестували, самі їх викотили у production, самі їх використовуємо, самі вигадуємо, куди рухатися далі, при цьому взаємодіємо з великою спільнотою WAL-G.
І на наш погляд, зараз ця система резервного копіювання, в тому числі враховуючи наші зусилля, стала оптимальною для хмарного оточення. Це краще, ніж варто бекапит Postgres у хмарі.
Що це означає? Ми просували досить велику ідею: резервне копіювання має бути безпечним, дешевим при експлуатації та максимально швидким при відновленні.
Чому воно має бути дешевим при експлуатації? Коли нічого не зламалося, ви не повинні знати, що ви маєте резервні копії. Все працюєте нормально, ви витрачаєте якнайменше центрального процесора, ви використовуєте якнайменше ресурсів вашого диска і шлете якнайменше байтиків у мережу, щоб не заважати корисному навантаженню ваших цінних сервісів.
А коли все зламалося, наприклад, адмін дропнув дані, щось пішло не так, і вам потрібно терміново повернутися в минуле, ви відновлюєтеся на всі гроші, тому що ви хочете ваші дані повернути швидко та цілісно.
І ми цю просту ідею висунули. І, як нам здається, нам удалося її реалізувати.
Але це не все. Ми хотіли ще одну маленьку річ. Ми хотіли багато різних баз даних. Не всі наші клієнти користуються Postgres. Деякі користуються MySQL, MongoDB. У співтоваристві інші розробники підтримали FoundationDB. І цей перелік постійно розширюється.
Ідея того, що база даних експлуатується в керованому оточенні у хмарі, спільноті подобається. І розробники підтримують свої бази даних, які одночасно разом із Postgres нашою системою резервного копіювання можна копіювати.
Чого ми навчилися у цій історії? Наш продукт як підрозділ розвитку, це не рядки коди, це не оператори, це не файли. Наш продукт – це не pull requests. Це ідеї, які ми транслюємо спільноти. Це технологічна експертиза та рух технологій у бік хмарного оточення.
Є така база даних як Postgres. Мені ядро Postgres подобається найбільше. Я багато часу витрачаю на те, щоб розвивати ядро Postgres спільно із спільнотою.
Але тут треба сказати, що Яндекс.Хмари має внутрішню інсталяцію керованих баз даних. І почалася вона давним-давно в Яндекс.Пошті. Та експертиза, яка привела зараз до керованого Postgres, вона була накопичена тоді, коли пошта захотіла заїхати до Postgres.
У пошти дуже схожі на хмару вимоги. Їй потрібно, щоб ви могли відмасштабуватися на несподіване експонентне зростання у будь-якій точці ваших даних. І пошта вже мала навантаження з якимись сотнями мільйонів ящиків величезної кількості користувачів, які постійно роблять багато запитів.
І це був досить серйозний виклик команді, яка займалася розвитком Postgres. Тоді всі проблеми, з якими ми стикалися, повідомляли спільноту. І ці проблеми виправлялися, причому виправлялися спільнотою місцями навіть на рівні платної підтримки деяких інших баз даних і навіть краще. Т. е. відправити листа в PgSQL hacker і отримати відповідь можна протягом 40 хвилин. Платний саппорт у якихось базах даних може подумати, що є пріоритетніші речі, ніж ваш баг.
Зараз внутрішня інсталяція Postgres – це якісь петабайти даних. Це якісь мільйони запитів на секунду. Це тисячі кластерів. Вона дуже масштабна.
Але є нюанс. Вона живе не на модних мережевих дисках, а на досить простому залізі. І там є тестове оточення спеціально для цікавих нових речей.
І в певний момент у тестовому оточенні ми отримали таке повідомлення, яке свідчить про те, що порушено внутрішні інваріанти індексів баз даних.
Інваріант – це якесь співвідношення, яке ми очікуємо, що виконуватиметься завжди.
Дуже критична ситуація для нас. Вона свідчить, що якісь дані, можливо, втрачені. А втрата даних – це прямо катастрофічне.
Загальна ідея, яку ми прямуємо в керованих базах даних у тому, що навіть докладаючи зусиль, втратити дані буде складно. Навіть якщо ви їх доцільно видалите, вам знадобиться ще ігнорувати їх відсутність протягом тривалого часу. Збереження даних – це релігія, яку ми слідуємо досить старанно.
А тут виникає ситуація, яка говорить про те, що може бути ситуація, до якої ми можемо не бути готові. І ми почали готуватись до цієї ситуації.
Перше, що ми зробили, ми погріпали логи із цих тисяч кластерів. Знайшли, які кластери розташовуються на дисках з проблемними прошивками, які втрачали оновлення сторінок даних. Розмітили всю кодову інформацію Postgres. І ті повідомлення, які свідчать про порушення внутрішніх інваріантів, ми розмітили кодом, що призначений для виявлення корупції даних.
Цей патч був практично прийнятий спільнотою без особливого обговорення, тому що в кожному конкретному випадку було очевидно, що щось погане трапилося, треба повідомити лог про це.
Після цього ми дійшли того, що ми маємо моніторинг, який сканує логи. І у разі підозрілих повідомлень будить чергового, і черговий лагодить.
Але! Сканування ліг - це дешева операція на одному кластері і катастрофічно дорога для тисячі кластерів.
Ми написали розширення, яке називається . Воно створює уявлення про базу даних, в якому можна дешево і швидко поселити статистику з помилок. І якщо потрібно будити чергового, ми дізнаємося про це, не скануючи гігабайтні файли, а витягуючи кілька байт з хеш-таблиці.
Це розширення було прийнято, наприклад, у репозитарії для . Якщо ви хочете використовувати його, ви можете собі його поставити. Звісно, це open source.
Але це не все. Ми почали використовувати Amcheck — розширення, яке створено спільнотою для пошуку порушень інваріантів в індексах.
І ми з'ясували, що якщо експлуатувати його у масштабі, то там є баги. Ми почали їх лагодити. Наші виправлення було прийнято.
Ми виявили, що це розширення не вміє аналізувати GiST&GIT індекси. Ми зробили їхню підтримку. Але ця підтримка поки що обговорюється спільнотою, бо це відносно нова функціональність і там є багато деталей.
І ще ми виявили, що у разі перевірок індексів на порушення на лідері реплікації, на майстрі все працює добре, а на репліках, на follower пошук корупцій не такий ефективний. Не всі інваріанти перевіряються. І один інваріант нас дуже турбував. І ми півтора роки спілкувалися із спільнотою для того, щоб включити цю перевірку на репліках.
Писали код, який повинен дотримуватися всіх can… протоколів. Обговорювали досить довго з Пітером Гейганом із Crunchy Data цей патч. Йому довелося трохи модифікувати існуюче B-дерево в Postgres для того, щоб цей патч прийняти. Його було прийнято. І зараз перевірка індексів на репліках теж стала досить ефективною для того, щоб виявляти порушення, з якими ми стикалися. Т. е. це порушення, які можуть бути викликані помилками в прошивці дисків, багами в Postgres, багами в ядрі Linux, залізними проблемами. Досить великий список джерел проблем, яких ми готувалися.
Але крім індексів є така частина, як heap, тобто місце, де дані зберігаються. І там не так багато інваріантів, які можна було б перевіряти.
У нас є розширення, яке називається Heapcheck. Ми почали його розвивати. І паралельно разом з нами компанія EnterpriseDB теж стала писати модуль, який вони назвали так само Heapcheck. Тільки ми його назвали PgHeapcheck, а вони просто Heapcheck. Він у них з аналогічними функціями, трошки з іншою сигнатурою, але з тими самими ідеями. Вони трохи місцями краще їх реалізували. І раніше виклали в Open Source.
І тепер ми займаємося тим, що розвиваємо їхнє розширення, тому що це вже не їхнє розширення, а розширення спільноти. І в майбутньому – це частина ядра, яка поставлятиметься всім для того, щоб можна було про майбутні проблеми знати заздалегідь.
Місцями ми навіть дійшли того, що у нас є хибнопозитивні спрацьовування наших моніторингів. Наприклад, система 1С. При використанні бази даних Postgres іноді записує в неї такі дані, які сама рахувати зможе, але pg_dump рахувати їх не зможе.
Ця ситуація мала вигляд нашої системи виявлення проблем як корупція. Чергового розбудили. Черговий глянув, що відбувається. Через деякий час прийшов клієнт і сказав, що маю проблеми. Черговий пояснив, у чому проблема. Але проблема в ядрі Postgres.
Я знайшов обговорення цієї особливості. І написав, що ми зіткнулися з цією особливістю і було неприємно, людина вночі прокидалася, щоб розібратися з тим, що це таке.
Спільнота відповіла: «О, справді, треба лагодити».
Я маю просту аналогію. Якщо ви ходите у черевику, в який потрапила піщинка, то, в принципі, можна йти далі – нічого страшного. Якщо ви продаєте черевики тисячам чоловіків, то давайте робити черевики без піску зовсім. А якщо хтось із користувачів ваших черевиків зібрався бігти марафон, то ви хочете зробити дуже хороші черевики, а потім уже відмасштабувати на всіх ваших користувачів. І такі несподівані користувачі завжди знаходяться у хмарному оточенні. Завжди є користувачі, які експлуатують кластер якимось оригінальним способом. До цього треба завжди готуватись.
Чого ми тут навчились? Ми навчилися простої речі: найголовніше пояснити спільноті, що проблема є. Якщо співтовариство усвідомило проблему, виникає природна конкуренція через те, щоб проблему вирішити. Тому що важливу проблему усі хочуть вирішити. Усі вендори, всі хакери розуміють, що самі можуть на ці граблі наступити, тому хочуть їх усунути.
Якщо ви працюєте над якоюсь проблемою, але вона окрім вас нікого не турбує, але ви працюєте над нею системно і її зрештою вирішили, то ваш pull request обов'язково буде прийнятий. Ваш патч буде прийнято, ваші доопрацювання або навіть запити на доопрацювання будуть розглянуті спільнотою. Зрештою, ми робимо базу даних краще один для одного.
Цікава база даних – Greenplum. Це дуже паралельна база даних, заснована на кодовій базі Postgres, яка мені добре знайома.
І в Greenplum є цікава функціональність – це append optimized таблиці. Це такі таблиці, у яких можна швидко дописувати. Вони можуть бути або стовпцевими, або малими.
Але там не було кластеризації, тобто не було функціональності, коли можна впорядкувати дані, розташовані в таблиці, відповідно до порядку, який є в одному з індексів.
До мене прийшли хлопці з таксі та кажуть: «Андрію, ти ж знаєш Postgres. І тут майже те саме. Перемикання на 20 хвилин. Береш і робиш». Я подумав, що так, я знаю Postgres, перемикання на 20 хвилин – треба цим зайнятися.
Але ні, це було не 20 хвилин, я писав кілька місяців. На конференції PgConf.Russia я підійшов до Heikki Linakangas з Pivotal і запитав: Є якісь проблеми з цим? Чому немає кластеризації append optimized таблиці?». Він каже: «Береш дані. Сортуєш, перекладаєш. Це просто робота». Я: "О, так, це треба просто взяти і зробити". Він каже: "Так, потрібні вільні руки, які це зроблять". Я подумав, що треба цим зайнятися.
І за кілька місяців я відправив pull request, який реалізовував цю функціональність. Цей pull request подивилися у Pivotal разом із спільнотою. Звісно, там були баги.
Але найцікавіше, що за міри цього pull request у самому Greenplum знайшли баги. Ми виявили, що heap-таблиці при кластеризації іноді порушують транзакційність. І це річ, яку треба лагодити. І вона в тому місці, яке я щойно чіпав. І природна реакція моя була - добре, давайте я цим теж займуся.
Я полагодив цей баг. Надіслав pull request фіксам. Його помержили.
Після чого з'ясувалося, що цю функціональність потрібно отримати ще у версії Greenplum для PostgreSQL 12. Т. е. пригоди на 20 хвилин продовжуються новими цікавими пригодами. Було цікаво торкнутися актуального розвитку, де спільнота пиляє нові та найважливіші фічі. Це помержили.
Але це все не закінчилося. Після всього з'ясувалося, що треба документацію на це все написати.
Я почав писати документацію. На щастя, прийшли документатори із Pivotal. Для них англійська рідна. Вони допомогли мені із документацією. По суті, самі переписали те, що я пропонував справжньою англійською.
І на цьому, здавалося б, пригода закінчилася. І знаєте, що сталося згодом? До мене прийшли хлопці з таксі та кажуть: «Тут дві пригоди ще є, кожна на 10 хвилин». І що мені треба було їм сказати? Я сказав, що зараз доповідь на scale зроблю, потім подивимося ваші пригоди, бо це цікава робота.
Чого ми навчилися у цьому випадку? Тому, що робота з open source – це робота з конкретною людиною, це завжди робота з спільнотою. Тому що в кожній окремій стадії я працював із якимсь розробником, із якимось тестувальником, із якимось хакером, із якимось документаром, із якимось архітектором. Я працював не з Greenplum, я працював з людьми навколо Greenplum.
Але! Є ще один важливий момент – це просто робота. Т. е. приходиш, випиваєш кави, пишеш код. Працюють усі прості інваріанти. Нормально роби нормально буде! І це досить цікава робота. На цю роботу є запит з боку клієнтів Яндекс.Хмари, користувачів наших кластерів як усередині Яндекса, так і зовні. І, я думаю, що кількість проектів, у яких ми беремо участь, збільшуватиметься і глибина нашого залучення теж збільшуватиметься.
На цьому все. Давайте переходити до питань.
Сесія питань
Вітання! У нас чергова сесія питань та відповідей. І у студії Андрій Бородін. Це людина, яка щойно розповідала вам про внесок Яндекс.Хмари та Яндекса в open source. У нас зараз доповідь не зовсім про Хмару, але водночас на таких технологіях ми й ґрунтуємося. Не будь того, що зробили ви всередині Яндекса, не було сервісу в Яндекс.Хмарі, тому дякую тобі від мене особисто. І перше питання з трансляції: «На чому написано кожен із проектів, який ти згадував?».
Система резервного копіювання WAL-G написана на Go. Це один із найновіших проектів, над яким ми працювали. Йому буквально лише 3 роки. А база даних найчастіше – це про надійність. І це означає, що бази даних досить старі і вони зазвичай написані на C. Проект Postgres починався років 30 тому. Тоді правильним вибором був C89. І на ньому Postgres написано. Більш сучасні бази, такі як ClickHouse вже пишуть на C++ зазвичай. Вся системна технологія базується навколо C і C++.
Запитання від нашого фінансового менеджера, який відповідає у Хмарі за витрати: «Навіщо Хмара витрачає гроші на підтримку open source?».
Тут є проста відповідь для фінансового менеджера. Ми це робимо для того, щоб робити наші сервіси краще. У якому плані ми можемо зробити краще? Ми можемо зробити ефективніше, швидше, зробити щось більш масштабованим. Але для нас ця історія насамперед про надійність. Наприклад, у системі резервного копіювання ми рев'юнім 100% патчі, які до нього застосовуються. Ми знаємо, що це за код. І ми спокійніше викочуємо нові версії у production. Т. е. в першу чергу це про впевненість, про готовність до розвитку та про надійність
Ще питання: «Чи відрізняється вимоги зовнішніх користувачів, які живуть в Яндекс.Хмарі, від внутрішніх користувачів, які живуть у внутрішньому Хмарі?».
Профіль навантажень, звісно, різний. Але з погляду мого підрозділу всі особливі та цікаві випадки створюються на нестандартному навантаженні. Розробники з фантазією, розробники, що роблять несподівані речі, вони зустрічаються і можливо як всередині, так і зовні. У цьому плані у нас все приблизно однаково. І, напевно, єдина важлива особливість всередині яндексової експлуатації баз даних буде те, що всередині Яндекса ми маємо вчення. У якийсь момент якась зона доступності повністю сягає, і всі сервіси Яндекса повинні якось продовжити функціонувати, незважаючи на це. Ось це невелика відмінність. Але воно створює багато дослідницької розробки на стику бази даних та мережевого стека. В іншому зовнішні та внутрішні інсталяції створюють однакові запити на фічі та схожі запити щодо поліпшення надійності та продуктивності.
Наступне питання: «Як особисто ти ставишся до того, що багато з того, що ти робиш, використовується іншими хмарами?». Ми не називатимемо конкретні, але багато проектів, які зробили в Яндекс.Хмарі, використовуються в чужих хмарах.
Це класно. По-перше, це ознака того, що ми зробили щось правильне. І це чухає его. І ми більше впевнені, що ухвалили правильне рішення. З іншого боку, це надія, що в майбутньому це буде приносити нам нові ідеї, нові запити з боку сторонніх користувачів. Більшість issues на GitHub створюються окремими сисадмінами, окремими DBA, окремими архітекторами, окремими інженерами, але іноді приходять люди із систематизованим досвідом і кажуть, що у 30% певних випадках у нас є ось така проблема і давайте подумаємо, як її вирішити. Ось це те, на що ми чекаємо найбільше. Ми чекаємо, що ми матимемо обмін досвідом з іншими хмарними платформами.
Ти багато розповідав про марафон. Я знаю, що ти пробіг марафон у Москві. Як результат? Обігнав хлопців із Postgres Pro?
Ні, Олег Бартунов бігає дуже швидко. Він на годину раніше за мене фінішував. Загалом я задоволений тим, що я добіг. Для мене просто фініш був здобутком. Загалом це дивно, що в postgres'овій спільноті стільки бігунів. Мені здається, що є якась залежність між аеробними видами спорту та прагненням до системного програмування.
Ти хочеш сказати, що в ClickHouse немає бігунів?
Я достеменно знаю, що вони там є. ClickHouse – це також база даних. До речі, мені зараз Олег пише: Ідемо бігати після доповіді? Це чудова ідея.
Ще питання з трансляції від Микити: «Чому ти баг у Greenplum правил сам, а не віддав junior'ам?». Правда, тут не дуже пояснено, що за баг і в якомусь сервісі, але, напевно, мається на увазі той, про який ти розповідав.
Так, загалом, можна було віддати комусь. Просто це був код, який я щойно змінив. І було природним продовжити відразу його зробити. В принципі, ідея розділяти експертизу з командою – це хороша ідея. Ми обов'язково будемо розділяти завдання щодо Greenplum між усіма учасниками нашого підрозділу.
Якщо мова зайшла про junior'ів, таке питання. Людина вирішила створити перший коміт у Postgres. Що йому треба зробити, щоби зробити перший коміт?
Це цікаве питання: "З чого почати?". Зазвичай почати з чогось у ядрі досить складно. Наприклад, у Postgres є список to do list. Але насправді це лист того, що намагалися зробити, але не вийшло. Це складні речі. І зазвичай можна знайти якісь утиліти в екосистемі, якісь розширення, які можна покращити, які привертають менше уваги розробників ядра. І відповідно там є більше точок для зростання. На програмі Google Summer of code щороку postgres'не співтовариство виставляє багато різних тем, якими можна було б зайнятися. Цього року у нас, здається, було троє студентів. Один навіть у WAL-G писав на теми, які важливі для Яндекса. У Greenplum все простіше, ніж у співтоваристві Postgres, тому що хакери Greenplum дуже добре ставляться pull request'ам і починають рев'ювити відразу. Надіслати патч до Postgres - це якась історія на місяці, а в Greenplum прийдуть через день і подивляться, що ти зробив. Інша річ, що у Greenplum потрібно вирішувати актуальні проблеми. Greenplum експлуатується не так широко, тому знайти проблему досить складно. А насамперед треба вирішувати, звісно, проблеми.
Джерело: habr.com