Bus peržiūrėtas „Yandex“ indėlis į šias duomenų bazes.
- „ClickHouse“
- Odyssey
- Atkūrimas iki tam tikro momento (WAL-G)
- PostgreSQL (įskaitant logerrors, Amcheck, heapcheck)
- Žalioji slyva
Vaizdo įrašas:
Labas pasauli! Mano vardas Andrejus Borodinas. Ir tai, ką aš darau Yandex.Cloud, yra atvirų reliacinių duomenų bazių kūrimas Yandex.Cloud ir Yandex.Cloud klientų labui.
Šioje kalboje kalbėsime apie iššūkius, su kuriais susiduria atviros duomenų bazės. Kodėl tai svarbu? Nes mažos, mažos problemos, kurios, kaip uodai, vėliau tampa drambliais. Jie tampa dideli, kai turite daug grupių.
Bet tai nėra pagrindinis dalykas. Nutinka neįtikėtinų dalykų. Dalykai, kurie nutinka vienu iš milijono atvejų. O debesų aplinkoje turite būti tam pasiruošę, nes neįtikėtini dalykai tampa labai tikėtini, kai kažkas egzistuoja dideliu mastu.
Bet! Koks yra atvirų duomenų bazių pranašumas? Faktas yra tas, kad jūs turite teorinę galimybę susidoroti su bet kokia problema. Turite šaltinio kodą, turite programavimo žinių. Sujungiame ir veikia.
Kokie metodai yra dirbant su atvirojo kodo programine įranga?
- Paprasčiausias būdas yra naudoti programinę įrangą. Jei naudojate protokolus, jei naudojate standartus, jei naudojate formatus, jei rašote užklausas atvirojo kodo programinėje įrangoje, tai jau palaikote.
- Jūs didinate jos ekosistemą. Jūs padidinate tikimybę anksti aptikti klaidą. Jūs padidinate šios sistemos patikimumą. Jūs padidinate kūrėjų prieinamumą rinkoje. Jūs tobulinate šią programinę įrangą. Jūs jau esate bendradarbis, jei ką tik įgavote stilių ir ką nors patobulinote.
- Kitas suprantamas metodas yra atvirojo kodo programinės įrangos rėmimas. Pavyzdžiui, gerai žinoma Google Summer of Code programa, kai Google moka daugybei studentų iš viso pasaulio suprantamus pinigus, kad jie kurtų atviros programinės įrangos projektus, atitinkančius tam tikrus licencijavimo reikalavimus.
- Tai labai įdomus metodas, nes jis leidžia programinei įrangai tobulėti nenukreipiant dėmesio nuo bendruomenės. „Google“, kaip technologijų milžinė, nesako, kad norime šios funkcijos, norime ištaisyti šią klaidą ir čia reikia kasti. „Google“ sako: „Daryk tai, ką darai. Tiesiog dirbkite taip, kaip dirbote, ir viskas bus gerai.
- Kitas būdas dalyvauti atvirajame kode yra dalyvavimas. Kai kyla problemų dėl atvirojo kodo programinės įrangos ir yra kūrėjų, jūsų kūrėjai pradeda jas spręsti. Jie pradeda daryti jūsų infrastruktūrą efektyvesnę, jūsų programas greitesnes ir patikimesnes.
Vienas garsiausių „Yandex“ projektų atvirojo kodo programinės įrangos srityje yra „ClickHouse“. Tai duomenų bazė, sukurta kaip atsakas į iššūkius, su kuriais susiduria Yandex.Metrica.
Ir kaip duomenų bazė, ji buvo sukurta atvirojo kodo, siekiant sukurti ekosistemą ir plėtoti ją kartu su kitais kūrėjais (ne tik „Yandex“). O dabar tai didelis projektas, kuriame dalyvauja daug įvairių įmonių.
„Yandex.Cloud“ sukūrėme „ClickHouse“ ant „Yandex Object Storage“, t. y. ant debesies saugyklos.
Kodėl tai svarbu debesyje? Nes bet kuri duomenų bazė veikia šiame trikampyje, šioje piramidėje, šioje atminties tipų hierarchijoje. Turite greitus, bet mažus registrus ir pigius didelius, bet lėtus SSD, kietuosius diskus ir kai kuriuos kitus blokuojančius įrenginius. Ir jei esate efektyvus piramidės viršuje, tuomet turite greitą duomenų bazę. Jei esate efektyvus šios piramidės apačioje, tuomet turite padidintą duomenų bazę. Šiuo atžvilgiu dar vieno sluoksnio pridėjimas iš apačios yra logiškas būdas padidinti duomenų bazės mastelį.
Kaip tai būtų galima padaryti? Tai svarbus šio pranešimo punktas.
- Galėtume įdiegti ClickHouse per MDS. MDS yra vidinė „Yandex“ debesies saugyklos sąsaja. Jis yra sudėtingesnis nei įprastas S3 protokolas, tačiau labiau tinka blokiniam įrenginiui. Tai geriau įrašyti duomenis. Tam reikia daugiau programavimo. Programuotojai užprogramuos, tai net gerai, įdomu.
- S3 yra labiau paplitęs metodas, dėl kurio sąsaja tampa paprastesnė, nes mažiau prisitaiko prie tam tikrų darbo krūvių.
Natūralu, kad norėdami suteikti funkcionalumą visai ClickHouse ekosistemai ir atlikti užduotį, kurios reikia Yandex.Cloud viduje, nusprendėme pasirūpinti, kad visa ClickHouse bendruomenė iš to gautų naudos. Įdiegėme ClickHouse per S3, o ne ClickHouse per MDS. Ir tai yra daug darbo.
Nuorodos:
„Failų sistemos abstrakcijos sluoksnis“
„AWS SDK S3 integravimas“
„Pagrindinis IDisk sąsajos diegimas, skirtas S3“
"Žurnalų saugojimo variklių integravimas su IDisk sąsaja"
„S3 ir SeekableReadBuffer žurnalo variklio palaikymas“
„Storage Stripe Log S3 palaikymas“
„Storage MergeTree pradinis palaikymas S3“
"MergeTree visiškas S3 palaikymas"
„Support ReplicatedMergeTree over S3“
„Pridėti numatytuosius kredencialus ir pasirinktines s3 saugyklos antraštes“
"S3 su dinamine tarpinio serverio konfigūracija"
"S3 su tarpiniu serveriu"
Tai yra ištraukimo užklausų sąrašas, skirtas įdiegti virtualią failų sistemą ClickHouse. Tai yra daug ištraukimo užklausų.
Nuorodos:
„DiskS3 kietųjų nuorodų optimalus įgyvendinimas“
„S3 HTTP klientas – venkite kopijuoti atsakymų srautą į atmintį“
„Stenkitės nekopijuoti viso atsakymo srauto į atmintį S3 HTTP
klientas"
„Galimybė žymėti ir indeksuoti S3 disko failus talpykloje“
"Perkelkite dalis iš DiskLocal į DiskS3 lygiagrečiai"
Tačiau darbai tuo nesibaigė. Sukūrus funkciją, reikėjo dar šiek tiek padirbėti, norint optimizuoti šią funkciją.
Nuorodos:
„Pridėti SelectedRows ir SelectedBytes įvykių“
„Pridėti profiliavimo įvykius iš S3 užklausos į system.events“
"Pridėti QueryTimeMicroseconds, SelectQueryTimeMicroseconds ir InsertQueryTimeMicroseconds"
Ir tada reikėjo padaryti jį diagnozuojamą, nustatyti stebėjimą ir valdyti.
Ir visa tai buvo padaryta tam, kad visa bendruomenė, visa ClickHouse ekosistema gautų šio darbo rezultatą.
Pereikime prie transakcinių duomenų bazių, prie OLTP duomenų bazių, kurios man asmeniškai artimesnės.
Tai atvirojo kodo DBVS kūrimo skyrius. Šie vaikinai daro gatvės magiją tobulindami sandorių atvirojo kodo duomenų bazes.
Vienas iš projektų, kurio pavyzdžiu galime kalbėti apie tai, kaip ir ką darome, yra „Connection Pooler“ Postgres mieste.
Postgres yra procesų duomenų bazė. Tai reiškia, kad duomenų bazėje turėtų būti kuo mažiau tinklo jungčių, kurios apdoroja operacijas.
Kita vertus, debesų aplinkoje įprasta situacija, kai į vieną klasterį vienu metu ateina tūkstantis jungčių. O jungčių kaupiklio užduotis yra supakuoti tūkstantį jungčių į nedidelį skaičių serverio jungčių.
Galima sakyti, kad ryšio kaupiklis yra telefono operatorius, kuris pertvarko baitus taip, kad jie efektyviai pasiektų duomenų bazę.
Deja, nėra gero rusiško žodžio, reiškiančio „connection pooler“. Kartais tai vadinama multiplekserio jungtimis. Jei žinote, kaip vadinti ryšio telkinį, būtinai pasakykite man, aš labai mielai kalbėsiu taisyklinga rusų technine kalba.
Ištyrėme ryšio telkinius, kurie buvo tinkami valdomam postgres klasteriui. Ir PgBouncer mums buvo geriausias pasirinkimas. Tačiau susidūrėme su daugybe problemų su PgBouncer. Prieš daugelį metų Volodya Borodin pranešė, kad naudojame PgBouncer, mums viskas patinka, bet yra niuansų, yra ką dirbti.
Ir dirbome. Ištaisėme iškilusias problemas, pataisėme „Bouncer“ ir bandėme nukreipti ištraukimo užklausas prieš srovę. Tačiau su pagrindine vienos sriegies dirbti buvo sunku.
Turėjome rinkti kaskadas iš pataisytų Bouncers. Kai turime daug vienos gijos atšokėjų, viršutiniame sluoksnyje esančios jungtys perkeliamos į vidinį Bouncer sluoksnį. Tai prastai valdoma sistema, kurią sunku sukurti ir išplėsti pirmyn ir atgal.
Priėjome išvados, kad sukūrėme savo ryšio telkinį, kuris vadinasi Odisėja. Rašėme nuo nulio.
2019 m. PgCon konferencijoje pristačiau šį telkinį kūrėjų bendruomenei. Dabar „GitHub“ turime šiek tiek mažiau nei 2 žvaigždžių, t. y. projektas gyvas, projektas populiarus.
Ir jei sukursite „Postgres“ klasterį „Yandex.Cloud“, tai bus klasteris su įmontuotu „Odyssey“, kuris perkonfigūruojamas keičiant klasterio mastelį pirmyn arba atgal.
Ko išmokome iš šio projekto? Pradėti konkuruojantį projektą visada yra agresyvus žingsnis, tai kraštutinė priemonė, kai sakome, kad yra problemų, kurios nėra sprendžiamos pakankamai greitai, nesprendžiamos tokiais laiko intervalais, kurie mums tiktų. Bet tai veiksminga priemonė.
PgBouncer pradėjo vystytis greičiau.
O dabar atsirado kitų projektų. Pavyzdžiui, pgagroal, kurį sukūrė Red Hat kūrėjai. Jie siekia panašių tikslų ir įgyvendina panašias idėjas, bet, žinoma, su savo specifika, kuri artimesnė pgagroal kūrėjams.
Kitas darbo su postgres bendruomene atvejis yra atkūrimas tam tikru momentu. Tai atkūrimas po gedimo, tai atkūrimas iš atsarginės kopijos.
Yra daug atsarginių kopijų ir jos visos yra skirtingos. Beveik kiekvienas „Postgres“ pardavėjas turi savo atsarginį sprendimą.
Jei imsite visas atsargines sistemas, sukursite savybių matricą ir juokais apskaičiuosite determinantą šioje matricoje, jis bus lygus nuliui. Ką tai reiškia? Ką daryti, jei paimsite tam tikrą atsarginės kopijos failą, tada jo negalima surinkti iš visų kitų dalių. Jis unikalus savo įgyvendinimu, unikalus savo paskirtimi, unikalus idėjomis, kurios jame yra įdėtos. Ir jie visi yra specifiniai.
Kol mes dirbome su šia problema, „CitusData“ pradėjo WAL-G projektą. Tai atsarginė sistema, sukurta atsižvelgiant į debesų aplinką. Dabar „CitusData“ jau yra „Microsoft“ dalis. Ir tuo metu mums labai patiko idėjos, išdėstytos pradiniuose WAL-G leidimuose. Ir mes pradėjome prisidėti prie šio projekto.
Dabar šiame projekte yra daug dešimčių kūrėjų, tačiau tarp 10 geriausių WAL-G prisidedančių yra 6 „Yandexoid“. Ten atsinešėme daug savo idėjų. Ir, žinoma, patys juos įdiegėme, patys išbandėme, patys išleidome į gamybą, patys naudojame, patys sugalvojame, kur toliau judėti, bendraudami su didele WAL-G bendruomene.
Ir mūsų požiūriu, dabar ši atsarginė sistema, įskaitant mūsų pastangas, tapo optimali debesų aplinkai. Tai yra geriausia „Postgres“ atsarginės kopijos kūrimo debesyje kaina.
Ką tai reiškia? Mes reklamavome gana didelę idėją: atsarginė kopija turi būti saugi, pigi ir kuo greičiau atkuriama.
Kodėl eksploatacija turėtų būti pigi? Kai niekas nesugenda, neturėtumėte žinoti, kad turite atsarginių kopijų. Viskas veikia puikiai, eikvojate kuo mažiau procesoriaus, naudojate kuo mažiau savo disko resursų ir siunčiate į tinklą kuo mažiau baitų, kad netrukdytumėte savo vertingų paslaugų apkrovai.
O kai viskas sugenda, pvz adminas numetė duomenis, kažkas ne taip, ir skubiai reikia grįžti į praeitį, atsigaunate su visais pinigais, nes norite greitai ir nepažeisti duomenis.
Ir mes propagavome šią paprastą idėją. Ir, mums atrodo, mums pavyko tai įgyvendinti.
Bet tai dar ne viskas. Norėjome dar vieno mažo dalyko. Norėjome daug skirtingų duomenų bazių. Ne visi mūsų klientai naudojasi „Postgres“. Kai kurie žmonės naudoja MySQL, MongoDB. Bendruomenėje kiti kūrėjai palaikė FoundationDB. Ir šis sąrašas nuolat plečiasi.
Bendruomenei patinka idėja, kad duomenų bazė būtų paleista valdomoje debesies aplinkoje. Kūrėjai prižiūri savo duomenų bazes, kurių atsargines kopijas galima sukurti vienodai kartu su „Postgres“ su mūsų atsargine sistema.
Ko išmokome iš šios istorijos? Mūsų produktas, kaip kūrimo padalinys, nėra kodo eilutės, ne teiginiai, ne failai. Mūsų produktas nėra traukiamas prašymas. Tai yra idėjos, kurias perteikiame bendruomenei. Tai yra technologinė patirtis ir technologijų judėjimas debesų aplinkos link.
Yra tokia duomenų bazė kaip Postgres. Man labiausiai patinka Postgres branduolys. Daug laiko praleidžiu kurdamas Postgres branduolį su bendruomene.
Tačiau čia reikia pasakyti, kad „Yandex.Cloud“ turi vidinį valdomų duomenų bazių diegimą. Ir tai prasidėjo seniai Yandex.Mail. Patirtis, kuri dabar padėjo valdyti Postgres, buvo sukaupta, kai paštas norėjo persikelti į Postgres.
Paštui keliami labai panašūs reikalavimai kaip debesiui. Tam reikia, kad galėtumėte pasiekti netikėtą eksponentinį augimą bet kuriuo duomenų tašku. O paštas jau buvo apkrautas šimtais milijonų daugybės vartotojų, nuolat teikiančių daug užklausų, pašto dėžučių.
Ir tai buvo gana rimtas iššūkis „Postgres“ kuriančiai komandai. Tada apie visas problemas, su kuriomis susidūrėme, buvo pranešta bendruomenei. Ir šios problemos buvo ištaisytos, o bendruomenės kai kuriose vietose ištaisytos net mokamos paramos kai kurioms kitoms duomenų bazėms lygiu ir dar geriau. Tai yra, galite išsiųsti laišką PgSQL įsilaužėliui ir gauti atsakymą per 40 minučių. Mokama pagalba kai kuriose duomenų bazėse gali manyti, kad yra svarbesni dalykai nei jūsų klaida.
Dabar vidinis „Postgres“ diegimas yra keletas petabaitų duomenų. Tai keli milijonai užklausų per sekundę. Tai yra tūkstančiai grupių. Tai labai didelio masto.
Bet yra niuansas. Jis gyvena ne išgalvotuose tinklo diskuose, o gana paprastoje aparatinėje įrangoje. Taip pat yra testavimo aplinka, skirta įdomiems naujiems dalykams.
Ir tam tikru momentu testinėje aplinkoje gavome pranešimą, nurodantį, kad buvo pažeisti vidiniai duomenų bazės indeksų invariantai.
Invariantas yra tam tikri santykiai, kurių tikimės visada išlaikyti.
Mums labai kritiška situacija. Tai rodo, kad kai kurie duomenys gali būti prarasti. Ir duomenų praradimas yra kažkas tiesiog katastrofiško.
Bendra idėja, kuria vadovaujamės valdomose duomenų bazėse, yra ta, kad net ir įdėjus pastangų, bus sunku prarasti duomenis. Net jei juos sąmoningai pašalinsite, vis tiek turėsite nekreipti dėmesio į jų nebuvimą ilgą laiką. Duomenų saugumas yra religija, kurios gana stropiai laikomės.
Ir čia susidaro situacija, kuri leidžia manyti, kad gali būti situacija, kuriai mes galime nepasiruošti. Ir mes pradėjome ruoštis šiai situacijai.
Pirmas dalykas, kurį padarėme, buvo palaidoti rąstus iš šių tūkstančių grupių. Mes nustatėme, kurios iš grupių buvo diskuose su problemine programine įranga, kuri praranda duomenų puslapio naujinimus. Pažymėjo visą Postgres duomenų kodą. O tuos pranešimus, kurie rodo vidinių invariantų pažeidimus, pažymėjome kodu, skirtu duomenų sugadinimui aptikti.
Šį pataisą bendruomenė praktiškai priėmė be didelių diskusijų, nes kiekvienu konkrečiu atveju buvo akivaizdu, kad atsitiko kažkas negero ir apie tai reikia pranešti žurnalui.
Po to priėjome prie taško, kad turime stebėjimą, kuris nuskaito žurnalus. O esant įtartinoms žinutėms budinčią budinčiąją, o budėtojas suremontuoja.
Bet! Žurnalų nuskaitymas yra pigi operacija viename klasteryje ir katastrofiškai brangi tūkstančiui grupių.
Parašėme pratęsimą pavadinimu . Tai sukuria duomenų bazės vaizdą, kuriame galite pigiai ir greitai pasirinkti praeities klaidų statistiką. O jei reikės pažadinti budėtoją, tai apie tai sužinosime neskenuodami gigabaitų failus, o ištraukę kelis baitus iš maišos lentelės.
Šis plėtinys buvo priimtas, pavyzdžiui, saugykloje . Jei norite jį naudoti, galite jį įdiegti patys. Žinoma, tai atvirojo kodo.
Bet tai dar ne viskas. Pradėjome naudoti „Amcheck“ – bendruomenės sukurtą plėtinį, kad surastume nekintamus indeksų pažeidimus.
Ir mes sužinojome, kad jei naudojate jį dideliu mastu, yra klaidų. Pradėjome juos taisyti. Mūsų pataisymai buvo priimti.
Mes nustatėme, kad šis plėtinys negali analizuoti GiST ir GIT indeksų. Privertėme juos palaikyti. Tačiau apie šį palaikymą bendruomenė vis dar diskutuoja, nes tai gana nauja funkcija ir jame yra daug smulkmenų.
Taip pat išsiaiškinome, kad tikrinant indeksus, ar nėra pažeidimų replikacijos lyderyje, pagrindiniame kompiuteryje, viskas veikia gerai, tačiau kopijose, sekime korupcijos paieška nėra tokia efektyvi. Ne visi invariantai tikrinami. Ir vienas invariantas mus labai vargino. Ir mes praleidome pusantrų metų bendraudami su bendruomene, kad galėtume patikrinti kopijas.
Parašėme kodą, kuris turėtų atitikti visus gali... protokolus. Šį pleistrą gana ilgai diskutavome su Peteriu Gaghanu iš Crunchy Data. Jis turėjo šiek tiek modifikuoti esamą B medį Postgrese, kad priimtų šį pataisą. Jis buvo priimtas. Dabar kopijų indeksų tikrinimas taip pat tapo pakankamai efektyvus, kad būtų galima nustatyti pažeidimus, su kuriais susidūrėme. Tai yra pažeidimai, kuriuos gali sukelti disko programinės įrangos klaidos, Postgres klaidos, Linux branduolio klaidos ir aparatinės įrangos problemos. Gana platus problemų, kurioms mes ruošėmės, šaltinių sąrašas.
Tačiau be indeksų yra tokia dalis kaip krūva, t.y. vieta, kur saugomi duomenys. Ir nėra daug invariantų, kuriuos būtų galima patikrinti.
Turime plėtinį pavadinimu Heapcheck. Mes pradėjome jį kurti. Ir lygiagrečiai kartu su mumis įmonė „EnterpriseDB“ taip pat pradėjo rašyti modulį, kurį jie taip pat pavadino „Heapcheck“. Tik mes tai pavadinome PgHeapcheck, o jie tiesiog pavadino Heapcheck. Jie turi panašias funkcijas, šiek tiek kitokį parašą, bet su tomis pačiomis idėjomis. Kai kuriose vietose jie juos įgyvendino šiek tiek geriau. Ir jie anksčiau paskelbė jį atvirame kode.
O dabar plėtojame jų plėtrą, nes tai jau ne jų, o bendruomenės plėtra. Ir ateityje tai bus branduolio dalis, kuri bus pateikta visiems, kad jie iš anksto žinotų apie būsimas problemas.
Kai kuriose vietose netgi padarėme išvadą, kad mūsų stebėjimo sistemose yra klaidingų teigiamų rezultatų. Pavyzdžiui, 1C sistema. Naudodamas duomenų bazę, Postgres kartais įrašo į ją duomenis, kuriuos gali nuskaityti, bet pg_dump negali nuskaityti.
Ši situacija atrodė kaip korupcija mūsų problemų aptikimo sistemai. Budėtojas buvo pažadintas. Budėtojas pažiūrėjo, kas vyksta. Po kiek laiko atėjo klientas ir pasakė, kad turiu problemų. Prižiūrėtojas paaiškino, kokia problema. Tačiau problema yra „Postgres“ branduolyje.
Radau diskusiją apie šią funkciją. Ir parašė, kad susidūrėme su šia savybe ir buvo nemalonu, žmogus pabudo naktį tam, kad išsiaiškintų, kas tai yra.
Bendruomenė atsakė: „O, mums tikrai reikia tai sutvarkyti“.
Turiu paprastą analogiją. Jei vaikštote su batu, kuriame yra smėlio grūdelis, iš principo galite judėti toliau – jokių problemų. Jei parduodate batus tūkstančiams žmonių, tai gaminkime batus visai be smėlio. Ir jei vienas iš jūsų batų naudotojų ketina bėgti maratoną, tuomet norite pagaminti labai gerus batus ir pritaikyti juos visiems naudotojams. O tokių netikėtų vartotojų visada būna debesų aplinkoje. Visada yra vartotojų, kurie išnaudoja klasterį kokiu nors originaliu būdu. Jūs visada turite tam pasiruošti.
Ko mes čia išmokome? Išmokome paprastą dalyką: svarbiausia paaiškinti bendruomenei, kad yra problema. Jei bendruomenė pripažino problemą, tada kyla natūrali konkurencija problemai išspręsti. Nes visi nori išspręsti svarbią problemą. Visi pardavėjai, visi įsilaužėliai supranta, kad jie patys gali užlipti ant šio grėblio, todėl nori juos pašalinti.
Jei sprendžiate problemą, bet ji netrukdo niekam, išskyrus jus, bet dirbate su ja sistemingai ir galiausiai tai laikoma problema, tada jūsų prašymas tikrai bus priimtas. Jūsų pataisa bus priimta, jūsų patobulinimai ar net patobulinimų prašymai bus peržiūrėti bendruomenės. Galų gale mes pageriname duomenų bazę vieni kitiems.
Įdomi duomenų bazė yra Greenplum. Tai labai lygiagreti duomenų bazė, pagrįsta Postgres kodų baze, kurią aš puikiai žinau.
O Greenplum turi įdomių funkcijų – pridėkite optimizuotas lenteles. Tai yra lentelės, kurias galite greitai pridėti. Jie gali būti stulpeliai arba eilutės.
Bet nebuvo klasterizavimo, t. y. nebuvo funkcijos, kurioje galėtumėte sutvarkyti lentelėje esančius duomenis pagal tvarką, kuri yra viename iš indeksų.
Vaikinai iš taksi priėjo prie manęs ir pasakė: „Andrei, tu žinai Postgresą. Ir čia beveik tas pats. Perjunkite į 20 minučių. Tu imk ir daryk“. Pagalvojau, kad taip, aš pažįstu Postgresą, kuris perjungia 20 minučių – man reikia tai padaryti.
Bet ne, tai buvo ne 20 minučių, aš tai rašiau per mėnesius. PgConf.Russia konferencijoje priėjau prie Heikki Linakango iš Pivotal ir paklausiau: „Ar dėl to yra kokių nors problemų? Kodėl nėra pridėti optimizuoto lentelių grupavimo? Jis sako: „Jūs paimkite duomenis. Jūs rūšiuojate, pertvarkote. Tai tik darbas“. Aš: „O, taip, tau tereikia imti ir padaryti“. Jis sako: „Taip, mums reikia laisvų rankų, kad tai padarytume“. Pagalvojau, kad būtinai turiu tai padaryti.
Ir po kelių mėnesių pateikiau ištraukimo užklausą, kuri įdiegė šią funkciją. Šią ištraukimo užklausą „Pivotal“ peržiūrėjo kartu su bendruomene. Žinoma, buvo klaidų.
Tačiau įdomiausia tai, kad sujungus šią ištraukimo užklausą, klaidų buvo rasta pačiame Greenplum. Pastebėjome, kad krūvos lentelės kartais pažeidžia operacijų eigą, kai yra sugrupuotos. Ir tai yra dalykas, kurį reikia taisyti. Ir ji yra toje vietoje, kurią ką tik paliečiau. Ir mano natūrali reakcija buvo – gerai, leisk man tai padaryti.
Ištaisiau šią klaidą. Išsiuntė fiksuotojams prašymą ištraukti. Jis buvo nužudytas.
Po to paaiškėjo, kad šią funkciją reikia gauti Greenplum versijoje, skirta PostgreSQL 12. Tai yra, 20 minučių nuotykiai tęsiasi su naujais įdomiais nuotykiais. Įdomu buvo prisiliesti prie dabartinės raidos, kur bendruomenė pjausto naujus ir svarbiausius bruožus. Jis užšalęs.
Bet tuo viskas nesibaigė. Po visko paaiškėjo, kad reikia rašyti visa tai dokumentaciją.
Pradėjau rašyti dokumentus. Laimei, atvyko dokumentininkai iš Pivotal. Anglų kalba yra jų gimtoji kalba. Jie man padėjo sutvarkyti dokumentus. Tiesą sakant, jie patys perrašė tai, ką aš pasiūliau, į tikrą anglų kalbą.
Ir čia, atrodytų, nuotykiai baigėsi. Ir ar žinai, kas tada atsitiko? Vaikinai iš taksi priėjo prie manęs ir pasakė: „Dar liko du nuotykiai, kiekvienas po 10 minučių“. Ir ką turėčiau jiems pasakyti? Sakiau, kad dabar pateiksiu ataskaitą apie mastą, tada pamatysime jūsų nuotykius, nes tai įdomus darbas.
Ko mes išmokome iš šio atvejo? Kadangi darbas su atviruoju šaltiniu visada yra darbas su konkrečiu asmeniu, tai visada yra darbas su bendruomene. Nes kiekviename etape dirbau su kokiu nors kūrėju, bandytoju, įsilaužėliu, dokumentininku, architektu. Aš nedirbau su Greenplum, dirbau su žmonėmis aplink Greenplum.
Bet! Yra dar vienas svarbus dalykas - tai tik darbas. Tai yra, ateini, išgeri kavos, parašai kodą. Veikia visokie paprasti invariantai. Daryk tai įprastai – bus gerai! Ir tai gana įdomus darbas. Šį darbą prašo „Yandex.Cloud“ klientai, mūsų grupių vartotojai tiek „Yandex“, tiek už jos ribų. Ir manau, kad projektų, kuriuose dalyvaujame, daugės ir mūsų įsitraukimo gylis taip pat didės.
Tai viskas. Pereikime prie klausimų.
Klausimų sesija
Sveiki! Turime dar vieną klausimų ir atsakymų sesiją. Ir studijoje Andrejus Borodinas. Tai asmuo, kuris ką tik papasakojo apie „Yandex.Cloud“ ir „Yandex“ indėlį į atvirąjį kodą. Mūsų ataskaita dabar nėra vien tik apie debesį, tačiau tuo pat metu mes remiamės tokiomis technologijomis. Be to, ką padarėte „Yandex“, „Yandex.Cloud“ nebūtų jokios paslaugos, todėl ačiū iš manęs asmeniškai. Ir pirmas klausimas iš laidos: „Apie ką parašyta kiekvienas iš jūsų paminėtų projektų?
Atsarginė sistema WAL-G parašyta Go. Tai vienas iš naujesnių projektų, prie kurių dirbome. Jam tiesiogine prasme tik 3 metai. O duomenų bazė dažnai yra susijusi su patikimumu. O tai reiškia, kad duomenų bazės yra gana senos ir dažniausiai rašomos C. Projektas Postgres prasidėjo maždaug prieš 30 metų. Tada C89 buvo teisingas pasirinkimas. Ir ant jo parašyta Postgres. Modernesnės duomenų bazės, tokios kaip ClickHouse, dažniausiai rašomos C++ kalba. Visas sistemos kūrimas grindžiamas C ir C++.
Klausimas iš mūsų finansų vadovo, atsakingo už „Cloud“ išlaidas: „Kodėl Cloud išleidžia pinigus atviro kodo palaikymui?
Čia yra paprastas atsakymas finansų vadovui. Tai darome norėdami pagerinti savo paslaugas. Kokiais būdais galime padaryti geriau? Galime atlikti darbus efektyviau, greičiau ir padaryti viską labiau keičiamą. Tačiau mums ši istorija visų pirma yra apie patikimumą. Pavyzdžiui, atsarginėje sistemoje peržiūrime 100% jai taikomų pataisų. Mes žinome, kas yra kodas. Ir mums patogiau pristatyti naujas versijas į gamybą. Tai yra, visų pirma, apie pasitikėjimą, apie pasirengimą tobulėti ir apie patikimumą
Kitas klausimas: „Ar išorinių vartotojų, gyvenančių Yandex.Cloud, reikalavimai skiriasi nuo vidinių vartotojų, gyvenančių vidiniame debesyje?
Apkrovos profilis, žinoma, skiriasi. Bet mano skyriaus požiūriu, visi ypatingi ir įdomūs atvejai yra sukurti ant nestandartinės apkrovos. Tikėtina, kad kūrėjai, turintys vaizduotę, kūrėjai, kurie daro netikėtai, yra tiek viduje, tiek išorėje. Šiuo atžvilgiu mes visi esame maždaug vienodi. Ir tikriausiai vienintelė svarbi „Yandex“ duomenų bazių veikimo savybė bus ta, kad „Yandex“ viduje turime mokymą. Tam tikru momentu tam tikra pasiekiamumo zona visiškai nueina į šešėlį, ir visos „Yandex“ paslaugos turi kažkaip toliau veikti, nepaisant to. Tai nedidelis skirtumas. Tačiau tai sukuria daug tyrimų duomenų bazės ir tinklo dėklo sąsajoje. Kitu atveju išoriniai ir vidiniai įrenginiai generuoja tas pačias užklausas dėl funkcijų ir panašius prašymus dėl patikimumo ir našumo gerinimo.
Kitas klausimas: „Kaip jūs asmeniškai manote, kad didžiąją dalį to, ką darote, naudoja kiti debesys? Konkrečių neįvardinsime, tačiau daugelis projektų, kurie buvo atlikti Yandex.Cloud, naudojami kitų žmonių debesyse.
Tai šaunu. Pirma, tai ženklas, kad kažką padarėme teisingai. Ir tai subraižo ego. Ir esame labiau įsitikinę, kad padarėme teisingą sprendimą. Kita vertus, tai yra viltis, kad ateityje tai atneš mums naujų idėjų, naujų trečiųjų šalių vartotojų užklausų. Daugumą GitHub problemų kuria pavieniai sistemų administratoriai, pavieniai DBA, individualūs architektai, pavieniai inžinieriai, tačiau kartais ateina sistemingos patirties turintys žmonės ir sako, kad 30% tam tikrų atvejų mes turime šią problemą ir pagalvokime, kaip ją išspręsti. To labiausiai ir laukiame. Tikimės pasidalinti patirtimi su kitomis debesų platformomis.
Jūs daug kalbėjote apie maratoną. Žinau, kad bėgote maratoną Maskvoje. Kaip rezultatas? Aplenkė vaikinus iš PostgreSQL?
Ne, Olegas Bartunovas bėga labai greitai. Jis baigė valanda prieš mane. Apskritai esu patenkintas tuo, kaip toli nuėjau. Man tik pabaiga buvo pasiekimas. Apskritai stebina, kad postgres bendruomenėje yra tiek daug bėgikų. Man atrodo, kad tarp aerobinio sporto ir sisteminio programavimo noro yra kažkoks ryšys.
Sakote, ClickHouse nėra bėgikų?
Tikrai žinau, kad jie ten yra. ClickHouse taip pat yra duomenų bazė. Beje, Olegas dabar man rašo: „Gal eisim pabėgioti po pranešimo? Tai puiki idėja.
Kitas Nikitos laidos klausimas: „Kodėl jūs pats ištaisėte Greenplum klaidą ir nedavėte jos jauniesiems? Tiesa, nelabai aišku, kas yra klaida ir kurioje servise, bet tikriausiai tai reiškia tą, apie kurią kalbėjote.
Taip, iš principo tai galėjo būti kam nors padovanota. Tai buvo tik kodas, kurį ką tik pakeičiau. Ir buvo natūralu tuoj pat tai daryti toliau. Iš esmės idėja dalytis patirtimi su komanda yra gera idėja. Greenplum užduotis tikrai pasidalinsime su visais mūsų padalinio nariais.
Kadangi mes kalbame apie jaunesnes, čia yra klausimas. Asmuo nusprendė sukurti pirmąjį įsipareigojimą Postgrese. Ką jis turi padaryti, kad pirmas įsipareigotų?
Tai įdomus klausimas: „Nuo kur pradėti? Paprastai gana sunku pradėti nuo kažko branduolyje. Pavyzdžiui, „Postgres“ yra darbų sąrašas. Bet iš tikrųjų tai yra lapas to, ką jie bandė padaryti, bet nepavyko. Tai sudėtingi dalykai. Ir paprastai ekosistemoje galite rasti tam tikrų paslaugų, kai kurių plėtinių, kuriuos galima patobulinti, kurie pritraukia mažiau branduolio kūrėjų dėmesio. Ir, atitinkamai, ten yra daugiau augimo taškų. Programoje „Google Summer of Code“ kiekvienais metais „postgres“ bendruomenė pateikia daugybę skirtingų temų, kurias būtų galima aptarti. Šiais metais turėjome, manau, tris mokinius. Vienas netgi rašė WAL-G temomis, kurios yra svarbios Yandex. „Greenplum“ viskas paprasčiau nei „Postgres“ bendruomenėje, nes „Greenplum“ įsilaužėliai labai gerai elgiasi su ištraukimo užklausomis ir iškart pradeda peržiūrą. Pleistro siuntimas „Postgres“ yra kelių mėnesių reikalas, tačiau „Greenplum“ ateis po dienos ir pamatys, ką padarėte. Kitas dalykas – Greenplum turi išspręsti dabartines problemas. Greenplum nėra plačiai naudojamas, todėl rasti savo problemą yra gana sunku. Ir pirmiausia, žinoma, turime išspręsti problemas.
Šaltinis: www.habr.com