Pregledat će se Yandexov doprinos sljedećim bazama podataka.
- klikanica
- Odiseja
- Oporavak do točke u vremenu (WAL-G)
- PostgreSQL (uključujući logerrors, Amcheck, heapcheck)
- Zelena šljiva
Video:
Pozdrav svijete! Moje ime je Andrej Borodin. A ono što radim u Yandex.Cloudu je razvoj otvorenih relacijskih baza podataka u interesu Yandex.Clouda i Yandex.Cloud klijenata.
U ovom govoru govorit ćemo o izazovima s kojima se suočavaju otvorene baze podataka u velikom broju. Zašto je to važno? Jer mali, mali problemi koji, poput komaraca, onda postanu slonovi. Postaju velike kada imate mnogo grozdova.
Ali to nije glavno. Događaju se nevjerojatne stvari. Stvari koje se događaju u jednom od milijun slučajeva. A u okruženju oblaka, morate biti spremni na to, jer nevjerojatne stvari postaju vrlo vjerojatne kada nešto postoji u velikom obimu.
Ali! Koja je prednost otvorenih baza podataka? Činjenica je da imate teoretsku priliku nositi se s bilo kojim problemom. Imate izvorni kod, imate znanje programiranja. Kombiniramo i djeluje.
Koji pristupi postoje u radu na softveru otvorenog koda?
- Najjednostavniji pristup je korištenje softvera. Ako koristite protokole, ako koristite standarde, ako koristite formate, ako pišete upite u softveru otvorenog koda, onda to već podržavate.
- Činite njegov ekosustav većim. Povećavate vjerojatnost ranog otkrivanja greške. Vi povećavate pouzdanost ovog sustava. Povećavate dostupnost programera na tržištu. Vi poboljšavate ovaj softver. Vi ste već suradnik ako ste samo prestali sa stilom i petljali s nečim tamo.
- Još jedan razumljiv pristup je sponzoriranje softvera otvorenog koda. Na primjer, dobro poznati program Google Summer of Code, kada Google plaća velikom broju studenata iz cijelog svijeta razumnim novcem kako bi razvili otvorene softverske projekte koji ispunjavaju određene uvjete licenciranja.
- Ovo je vrlo zanimljiv pristup jer omogućuje razvoj softvera bez pomicanja fokusa sa zajednice. Google, kao tehnološki div, ne kaže da želimo ovu značajku, želimo popraviti ovu grešku i tu trebamo kopati. Google kaže: “Radi ono što radiš. Samo nastavite raditi kako ste radili i sve će biti u redu.”
- Sljedeći pristup sudjelovanju u otvorenom kodu je sudjelovanje. Kada imate problem u softveru otvorenog koda i postoje programeri, vaši programeri počinju rješavati probleme. Oni počinju vašu infrastrukturu činiti učinkovitijom, vaše programe bržima i pouzdanijima.
Jedan od najpoznatijih Yandexovih projekata u području softvera otvorenog koda je ClickHouse. Ovo je baza podataka koja je nastala kao odgovor na izazove s kojima se suočava Yandex.Metrica.
I kao baza podataka napravljena je u otvorenom kodu kako bi se stvorio ekosustav i razvijao zajedno s drugim programerima (ne samo unutar Yandexa). A sada je ovo veliki projekt u koji su uključene mnoge različite tvrtke.
U Yandex.Cloudu napravili smo ClickHouse na vrhu Yandex Object Storagea, tj. na vrhu pohrane u oblaku.
Zašto je to važno u oblaku? Jer svaka baza podataka radi u ovom trokutu, u ovoj piramidi, u ovoj hijerarhiji vrsta memorije. Imate brze ali male registre i jeftine velike ali spore SSD diskove, hard diskove i neke druge blok uređaje. A ako ste učinkoviti na vrhu piramide, onda imate brzu bazu podataka. ako ste učinkoviti na dnu ove piramide, onda imate skaliranu bazu podataka. U tom smislu, dodavanje još jednog sloja odozdo logičan je pristup povećanju skalabilnosti baze podataka.
Kako bi se to moglo učiniti? Ovo je važna točka u ovom izvješću.
- Mogli bismo implementirati ClickHouse preko MDS-a. MDS je interno Yandexovo sučelje za pohranu u oblaku. Složeniji je od uobičajenog S3 protokola, ali je prikladniji za blok uređaje. Bolje je za snimanje podataka. Zahtijeva više programiranja. Programeri će programirati, čak je i dobro, zanimljivo je.
- S3 je uobičajeniji pristup koji sučelje čini jednostavnijim po cijenu manje prilagodbe određenim vrstama radnih opterećenja.
Naravno, želeći pružiti funkcionalnost cijelom ClickHouse ekosustavu i obaviti zadatak koji je potreban unutar Yandex.Clouda, odlučili smo se pobrinuti da cijela ClickHouse zajednica ima koristi od toga. Implementirali smo ClickHouse preko S3, a ne ClickHouse preko MDS-a. A ovo je puno posla.
reference:
"Sloj apstrakcije datotečnog sustava"
"AWS SDK S3 integracija"
“Osnovna implementacija IDisk sučelja za S3”
"Integracija motora za pohranu dnevnika s IDisk sučeljem"
"Podrška za log motor za S3 i SeekableReadBuffer"
"Storage Stripe Log S3 podrška"
"Storage MergeTree početna podrška za S3"
"MergeTree puna podrška za S3"
"Podrška ReplicatedMergeTree preko S3"
“Dodaj zadane vjerodajnice i prilagođena zaglavlja za s3 pohranu”
"S3 s dinamičkom proxy konfiguracijom"
"S3 s proxy razrješavačem"
Ovo je popis zahtjeva za izvlačenje za implementaciju virtualnog datotečnog sustava u ClickHouse. Ovo je veliki broj zahtjeva za povlačenjem.
reference:
"DiskS3 hardlinks optimalna implementacija"
“S3 HTTP klijent — Izbjegavajte kopiranje toka odgovora u memoriju”
“Izbjegavajte kopiranje cijelog toka odgovora u memoriju u S3 HTTP-u
klijent"
“Mogućnost predmemoriranja datoteka oznaka i indeksa za S3 disk”
"Premjesti dijelove s DiskLocal na DiskS3 paralelno"
No posao tu nije završio. Nakon što je značajka napravljena, bilo je potrebno još malo raditi kako bi se optimizirala ova funkcionalnost.
reference:
"Dodaj događaje SelectedRows i SelectedBytes"
"Dodaj događaje profiliranja iz S3 zahtjeva u system.events"
"Dodaj QueryTimeMicroseconds, SelectQueryTimeMicroseconds i InsertQueryTimeMicroseconds"
A onda ga je trebalo učiniti dijagnostičkim, postaviti monitoring i učiniti ga upravljivim.
I sve je to napravljeno kako bi cijela zajednica, cijeli ClickHouse ekosustav, dobio rezultat ovog rada.
Prijeđimo na transakcijske baze, na OLTP baze koje su meni osobno bliže.
Ovo je odjel za razvoj DBMS-a otvorenog koda. Ovi dečki rade uličnu magiju kako bi poboljšali transakcijske otvorene baze podataka.
Jedan od projekata na čijem primjeru možemo govoriti o tome kako i što radimo je Connection Pooler u Postgresu.
Postgres je procesna baza podataka. To znači da baza podataka treba imati što manje mrežnih veza koje obrađuju transakcije.
S druge strane, u cloud okruženju tipična je situacija kada na jedan klaster dolazi tisuću veza odjednom. A zadatak skupljača veza je pakirati tisuću veza u mali broj veza poslužitelja.
Možemo reći da je uređaj za skupljanje veze telefonski operater koji preuređuje bajtove tako da učinkovito dođu do baze podataka.
Nažalost, ne postoji dobra ruska riječ za povezivač. Ponekad se naziva multiplekserskim vezama. Ako znate kako nazvati skupljač veza, svakako mi recite, bit ću vrlo sretan ako govorim ispravan ruski tehnički jezik.
Istražili smo skupove veza koji su bili prikladni za upravljani postgres klaster. A PgBouncer je bio najbolji izbor za nas. Ali naišli smo na niz problema s PgBouncerom. Prije mnogo godina Volodya Borodin je izvijestio da koristimo PgBouncer, sve nam se sviđa, ali postoje nijanse, postoji nešto na čemu treba raditi.
I radili smo. Popravili smo probleme na koje smo naišli, zakrpali smo Bouncer i pokušali poslati zahtjeve za povlačenje uzvodno. No s fundamentalnim single-threadingom bilo je teško raditi.
Morali smo skupljati kaskade od zakrpanih izbacivača. Kada imamo mnogo jednonitnih izbacivača, veze na gornjem sloju prenose se na unutarnji sloj izbacivača. Ovo je sustav kojim se loše upravlja i koji je teško izgraditi i skalirati naprijed-natrag.
Došli smo do zaključka da smo kreirali vlastiti skup povezivanja koji se zove Odyssey. Napisali smo ga od nule.
U 2019., na PgCon konferenciji, predstavio sam ovaj pooler zajednici programera. Sada imamo nešto manje od 2 zvjezdica na GitHubu, tj. projekt je živ, projekt je popularan.
A ako stvorite Postgres klaster u Yandex.Cloudu, tada će to biti klaster s ugrađenom Odyssey, koja se rekonfigurira prilikom skaliranja klastera naprijed ili natrag.
Što smo naučili iz ovog projekta? Pokretanje konkurentskog projekta uvijek je agresivan korak, krajnja je mjera kada kažemo da postoje problemi koji se ne rješavaju dovoljno brzo, ne rješavaju se u vremenskim intervalima koji bi nama odgovarali. Ali ovo je učinkovita mjera.
PgBouncer se počeo brže razvijati.
A sada su se pojavili i drugi projekti. Na primjer, pgagroal, koji su razvili Red Hat programeri. Slijede slične ciljeve i provode slične ideje, ali, naravno, sa svojim specifičnostima, koje su bliže programerima pgagroala.
Još jedan slučaj rada s postgres zajednicom je vraćanje na točku u vremenu. Ovo je oporavak nakon kvara, ovo je oporavak iz sigurnosne kopije.
Postoji mnogo sigurnosnih kopija i sve su različite. Gotovo svaki prodavač Postgresa ima vlastito backup rješenje.
Ako uzmete sve rezervne sustave, napravite matricu značajki i u šali izračunate determinantu u ovoj matrici, ona će biti nula. Što to znači? Što ako uzmete određenu datoteku sigurnosne kopije, ona se ne može sastaviti od dijelova svih ostalih. Jedinstven je po svojoj provedbi, jedinstven je po svojoj namjeni, jedinstven je po idejama koje su u njemu ugrađene. I svi su specifični.
Dok smo radili na ovom problemu, CitusData je pokrenuo WAL-G projekt. Ovo je backup sustav koji je napravljen imajući na umu okruženje oblaka. Sada je CitusData već dio Microsofta. I u tom trenutku su nam se jako svidjele ideje koje su postavljene u prvim izdanjima WAL-G-a. I počeli smo pridonositi ovom projektu.
Sada postoji mnogo desetaka programera u ovom projektu, ali 10 najvećih doprinositelja WAL-G-u uključuje 6 Yandexoida. Tamo smo donijeli puno svojih ideja. I, naravno, sami smo ih implementirali, sami smo ih testirali, sami smo ih uveli u proizvodnju, sami ih koristimo, sami smišljamo kamo ići dalje, dok smo u interakciji s velikom WAL-G zajednicom.
I s našeg stajališta, sada je ovaj sustav sigurnosne kopije, uključujući i naše napore, postao optimalan za okruženje u oblaku. Ovo je najbolja cijena sigurnosne kopije Postgresa u oblaku.
Što to znači? Promicali smo prilično veliku ideju: sigurnosna kopija bi trebala biti sigurna, jeftina za rad i što je brže moguće za vraćanje.
Zašto bi rad bio jeftin? Kad ništa nije pokvareno, ne biste trebali znati da imate sigurnosne kopije. Sve radi dobro, trošite što je moguće manje CPU-a, koristite što je moguće manje diskovnih resursa i šaljete što manje bajtova na mrežu kako ne biste ometali korisni teret vaših vrijednih usluga.
A kad se sve pokvari, na primjer, admin je ispustio podatke, nešto je pošlo po zlu, a vi se hitno morate vratiti u prošlost, oporavljate se sa svim novcem, jer želite svoje podatke natrag brzo i netaknute.
I promovirali smo ovu jednostavnu ideju. I, čini nam se, uspjeli smo to provesti.
Ali to nije sve. Htjeli smo još jednu sitnicu. Htjeli smo mnogo različitih baza podataka. Ne koriste svi naši klijenti Postgres. Neki ljudi koriste MySQL, MongoDB. U zajednici su drugi programeri podržali FoundationDB. I ovaj se popis stalno širi.
Zajednici se sviđa ideja da se baza podataka pokreće u upravljanom okruženju u oblaku. A programeri održavaju svoje baze podataka, koje se mogu ravnomjerno sigurnosno kopirati zajedno s Postgresom s našim sustavom sigurnosnog kopiranja.
Što smo naučili iz ove priče? Naš proizvod, kao razvojni odjel, nisu linije koda, nisu izjave, nisu datoteke. Naš proizvod nije zahtjev za povlačenjem. To su ideje koje prenosimo zajednici. Ovo je tehnološka stručnost i kretanje tehnologije prema okruženju oblaka.
Postoji takva baza podataka kao što je Postgres. Najviše mi se sviđa Postgres jezgra. Provodim puno vremena razvijajući Postgres jezgru sa zajednicom.
Ali ovdje se mora reći da Yandex.Cloud ima internu instalaciju upravljanih baza podataka. A počelo je davno u Yandex.Mailu. Stručnost koja je sada dovela do upravljanog Postgresa akumulirana je kada se pošta htjela preseliti u Postgres.
Mail ima vrlo slične zahtjeve kao i oblak. Potrebno je da budete u mogućnosti skalirati do neočekivanog eksponencijalnog rasta u bilo kojoj točki vaših podataka. A pošta je već bila krcata stotinama milijuna poštanskih sandučića ogromnog broja korisnika koji neprestano postavljaju brojne zahtjeve.
I to je bio prilično ozbiljan izazov za tim koji je razvijao Postgres. Tada smo sve probleme na koje smo naišli prijavljivali zajednici. I ti problemi su ispravljeni, a ispravljena je od strane zajednice na nekim mjestima čak i na razini plaćene podrške za neke druge baze podataka, pa čak i bolje. To jest, možete poslati pismo PgSQL hakeru i dobiti odgovor u roku od 40 minuta. Plaćena podrška u nekim bazama podataka može misliti da postoje prioritetnije stvari od vašeg buga.
Sada je interna instalacija Postgresa nekoliko petabajta podataka. To su neki milijuni zahtjeva u sekundi. To su tisuće klastera. Vrlo je velikih razmjera.
Ali postoji nijansa. Ne živi na otmjenim mrežnim pogonima, već na prilično jednostavnom hardveru. A postoji i testno okruženje posebno za zanimljive nove stvari.
U određenom smo trenutku u testnom okruženju primili poruku koja pokazuje da su interne invarijante indeksa baze podataka prekršene.
Invarijanta je neka vrsta odnosa za koji očekujemo da se uvijek održava.
Jako kritična situacija za nas. Označava da su neki podaci možda izgubljeni. A gubitak podataka je nešto stvarno katastrofalno.
Opća ideja koju slijedimo u upravljanim bazama podataka je da će čak i uz napor biti teško izgubiti podatke. Čak i ako ih namjerno uklonite, i dalje ćete morati ignorirati njihovu odsutnost dulje vrijeme. Sigurnost podataka je religija koju slijedimo prilično marljivo.
I tu se javlja situacija koja sugerira da bi mogla postojati situacija za koju možda nismo spremni. I počeli smo se pripremati za ovu situaciju.
Prvo što smo učinili bilo je zakopati trupce iz tih tisuća klastera. Pronašli smo koji su se klasteri nalazili na diskovima s problematičnim firmverom koji je gubio ažuriranja podatkovne stranice. Označen sav Postgres podatkovni kod. I označili smo te poruke koje ukazuju na kršenja internih invarijanti kodom koji je dizajniran za otkrivanje oštećenja podataka.
Ovu zakrpu zajednica je praktički prihvatila bez puno rasprave, jer je u svakom konkretnom slučaju bilo očito da se nešto loše dogodilo i da je to trebalo prijaviti u log.
Nakon ovoga smo došli do toga da imamo monitoring koji skenira logove. A u slučaju sumnjivih poruka, probudi dežurnog, a dežurni to popravi.
Ali! Skeniranje zapisa je jeftina operacija na jednom klasteru i katastrofalno skupa za tisuću klastera.
Napisali smo proširenje tzv . Stvara prikaz baze podataka u kojoj možete jeftino i brzo odabrati statistiku o prošlim pogreškama. A ako trebamo probuditi dežurnog, onda ćemo to saznati bez skeniranja gigabajtnih datoteka, već izdvajanjem nekoliko bajtova iz hash tablice.
Ovo proširenje je usvojeno, na primjer, u repozitoriju za . Ako ga želite koristiti, možete ga sami instalirati. Naravno da je open source.
Ali to nije sve. Počeli smo koristiti Amcheck, proširenje koje je izradila zajednica, za pronalaženje invarijantnih kršenja u indeksima.
I otkrili smo da ako njime upravljate u velikom broju, postoje greške. Počeli smo ih popravljati. Naši su ispravci prihvaćeni.
Otkrili smo da ovo proširenje ne može analizirati GiST & GIT indekse. Natjerali smo ih da podrže. Ali zajednica još uvijek raspravlja o ovoj podršci jer je ovo relativno nova funkcionalnost i tu ima puno detalja.
Također smo otkrili da kod provjere indeksa za kršenja na voditelju replikacije, na masteru, sve radi dobro, ali na replikama, na sljedbeniku, potraga za korupcijom nije toliko učinkovita. Nisu sve invarijante provjerene. A jedna nas je invarijanta jako zasmetala. Proveli smo godinu i pol dana u komunikaciji sa zajednicom kako bismo omogućili ovu provjeru replika.
Napisali smo kod koji bi trebao slijediti sve mogu... protokole. Dugo smo razgovarali o ovoj zakrpi s Peterom Gaghanom iz Crunchy Data. Morao je malo modificirati postojeće B-stablo u Postgresu kako bi prihvatio ovu zakrpu. Bio je primljen. Sada je i provjera indeksa na replikama postala dovoljno učinkovita za otkrivanje kršenja na koja smo naišli. Odnosno, ovo su kršenja koja mogu biti uzrokovana pogreškama u firmveru diska, greškama u Postgresu, greškama u jezgri Linuxa i hardverskim problemima. Prilično opširan popis izvora problema za koje smo se pripremali.
Ali osim indeksa, postoji dio kao što je heap, tj. mjesto gdje se podaci pohranjuju. I nema mnogo invarijanti koje bi se mogle provjeriti.
Imamo proširenje koje se zove Heapcheck. Počeli smo ga razvijati. A paralelno s nama i tvrtka EnterpriseDB počela je pisati modul koji su na isti način nazvali Heapcheck. Samo što smo mi to nazvali PgHeapcheck, a oni su to jednostavno zvali Heapcheck. Imaju ga sa sličnim funkcijama, nešto drugačijim potpisom, ali s istim idejama. Ponegdje su ih malo bolje implementirali. I prije su to objavili u otvorenom kodu.
I sada razvijamo njihovo širenje, jer to više nije njihovo širenje, nego širenje zajednice. A u budućnosti, ovo je dio kernela koji će biti isporučen svima kako bi mogli unaprijed znati za buduće probleme.
Na nekim smo mjestima čak došli do zaključka da imamo lažno pozitivne rezultate u našim sustavima praćenja. Na primjer, sustav 1C. Kada koristi bazu podataka, Postgres ponekad upisuje podatke u nju koje može čitati, ali pg_dump ne može čitati.
Ova situacija izgledala je kao oštećenje našeg sustava za otkrivanje problema. Probudili su dežurnog. Dežurni je pogledao što se događa. Nakon nekog vremena došao je klijent i rekao da imam problema. Dežurni je objasnio u čemu je problem. Ali problem je u Postgres jezgri.
Našao sam raspravu o ovoj značajci. I napisao je da smo naišli na tu značajku i da je bila neugodna, osoba se budila noću kako bi shvatila što je to.
Zajednica je odgovorila: "Oh, stvarno to moramo popraviti."
Imam jednostavnu analogiju. Ako hodate u cipeli u kojoj ima zrnca pijeska, onda, u principu, možete dalje – nema problema. Ako prodajete čizme tisućama ljudi, onda napravimo čizme uopće bez pijeska. A ako će jedan od korisnika vaših cipela trčati maraton, tada želite napraviti vrlo dobre cipele, a zatim ih proširiti na sve svoje korisnike. A takvi neočekivani korisnici uvijek su u oblaku. Uvijek ima korisnika koji iskorištavaju klaster na neki originalan način. Za ovo se uvijek morate pripremiti.
Što smo naučili ovdje? Naučili smo jednostavnu stvar: najvažnije je objasniti zajednici da postoji problem. Ako je zajednica prepoznala problem, tada se javlja prirodno natjecanje u rješavanju problema. Jer svatko želi riješiti važan problem. Svi prodavači, svi hakeri shvaćaju da i sami mogu stati na te grablje, pa ih žele eliminirati.
Ako radite na problemu, ali on ne smeta nikome osim vama, ali radite na njemu sustavno i on se u konačnici smatra problemom, tada će vaš zahtjev za povlačenjem sigurno biti prihvaćen. Vaša će zakrpa biti prihvaćena, vaša poboljšanja ili čak zahtjevi za poboljšanjima bit će pregledani od strane zajednice. Na kraju dana, činimo bazu podataka boljom za druge.
Zanimljiva baza podataka je Greenplum. To je vrlo paralelna baza podataka temeljena na Postgres kodnoj bazi, s kojom sam jako dobro upoznat.
A Greenplum ima zanimljivu funkcionalnost - dodavanje optimiziranih tablica. Ovo su tablice koje možete brzo dodati. Mogu biti stupčasti ili redni.
Ali nije bilo klasteriranja, odnosno nije bilo funkcionalnosti u kojoj možete rasporediti podatke koji se nalaze u tablici prema redoslijedu koji se nalazi u jednom od indeksa.
Dečki iz taksija su mi došli i rekli: “Andrej, ti znaš Postgres. I ovdje je gotovo isto. Prebacite na 20 minuta. Uzmi i učini to.” Mislio sam da da, znam Postgres, prebacivanje na 20 minuta - moram to učiniti.
Ali ne, nije bilo 20 minuta, pisao sam to mjesecima. Na konferenciji PgConf.Russia obratio sam se Heikkiju Linakangasu iz Pivotala i pitao: “Ima li problema s ovim? Zašto nema grupiranja tablica optimiziranih za dodavanje?" On kaže: “Vi uzmite podatke. Razvrstavaš, preuređuješ. To je samo posao." Ja: "Oh, da, samo trebaš uzeti i učiniti." On kaže: "Da, potrebne su nam slobodne ruke za ovo." Mislio sam da ovo svakako moram učiniti.
I nekoliko mjeseci kasnije poslao sam zahtjev za povlačenjem koji je implementirao ovu funkcionalnost. Ovaj zahtjev za povlačenje pregledao je Pivotal zajedno sa zajednicom. Naravno, bilo je grešaka.
Ali najzanimljivija stvar je da kada je ovaj zahtjev za povlačenjem spojen, greške su pronađene u samom Greenplum-u. Otkrili smo da heap tablice ponekad prekidaju transakcijsku sposobnost kada se grupiraju. I to je stvar koju treba popraviti. I ona je na mjestu koje sam upravo dotaknuo. I moja je prirodna reakcija bila – dobro, pusti me da i ja to učinim.
Popravio sam ovu grešku. Poslan zahtjev za povlačenje popravljačima. Ubijen je.
Nakon čega se pokazalo da ovu funkcionalnost treba dobiti u Greenplum verziji za PostgreSQL 12. Odnosno, 20-minutna avantura nastavlja se novim zanimljivim dogodovštinama. Bilo je zanimljivo dotaknuti se trenutnog razvoja, gdje zajednica uvodi nove i najvažnije značajke. Smrznuto je.
Ali tu nije bio kraj. Nakon svega pokazalo se da za sve to trebamo napisati dokumentaciju.
Počeo sam pisati dokumentaciju. Srećom, naišli su dokumentaristi iz Pivotala. Engleski im je materinji jezik. Pomogli su mi oko dokumentacije. Zapravo, oni su sami prepisali ono što sam predložio na pravi engleski.
I ovdje je, čini se, avantura završila. I znate li što se tada dogodilo? Prišli su mi dečki iz taksija i rekli: “Imaju još dvije avanture, svaka po 10 minuta.” I što da im kažem? Rekao sam da ću sada dati izvješće u mjerilu, pa ćemo vidjeti vaše avanture, jer ovo je zanimljiv posao.
Što smo naučili iz ovog slučaja? Budući da je rad s otvorenim kodom uvijek rad s određenom osobom, uvijek je rad sa zajednicom. Zato što sam u svakoj pojedinoj fazi radio s nekim programerom, nekim testerom, nekim hakerom, nekim dokumentaristom, nekim arhitektom. Nisam radio s Greenplumom, radio sam s ljudima oko Greenpluma.
Ali! Postoji još jedna važna točka - to je samo posao. Odnosno dođeš, popiješ kavu, napišeš kod. Sve vrste jednostavnih invarijanti rade. Učinite to normalno - bit će dobro! I to je prilično zanimljiv posao. Postoji zahtjev za ovaj rad od Yandex.Cloud klijenata, korisnika naših klastera unutar Yandexa i izvan njega. I mislim da će se povećati broj projekata u kojima sudjelujemo i dubina našeg angažmana.
To je sve. Prijeđimo na pitanja.
Sesija pitanja
Zdravo! Imamo još jednu sesiju pitanja i odgovora. I u studiju Andrej Borodin. Ovo je osoba koja vam je upravo rekla o doprinosu Yandex.Clouda i Yandexa otvorenom kodu. Naše izvješće sada nije u potpunosti o Cloudu, ali se u isto vrijeme temeljimo na takvim tehnologijama. Bez onoga što ste učinili unutar Yandexa, ne bi bilo usluge u Yandex.Cloudu, stoga vam osobno zahvaljujem. I prvo pitanje iz emisije: “O čemu piše svaki od projekata koje ste spomenuli?”
Sigurnosni sustav u WAL-G-u napisan je u Go. Ovo je jedan od novijih projekata na kojima smo radili. Doslovno ima samo 3 godine. A baza podataka često se odnosi na pouzdanost. A to znači da su baze podataka prilično stare i obično su napisane u C-u. Projekt Postgres započeo je prije otprilike 30 godina. Onda je C89 bio pravi izbor. I na njemu piše Postgres. Modernije baze podataka kao što je ClickHouse obično su napisane u C++. Sav razvoj sustava temelji se na C i C++.
Pitanje našeg financijskog menadžera, koji je odgovoran za troškove u Cloudu: "Zašto Cloud troši novac na podršku otvorenom kodu?"
Ovdje postoji jednostavan odgovor za financijskog upravitelja. To činimo kako bismo poboljšali naše usluge. Na koji način možemo biti bolji? Možemo raditi stvari učinkovitije, brže i učiniti ih skalabilnijima. Ali za nas je ova priča prvenstveno o pouzdanosti. Na primjer, u sigurnosnom sustavu pregledavamo 100% zakrpa koje se na njega odnose. Znamo koji je kod. I lakše nam je uvoditi nove verzije u proizvodnju. To jest, prije svega, radi se o samopouzdanju, o spremnosti za razvoj i o pouzdanosti
Drugo pitanje: "Razlikuju li se zahtjevi vanjskih korisnika koji žive u Yandex.Cloudu od internih korisnika koji žive u internom oblaku?"
Profil opterećenja je, naravno, drugačiji. Ali sa stajališta mog odjela, svi posebni i zanimljivi slučajevi nastaju na nestandardnom opterećenju. Programeri s maštom, programeri koji rade neočekivano, vjerojatno će se naći i interno i eksterno. Po tom pitanju svi smo otprilike isti. I, vjerojatno, jedina važna značajka unutar Yandexovog rada baza podataka bit će da unutar Yandexa imamo učenje. U nekom trenutku neka zona dostupnosti potpuno ode u sjenu, a sve usluge Yandexa moraju nekako nastaviti funkcionirati unatoč tome. Ovo je mala razlika. Ali stvara mnogo istraživačkog razvoja na sučelju baze podataka i mrežnog skupa. Inače, vanjske i unutarnje instalacije generiraju iste zahtjeve za značajkama i slične zahtjeve za poboljšanjem pouzdanosti i performansi.
Sljedeće pitanje: "Kako se vi osobno osjećate zbog činjenice da velik dio onoga što radite koriste drugi Cloudovi?" Nećemo imenovati konkretne, ali mnogi projekti koji su napravljeni u Yandex.Cloudu koriste se u tuđim oblacima.
Ovo je cool. Prvo, to je znak da smo učinili nešto dobro. I to grebe po egu. I više smo uvjereni da smo donijeli ispravnu odluku. S druge strane, to je nada da će nam to u budućnosti donijeti nove ideje, nove zahtjeve korisnika trećih strana. Većinu problema na GitHubu stvaraju pojedinačni sysadmini, pojedinačni DBA-ovi, pojedinačni arhitekti, pojedinačni inženjeri, ali ponekad dođu ljudi sa sustavnim iskustvom i kažu da u 30% određenih slučajeva imamo taj problem i razmislimo kako ga riješiti. Tome se najviše veselimo. Radujemo se razmjeni iskustava s drugim platformama u oblaku.
Puno ste pričali o maratonu. Znam da ste trčali maraton u Moskvi. Kao rezultat? Pretekao dečke iz PostgreSQL-a?
Ne, Oleg Bartunov trči vrlo brzo. Završio je sat vremena prije mene. Sve u svemu, zadovoljan sam koliko sam daleko stigao. Za mene je sam završetak bio uspjeh. Sve u svemu, iznenađujuće je da postoji toliko mnogo trkača u postgres zajednici. Čini mi se da postoji neka vrsta veze između aerobnih sportova i želje za programiranjem sustava.
Hoćete reći da u ClickHouseu nema trkača?
Pouzdano znam da su tamo. ClickHouse je također baza podataka. Usput, Oleg mi sada piše: "Hoćemo li trčati nakon izvještaja?" Ovo je super ideja.
Još jedno pitanje iz prijenosa Nikite: "Zašto ste sami popravili grešku u Greenplum-u, a niste je dali juniorima?" Istina, nije baš najjasnije koji je bug i u kojem servisu, ali vjerojatno se misli na ovaj o kojem ste govorili.
Da, u principu se moglo dati nekome. Upravo sam promijenio šifru. I bilo je prirodno nastaviti to raditi odmah. U principu, ideja dijeljenja stručnosti s timom je dobra ideja. Definitivno ćemo podijeliti Greenplum zadatke među svim članovima naše divizije.
Kad smo kod juniora, evo jedno pitanje. Osoba je odlučila kreirati prvi commit u Postgresu. Što treba učiniti da izvrši prvi commit?
Ovo je zanimljivo pitanje: "Odakle početi?" Obično je prilično teško započeti s nečim u kernelu. U Postgresu, na primjer, postoji popis obaveza. Ali zapravo, ovo je list onoga što su pokušali učiniti, ali nisu uspjeli. To su složene stvari. I obično možete pronaći neke pomoćne programe u ekosustavu, neka proširenja koja se mogu poboljšati, koja privlače manje pozornosti programera kernela. I, shodno tome, tu ima više bodova za rast. Na programu Google Summer of code svake godine postgres zajednica izlaže mnogo različitih tema kojima bi se moglo pozabaviti. Ove godine imali smo, čini mi se, tri učenika. Jedan je čak pisao u WAL-G o temama koje su važne za Yandex. U Greenplum-u je sve jednostavnije nego u Postgres zajednici, jer Greenplum hakeri vrlo dobro tretiraju pull zahtjeve i odmah počinju pregledavati. Slanje zakrpe Postgresu je pitanje mjeseci, ali Greenplum će doći za jedan dan i vidjeti što ste učinili. Druga stvar je da Greenplum treba riješiti trenutne probleme. Greenplum se ne koristi široko, pa je vrlo teško pronaći svoj problem. A prije svega treba riješiti probleme, naravno.
Izvor: www.habr.com