Будзе разгледжаны ўклад Яндэкса ў наступныя базы даных.
- ClickHouse
- Адысея
- Аднаўленне на кропку ў часе (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 in memory in 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 000 зорачак на 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