Farið verður yfir framlag Yandex til eftirfarandi gagnagrunna.
- smellahús
- Odyssey
- Endurheimt að tímapunkti (WAL-G)
- PostgreSQL (þar á meðal logerrors, Amcheck, heapcheck)
- Greenplum
Video:
Halló heimur! Ég heiti Andrey Borodin. Og það sem ég geri hjá Yandex.Cloud er að þróa opna tengslagagnagrunna í þágu Yandex.Cloud og Yandex.Cloud viðskiptavina.
Í þessu erindi munum við tala um áskoranirnar sem standa frammi fyrir opnum gagnagrunnum í mælikvarða. Hvers vegna er það mikilvægt? Vegna þess að lítil, lítil vandamál sem, eins og moskítóflugur, verða síðan að fílum. Þeir verða stórir þegar þú ert með marga klasa.
En það er ekki aðalatriðið. Ótrúlegir hlutir gerast. Hlutir sem gerast í einu af hverjum milljón tilfellum. Og í skýjaumhverfi verður þú að vera viðbúinn því, því ótrúlegir hlutir verða mjög líklegar þegar eitthvað er til í stærðargráðu.
En! Hver er kosturinn við opna gagnagrunna? Staðreyndin er sú að þú hefur fræðilegt tækifæri til að takast á við hvaða vandamál sem er. Þú hefur frumkóðann, þú hefur forritunarþekkingu. Við sameinum það og það virkar.
Hvaða aðferðir eru í vinnu við opinn hugbúnað?
- Einfaldasta aðferðin er að nota hugbúnað. Ef þú notar samskiptareglur, ef þú notar staðla, ef þú notar snið, ef þú skrifar fyrirspurnir í opnum hugbúnaði, þá styður þú það nú þegar.
- Þú ert að gera vistkerfi þess stærra. Þú eykur líkurnar á því að villu greinist snemma. Þú eykur áreiðanleika þessa kerfis. Þú eykur framboð forritara á markaðnum. Þú bætir þennan hugbúnað. Þú ert nú þegar þátttakandi ef þú varst bara búinn að fá stíl og fikta í einhverju þar.
- Önnur skiljanleg nálgun er að styrkja opinn hugbúnað. Sem dæmi má nefna hið þekkta Google Summer of Code forrit, þegar Google greiðir fjölda nemenda alls staðar að úr heiminum skiljanlega peninga þannig að þeir þróa opin hugbúnaðarverkefni sem uppfylla ákveðnar leyfiskröfur.
- Þetta er mjög áhugaverð nálgun því hún gerir hugbúnaðinum kleift að þróast án þess að færa fókusinn frá samfélaginu. Google, sem tæknirisi, segir ekki að við viljum þennan eiginleika, við viljum laga þessa villu og þetta er þar sem við þurfum að grafa. Google segir: „Gerðu það sem þú gerir. Haltu bara áfram að vinna eins og þú hefur verið að vinna og allt verður í lagi."
- Næsta leið til að taka þátt í opnum hugbúnaði er þátttaka. Þegar þú átt í vandræðum með opinn hugbúnað og það eru forritarar byrja verktaki þín að leysa vandamálin. Þeir byrja að gera innviði þína skilvirkari, forritin þín hraðari og áreiðanlegri.
Eitt frægasta Yandex verkefnið á sviði opins hugbúnaðar er ClickHouse. Þetta er gagnagrunnur sem varð til sem svar við áskorunum sem Yandex.Metrica stendur frammi fyrir.
Og sem gagnagrunnur var hann gerður í opnum hugbúnaði til að búa til vistkerfi og þróa það ásamt öðrum forriturum (ekki aðeins innan Yandex). Og nú er þetta stórt verkefni sem mörg mismunandi fyrirtæki taka þátt í.
Í Yandex.Cloud bjuggum við til ClickHouse ofan á Yandex Object Storage, þ.e. ofan á skýjageymslu.
Af hverju er þetta mikilvægt í skýinu? Vegna þess að hvaða gagnagrunnur sem er virkar í þessum þríhyrningi, í þessum pýramída, í þessu stigveldi minnistegunda. Þú ert með hraðvirkar en litlar skrár og ódýra stóra en hæga SSD diska, harða diska og nokkur önnur blokkartæki. Og ef þú ert duglegur efst í pýramídanum, þá ertu með hraðvirkan gagnagrunn. ef þú ert duglegur neðst í þessum pýramída, þá ertu með skalaðan gagnagrunn. Og í þessu sambandi, að bæta við öðru lagi að neðan er rökrétt nálgun til að auka sveigjanleika gagnagrunnsins.
Hvernig var hægt að gera það? Þetta er mikilvægt atriði í þessari skýrslu.
- Við gætum innleitt ClickHouse yfir MDS. MDS er innra Yandex skýgeymsluviðmót. Það er flóknara en venjulega S3 samskiptareglur, en það er hentugra fyrir blokk tæki. Það er betra til að skrá gögn. Það þarf meiri forritun. Forritarar munu forrita, það er jafnvel gott, það er áhugavert.
- S3 er algengari nálgun sem gerir viðmótið einfaldara á kostnað minni aðlögunar að ákveðnum tegundum vinnuálags.
Við vildum náttúrulega veita öllu ClickHouse vistkerfinu virkni og vinna verkefnið sem þarf innan Yandex.Cloud, ákváðum við að tryggja að allt ClickHouse samfélagið myndi njóta góðs af því. Við innleiddum ClickHouse yfir S3, ekki ClickHouse yfir MDS. Og þetta er mikil vinna.
Tilvísanir:
„Uppdráttarlag skráakerfis“
"AWS SDK S3 samþætting"
„Grunnútfærsla á IDisk tengingu fyrir S3“
"Samþætting gagnageymsluvéla með IDisk tengi"
„Stuðningur við skráningarvél fyrir S3 og SeekableReadBuffer“
„Stuðningur við geymslu Stripe Log S3“
"Storage MergeTree upphafsstuðningur fyrir S3"
"MergeTree fullur stuðningur fyrir S3"
„Styðja ReplicatedMergeTree yfir S3“
„Bæta við sjálfgefnum skilríkjum og sérsniðnum hausum fyrir s3 geymslu“
"S3 með kraftmikilli proxy stillingu"
"S3 með umboðslausni"
Þetta er dráttarbeiðnalisti til að útfæra sýndarskráakerfi í ClickHouse. Þetta er mikill fjöldi dráttarbeiðna.
Tilvísanir:
"DiskS3 hardlinks ákjósanlegur útfærsla"
„S3 HTTP viðskiptavinur - Forðastu að afrita svarstraum í minni“
„Forðastu að afrita allan svarstrauminn í minni í S3 HTTP
viðskiptavinur"
„Getu til að geyma skyndiminni og skrá skrár fyrir S3 disk“
"Færðu hluta frá DiskLocal til DiskS3 samhliða"
En verkinu lauk ekki þar. Eftir að eiginleikinn var gerður þurfti meiri vinnu til að hámarka þessa virkni.
Tilvísanir:
"Bæta við SelectedRows og SelectedBytes viðburðum"
"Bæta prófílatburði úr S3 beiðni við system.events"
"Bæta við QueryTimeMicroseconds, SelectQueryTimeMicroseconds og InsertQueryTimeMicroseconds"
Og þá þurfti að gera það greiningarhæft, setja upp eftirlit og gera það viðráðanlegt.
Og allt var þetta gert þannig að allt samfélagið, allt vistkerfið ClickHouse, fékk afrakstur þessarar vinnu.
Við skulum fara yfir í viðskiptagagnagrunna, í OLTP gagnagrunna, sem eru mér persónulega nær.
Þetta er opinn uppspretta DBMS þróunarsvið. Þessir krakkar eru að gera götugaldra til að bæta viðskiptalega opna gagnagrunna.
Eitt af verkefnunum, með því að nota dæmi sem við getum talað um hvernig og hvað við gerum, er Connection Pooler í Postgres.
Postgres er ferli gagnagrunnur. Þetta þýðir að gagnagrunnurinn ætti að hafa eins fáar nettengingar og mögulegt er sem annast viðskipti.
Á hinn bóginn, í skýjaumhverfi, er dæmigert ástand þegar þúsund tengingar koma í einn þyrping í einu. Og verkefni tengingapottsins er að pakka þúsund tengingum inn í lítinn fjölda netþjónatenginga.
Við getum sagt að tengingargeymirinn sé símafyrirtækið sem endurraðar bæti þannig að þau nái á skilvirkan hátt í gagnagrunninn.
Því miður er ekki til gott rússneskt orð fyrir tengingu pooler. Stundum er það kallað multiplexer tengingar. Ef þú veist hvað þú átt að kalla tengingargeymirinn, vertu viss um að segja mér það, ég mun vera mjög ánægður með að tala rétt rússneskt tæknimál.
Við rannsökuðum tengingarhópa sem hentaði fyrir stýrðan postgres klasa. Og PgBouncer var besti kosturinn fyrir okkur. En við lentum í ýmsum vandamálum með PgBouncer. Fyrir mörgum árum gaf Volodya Borodin skýrslur um að við notum PgBouncer, okkur líkar allt, en það eru blæbrigði, það er eitthvað til að vinna í.
Og við unnum. Við laguðum vandamálin sem við lentum í, plástraðum Bouncer og reyndum að ýta á dráttarbeiðnir andstreymis. En grundvallareinþráður var erfitt að vinna með.
Við þurftum að safna fossum frá pjattum Bouncers. Þegar við erum með marga einþráða Bouncers flytjast tengingarnar á efsta lagið yfir á innra lagið á Bouncers. Þetta er illa stjórnað kerfi sem erfitt er að byggja upp og skala fram og til baka.
Við komumst að þeirri niðurstöðu að við bjuggum til okkar eigin tengingalaugar, sem heitir Odyssey. Við skrifuðum það frá grunni.
Árið 2019, á PgCon ráðstefnunni, kynnti ég þennan pooler fyrir þróunarsamfélaginu. Núna erum við með aðeins færri en 2 stjörnur á GitHub, þ.e.a.s. verkefnið er lifandi, verkefnið er vinsælt.
Og ef þú býrð til Postgres þyrping í Yandex.Cloud, þá verður það þyrping með innbyggðum Odyssey, sem er endurstillt þegar þyrpingin er stækkuð fram eða til baka.
Hvað lærðum við af þessu verkefni? Að setja af stað samkeppnisverkefni er alltaf ágengt skref, það er öfgafullur mælikvarði þegar við segjum að það séu vandamál sem eru ekki leyst nógu fljótt, eru ekki leyst á þeim tíma sem myndi henta okkur. En þetta er áhrifarík ráðstöfun.
PgBouncer byrjaði að þróast hraðar.
Og nú hafa önnur verkefni birst. Til dæmis pgagroal, sem er þróað af Red Hat hönnuðum. Þeir sækjast eftir svipuðum markmiðum og framkvæma svipaðar hugmyndir, en auðvitað með eigin sérstöðu, sem eru nær pgagroal verktaki.
Annað mál um að vinna með postgres samfélaginu er að koma aftur á tímapunkt. Þetta er bati eftir bilun, þetta er bati úr öryggisafriti.
Afritin eru mörg og þau eru öll mismunandi. Næstum sérhver Postgres söluaðili hefur sína eigin öryggisafritunarlausn.
Ef þú tekur öll afritunarkerfin, býrð til eiginleikafylki og reiknar í gríni ákvarðanaþáttinn í þessu fylki, þá verður það núll. Hvað þýðir þetta? Hvað ef þú tekur ákveðna öryggisafrit, þá er ekki hægt að setja hana saman úr stykki af öllum hinum. Hún er einstök í útfærslu sinni, hún er einstök í tilgangi sínum, hún er einstök í þeim hugmyndum sem í henni felast. Og þeir eru allir sérstakir.
Á meðan við vorum að vinna í þessu máli setti CitusData af stað WAL-G verkefnið. Þetta er varakerfi sem var gert með auga fyrir skýjaumhverfinu. Nú er CitusData þegar hluti af Microsoft. Og á því augnabliki líkaði okkur mjög vel við hugmyndirnar sem voru settar fram í fyrstu útgáfum WAL-G. Og við byrjuðum að leggja þessu verkefni lið.
Nú eru margir tugir þróunaraðila í þessu verkefni, en efstu 10 þátttakendurnir í WAL-G eru 6 Yandexoids. Við komum með margar hugmyndir okkar þangað. Og auðvitað útfærðum við þau sjálf, prófuðum þau sjálf, settum þau út í framleiðslu sjálf, við notum þau sjálf, finnum sjálf hvert við eigum að flytja næst, á meðan við áttum samskipti við stóra WAL-G samfélagið.
Og frá okkar sjónarhóli, nú er þetta öryggisafritunarkerfi, þar með talið að teknu tilliti til viðleitni okkar, orðið ákjósanlegt fyrir skýjaumhverfi. Þetta er besti kostnaðurinn við að taka afrit af Postgres í skýinu.
Hvað þýðir það? Við vorum að kynna nokkuð stóra hugmynd: öryggisafrit ætti að vera öruggt, ódýrt í rekstri og eins hratt og hægt er að endurheimta.
Hvers vegna ætti það að vera ódýrt í rekstri? Þegar ekkert er bilað ættirðu ekki að vita að þú sért með öryggisafrit. Allt virkar vel, þú eyðir eins litlum örgjörva og mögulegt er, þú notar eins lítið af diskaauðlindunum þínum og mögulegt er og þú sendir eins fá bæti á netið og mögulegt er til að trufla ekki burðargetu dýrmætrar þjónustu þinnar.
Og þegar allt bilar, til dæmis, sleppti admin gögnunum, eitthvað fór úrskeiðis, og þú þarft brýn að fara aftur til fortíðar, þú batnar með öllum peningunum, því þú vilt fá gögnin þín aftur fljótt og ósnortinn.
Og við kynntum þessa einföldu hugmynd. Og okkur sýnist að okkur hafi tekist að koma því í framkvæmd.
En það er ekki allt. Okkur langaði í eitt lítið í viðbót. Við vildum hafa marga mismunandi gagnagrunna. Ekki nota allir viðskiptavinir okkar Postgres. Sumir nota MySQL, MongoDB. Í samfélaginu hafa aðrir verktaki stutt FoundationDB. Og þessi listi stækkar stöðugt.
Samfélaginu líkar hugmyndin um að gagnagrunnurinn sé keyrður í stýrðu umhverfi í skýinu. Og þróunaraðilar viðhalda gagnagrunnum sínum, sem hægt er að taka afrit af á einsleitan hátt ásamt Postgres með afritunarkerfinu okkar.
Hvað höfum við lært af þessari sögu? Varan okkar, sem þróunardeild, er ekki kóðalínur, það eru ekki staðhæfingar, það eru ekki skrár. Varan okkar er ekki draga beiðnir. Þetta eru hugmyndirnar sem við komum á framfæri við samfélagið. Þetta er tækniþekking og hreyfing tækni í átt að skýjaumhverfi.
Það er til gagnagrunnur eins og Postgres. Mér líkar best við Postgres kjarnann. Ég eyði miklum tíma í að þróa Postgres kjarnann með samfélaginu.
En hér verður að segjast að Yandex.Cloud er með innri uppsetningu á stýrðum gagnagrunnum. Og það byrjaði fyrir löngu síðan í Yandex.Mail. Sú sérfræðiþekking sem nú hefur leitt til stýrðs Postgres safnaðist upp þegar pósturinn vildi flytja inn í Postgres.
Póstur hefur mjög svipaðar kröfur og skýið. Það þarf að þú getir stækkað í óvæntan veldisvöxt hvenær sem er í gögnunum þínum. Og pósturinn var nú þegar hlaðinn af hundruðum milljóna pósthólfa af miklum fjölda notenda sem stöðugt leggja fram margar beiðnir.
Og þetta var frekar alvarleg áskorun fyrir liðið sem var að þróa Postgres. Á þeim tíma voru öll vandamál sem við lentum í tilkynnt til samfélagsins. Og þessi vandamál voru leiðrétt og leiðrétt af samfélaginu á sumum stöðum jafnvel á stigi greiddra stuðnings fyrir suma aðra gagnagrunna og jafnvel betra. Það er, þú getur sent bréf til PgSQL tölvusnápur og fengið svar innan 40 mínútna. Greiddur stuðningur í sumum gagnagrunnum gæti haldið að það séu fleiri forgangsatriði en villan þín.
Nú er innri uppsetning Postgres nokkur petabytes af gögnum. Þetta eru einhverjar milljónir beiðna á sekúndu. Þetta eru þúsundir klasa. Það er mjög umfangsmikið.
En það er blæbrigði. Það lifir ekki á fínum netdrifum, heldur á frekar einföldum vélbúnaði. Og það er prófunarumhverfi sérstaklega fyrir áhugaverða nýja hluti.
Og á ákveðnu augnabliki í prófunarumhverfinu fengum við skilaboð sem gefa til kynna að innri óbreytileikar gagnagrunnsvísitölunnar hafi verið brotin.
Óbreytilegt er einhvers konar samband sem við gerum ráð fyrir að haldi alltaf.
Mjög krítísk staða fyrir okkur. Það gefur til kynna að einhver gögn gætu hafa glatast. Og gagnatap er beinlínis hörmulegt.
Almenna hugmyndin sem við fylgjumst með í stýrðum gagnagrunnum er að jafnvel með fyrirhöfn verður erfitt að tapa gögnum. Jafnvel þó þú fjarlægir þau vísvitandi þarftu samt að hunsa fjarveru þeirra í langan tíma. Gagnaöryggi er trúarbrögð sem við fylgjum af mikilli kostgæfni.
Og hér kemur upp staða sem bendir til þess að það geti komið upp aðstæður sem við erum kannski ekki viðbúin. Og við byrjuðum að búa okkur undir þetta ástand.
Það fyrsta sem við gerðum var að grafa stokkana úr þessum þúsundum klasa. Við fundum hver af þyrpingunum var staðsettur á diskum með erfiðan fastbúnað sem var að tapa uppfærslum á gagnasíðum. Merkti allan Postgres gagnakóða. Og við merktum þessi skilaboð sem gefa til kynna brot á innri óbreytileika með kóða sem er hannaður til að greina spillingu gagna.
Þessi plástur var nánast samþykktur af samfélaginu án mikillar umræðu, því í hverju einstöku tilviki var augljóst að eitthvað slæmt hafði gerst og þurfti að tilkynna það til loggsins.
Eftir þetta komumst við að því að við erum með vöktun sem skannar annála. Og ef um grunsamleg skilaboð er að ræða vekur hann vaktstjórann og vaktstjórinn gerir við það.
En! Skönnun á annálum er ódýr aðgerð á einum klasa og hörmulega dýr fyrir þúsund klasa.
Við skrifuðum framlengingu sem heitir . Það skapar yfirsýn yfir gagnagrunninn þar sem þú getur á ódýran og fljótlegan hátt valið tölfræði um fyrri villur. Og ef við þurfum að vekja vaktstjórann, þá munum við komast að þessu án þess að skanna gígabæta skrár, heldur með því að draga nokkur bæti úr kjötkássatöflunni.
Þessi framlenging hefur verið samþykkt, til dæmis, í geymslunni fyrir . Ef þú vilt nota það geturðu sett það upp sjálfur. Auðvitað er það opinn uppspretta.
En það er ekki allt. Við byrjuðum að nota Amcheck, samfélagsbyggða viðbót, til að finna óbreytileg brot í vísitölum.
Og við komumst að því að ef þú notar það í stærðargráðu, þá eru gallar. Við byrjuðum að laga þá. Leiðréttingar okkar hafa verið samþykktar.
Við komumst að því að þessi viðbót getur ekki greint GiST & GIT vísitölur. Við létum þá styðja. En þessi stuðningur er enn í umræðunni í samfélaginu, því þetta er tiltölulega ný virkni og það er mikið af smáatriðum þar.
Og við komumst líka að því að þegar athugað er með vísitölur fyrir brot á afritunarleiðtoganum, á meistaranum, virkar allt vel, en á eftirmyndunum, á fylgjendum, er leitin að spillingu ekki svo áhrifarík. Ekki eru allar óbreytanlegar athuganir. Og einn óbreytilegur truflaði okkur mjög. Og við eyddum einu og hálfu ári í samskipti við samfélagið til að virkja þessa athugun á eftirmyndum.
Við skrifuðum kóða sem ætti að fylgja öllum geta... samskiptareglum. Við ræddum þennan plástur í nokkurn tíma við Peter Gaghan frá Crunchy Data. Hann þurfti að breyta aðeins núverandi B-tré í Postgres til að samþykkja þennan plástur. Hann var samþykktur. Og nú hefur eftirlit með vísitölum á eftirmyndum einnig orðið nógu áhrifaríkt til að greina brotin sem við lentum í. Það er að segja, þetta eru brotin sem geta stafað af villum í fastbúnaði disksins, villum í Postgres, villum í Linux kjarnanum og vélbúnaðarvandamálum. Alveg viðamikill listi yfir uppsprettur vandamála sem við vorum að undirbúa okkur fyrir.
En fyrir utan vísitölur er hluti eins og hrúga, þ.e. staðurinn þar sem gögnin eru geymd. Og það eru ekki margir óbreytanlegir sem hægt væri að athuga.
Við erum með viðbót sem heitir Heapcheck. Við byrjuðum að þróa það. Og samhliða, ásamt okkur, byrjaði EnterpriseDB fyrirtækið einnig að skrifa einingu, sem þeir kölluðu Heapcheck á sama hátt. Aðeins við kölluðum það PgHeapcheck, og þeir kölluðu það bara Heapcheck. Þeir hafa það með svipaðar aðgerðir, aðeins öðruvísi undirskrift, en með sömu hugmyndir. Þeir útfærðu þá aðeins betur sums staðar. Og þeir birtu það í opnum uppspretta áður.
Og nú erum við að þróa stækkun þeirra, því það er ekki lengur stækkun þeirra, heldur stækkun samfélagsins. Og í framtíðinni er þetta hluti af kjarnanum sem verður útvegaður öllum svo þeir geti vitað um framtíðarvandamál fyrirfram.
Sums staðar komumst við jafnvel að þeirri niðurstöðu að við séum með rangar jákvæðar upplýsingar í vöktunarkerfum okkar. Til dæmis, 1C kerfið. Þegar gagnagrunnur er notaður skrifar Postgres stundum gögn inn í hann sem hann getur lesið, en pg_dump getur ekki lesið.
Þetta ástand leit út eins og spilling á vandamálagreiningarkerfinu okkar. Vaktstjórinn var vakinn. Vaktstjórinn skoðaði hvað var að gerast. Eftir nokkurn tíma kom viðskiptavinur og sagði að ég ætti í vandræðum. Gestgjafinn útskýrði hvert vandamálið væri. En vandamálið er í Postgres kjarnanum.
Ég fann umræðu um þennan eiginleika. Og hann skrifaði að við lentum í þessum eiginleika og það væri óþægilegt, maður vaknaði á nóttunni til að komast að því hvað þetta væri.
Samfélagið svaraði: „Ó, við þurfum virkilega að laga það.
Ég er með einfalda líkingu. Ef þú ert að ganga í skó sem er með sandkorn í, þá geturðu í grundvallaratriðum haldið áfram - ekkert mál. Ef þú selur þúsundum manna stígvél, þá skulum við búa til stígvél án sands. Og ef einn af notendum skónna þinna ætlar að hlaupa maraþon, þá viltu búa til mjög góða skó og stækka þá til allra notenda þinna. Og slíkir óvæntir notendur eru alltaf í skýjaumhverfinu. Það eru alltaf notendur sem nýta sér klasann á einhvern frumlegan hátt. Þú verður alltaf að búa þig undir þetta.
Hvað höfum við lært hér? Við lærðum einfaldan hlut: það mikilvægasta er að útskýra fyrir samfélaginu að það sé vandamál. Ef samfélagið hefur viðurkennt vandann, þá skapast eðlileg samkeppni um að leysa vandann. Vegna þess að allir vilja leysa mikilvægt vandamál. Allir söluaðilar, allir tölvuþrjótar skilja að þeir geta sjálfir stigið á þessa hrífu, svo þeir vilja útrýma þeim.
Ef þú ert að vinna í vandamáli, en það truflar engan nema þig, en þú vinnur markvisst í því og það er á endanum talið vandamál, þá verður pull beiðni þín örugglega samþykkt. Plásturinn þinn verður samþykktur, endurbætur þínar eða jafnvel beiðnir um úrbætur verða skoðaðar af samfélaginu. Í lok dagsins gerum við gagnagrunninn betri fyrir hvert annað.
Áhugaverður gagnagrunnur er Greenplum. Það er mjög samhliða gagnagrunnur byggður á Postgres kóðagrunni, sem ég þekki mjög vel.
Og Greenplum hefur áhugaverða virkni - bættu við fínstilltum töflum. Þetta eru töflur sem þú getur fljótt bætt við. Þau geta verið annað hvort súlulaga eða raðir.
En það var engin þyrping, þ.e. það var engin virkni þar sem hægt er að raða gögnum sem eru staðsett í töflunni í samræmi við röðina sem er í einni af vísitölunum.
Strákarnir úr leigubílnum komu til mín og sögðu: „Andrey, þú þekkir Postgres. Og hér er þetta nánast það sama. Skiptu yfir í 20 mínútur. Þú tekur það og gerir það." Ég hugsaði að já, ég þekki Postgres, skipti í 20 mínútur - ég þarf að gera þetta.
En nei, það voru ekki 20 mínútur, ég skrifaði það á mánuðum. Á PgConf.Russia ráðstefnunni leitaði ég til Heikki Linakangas frá Pivotal og spurði: „Eru einhver vandamál með þetta? Af hverju er engin bjartsýni töfluþyrping til?" Hann segir: „Þú tekur gögnin. Þú flokkar, þú endurraðar. Þetta er bara vinna." Ég: "Ó, já, þú þarft bara að taka það og gera það." Hann segir: „Já, við þurfum frjálsar hendur til að gera þetta. Ég hélt að ég þyrfti klárlega að gera þetta.
Og nokkrum mánuðum síðar lagði ég fram dráttarbeiðni sem útfærði þessa virkni. Pivotal skoðaði þessa beiðni ásamt samfélaginu. Auðvitað voru pöddur.
En það sem er mest áhugavert er að þegar þessi pull beiðni var sameinuð fundust pöddur í Greenplum sjálfu. Við höfum komist að því að hrúgutöflur rjúfa stundum viðskipti þegar þær eru þyrpaðar. Og þetta er hlutur sem þarf að laga. Og hún er á þeim stað sem ég snerti. Og eðlileg viðbrögð mín voru - allt í lagi, leyfðu mér að gera þetta líka.
Ég lagaði þessa villu. Sendi dráttarbeiðni til lagfæringanna. Hann var drepinn.
Eftir það kom í ljós að þessa virkni þarf að fá í Greenplum útgáfunni fyrir PostgreSQL 12. Það er að segja að 20 mínútna ævintýrið heldur áfram með nýjum áhugaverðum ævintýrum. Það var áhugavert að snerta núverandi þróun, þar sem samfélagið er að klippa nýja og mikilvægustu eiginleika. Það er frosið.
En það endaði ekki þar. Eftir allt saman kom í ljós að við þurftum að skrifa skjöl fyrir þetta allt.
Ég byrjaði að skrifa skjöl. Sem betur fer komu heimildarmennirnir frá Pivotal með. Enska er móðurmál þeirra. Þeir hjálpuðu mér með skjölin. Reyndar endurskrifuðu þeir sjálfir það sem ég lagði til yfir á alvöru ensku.
Og hér, að því er virðist, var ævintýrinu lokið. Og veistu hvað gerðist þá? Strákarnir úr leigubílnum komu til mín og sögðu: „Það eru enn tvö ævintýri, hvert í 10 mínútur. Og hvað á ég að segja þeim? Ég sagði að nú mun ég gefa skýrslu í mælikvarða, svo sjáum við ævintýri þín, því þetta er áhugavert starf.
Hvað lærðum við af þessu máli? Vegna þess að vinna með opinn uppspretta er alltaf að vinna með ákveðnum einstaklingi, það er alltaf að vinna með samfélaginu. Vegna þess að á hverju stigi vann ég með einhverjum forritara, einhverjum prófara, einhverjum tölvuþrjóta, einhverjum heimildarmanni, einhverjum arkitekt. Ég vann ekki með Greenplum, ég vann með fólki í kringum Greenplum.
En! Það er annar mikilvægur punktur - það er bara vinna. Það er, þú kemur, drekkur kaffi, skrifar kóða. Allskonar einföld óbreytileiki virka. Gerðu það venjulega - það verður allt í lagi! Og það er alveg áhugavert starf. Það er beiðni um þessa vinnu frá Yandex.Cloud viðskiptavinum, notendum klasa okkar bæði innan Yandex og utan. Og ég held að verkefnum sem við tökum þátt í muni fjölga og dýpt í aðkomu okkar muni líka aukast.
Það er allt og sumt. Við skulum halda áfram að spurningunum.
Spurningafundur
Halló! Við erum með aðra spurningu og svörum. Og í stúdíóinu Andrei Borodin. Þetta er manneskjan sem sagði þér nýlega frá framlagi Yandex.Cloud og Yandex til opinn uppspretta. Skýrslan okkar núna snýst ekki algjörlega um skýið, en á sama tíma byggjum við á slíkri tækni. Án þess sem þú gerðir inni í Yandex væri engin þjónusta í Yandex.Cloud, svo þakka þér frá mér persónulega. Og fyrsta spurningin úr útsendingunni: „Hvert er hvert af verkefnunum sem þú nefndir skrifað á?
Afritunarkerfið í WAL-G er skrifað í Go. Þetta er eitt af nýrri verkefnum sem við höfum unnið að. Hann er bókstaflega bara 3 ára. Og gagnagrunnur snýst oft um áreiðanleika. Og þetta þýðir að gagnagrunnarnir eru nokkuð gamlir og þeir eru venjulega skrifaðir í C. Postgres verkefnið hófst fyrir um 30 árum. Þá var C89 rétti kosturinn. Og Postgres er skrifað á það. Nútímalegri gagnagrunnar eins og ClickHouse eru venjulega skrifaðir í C++. Öll kerfisþróun byggir á C og C++.
Spurning frá fjármálastjóra okkar, sem ber ábyrgð á útgjöldum hjá Cloud: „Hvers vegna eyðir Cloud peningum í að styðja opinn hugbúnað?
Hér er einfalt svar fyrir fjármálastjórann. Þetta gerum við til að bæta þjónustu okkar. Á hvaða hátt getum við gert betur? Við getum gert hlutina á skilvirkari hátt, hraðar og gert hlutina skalanlegari. En fyrir okkur snýst þessi saga fyrst og fremst um áreiðanleika. Til dæmis, í öryggisafritunarkerfi skoðum við 100% af plástrunum sem eiga við það. Við vitum hver kóðinn er. Og við erum öruggari með að setja nýjar útgáfur í framleiðslu. Það er, fyrst og fremst, það snýst um sjálfstraust, um viðbúnað til þróunar og um áreiðanleika
Önnur spurning: "Eru kröfur ytri notenda sem búa í Yandex.Cloud frábrugðnar innri notendum sem búa í innra skýinu?"
Hleðslusniðið er auðvitað öðruvísi. En frá sjónarhóli deildar minnar eru öll sérstök og áhugaverðu tilvikin búin til á óstöðluðu álagi. Hönnuðir með hugmyndaflug, verktaki sem gera hið óvænta, eru eins líklegir til að finnast bæði innan og utan. Í þessu sambandi erum við öll nokkurn veginn eins. Og líklega mun eini mikilvægi eiginleikinn í Yandex rekstri gagnagrunna vera að innan Yandex erum við með kennslu. Á einhverjum tímapunkti fer eitthvað framboðssvæði algjörlega í skuggann og öll Yandex þjónusta verður einhvern veginn að halda áfram að virka þrátt fyrir þetta. Þetta er lítill munur. En það skapar mikla rannsóknarþróun á viðmóti gagnagrunnsins og netstafla. Annars mynda ytri og innri uppsetningar sömu beiðnir um eiginleika og svipaðar beiðnir til að bæta áreiðanleika og afköst.
Næsta spurning: "Hvernig finnst þér persónulega um þá staðreynd að mikið af því sem þú gerir er notað af öðrum skýjum?" Við munum ekki nefna tiltekin verkefni, en mörg verkefni sem voru unnin í Yandex.Cloud eru notuð í skýjum annarra.
Þetta er svalt. Í fyrsta lagi er það merki um að við höfum gert eitthvað rétt. Og það klórar egóið. Og við erum öruggari um að við höfum tekið rétta ákvörðun. Á hinn bóginn er þetta vonin um að í framtíðinni muni þetta færa okkur nýjar hugmyndir, nýjar beiðnir frá þriðja aðila notendum. Flest mál á GitHub eru búin til af einstökum kerfisstjórum, einstökum DBA, einstökum arkitektum, einstökum verkfræðingum, en stundum kemur fólk með kerfisbundna reynslu og segir að í 30% tilvika séum við með þetta vandamál og við skulum hugsa um hvernig eigi að leysa það. Þetta er það sem við hlökkum mest til. Við hlökkum til að deila reynslu með öðrum skýjapöllum.
Þú talaðir mikið um maraþonið. Ég veit að þú hljópst maraþon í Moskvu. Þar af leiðandi? Náði strákunum frá PostgreSQL?
Nei, Oleg Bartunov hleypur mjög hratt. Hann kláraði klukkutíma á undan mér. Á heildina litið er ég ánægður með hversu langt ég náði. Fyrir mig var bara að klára afrek. Á heildina litið kemur það á óvart að það eru svo margir hlauparar í postgres samfélaginu. Mér sýnist að það sé einhver tengsl á milli þolþjálfunar og löngunar í kerfisforritun.
Ertu að segja að það séu engir hlauparar á ClickHouse?
Ég veit fyrir víst að þeir eru þarna. ClickHouse er einnig gagnagrunnur. Við the vegur, Oleg er núna að skrifa mér: "Eigum við að fara að hlaupa eftir skýrsluna?" Þetta er frábær hugmynd.
Önnur spurning úr útsendingunni frá Nikita: "Hvers vegna lagaðir þú villuna í Greenplum sjálfur og gafst ekki yngri börnum?" Að vísu er ekki mjög ljóst hver villan er og í hvaða þjónustu, en það þýðir líklega þá sem þú talaðir um.
Já, í grundvallaratriðum hefði það getað verið gefið einhverjum. Það var bara kóðann sem ég breytti. Og það var eðlilegt að halda því áfram strax. Í grundvallaratriðum er hugmyndin um að deila sérfræðiþekkingu með teyminu góð hugmynd. Við munum örugglega deila Greenplum verkefnum á milli allra meðlima deildarinnar okkar.
Þar sem við erum að tala um yngri, þá er hér spurning. Viðkomandi ákvað að búa til fyrstu skuldbindinguna í Postgres. Hvað þarf hann að gera til að gera fyrstu skuldbindinguna?
Þetta er áhugaverð spurning: "Hvar á að byrja?" Það er yfirleitt frekar erfitt að byrja með eitthvað í kjarnanum. Í Postgres er til dæmis verkefnalisti. En í rauninni er þetta blað yfir því sem þeir reyndu að gera, en tókst ekki. Þetta eru flóknir hlutir. Og venjulega er hægt að finna einhver tól í vistkerfinu, sumar viðbætur sem hægt er að bæta, sem vekja minni athygli frá kjarnahönnuðum. Og í samræmi við það eru fleiri stig til vaxtar þar. Í Google Summer of code forritinu setur postgres samfélagið fram á hverju ári mörg mismunandi efni sem hægt væri að fjalla um. Í ár höfðum við, held ég, þrjá nemendur. Einn skrifaði meira að segja í WAL-G um efni sem eru mikilvæg fyrir Yandex. Í Greenplum er allt einfaldara en í Postgres samfélaginu, vegna þess að Greenplum tölvuþrjótar meðhöndla pull beiðnir mjög vel og byrja strax að skoða. Að senda plástur til Postgres er spurning um mánuði, en Greenplum mun koma eftir einn dag og sjá hvað þú hefur gert. Annað er að Greenplum þarf að leysa núverandi vandamál. Greenplum er ekki mikið notað, svo það er frekar erfitt að finna vandamálið þitt. Og fyrst og fremst þurfum við auðvitað að leysa vandamál.
Heimild: www.habr.com