Prispevek Yandexa k naslednjim zbirkam podatkov bo pregledan.
- KlikniteHouse
- Odyssey
- Okrevanje do določene točke (WAL-G)
- PostgreSQL (vključno z napakami dnevnika, Amcheck, heapcheck)
- Zelena sliva
Video:
Pozdravljen, svet! Moje ime je Andrej Borodin. In kar počnem pri Yandex.Cloud, je razvoj odprtih relacijskih baz podatkov v interesu odjemalcev Yandex.Cloud in Yandex.Cloud.
V tem govoru bomo govorili o izzivih, s katerimi se soočajo odprte zbirke podatkov v velikem obsegu. Zakaj je pomembno? Ker majhne, male težave, ki kot komarji potem postanejo sloni. Ko imate veliko grozdov, postanejo veliki.
Ampak to ni glavno. Zgodijo se neverjetne stvari. Stvari, ki se zgodijo v enem od milijona primerov. In v okolju v oblaku morate biti na to pripravljeni, saj postanejo neverjetne stvari zelo verjetne, ko nekaj obstaja v velikem obsegu.
Ampak! Kakšna je prednost odprtih baz podatkov? Dejstvo je, da imate teoretično možnost, da se spopadete s katero koli težavo. Imate izvorno kodo, imate znanje programiranja. Kombiniramo in deluje.
Kakšni so pristopi pri delu z odprtokodno programsko opremo?
- Najbolj enostaven pristop je uporaba programske opreme. Če uporabljate protokole, če uporabljate standarde, če uporabljate formate, če pišete poizvedbe v odprtokodni programski opremi, potem to že podpirate.
- Povečujete njegov ekosistem. Povečate verjetnost zgodnjega odkrivanja hrošča. Povečate zanesljivost tega sistema. Povečate razpoložljivost razvijalcev na trgu. Vi izboljšate to programsko opremo. Sodelujoči ste že, če ste se pravkar lotili stila in nekaj poigrali.
- Drug razumljiv pristop je sponzoriranje odprtokodne programske opreme. Na primer dobro znani program Google Summer of Code, ko Google plača velikemu številu študentov z vsega sveta razumljiv denar, da razvijejo projekte odprte programske opreme, ki izpolnjujejo določene licenčne zahteve.
- To je zelo zanimiv pristop, saj omogoča, da se programska oprema razvija, ne da bi preusmerila pozornost stran od skupnosti. Google kot tehnološki velikan ne pravi, da želimo to funkcijo, želimo popraviti to napako in tu moramo kopati. Google pravi: »Delaj, kar delaš. Samo nadaljujte z delom, kot ste delali, in vse bo v redu."
- Naslednji pristop k sodelovanju v odprti kodi je sodelovanje. Ko imate težave z odprtokodno programsko opremo in obstajajo razvijalci, vaši razvijalci začnejo reševati težave. Začnejo delati vašo infrastrukturo učinkovitejšo, vaše programe hitrejše in zanesljivejše.
Eden najbolj znanih Yandexovih projektov na področju odprtokodne programske opreme je ClickHouse. To je zbirka podatkov, ki je nastala kot odgovor na izzive, s katerimi se sooča Yandex.Metrica.
In kot podatkovna baza je bila narejena v odprti kodi, da bi ustvarili ekosistem in ga razvijali skupaj z drugimi razvijalci (ne samo znotraj Yandexa). In zdaj je to velik projekt, v katerega je vključenih veliko različnih podjetij.
V Yandex.Cloudu smo ustvarili ClickHouse na vrhu Yandex Object Storage, tj. na vrhu shrambe v oblaku.
Zakaj je to pomembno v oblaku? Ker vsaka baza podatkov deluje v tem trikotniku, v tej piramidi, v tej hierarhiji vrst pomnilnika. Imate hitre, a majhne registre in poceni velike, a počasne SSD diske, trde diske in nekatere druge blokovne naprave. In če ste učinkoviti na vrhu piramide, potem imate hitro bazo podatkov. če ste učinkoviti na dnu te piramide, potem imate povečano bazo podatkov. In v zvezi s tem je dodajanje še enega sloja od spodaj logičen pristop k povečanju razširljivosti baze podatkov.
Kako je to mogoče? To je pomembna točka v tem poročilu.
- Lahko bi implementirali ClickHouse preko MDS. MDS je notranji vmesnik za shranjevanje v oblaku Yandex. Je bolj zapleten kot običajni protokol S3, vendar je bolj primeren za blok naprave. Bolje je za zapisovanje podatkov. Zahteva več programiranja. Programerji bodo programirali, celo dobro je, zanimivo je.
- S3 je pogostejši pristop, ki poenostavi vmesnik na račun manjšega prilagajanja določenim vrstam delovnih obremenitev.
Seveda, ker želimo zagotoviti funkcionalnost celotnemu ekosistemu ClickHouse in opraviti nalogo, ki je potrebna znotraj Yandex.Cloud, smo se odločili zagotoviti, da bo imela od tega koristi celotna skupnost ClickHouse. ClickHouse smo implementirali prek S3, ne ClickHouse prek MDS. In to je veliko dela.
Reference:
"Sloj abstrakcije datotečnega sistema"
"Integracija AWS SDK S3"
“Osnovna izvedba vmesnika IDisk za S3”
"Integracija mehanizmov za shranjevanje dnevnikov z vmesnikom IDisk"
"Podpora za mehanizem dnevnika za S3 in SeekableReadBuffer"
"Podpora za Storage Stripe Log S3"
"Začetna podpora Storage MergeTree za S3"
"Popolna podpora MergeTree za S3"
"Podpora ReplicatedMergeTree preko S3"
»Dodaj privzete poverilnice in glave po meri za shranjevanje s3«
"S3 z dinamično konfiguracijo proxyja"
"S3 z razreševalcem proxyja"
To je seznam zahtev za vleko za implementacijo virtualnega datotečnega sistema v ClickHouse. To je veliko število zahtev za vleko.
Reference:
"DiskS3 trde povezave optimalna implementacija"
»Odjemalec S3 HTTP — Izogibajte se kopiranju odzivnega toka v pomnilnik«
»Izogibajte se kopiranju celotnega odzivnega toka v pomnilnik v S3 HTTP
stranka"
»Zmožnost predpomnilnika oznak in indeksnih datotek za disk S3«
"Vzporedno premakni dele iz DiskLocal na DiskS3"
A delo se tu ni končalo. Ko je bila funkcija ustvarjena, je bilo potrebno še nekaj dela za optimizacijo te funkcije.
Reference:
"Dodaj dogodke SelectedRows in SelectedBytes"
"Dodaj dogodke profiliranja iz zahteve S3 v system.events"
"Dodaj QueryTimeMicroseconds, SelectQueryTimeMicroseconds in InsertQueryTimeMicroseconds"
In potem je bilo treba narediti diagnozo, vzpostaviti nadzor in narediti obvladljivo.
In vse to je bilo narejeno tako, da je celotna skupnost, celoten ekosistem ClickHouse prejel rezultat tega dela.
Preidimo na transakcijske baze, na OLTP baze, ki so meni osebno bližje.
To je oddelek za razvoj odprtokodnih DBMS. Ti fantje izvajajo ulično čarovnijo za izboljšanje transakcijskih odprtih baz podatkov.
Eden od projektov, na primeru katerega lahko govorimo o tem, kako in kaj počnemo, je Connection Pooler v Postgresu.
Postgres je baza podatkov procesov. To pomeni, da mora imeti baza podatkov čim manj omrežnih povezav, ki obravnavajo transakcije.
Po drugi strani pa je v oblačnem okolju tipična situacija, ko v eno gručo pride tisoč povezav hkrati. Naloga zbiralnika povezav je pakirati tisoč povezav v majhno število strežniških povezav.
Lahko rečemo, da je zbiralnik povezav telefonski operater, ki preureja bajte tako, da učinkovito dosežejo bazo podatkov.
Na žalost ni dobre ruske besede za povezovalnik povezav. Včasih se imenujejo povezave multiplekserja. Če veste, kako poimenovati povezovalno skupino, mi vsekakor povejte, z veseljem bom govoril pravilen ruski tehnični jezik.
Raziskali smo povezovalne bazene, ki so bili primerni za upravljano gručo postgres. In PgBouncer je bil za nas najboljša izbira. Toda s PgBouncerjem smo naleteli na številne težave. Pred mnogimi leti je Volodya Borodin poročal, da uporabljamo PgBouncer, vse nam je všeč, vendar obstajajo nianse, na čem je treba delati.
In smo delali. Odpravili smo težave, na katere smo naleteli, popravili smo Bouncer in poskusili potisniti zahteve za vleko navzgor. Toda temeljno enonitnost je bilo težko delati.
Morali smo zbirati kaskade iz zakrpanih Bouncerjev. Ko imamo veliko enonitnih odbijačev, se povezave na zgornji plasti prenesejo na notranjo plast odbijačev. To je slabo upravljan sistem, ki ga je težko graditi in spreminjati naprej in nazaj.
Prišli smo do zaključka, da smo ustvarili lasten povezovalni bazen, ki se imenuje Odyssey. Napisali smo ga iz nič.
Leta 2019 sem na konferenci PgCon predstavil ta pooler skupnosti razvijalcev. Zdaj imamo na GitHubu nekaj manj kot 2 zvezdic, torej projekt živi, projekt je priljubljen.
In če ustvarite gručo Postgres v Yandex.Cloudu, bo to gruča z vgrajeno Odyssey, ki se na novo konfigurira pri skaliranju gruče naprej ali nazaj.
Kaj smo se naučili iz tega projekta? Zagon konkurenčnega projekta je vedno agresiven korak, je skrajni ukrep, ko rečemo, da obstajajo problemi, ki se ne rešujejo dovolj hitro, se ne rešujejo v časovnih intervalih, ki bi nam ustrezali. Toda to je učinkovit ukrep.
PgBouncer se je začel razvijati hitreje.
In zdaj so se pojavili drugi projekti. Na primer pgagroal, ki so ga razvili razvijalci Red Hat. Zasledujejo podobne cilje in uresničujejo podobne ideje, a seveda s svojimi specifikami, ki so bližje razvijalcem pgagroala.
Drug primer dela s skupnostjo postgres je obnavljanje na določeno časovno točko. To je obnovitev po napaki, to je obnovitev iz varnostne kopije.
Obstaja veliko varnostnih kopij in vse so različne. Skoraj vsak prodajalec Postgres ima svojo rešitev za varnostno kopiranje.
Če vzamete vse rezervne sisteme, ustvarite matriko funkcij in v šali izračunate determinanto v tej matriki, bo nič. Kaj to pomeni? Kaj pa, če vzamete določeno varnostno kopijo datoteke, potem je ni mogoče sestaviti iz delov vseh drugih. Edinstven je v svoji izvedbi, edinstven je v svojem namenu, edinstven je v idejah, ki so vgrajene vanj. In vsi so specifični.
Medtem ko smo se ukvarjali s to težavo, je CitusData zagnal projekt WAL-G. To je varnostni sistem, ki je bil narejen s pogledom na okolje v oblaku. Zdaj je CitusData že del Microsofta. In v tistem trenutku so nam bile zelo všeč ideje, ki so bile določene v začetnih izdajah WAL-G. In začeli smo prispevati k temu projektu.
Zdaj je v tem projektu na desetine razvijalcev, vendar je med 10 največjih sodelavcev WAL-G 6 Yandexoidov. Tja smo prinesli veliko svojih idej. In seveda smo jih sami implementirali, sami testirali, sami uvedli v proizvodnjo, sami jih uporabljamo, sami ugotavljamo, kam naprej, medtem ko sodelujemo z veliko skupnostjo WAL-G.
In z našega vidika je zdaj ta varnostni sistem, vključno z upoštevanjem naših prizadevanj, postal optimalen za okolje v oblaku. To je najboljši strošek varnostnega kopiranja Postgres v oblaku.
Kaj to pomeni? Spodbujali smo dokaj veliko idejo: varnostno kopiranje mora biti varno, poceni za uporabo in kar se da hitro obnoviti.
Zakaj bi moralo biti poceni za delovanje? Ko ni nič pokvarjeno, ne bi smeli vedeti, da imate varnostne kopije. Vse deluje v redu, porabite čim manj CPE-ja, porabite čim manj diskovnih virov in pošljete čim manj bajtov v omrežje, da ne motite obremenitve vaših dragocenih storitev.
In ko se vse pokvari, je na primer admin izpustil podatke, je šlo nekaj narobe in se moraš nujno vrniti v preteklost, okrevaš z vsem denarjem, ker hočeš svoje podatke nazaj hitro in nedotaknjene.
In promovirali smo to preprosto idejo. In kot se nam zdi, nam je to uspelo uresničiti.
A to še ni vse. Želeli smo še eno malenkost. Želeli smo veliko različnih baz podatkov. Vse naše stranke ne uporabljajo Postgresa. Nekateri ljudje uporabljajo MySQL, MongoDB. V skupnosti so drugi razvijalci podprli FoundationDB. In ta seznam se nenehno širi.
Skupnosti je všeč zamisel, da se baza podatkov izvaja v upravljanem okolju v oblaku. In razvijalci vzdržujejo svoje baze podatkov, ki jih je mogoče enotno varnostno kopirati skupaj s Postgresom z našim sistemom za varnostno kopiranje.
Kaj smo se naučili iz te zgodbe? Naš izdelek, kot razvojni oddelek, ni vrstice kode, niso izjave, niso datoteke. Naš izdelek ni zahteve po vleku. To so ideje, ki jih posredujemo skupnosti. To je tehnološko strokovno znanje in premik tehnologije v okolje v oblaku.
Obstaja takšna baza podatkov, kot je Postgres. Najbolj mi je všeč jedro Postgres. Veliko časa porabim za razvoj jedra Postgres s skupnostjo.
Toda tukaj je treba povedati, da ima Yandex.Cloud notranjo namestitev upravljanih baz podatkov. In začelo se je že dolgo nazaj v Yandex.Mail. Strokovno znanje, ki je zdaj vodilo do upravljanega Postgresa, se je nabralo, ko se je pošta želela preseliti v Postgres.
Pošta ima zelo podobne zahteve kot oblak. Potrebuje, da se lahko kadar koli v svojih podatkih prilagodite do nepričakovane eksponentne rasti. In pošta je imela že nekaj sto milijonov poštnih predalov ogromnega števila uporabnikov, ki nenehno postavljajo številne zahteve.
In to je bil resen izziv za ekipo, ki je razvijala Postgres. Takrat so vse težave, na katere smo naleteli, poročali skupnosti. In te težave so bile popravljene, ponekod jih je popravila skupnost celo na ravni plačljive podpore za nekatere druge baze podatkov in še bolje. To pomeni, da lahko hekerju PgSQL pošljete pismo in prejmete odgovor v 40 minutah. Plačljiva podpora v nekaterih zbirkah podatkov lahko misli, da so stvari bolj prednostne kot vaša napaka.
Zdaj je notranja namestitev Postgresa nekaj petabajtov podatkov. Gre za nekaj milijonov zahtevkov na sekundo. To je na tisoče grozdov. Je zelo obsežno.
Vendar obstaja odtenek. Ne živi na modnih omrežnih pogonih, ampak na dokaj preprosti strojni opremi. In obstaja testno okolje posebej za zanimive nove stvari.
In v določenem trenutku smo v testnem okolju prejeli sporočilo, ki kaže, da so bile kršene notranje invariante indeksov baze podatkov.
Invariant je neke vrste razmerje, za katerega pričakujemo, da bo vedno veljalo.
Zelo kritična situacija za nas. Označuje, da so bili nekateri podatki morda izgubljeni. In izguba podatkov je nekaj naravnost katastrofalnega.
Splošna ideja, ki ji sledimo pri upravljanih zbirkah podatkov, je, da bo podatke težko izgubiti tudi z naporom. Tudi če jih namerno odstranite, boste še vedno morali dolgo časa ignorirati njihovo odsotnost. Varnost podatkov je religija, ki ji zelo pridno sledimo.
In tukaj se pojavi situacija, ki nakazuje, da lahko pride do situacije, na katero morda nismo pripravljeni. In začeli smo se pripravljati na to situacijo.
Prva stvar, ki smo jo naredili, je bila, da smo zakopali hlode iz teh tisočih grozdov. Ugotovili smo, kateri od grozdov so bili na diskih s problematično vdelano programsko opremo, ki so izgubljale posodobitve strani s podatki. Označena vsa podatkovna koda Postgres. Tista sporočila, ki kažejo na kršitve notranjih invariant, smo označili s kodo, ki je zasnovana za odkrivanje poškodb podatkov.
Ta popravek je skupnost praktično sprejela brez večje razprave, saj je bilo v vsakem posameznem primeru očitno, da se je zgodilo nekaj slabega in da je bilo treba to prijaviti v dnevnik.
Po tem smo prišli do točke, da imamo nadzor, ki skenira dnevnike. In v primeru sumljivih sporočil zbudi dežurnega, ta pa popravi.
Ampak! Skeniranje dnevnikov je poceni operacija na enem grozdu in katastrofalno draga za tisoč grozdov.
Napisali smo razširitev, imenovano . Ustvari pogled na bazo podatkov, v kateri lahko poceni in hitro izberete statistiko preteklih napak. In če moramo zbuditi dežurnega častnika, potem bomo o tem izvedeli brez skeniranja gigabajtnih datotek, ampak z ekstrakcijo nekaj bajtov iz zgoščene tabele.
Ta razširitev je bila sprejeta na primer v skladišču za . Če ga želite uporabljati, ga lahko namestite sami. Seveda je odprtokoden.
A to še ni vse. Začeli smo uporabljati Amcheck, razširitev, ki jo je ustvarila skupnost, za iskanje nespremenljivih kršitev v indeksih.
In ugotovili smo, da če ga upravljate v velikem obsegu, obstajajo hrošči. Začeli smo jih popravljati. Naši popravki so bili sprejeti.
Ugotovili smo, da ta razširitev ne more analizirati indeksov GiST in GIT. Dali smo jim podporo. Toda skupnost še vedno razpravlja o tej podpori, ker je to relativno nova funkcionalnost in je tam veliko podrobnosti.
Ugotovili smo tudi, da pri preverjanju indeksov za kršitve na voditelju replikacije, na masterju, vse deluje dobro, na replikah, na sledilniku pa iskanje poškodovanosti ni tako učinkovito. Vse invariante niso preverjene. In ena invarianta nas je zelo motila. In porabili smo leto in pol za komunikacijo s skupnostjo, da bi omogočili to preverjanje replik.
Napisali smo kodo, ki bi morala slediti vsem lahko ... protokolom. O tem popravku smo kar nekaj časa razpravljali s Petrom Gaghanom iz Crunchy Data. Moral je nekoliko spremeniti obstoječe B-drevo v Postgresu, da je sprejel ta popravek. Bil je sprejet. Zdaj je tudi preverjanje indeksov na replikah postalo dovolj učinkovito za odkrivanje kršitev, na katere smo naleteli. Se pravi, to so kršitve, ki jih lahko povzročijo napake v vdelani programski opremi diska, napake v Postgresu, napake v jedru Linuxa in težave s strojno opremo. Precej obsežen seznam virov težav, na katere smo se pripravljali.
Toda poleg indeksov obstaja tudi del, kot je kopica, tj. kraj, kjer so shranjeni podatki. In ni veliko invariant, ki bi jih lahko preverili.
Imamo razširitev, imenovano Heapcheck. Začeli smo ga razvijati. In vzporedno je skupaj z nami tudi podjetje EnterpriseDB začelo pisati modul, ki so ga na enak način poimenovali Heapcheck. Samo mi smo temu rekli PgHeapcheck, oni pa so ga pravkar imenovali Heapcheck. Imajo ga s podobnimi funkcijami, nekoliko drugačnim podpisom, a z enakimi idejami. Ponekod so jih nekoliko bolje izvedli. In že prej so ga objavili v odprti kodi.
In zdaj razvijamo njihovo širitev, ker to ni več njihova širitev, ampak širitev skupnosti. In v prihodnosti bo to del jedra, ki bo na voljo vsem, da bodo lahko vnaprej vedeli za prihodnje težave.
Ponekod smo prišli celo do zaključka, da imamo v svojih nadzornih sistemih lažne pozitivne rezultate. Na primer sistem 1C. Ko uporablja bazo podatkov, Postgres včasih vanjo zapiše podatke, ki jih lahko prebere, vendar pg_dump ne more prebrati.
Ta situacija je bila videti kot okvara našega sistema za odkrivanje težav. Dežurnega so zbudili. Dežurni je pogledal, kaj se dogaja. Čez nekaj časa je prišla stranka in rekla, da imam težave. Spremljevalec je pojasnil, v čem je težava. Toda težava je v jedru Postgres.
Našel sem razpravo o tej funkciji. In napisal je, da smo naleteli na to lastnost in da je bilo neprijetno, človek se je ponoči zbudil, da bi ugotovil, kaj je to.
Skupnost je odgovorila: "Oh, res moramo popraviti."
Imam preprosto analogijo. Če hodiš v čevlju, v katerem je zrno peska, potem načeloma lahko greš naprej – ni problema. Če prodajate škornje na tisoče ljudi, potem naredimo škornje sploh brez peska. In če bo eden od uporabnikov vaših čevljev pretekel maraton, potem želite izdelati zelo dobre čevlje in jih nato razširiti na vse svoje uporabnike. In taki nepričakovani uporabniki so vedno v oblačnem okolju. Vedno se najdejo uporabniki, ki gručo izkoriščajo na izviren način. Na to se morate vedno pripraviti.
Kaj smo se tukaj naučili? Naučili smo se enostavne stvari: najpomembnejše je razložiti skupnosti, da obstaja problem. Če je skupnost prepoznala problem, se pojavi naravna konkurenca za rešitev problema. Ker vsak želi rešiti pomemben problem. Vsi prodajalci, vsi hekerji razumejo, da lahko sami stopijo na te grablje, zato jih želijo odpraviti.
Če delate na problemu, vendar ta ne moti nikogar razen vas, vendar delate na njem sistematično in se na koncu obravnava kot problem, potem bo vaša zahteva po vleku zagotovo sprejeta. Vaš popravek bo sprejet, vaše izboljšave ali celo zahteve za izboljšave bo pregledala skupnost. Na koncu dneva bazo podatkov izboljšamo drug za drugega.
Zanimiva zbirka podatkov je Greenplum. To je zelo vzporedna baza podatkov, ki temelji na kodni bazi Postgres, ki jo zelo dobro poznam.
In Greenplum ima zanimivo funkcionalnost - dodajanje optimiziranih tabel. To so tabele, ki jih lahko hitro dodate. Lahko so v obliki stolpcev ali vrstic.
Ni pa bilo združevanja v gruče, torej ni bilo nobene funkcionalnosti, kjer bi lahko razporedili podatke v tabeli v skladu z vrstnim redom, ki je v enem od indeksov.
Do mene so prišli fantje iz taksija in rekli: »Andrej, poznaš Postgres. In tukaj je skoraj enako. Preklopite na 20 minut. Vzemi in naredi." Mislil sem, da ja, poznam Postgres, preklop za 20 minut - to moram storiti.
Ampak ne, ni bilo 20 minut, pisal sem ga več mesecev. Na konferenci PgConf.Russia sem stopil do Heikkija Linakangasa iz Pivotala in ga vprašal: »Ali so s tem kakšne težave? Zakaj ni združevanja tabel, optimiziranega za dodajanje?« Pravi: »Vzameš podatke. Razvrstiš, preurediš. To je samo služba." Jaz: "Oh, ja, samo vzeti moraš in narediti." Pravi: "Da, za to potrebujemo proste roke." Mislil sem, da to zagotovo moram narediti.
In nekaj mesecev kasneje sem oddal zahtevo za vleko, ki je implementirala to funkcionalnost. To zahtevo za vlečenje je pregledal Pivotal skupaj s skupnostjo. Seveda so bile napake.
Najbolj zanimivo pa je, da so bile ob združitvi te zahteve za vleko napake najdene v samem Greenplumu. Ugotovili smo, da tabele kopice pri združevanju v gruče včasih prekinejo transakcijskost. In to je stvar, ki jo je treba popraviti. In ona je na mestu, ki sem se ga pravkar dotaknil. In moja naravna reakcija je bila – v redu, naj to naredim tudi jaz.
Popravil sem to napako. Popravljalcem je bila poslana zahteva za vlečenje. Bil je ubit.
Nakar se je izkazalo, da je to funkcionalnost treba pridobiti v različici Greenplum za PostgreSQL 12. Se pravi, 20-minutna avantura se nadaljuje z novimi zanimivimi dogodivščinami. Zanimivo se je bilo dotakniti trenutnega razvoja, kjer skupnost kroji nove in najpomembnejše funkcije. Zamrznjeno je.
A tu se ni končalo. Po vsem skupaj se je izkazalo, da moramo za vse to napisati dokumentacijo.
Začel sem pisati dokumentacijo. Na srečo so prišli dokumentarci iz Pivotala. Angleščina je njihov materni jezik. Pomagali so mi z dokumentacijo. Pravzaprav so sami prepisali, kar sem predlagal, v pravo angleščino.
In tukaj se je zdelo, da se je avantura končala. In veste, kaj se je zgodilo potem? Do mene so prišli fantje iz taksija in rekli: "Čakata še dve dogodivščini, vsaka po 10 minut." In kaj naj jim rečem? Rekel sem, da bom zdaj podal poročilo v obsegu, potem pa bomo videli vaše dogodivščine, ker je to zanimivo delo.
Kaj smo se naučili iz tega primera? Ker je delo z odprto kodo vedno delo z določeno osebo, je vedno delo s skupnostjo. Ker sem na vsaki posamezni stopnji delal z nekim razvijalcem, nekaterim preizkuševalcem, nekaterim hekerjem, nekaterim dokumentaristom, nekaterim arhitektom. Nisem delal z Greenplumom, delal sem z ljudmi okrog Greenpluma.
Ampak! Obstaja še ena pomembna točka - to je samo delo. Se pravi, prideš, spiješ kavo, napišeš kodo. Delujejo vse vrste preprostih invariant. Naredite normalno - vse bo v redu! In to je zelo zanimivo delo. Obstaja zahteva za to delo s strani odjemalcev Yandex.Cloud, uporabnikov naših grozdov znotraj in zunaj Yandexa. In mislim, da se bo povečalo število projektov, v katerih sodelujemo, in povečala se bo tudi globina naše vključenosti.
To je vse. Preidimo na vprašanja.
Seja vprašanj
Zdravo! Imamo še eno sejo vprašanj in odgovorov. In v studiu Andrej Borodin. To je oseba, ki vam je pravkar povedala o prispevku Yandex.Clouda in Yandexa k odprtokodnosti. Naše poročilo zdaj ni v celoti o oblaku, hkrati pa temeljimo na teh tehnologijah. Brez tega, kar ste storili v Yandexu, ne bi bilo storitve v Yandex.Cloudu, zato se vam osebno zahvaljujem. In prvo vprašanje iz oddaje: “O čem piše vsak od projektov, ki ste jih omenili?”
Rezervni sistem v WAL-G je napisan v Go. To je eden novejših projektov, ki smo jih delali. Star je dobesedno samo 3 leta. In baza podatkov je pogosto povezana z zanesljivostjo. In to pomeni, da so baze podatkov precej stare in so običajno napisane v C. Projekt Postgres se je začel pred približno 30 leti. Potem je bil C89 prava izbira. In na njem piše Postgres. Sodobnejše zbirke podatkov, kot je ClickHouse, so običajno napisane v C++. Ves razvoj sistema temelji na C in C++.
Vprašanje našega finančnega menedžerja, ki je odgovoren za stroške pri Cloudu: "Zakaj Cloud troši denar za podporo odprte kode?"
Tukaj je preprost odgovor za finančnega menedžerja. To počnemo, da bi bile naše storitve boljše. Na kakšen način lahko postanemo boljši? Stvari lahko naredimo učinkoviteje, hitreje in jih naredimo bolj razširljive. Toda za nas je ta zgodba predvsem o zanesljivosti. Na primer, v sistemu za varnostno kopiranje pregledamo 100 % popravkov, ki veljajo zanj. Vemo, kakšna je koda. In bolj udobno uvajamo nove različice v proizvodnjo. To pomeni, da gre najprej za samozavest, za pripravljenost na razvoj in za zanesljivost
Drugo vprašanje: "Ali se zahteve zunanjih uporabnikov, ki živijo v Yandex.Cloudu, razlikujejo od notranjih uporabnikov, ki živijo v notranjem oblaku?"
Obremenitveni profil je seveda drugačen. Toda z vidika mojega oddelka so vsi posebni in zanimivi primeri ustvarjeni na nestandardni obremenitvi. Razvijalce z domišljijo, razvijalce, ki delajo nepričakovano, je verjetno najti tako znotraj kot zunaj. Glede tega smo vsi približno enaki. In verjetno bo edina pomembna značilnost znotraj delovanja baz podatkov Yandex ta, da imamo znotraj Yandexa učenje. Na neki točki neko območje razpoložljivosti popolnoma preide v senco in vse storitve Yandex morajo kljub temu nekako še naprej delovati. To je majhna razlika. Vendar ustvarja veliko raziskovalnega razvoja na vmesniku baze podatkov in omrežnega sklada. V nasprotnem primeru zunanje in notranje namestitve ustvarjajo enake zahteve po funkcijah in podobne zahteve za izboljšanje zanesljivosti in zmogljivosti.
Naslednje vprašanje: "Kako se vi osebno počutite glede dejstva, da veliko tega, kar počnete, uporabljajo drugi oblaki?" Ne bomo imenovali posebnih, vendar se številni projekti, ki so bili narejeni v Yandex.Cloudu, uporabljajo v oblakih drugih ljudi.
To je kul. Prvič, to je znak, da smo naredili nekaj prav. In grebe po egu. In bolj smo prepričani, da smo se odločili prav. Po drugi strani pa je to upanje, da nam bo to v prihodnosti prineslo nove ideje, nove zahteve tretjih uporabnikov. Večino težav na GitHubu ustvarijo posamezni sistemski administratorji, posamezni DBA, posamezni arhitekti, posamezni inženirji, včasih pa pridejo ljudje s sistematičnimi izkušnjami in rečejo, da imamo v 30% določenih primerov ta problem in dajmo razmisliti, kako ga rešiti. Tega se najbolj veselimo. Veselimo se izmenjave izkušenj z drugimi platformami v oblaku.
Veliko ste govorili o maratonu. Vem, da ste pretekli maraton v Moskvi. Kot rezultat? Prehitel fante iz PostgreSQL?
Ne, Oleg Bartunov teče zelo hitro. Končal je uro pred mano. Na splošno sem zadovoljen s tem, kako daleč sem prišel. Zame je bil že samo zaključek dosežek. Na splošno je presenetljivo, da je v postgres skupnosti toliko tekačev. Zdi se mi, da obstaja neka povezava med aerobnimi športi in željo po sistemskem programiranju.
Hočete reči, da pri ClickHouse ni tekačev?
Zagotovo vem, da so tam. ClickHouse je tudi zbirka podatkov. Mimogrede, Oleg mi zdaj piše: "Greva teči po poročilu?" To je odlična ideja.
Še eno vprašanje iz oddaje Nikite: "Zakaj ste sami odpravili napako v Greenplum in je niste dali mladincem?" Res je, da ni čisto jasno, kaj je hrošč in v kateri storitvi, a verjetno gre za tisto, o kateri ste govorili.
Ja, načeloma bi se lahko dalo komu. Pravkar sem spremenil kodo. In naravno je bilo, da sem to takoj nadaljeval. Načeloma je ideja o izmenjavi strokovnega znanja z ekipo dobra ideja. Zagotovo si bomo Greenplum naloge razdelili med vse člane naše divizije.
Ker govorimo o mladincih, je tukaj vprašanje. Oseba se je odločila ustvariti prvo objavo v Postgresu. Kaj mora storiti, da naredi prvo obvezo?
To je zanimivo vprašanje: "Kje začeti?" Običajno je precej težko začeti z nečim v jedru. V Postgresu je na primer seznam opravil. A v resnici je to list tistega, kar so poskušali narediti, pa jim ni uspelo. To so kompleksne stvari. Običajno lahko v ekosistemu najdete nekaj pripomočkov, nekaj razširitev, ki jih je mogoče izboljšati, ki pritegnejo manj pozornosti razvijalcev jedra. In zato je tam več točk za rast. V programu Google Summer of code skupnost postgres vsako leto predstavi veliko različnih tem, ki bi jih lahko obravnavali. Letos smo imeli, mislim, tri študente. Eden je celo pisal v WAL-G o temah, ki so pomembne za Yandex. V Greenplum je vse preprosteje kot v skupnosti Postgres, saj Greenplum hekerji zelo dobro obravnavajo zahteve po vleku in takoj začnejo pregledovati. Pošiljanje popravka Postgresu je vprašanje mesecev, vendar bo Greenplum prišel čez en dan in videl, kaj ste naredili. Druga stvar je, da mora Greenplum rešiti trenutne probleme. Greenplum se ne uporablja pogosto, zato je iskanje težave precej težko. In najprej moramo seveda rešiti probleme.
Vir: www.habr.com