Яндекстин төмөнкү маалымат базаларына кошкон салымы каралат.
- Clickhouse
- Odyssey
- Убакыттын өтүшү менен калыбына келтирүү (WAL-G)
- PostgreSQL (анын ичинде каталар, Amcheck, Heapcheck)
- Greenplum
Videos:
Салам дүйнө! Менин атым Андрей Бородин. Жана мен Yandex.Cloudта эмне кылам, бул Yandex.Cloud жана Yandex.Cloud кардарларынын кызыкчылыгында ачык реляциялык маалымат базаларын иштеп чыгуу.
Бул баяндамада биз масштабда ачык маалымат базаларынын алдында турган кыйынчылыктар жөнүндө сүйлөшөбүз. Бул эмне үчүн маанилүү? Анткени чиркейлер сыяктуу, анан пилге айланган кичинекей, кичинекей көйгөйлөр. Көптөгөн кластерлер болгондо, алар чоңоюшат.
Бирок бул негизги нерсе эмес. Укмуштуудай нерселер болот. Миллиондо бир учурда боло турган нерселер. Ал эми булут чөйрөсүндө буга даяр болушуңуз керек, анткени масштабда бир нерсе болгондо укмуштуудай нерселердин ыктымалдыгы жогору болуп калат.
Бирок! Ачык маалымат базаларынын артыкчылыгы эмнеде? Чындыгында, сизде ар кандай маселе менен күрөшүүгө теориялык мүмкүнчүлүк бар. Сизде баштапкы код бар, сизде программалоо билими бар. Биз аны бириктиребиз жана ал иштейт.
Ачык программалык камсыздоо боюнча иштөөдө кандай ыкмалар бар?
- Эң жөнөкөй ыкма программалык камсыздоону колдонуу. Эгерде сиз протоколдорду колдонсоңуз, стандарттарды колдонсоңуз, форматтарды колдонсоңуз, ачык программалык камсыздоодо сурамдарды жазсаңыз, анда сиз аны мурунтан эле колдойсуз.
- Сиз анын экосистемасын чоңойтуп жатасыз. Мүчүлүштүктөрдү эрте аныктоо ыктымалдыгын жогорулатасыз. Сиз бул системанын ишенимдүүлүгүн жогорулатасыз. Сиз рынокто иштеп чыгуучулардын жеткиликтүүлүгүн жогорулатуу. Сиз бул программаны өркүндөтүңүз. Эгер сиз жаңы эле стилге ээ болуп, ал жерде бир нерсе менен алектенип жатсаңыз, буга чейин салым кошконсуз.
- Дагы бир түшүнүктүү ыкма ачык программалык камсыздоону демөөрчүлүк кылуу болуп саналат. Мисалы, белгилүү Google Summer of Code программасы, Google дүйнө жүзүндөгү студенттерге белгилүү бир лицензиялык талаптарга жооп берген ачык программалык долбоорлорду иштеп чыгуу үчүн түшүнүктүү акча төлөп берет.
- Бул абдан кызыктуу ыкма, анткени ал программалык камсыздоого көңүлдү коомчулуктан башка жакка жылдырбастан өнүктүрүүгө мүмкүндүк берет. Google, технология гиганты катары, биз бул функцияны каалайбыз деп айтпайт, биз бул мүчүлүштүктөрдү оңдоону каалайбыз жана бул жерде биз казышыбыз керек. Google мындай дейт: "Эмне кылсаң ошону кыл. Кандай иштесең, ошондой иштей бер, ошондо баары жакшы болот."
- Ачык булакка катышуунун кийинки ыкмасы - бул катышуу. Ачык программалык камсыздоодо көйгөй пайда болгондо жана иштеп чыгуучулар бар болгондо, иштеп чыгуучуларыңыз көйгөйлөрдү чече башташат. Алар сиздин инфраструктураңызды эффективдүү, программаларыңызды тезирээк жана ишенимдүү кыла баштайт.
Ачык программалык камсыздоо жаатындагы эң белгилүү Яндекс долбоорлорунун бири ClickHouse болуп саналат. Бул Yandex.Metrica алдында турган кыйынчылыктарга жооп катары жаралган маалымат базасы.
Ал эми маалымат базасы катары, ал экосистеманы түзүү жана аны башка иштеп чыгуучулар менен бирге өнүктүрүү үчүн ачык булакта жасалган (Яндекс ичинде гана эмес). Эми бул көп түрдүү компаниялар катышкан чоң долбоор.
Yandex.Cloud'та биз ClickHouse'ду Yandex Object Storage'дин үстүнө, башкача айтканда, булут сактагычтын үстүнө түздүк.
Эмне үчүн булутта бул маанилүү? Анткени ар кандай маалымат базасы ушул үч бурчтукта, ушул пирамидада, эс тутум түрлөрүнүн ушул иерархиясында иштейт. Сизде тез, бирок кичинекей регистрлер жана арзан чоң, бирок жай SSD, катуу дисктер жана башка блоктук түзүлүштөр бар. Эгер сиз пирамиданын башында натыйжалуу болсоңуз, анда сизде тез маалымат базасы бар. эгерде сиз бул пирамиданын түбүндө натыйжалуу болсоңуз, анда сизде масштабдуу маалымат базасы бар. Бул жагынан алганда, ылдыйдан дагы бир катмарды кошуу маалымат базасынын масштабдуулугун жогорулатуунун логикалык ыкмасы болуп саналат.
Муну кантип жасоого болот эле? Бул отчетто маанилүү жагдай болуп саналат.
- Биз MDS үстүнөн ClickHouse ишке ашыра алабыз. MDS ички Yandex булут сактагыч интерфейси болуп саналат. Бул жалпы S3 протоколуна караганда татаалыраак, бирок блоктук түзүлүшкө ылайыктуу. Маалыматтарды жаздыруу үчүн жакшыраак. Бул көбүрөөк программалоону талап кылат. Программисттер программалайт, бул жакшы, кызыктуу.
- S3 - бул иш жүктөмүнүн айрым түрлөрүнө азыраак ыңгайлашуунун эсебинен интерфейсти жөнөкөйлөткөн кеңири таралган ыкма.
Албетте, ClickHouse экосистемасын бүтүндөй функционалдуулук менен камсыз кылууну жана Yandex.Cloud ичинде керектүү тапшырманы аткарууну каалап, биз ClickHouse коомчулугунун бүтүндөй пайдасын көрүүнү чечтик. Биз ClickHouse үстүнөн MDS эмес, ClickHouse үстүнөн S3 ишке киргиздик. Ал эми бул көп иш.
шилтеме:
"Файл тутумунун абстракция катмары"
"AWS SDK S3 интеграциясы"
"S3 үчүн IDisk интерфейсинин базалык ишке ашырылышы"
"IDisk интерфейси менен журналдарды сактоочу кыймылдаткычтарды интеграциялоо"
"S3 жана SeekableReadBuffer үчүн журнал кыймылдаткычын колдоо"
"Storage Stripe Log S3 колдоо"
"S3 үчүн Storage MergeTree баштапкы колдоосу"
"MergeTree S3 үчүн толук колдоо"
"S3 үстүнөн ReplicatedMergeTreeди колдоо"
"S3 сактагычы үчүн демейки эсептик дайындарды жана жеке аталыштарды кошуңуз"
"С3 динамикалык прокси конфигурациясы менен"
"S3 прокси чечүүчү менен"
Бул ClickHouse ичинде виртуалдык файл тутумун ишке ашыруу үчүн тартуу суроо тизмеси. Бул тартуу суроо-талаптарынын көп саны.
шилтеме:
"DiskS3 катуу шилтемелер оптималдуу ишке ашыруу"
"S3 HTTP кардары - Жооп агымын эс тутумга көчүрүүдөн качыңыз"
"Бардык жооп агымын S3 HTTPдеги эс тутумга көчүрүүдөн качыңыз
кардар"
"S3 диск үчүн белгилөө жана индекстөө файлдарын кэш кылуу мүмкүнчүлүгү"
"Бөлүктөрдү DiskLocalдан DiskS3ке параллелдүү жылдыруу"
Бирок иш муну менен эле бүтпөйт. Функция жасалгандан кийин, бул функцияны оптималдаштыруу үчүн дагы бир нече иш талап кылынды.
шилтеме:
"SelectedRows жана SelectedBytes окуяларын кошуу"
"S3 сурамынан system.eventsке профилдөө окуяларын кошуу"
"QueryTimeMicroseconds, SelectQueryTimeMicroseconds жана InsertQueryTimeMicroseconds кошуу"
Анан аны диагностикалоо, мониторингди орнотуу жана аны башкара турган кылуу керек болчу.
Мунун баары бүт жамаат, бүт ClickHouse экосистемасы бул иштин жыйынтыгын алышы үчүн жасалды.
Келгиле, транзакциялык маалымат базаларына, жеке мага жакыныраак болгон OLTP маалымат базаларына өтөлү.
Бул ачык булак DBMS өнүктүрүү бөлүмү. Бул балдар транзакциялык ачык маалымат базаларын жакшыртуу үчүн көчө сыйкырларын жасап жатышат.
Мисалы, биз кантип жана эмне кылаарыбыз жөнүндө сүйлөшө турган долбоорлордун бири - Postgresтеги Connection Pooler.
Postgres процесстер базасы. Бул маалымат базасында транзакцияларды жүргүзүүчү мүмкүн болушунча аз тармактык байланыштар болушу керек дегенди билдирет.
Башка жагынан алганда, булут чөйрөсүндө, бир эле учурда миң туташуулар бир кластерге келгенде типтүү кырдаал болуп саналат. Ал эми туташуу пулаторунун милдети миң туташууну аз сандагы сервердик туташууларга топтоо.
Биз байланыш пулатору телефон оператору деп айта алабыз, ал байттарды маалымат базасына эффективдүү жетүү үчүн кайра иретке келтирет.
Тилекке каршы, байланыш пулатору үчүн жакшы орус сөзү жок. Кээде мультиплексордук байланыштар деп аталат. Эгер сиз байланыш пулаторун эмне деп атаарыңызды билсеңиз, анда мага айтыңыз, мен туура орус техникалык тилинде сүйлөөгө абдан кубанычта болом.
Биз башкарылган постгрес кластерине ылайыктуу болгон байланыш пулаторлорун изилдедик. Жана PgBouncer биз үчүн эң жакшы тандоо болду. Бирок биз PgBouncer менен бир катар көйгөйлөргө туш болдук. Көп жылдар мурун Володя Бородин биз PgBouncer колдонобуз деп отчет берген, бизге бардыгы жагат, бирок нюанстар бар, иштөө үчүн бир нерсе бар.
А биз иштедик. Биз кабылган көйгөйлөрдү оңдоп, Bouncerди жаңыртып, суроо-талаптарды агымга түртүүгө аракет кылдык. Бирок фундаменталдуу бир жип менен иштөө кыйынга турду.
Биз жамаачыланган Bouncers каскаддарын чогултууга туура келди. Бизде көптөгөн бир жиптүү Bouncers болгондо, үстүнкү катмардагы байланыштар Bouncersтин ички катмарына которулат. Бул начар башкарылган система, аны куруу жана алдыга жана артка кеңейтүү кыйын.
Биз Одиссей деп аталган өзүбүздүн байланыш пулаторубузду түздүк деген жыйынтыкка келдик. Биз аны башынан жаздык.
2019-жылы, PgCon конференциясында мен бул бассейнди иштеп чыгуучулар коомчулугуна сунуштадым. Азыр бизде GitHubда 2ден бир аз азыраак жылдыз бар, б.а. долбоор жандуу, долбоор популярдуу.
Жана эгер сиз Yandex.Cloud'та Postgres кластерин түзсөңүз, анда ал кластерди алдыга же артка масштабдаганда кайра конфигурацияланган орнотулган Odyssey менен кластер болот.
Бул долбоордон эмнени үйрөндүк? Атаандаш долбоорду ишке киргизүү дайыма агрессивдүү кадам болуп саналат, биз жетишерлик тез чечилбей жаткан көйгөйлөр бар, бизге ылайыктуу убакыт аралыгы менен чечилбей жатат деп айтсак, бул экстремалдык чара. Бирок бул эффективдүү чара.
PgBouncer тезирээк өнүгө баштады.
Эми башка долбоорлор пайда болду. Мисалы, Red Hat иштеп чыгуучулары тарабынан иштелип чыккан pgagroal. Алар окшош максаттарды көздөшөт жана окшош идеяларды ишке ашырышат, бирок, албетте, pgagroal иштеп чыгуучуларына жакыныраак болгон өз өзгөчөлүктөрү менен.
Postgres коомчулугу менен иштөөнүн дагы бир учуру - убакыттын өтүшү менен калыбына келтирүү. Бул катадан кийин калыбына келтирүү, бул камдык көчүрмөдөн калыбына келтирүү.
Көптөгөн камдык көчүрмөлөр бар жана алардын бардыгы ар түрдүү. Дээрлик ар бир Postgres сатуучусунун өзүнүн резервдик чечими бар.
Эгер сиз бардык резервдик системаларды алып, өзгөчөлүк матрицасын түзсөңүз жана бул матрицадагы детерминантты тамашалап эсептесеңиз, ал нөлгө барабар болот. Бул эмнени билдирет? Эгер сиз белгилүү бир камдык файлды алсаңыз, анда аны башкалардын бөлүктөрүнөн чогултуу мүмкүн эмес. Ал ишке ашырылышы боюнча өзгөчө, максаты менен өзгөчө, ага камтылган идеялары өзгөчө. Жана алардын бардыгы конкреттүү.
Биз бул маселенин үстүндө иштеп жатканда CitusData WAL-G долбоорун ишке киргизди. Бул булут чөйрөсүнө көз салуу менен жасалган резервдик система. Азыр CitusData буга чейин Microsoftтун бир бөлүгү болуп саналат. Ошондо WAL-Gдин алгачкы чыгарылыштарында айтылган идеялар бизге абдан жакты. Жана биз бул долбоорго салым кошо баштадык.
Азыр бул долбоордо ондогон иштеп чыгуучулар бар, бирок WAL-Gге эң мыкты 10 салым кошкондордун арасында 6 Яндексоид бар. Биз ал жакка көптөгөн идеяларыбызды алып келдик. Анан, албетте, биз аларды өзүбүз ишке ашырдык, өзүбүз сынап көрдүк, өндүрүшкө өзүбүз киргиздик, өзүбүз колдонобуз, WAL-G чоң коомчулугу менен өз ара аракеттенип, андан ары кайда жыларыбызды өзүбүз аныктайбыз.
Ал эми биздин көз карашыбыз боюнча, азыр бул резервдик система, анын ичинде биздин күч-аракетибизди эске алуу менен, булут чөйрөсү үчүн оптималдуу болуп калды. Бул булуттагы Postgres камдык көчүрмөсүн сактоонун эң жакшы баасы.
Бул эмнени билдирет? Биз бир топ чоң идеяны алдыга жылдырганбыз: камдык көчүрмө коопсуз, иштетүү үчүн арзан жана калыбына келтирүү мүмкүн болушунча тез болушу керек.
Эмне үчүн аны иштетүү арзан болушу керек? Эч нерсе бузулбаганда, сизде камдык көчүрмөлөр бар экенин билбешиңиз керек. Баары жакшы иштейт, сиз мүмкүн болушунча аз CPU ысырап кыласыз, диск ресурстарыңызды мүмкүн болушунча аз колдоносуз жана баалуу кызматтарыңыздын пайдалуу жүктөмүнө тоскоол болбоо үчүн тармакка мүмкүн болушунча аз байт жөнөтөсүз.
Ал эми баары бузулганда, мисалы, администратор маалыматтарды таштады, бир нерсе туура эмес болуп калды, жана сиз тез арада өткөнгө кайтууңуз керек, сиз бардык акча менен калыбына келтиресиз, анткени сиз маалыматтарыңызды тез жана бүтүн бойдон кайтарууну каалайсыз.
Жана биз бул жөнөкөй идеяны көтөрдүк. Ал эми, биз аны ишке ашыра алдык окшойт.
Бирок бул баары эмес. Биз дагы бир кичинекей нерсени кааладык. Биз көптөгөн ар кандай маалымат базаларын кааладык. Биздин кардарлардын баары эле Postgres колдонушпайт. Кээ бир адамдар MySQL, MongoDB колдонушат. Коомчулукта башка иштеп чыгуучулар FoundationDBди колдошту. Жана бул тизме тынымсыз кеңейүүдө.
Коомчулукка маалымат базасы булуттагы башкарылган чөйрөдө иштөө идеясы жагат. Жана иштеп чыгуучулар биздин резервдик системабыз менен Postgres менен бирдей камдык көчүрмөсүн сактоого мүмкүн болгон маалымат базаларын сактап турушат.
Бул окуядан эмнеге үйрөндүк? Биздин продукт, өнүктүрүү бөлүмү катары, код саптары эмес, бул билдирүүлөр эмес, файлдар эмес. Биздин продукт тартуу суроо эмес. Мына ушул идеяларды биз коомчулукка жеткиребиз. Бул технологиялык экспертиза жана технологиянын булут чөйрөсүнө карай кыймылы.
Postgres сыяктуу маалымат базасы бар. Мен Postgres өзөгүн эң жакшы көрөм. Мен коомчулук менен Postgres өзөгүн өнүктүрүүгө көп убакыт коротом.
Бирок бул жерде Yandex.Cloud башкарылуучу маалымат базаларынын ички орнотуусу бар деп айтуу керек. Ал эми Yandex.Mail-да көп убакыт мурун башталган. Почта Постгреске өтүүнү каалаган учурда башкарылган Postgresке алып келген тажрыйба топтолгон.
Почта булутка абдан окшош талаптарга ээ. Бул сиздин берилиштериңиздин каалаган жеринде күтүлбөгөн экспоненциалдык өсүшкө чейин масштабдалышыңыз керек. Ал эми почта буга чейин эле көп сандагы колдонуучулардын жүз миллиондогон почта ящиктери менен жүктөм болгон, алар дайыма көптөгөн суроо-талаптарды жасашкан.
Бул Postgres иштеп жаткан команда үчүн олуттуу кыйынчылык болду. Ал кезде кандай көйгөйлөр болсо коомчулукка кабарланчу. Ал эми бул көйгөйлөр оңдолду жана айрым жерлерде коомчулук тарабынан оңдолду, атүгүл кээ бир башка маалымат базалары үчүн акы төлөнүүчү колдоо деңгээлинде жана андан да жакшыраак. Башкача айтканда, PgSQL хакерине кат жөнөтүп, 40 мүнөттүн ичинде жооп ала аласыз. Кээ бир маалымат базаларында акы төлөнүүчү колдоо сиздин мүчүлүштүккө караганда артыкчылыктуу нерселер бар деп ойлошу мүмкүн.
Азыр Postgresтин ички орнотуусу бир нече петабайт маалымат. Бул секундасына миллиондогон суроо-талаптар. Бул миңдеген кластерлер. Бул абдан масштабдуу.
Бирок бир нюанс бар. Ал кооз тармактык дисктерде эмес, жөнөкөй жабдыкта жашайт. Жана кызыктуу жаңы нерселер үчүн атайын тест чөйрөсү бар.
Жана белгилүү бир учурда тест чөйрөсүндө биз маалымат базасынын индекстеринин ички инварианттары бузулганын көрсөткөн билдирүү алдык.
Инвариант - бул биз дайыма кармай турган мамиленин кандайдыр бир түрү.
Биз үчүн өтө оор кырдаал. Бул кээ бир маалыматтар жоголушу мүмкүн экенин көрсөтүп турат. Ал эми маалыматтардын жоголушу - бул абдан катастрофалык нерсе.
Башкарылуучу маалымат базаларында биз карманган жалпы идея - күч-аракет жумшалса да, маалыматтарды жоготуу кыйын болот. Аларды атайылап алып салсаңыз дагы, көп убакыт бою алардын жоктугуна көңүл бурушуңуз керек болот. Маалыматтын коопсуздугу - бул биз кылдаттык менен карманган дин.
Бул жерде биз даяр болбой турган жагдай болушу мүмкүн деген жагдай пайда болот. Жана биз бул кырдаалга даярдана баштадык.
Биринчи кылган ишибиз бул миңдеген кластерлердин дөңгөчтөрүн көмүү болду. Кластерлердин кайсынысы маалымат бетинин жаңыртууларын жоготуп жаткан көйгөйлүү микропрограммасы бар дисктерде жайгашканын таптык. Бардык Postgres маалымат кодун белгиленген. Жана биз ички инварианттардын бузулушун көрсөткөн билдирүүлөрдү маалыматтардын бузулушун аныктоо үчүн иштелип чыккан код менен белгиледик.
Бул жамаачы иш жүзүндө коомчулук тарабынан көп талкуусуз эле кабыл алынган, анткени ар бир конкреттүү учурда кандайдыр бир жаман нерсе болуп, журналга билдирүү керек экени көрүнүп турду.
Андан кийин, биз журналдарды сканерлей турган мониторинг бар деген ойго келдик. Ал эми шектүү билдирүүлөр келип калса, нөөмөтчүнү ойготуп, нөөмөтчү оңдоп-түзөөдө.
Бирок! Журналдарды сканерлөө - бул бир кластерде арзан операция жана миң кластер үчүн катастрофалык кымбат.
деген кеңейтүүнү жаздык . Ал өткөн каталар боюнча статистиканы арзан жана тез тандап ала турган маалымат базасынын көрүнүшүн түзөт. Эгерде биз дежурныйды ойготуубуз керек болсо, анда биз бул тууралуу гигабайттык файлдарды сканерлебестен, бирок хэш таблицасынан бир нече байт алуу менен билебиз.
Бул кеңейтүү, мисалы, репозиторийде кабыл алынган . Эгер сиз аны колдонгуңуз келсе, аны өзүңүз орното аласыз. Албетте, бул ачык булак.
Бирок бул баары эмес. Биз индекстердеги инварианттык бузууларды табуу үчүн коомчулук тарабынан түзүлгөн Amcheck кеңейтүүсүн колдоно баштадык.
Жана биз аны масштабда иштетсеңиз, мүчүлүштүктөр бар экенин билдик. Биз аларды оңдой баштадык. Биздин оңдоолор кабыл алынды.
Бул кеңейтүү GiST жана GIT индекстерин талдай албасын аныктадык. Биз аларга колдоо көрсөттүк. Бирок бул колдоо дагы эле коомчулук тарабынан талкууланууда, анткени бул салыштырмалуу жаңы функция жана ал жерде көптөгөн деталдар бар.
Жана ошондой эле биз репликация лидеринде, мастерде бузуулар боюнча индекстерди текшерүүдө бардыгы жакшы иштеп жатканын, ал эми репликаларда, ээрчүүдө коррупцияны издөө анчалык натыйжалуу эмес экенин аныктадык. Бардык инварианттар текшерилбейт. Жана бир инвариант бизди абдан тынчсыздандырды. Ал эми биз репликаларды текшерүүнү иштетүү үчүн коомчулук менен байланышып, бир жарым жыл өткөрдүк.
Бардык can... протоколдоруна баш ийе турган код жаздык. Биз бул патчты Crunchy Dataдан Питер Гаган менен бир топ убакыт талкууладык. Ал бул патчты кабыл алуу үчүн Postgresтеги B-даракты бир аз өзгөртүүгө туура келди. Ал кабыл алынды. Эми репликалардагы индекстерди текшерүү дагы биз жолуккан мыйзам бузууларды аныктоо үчүн жетиштүү эффективдүү болуп калды. Башкача айтканда, бул диск микропрограммасындагы каталар, Postgresдеги мүчүлүштүктөр, Linux ядросундагы мүчүлүштүктөр жана аппараттык көйгөйлөрдөн улам келип чыгышы мүмкүн болгон бузуулар. Биз даярдап жаткан көйгөйлөрдүн булактарынын кеңири тизмеси.
Бирок индекстерден тышкары, үймөк сыяктуу бөлүк бар, б.а. маалыматтар сакталган жер. Жана текшерүүгө боло турган инварианттар көп эмес.
Бизде Heapcheck деген кеңейтүү бар. Биз аны иштеп чыгууну баштадык. Жана параллелдүү, биз менен бирге EnterpriseDB компаниясы да модулду жаза башташты, аны Heapcheck деп аташкан. Биз гана аны PgHeapcheck деп атадык, алар жөн гана Heapcheck деп аташкан. Аларда окшош функциялар, бир аз башкача кол тамга бар, бирок ошол эле идеялар менен. Аларды айрым жерлерде бир аз жакшыраак ишке ашырышты. Жана алар буга чейин ачык булакка жайгаштырышкан.
Эми биз алардын экспансиясын өнүктүрөбүз, анткени бул алардын экспансиясы эмес, коомчулуктун кеңейиши. Ал эми келечекте, бул ар бир адам келечектеги көйгөйлөр жөнүндө алдын ала билиши үчүн бериле турган ядронун бир бөлүгү.
Кээ бир жерлерде биздин мониторинг системаларыбызда жалган позитивдер бар деген жыйынтыкка да келдик. Мисалы, 1С системасы. Маалыматтар базасын колдонууда Postgres кээде ага окуй турган маалыматтарды жазат, бирок pg_dump окуй албайт.
Бул жагдай биздин көйгөйдү аныктоо системабызда коррупция сыяктуу көрүндү. Дежурныйды ойготуп жиберишти. Дежурный эмне болуп жатканын карады. Бир аз убакыт өткөндөн кийин бир кардар келип, менде көйгөйлөр бар экенин айтты. Кызматчы көйгөй эмнеде экенин айтып берди. Бирок көйгөй Postgres өзөгүндө.
Мен бул өзгөчөлүк жөнүндө талкууну таптым. Жана ал биз бул өзгөчөлүккө туш болдук жана бул жагымсыз экенин жазган, адам бул эмне экенин түшүнүү үчүн түн ичинде ойгонгон.
Коомчулук: "Ой, биз муну чындап оңдошубуз керек" деп жооп беришти.
Менде жөнөкөй окшоштук бар. Эгерде сизде кум дан бар бут кийим менен бара жатсаңыз, анда, негизинен, сиз уланта аласыз - көйгөй жок. Миңдеген кишиге өтүк сатсаң, анда өтүктү такыр кумсуз жасайлы. Эгер бут кийимиңизди колдонуучулардын бири марафонго катыша турган болсо, анда сиз абдан жакшы бут кийимдерди жасап, анан аларды бардык колдонуучуларыңызга жайылтууну каалайсыз. Ал эми мындай күтүлбөгөн колдонуучулар булут чөйрөсүндө дайыма болот. Кластерди кандайдыр бир оригиналдуу түрдө колдонгон колдонуучулар ар дайым бар. Бул үчүн дайыма даярдануу керек.
Биз бул жерден эмнени үйрөндүк? Биз жөнөкөй нерсени үйрөндүк: эң негизгиси коомчулукка көйгөй бар экенин түшүндүрүү. Эгерде коомчулук көйгөйдү тааныса, анда маселени чечүү үчүн табигый атаандаштык пайда болот. Анткени ар бир адам маанилүү маселени чечүүнү каалайт. Бардык сатуучулар, бардык хакерлер өздөрү бул тырмоого басышы мүмкүн экенин түшүнүшөт, ошондуктан аларды жок кылууну каалашат.
Эгерде сиз көйгөйдүн үстүндө иштеп жатсаңыз, бирок ал сизден башка эч кимди тынчсыздандырбаса, бирок сиз анын үстүндө системалуу иштеп жатасыз жана ал акыры көйгөй деп эсептелсе, анда сиздин тартуу өтүнүчүңүз сөзсүз кабыл алынат. Сиздин патчыңыз кабыл алынат, жакшыртууларыңыз, жада калса жакшыртуу боюнча өтүнүчтөрүңүз коомчулук тарабынан каралат. Акыр-аягы, биз бири-бирибизге маалымат базасын жакшыртабыз.
Кызыктуу маалымат базасы Greenplum болуп саналат. Бул Postgres код базасына негизделген абдан параллелдүү маалымат базасы, мен аны менен жакшы таанышмын.
Жана Greenplum кызыктуу функцияга ээ - оптималдаштырылган таблицаларды кошуңуз. Бул таблицалар, аларды тез эле кошо аласыз. Алар тилкелүү же сап болушу мүмкүн.
Бирок кластерлөө болгон эмес, башкача айтканда, таблицада жайгашкан маалыматтарды индекстердин биринде жайгашкан тартипке ылайык жайгаштыра турган функция болгон эмес.
Таксидеги балдар мага келип: «Андрей, сен Постгрести билесиң. Ал эми бул жерде дээрлик бирдей. 20 мүнөткө которулуңуз. Сен аны алып, кыл». Мен ооба, мен Postgres билем деп ойлодум, 20 мүнөткө которулуп - мен муну кылышым керек.
Бирок жок, 20 мүнөт болгон жок, мен аны айлап жаздым. PgConf.Russia конференциясында мен Пивоталдан Хейки Линакангаска кайрылып: «Мында кандайдыр бир көйгөйлөр барбы? Эмне үчүн тиркемелерди оптималдаштырылган таблица кластерлери жок?» Ал мындай дейт: «Сиз маалыматтарды алып жатасыз. Сиз иреттейсиз, кайра иреттейсиз. Бул жөн гана жумуш». Мен: "Ооба, сен аны алып, жасаш керек." Ал: «Ооба, бул үчүн колубуз бош керек»,— дейт. Мен муну сөзсүз кылышым керек деп ойлодум.
Бир нече айдан кийин мен бул функцияны ишке ашырган тартуу өтүнүчүн тапшырдым. Бул тартуу өтүнүчүн Pivotal коомчулук менен бирге карап чыкты. Албетте, мүчүлүштүктөр болгон.
Бирок эң кызыгы, бул тартуу өтүнүчү бириктирилгенде, каталар Greenplumдин өзүндө табылган. Биз үймөк таблицалары кластерленгенде транзакцияны бузуп жатканын байкадык. Ал эми бул оңдоп-түзөө керек болгон нерсе. Ал мен жаңы эле тийген жерде. Жана менин табигый реакциям - макул, мен да муну кыла бер.
Мен бул катаны оңдоп койдум. Оңдоочуларга тартуу өтүнүчүн жөнөттү. Ал өлтүрүлгөн.
Андан кийин бул функцияны PostgreSQL 12 үчүн Greenplum версиясында алуу керек экени белгилүү болду. Башкача айтканда, 20 мүнөттүк укмуштуу окуялар жаңы кызыктуу окуялар менен уланат. Коомчулуктун жаңы жана эң маанилүү өзгөчөлүктөрүн кесип жаткан учурдагы өнүгүүгө тийүү кызыктуу болду. Ал тоңуп калды.
Бирок муну менен эле бүтпөйт. Баарынан кийин мунун баарына документ жазуу керек экен.
Документтерди жаза баштадым. Бактыга жараша, Пивоталдан документалисттер келишти. Англис тили алардын эне тили болуп саналат. Алар мага документ жагынан жардам беришти. Чынында, алар өздөрү мен сунуштаган нерсени чыныгы англисче кылып кайра жазышты.
Мына, укмуштуу окуя бүттү окшойт. Анан эмне болгонун билесиңби? Таксидеги балдар мага келип: "Алдыда дагы эки укмуштуу окуя бар, ар бири 10 мүнөттөн" дешти. Анан аларга эмне дешим керек? Мен азыр масштаб боюнча отчет берем, анан сиздин жоруктарыңызды көрөбүз дедим, анткени бул кызыктуу жумуш.
Бул окуядан эмнеге үйрөндүк? Ачык булак менен иштөө ар дайым белгилүү бир адам менен иштөө болгондуктан, ал дайыма коомчулук менен иштешет. Анткени ар бир этапта мен иштеп чыгуучу, тестиер, хакер, документалист, архитектор менен иштештим. Мен Greenplum менен иштеген жокмун, Greenplum айланасындагы адамдар менен иштештим.
Бирок! Дагы бир маанилүү жагдай бар - бул жөн гана иш. Башкача айтканда, келиңиз, кофе ичиңиз, код жазыңыз. Ар кандай жөнөкөй инварианттар иштейт. Кадимкидей кылыңыз - баары жакшы болот! Жана бул абдан кызыктуу жумуш. Бул ишке Yandex.Cloud кардарларынан, Яндекстин ичиндеги жана сыртындагы биздин кластерлердин колдонуучуларынан суроо-талап бар. Ал эми биз катышкан долбоорлордун саны көбөйүп, катышуубуздун тереңдиги да көбөйөт деп ойлойм.
Баары болду. Келгиле, суроолорго өтөлү.
Суроолор сессиясы
Салам! Бизде дагы бир суроо-жооп бар. Ал эми студияда Андрей Бородин. Бул жаңы эле Яндекс.Cloud жана Яндекстин ачык булакка кошкон салымы жөнүндө айткан адам. Биздин отчет азыр толугу менен Булут жөнүндө эмес, бирок ошол эле учурда биз ушундай технологияларга негизделген. Яндекстин ичинде эмне кылбасаңыз, Yandex.Cloud'та эч кандай кызмат болмок эмес, андыктан жеке менден рахмат. Эфирдин биринчи суроосу: "Сиз айткан долбоорлордун ар бири эмне жөнүндө жазылган?"
WAL-Gдеги резервдик система Go тилинде жазылган. Бул биз иштеп жаткан жаңы долбоорлордун бири. Ал түз эле 3 жашта. Ал эми маалымат базасы көбүнчө ишенимдүүлүк жөнүндө. Бул маалымат базалары бир топ эски жана алар адатта C тилинде жазылган дегенди билдирет. Postgres долбоору болжол менен 30 жыл мурун башталган. Ошондо C89 туура тандоо болгон. Ошондо Postgres анда жазылган. ClickHouse сыяктуу заманбап маалымат базалары адатта C++ тилинде жазылат. Бардык системаларды иштеп чыгуу C жана C++ айланасында негизделген.
Булуттагы чыгымдар үчүн жооптуу каржы менеджерибиздин суроосу: "Эмне үчүн Cloud ачык булакты колдоого акча коротот?"
Бул жерде каржы менеджери үчүн жөнөкөй жооп бар. Биз муну кызматтарыбызды жакшыртуу үчүн жасайбыз. Кандай жолдор менен биз жакшыраак кыла алабыз? Биз иштерди натыйжалуураак, ылдамыраак кылып, масштабдуураак кыла алабыз. Бирок биз үчүн бул окуя биринчи кезекте ишенимдүүлүк жөнүндө. Мисалы, резервдик системада биз ага тиешелүү тактардын 100% карап чыгабыз. Биз код эмне экенин билебиз. Жана биз өндүрүшкө жаңы версияларды жайылтууга ыңгайлуураак. Бул, биринчи кезекте, бул ишеним жөнүндө, өнүгүүгө даярдыгы жана ишенимдүүлүгү жөнүндө
Дагы бир суроо: "Яндекс.Cloud'та жашаган тышкы колдонуучулардын талаптары ички булутта жашаган ички колдонуучулардан айырмаланабы?"
Жүктөө профили, албетте, ар кандай. Бирок менин бөлүмүмдүн көз карашы боюнча, бардык өзгөчө жана кызыктуу учурлар стандарттуу эмес жүктөмдө түзүлгөн. Фантазиясы бар иштеп чыгуучулар, күтүлбөгөн нерсени жасаган иштеп чыгуучулар ички жана тышкы жактан табылышы мүмкүн. Бул жагынан алганда биз бардыгыбыз болжол менен бирдейбиз. Жана, балким, Яндекс маалымат базаларынын ишинин ичиндеги бирден-бир маанилүү өзгөчөлүк, Яндекстин ичинде бизде окутуу бар. Кайсы бир учурда, кээ бир жеткиликтүүлүк зонасы толугу менен көлөкө болуп калат жана бардык Яндекс кызматтары буга карабастан кандайдыр бир жол менен иштей бериши керек. Бул кичинекей айырма. Бирок ал маалымат базасынын жана тармактык стектин интерфейсинде көптөгөн изилдөөлөрдү жаратат. Болбосо, тышкы жана ички орнотуулар өзгөчөлүктөргө бирдей суроо-талаптарды жана ишенимдүүлүктү жана аткарууну жакшыртуу үчүн окшош суроо-талаптарды жаратат.
Кийинки суроо: "Сиз кылган ишиңиздин көбүн башка Булуттар колдонуп жатканына жекече кандай карайсыз?" Биз конкреттүүлөрүн атабайбыз, бирок Yandex.Cloud'та жасалган көптөгөн долбоорлор башка адамдардын булуттарында колдонулат.
Бул сонун. Биринчиден, бул биз бир нерсени туура кылганыбыздын белгиси. Жана бул напсини тырмап салат. Жана биз туура чечим кабыл алганыбызга көбүрөөк ишенебиз. Экинчи жагынан, бул келечекте бизге жаңы идеяларды, үчүнчү тараптын колдонуучуларынын жаңы суроо-талаптарын алып келет деген үмүт. GitHub'дагы маселелердин көбүн айрым системалык администраторлор, жеке DBAлар, жеке архитекторлор, жеке инженерлер түзүшөт, бирок кээде системалуу тажрыйбасы бар адамдар келип, белгилүү бир учурларда 30% бизде бул көйгөй бар экенин айтышат жана аны кантип чечүү жөнүндө ойлонуп көрөлү. Бул биз эң көп күткөн нерсе. Биз башка булут платформалары менен тажрыйба алмашууну чыдамсыздык менен күтөбүз.
Сиз марафон тууралуу көп айттыңыз. Москвада марафонго катышканыңызды билем. Натыйжада? PostgreSQLдин балдарын басып өттүбү?
Жок, Олег Бартунов абдан ылдам чуркайт. Ал менден бир саат мурун бүттү. Жалпысынан алганда, мен канчалык жеткениме ыраазымын. Мен үчүн жөн гана бүтүрүү жетишкендик болчу. Жалпысынан, постгрес коомчулугунда мынчалык көп жөө күлүк бар экендиги таң калыштуу. Менимче, аэробдук спорт менен системалык программалоону каалоонун ортосунда кандайдыр бир байланыш бар окшойт.
ClickHouseда жөө күлүктөр жок деп жатасызбы?
Мен алардын бар экенин так билем. ClickHouse да маалымат базасы болуп саналат. Баса, азыр Олег мага жазып жатат: «Репортаждан кийин чуркайлыбы?». Бул сонун идея.
Никита уктуруусунун дагы бир суроосу: "Эмне үчүн Гринплумдагы мүчүлүштүктөрдү өзүңүз оңдоп, аны кенжелерге бербей койдуңуз?" Ырас, мүчүлүштүк эмне жана кайсы кызматта экени так эмес, бирок бул сиз айткан нерсени билдирет.
Ооба, негизи бирөөгө берсе болмок. Мен жөн эле өзгөрткөн код эле. Жана аны дароо улантуу табигый эле. Негизи, команда менен тажрыйба алмашуу идеясы жакшы идея. Биз Greenplum милдеттерин биздин бөлүмдүн бардык мүчөлөрү менен бөлүшөбүз.
Жаштар жөнүндө сөз болуп жаткандыктан, бул жерде бир суроо. адам Postgres биринчи commit түзүүнү чечти. Биринчи милдеттенмени аткаруу үчүн ал эмне кылышы керек?
Бул кызыктуу суроо: "Эмнеден баштоо керек?" Адатта, ядродогу бир нерсе менен баштоо абдан кыйын. Мисалы, Postgresте аткарыла турган иштердин тизмеси бар. Бирок, чындыгында, бул алардын аракет кылып, бирок ишке ашпай калган барактары. Бул татаал нерселер. Жана, адатта, сиз экосистемадан кээ бир утилиталарды, кээ бир кеңейтүүлөрдү таба аласыз, алар ядрону иштеп чыгуучулардын көңүлүн азыраак тартат. Жана, ошого жараша, ал жерде өсүү үчүн дагы көп пункттар бар. Google Summer of Code программасында жыл сайын postgres коомчулугу чечиле турган көптөгөн ар кандай темаларды сунуштайт. Быйыл үч студент болдук деп ойлойм. Ал тургай, бирөө Яндекс үчүн маанилүү темалар боюнча WAL-G жазган. Greenplumда бардыгы Postgres коомчулугуна караганда жөнөкөй, анткени Greenplum хакерлери тартуу өтүнүчтөрүн абдан жакшы карашат жана дароо карап башташат. Postgres'ке жамаачы жөнөтүү бир нече ай талап кылынат, бирок Greenplum бир күндө келип, эмне кылганыңызды көрөт. Дагы бир нерсе, Greenplum учурдагы көйгөйлөрдү чечиши керек. Greenplum кеңири колдонулбайт, андыктан көйгөйүңүздү табуу абдан кыйын. Анан биринчи кезекте көйгөйлөрдү чечүү керек, албетте.
Source: www.habr.com