Doprinos Yandexa sljedećim bazama podataka će biti pregledan.
- clickhouse
- Odiseja
- Oporavak do određenog vremena (WAL-G)
- PostgreSQL (uključujući logerrors, Amcheck, heapcheck)
- Greenplum
Video:
Zdravo svijete! Moje ime je Andrej Borodin. A ono što radim u Yandex.Cloudu je razvoj otvorenih relacijskih baza podataka u interesu Yandex.Cloud i Yandex.Cloud klijenata.
U ovom govoru ćemo govoriti o izazovima sa kojima se suočavaju otvorene baze podataka u velikom obimu. Zašto je to važno? Jer mali, mali problemi koji, kao komarci, onda postaju slonovi. Oni postaju veliki kada imate mnogo klastera.
Ali to nije glavna stvar. Događaju se nevjerovatne stvari. Stvari koje se dešavaju u jednom od milion slučajeva. A u okruženju oblaka, morate biti spremni na to, jer nevjerovatne stvari postaju vrlo vjerovatne kada nešto postoji u velikim razmjerima.
Ali! Koja je prednost otvorenih baza podataka? Činjenica je da imate teoretsku priliku da se nosite sa bilo kojim problemom. Imate izvorni kod, imate znanje programiranja. Kombiniramo i funkcionira.
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.
- Povećavate njegov ekosistem. Povećavate vjerovatnoću ranog otkrivanja greške. Povećavate pouzdanost ovog sistema. Povećavate dostupnost programera na tržištu. Vi poboljšavate ovaj softver. Već ste saradnik ako ste upravo stekli stil i nešto se petljali.
- Drugi razumljiv pristup je sponzorisanje softvera otvorenog koda. Na primjer, poznati program Google Summer of Code, kada Google plaća veliki broj studenata iz cijelog svijeta razumljivim novcem da razvijaju otvorene softverske projekte koji ispunjavaju određene licencne zahtjeve.
- Ovo je vrlo zanimljiv pristup jer omogućava softveru da se razvija bez pomjeranja fokusa sa zajednice. Google, kao tehnološki gigant, ne kaže da želimo ovu funkciju, želimo da popravimo ovu grešku i tu treba da kopamo. Google kaže: „Radi ono što radiš. Samo nastavite da radite kako ste radili i sve će biti u redu.”
- Sljedeći pristup učešću u otvorenom kodu je participacija. Kada imate problem u softveru otvorenog koda i postoje programeri, vaši programeri počinju rješavati probleme. Oni počinju da čine vašu infrastrukturu efikasnijom, a vaše programe bržim i pouzdanijim.
Jedan od najpoznatijih Yandex projekata u oblasti 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 ekosistem i razvijao ga zajedno sa drugim programerima (ne samo unutar Yandexa). A sada je ovo veliki projekat u koji je uključeno mnogo različitih kompanija.
U Yandex.Cloud-u smo kreirali ClickHouse na vrhu Yandex Object Storage-a, odnosno na vrhu pohrane u oblaku.
Zašto je ovo važno u oblaku? Jer bilo koja baza podataka radi u ovom trokutu, u ovoj piramidi, u ovoj hijerarhiji tipova memorije. Imate brze, ali male registre i jeftine velike ali spore SSD-ove, čvrste diskove i neke druge blok uređaje. A ako ste efikasni na vrhu piramide, onda imate brzu bazu podataka. ako ste efikasni na dnu ove piramide, onda imate skaliranu bazu podataka. I u tom smislu, dodavanje još jednog sloja odozdo je logičan pristup povećanju skalabilnosti baze podataka.
Kako se to može uraditi? Ovo je važna tačka u ovom izvještaju.
- Mogli bismo implementirati ClickHouse preko MDS-a. MDS je interni Yandex interfejs za skladištenje u oblaku. Složeniji je od uobičajenog S3 protokola, ali je pogodniji za blok uređaj. Bolje je za snimanje podataka. Zahtijeva više programiranja. Programeri će programirati, čak je dobro, zanimljivo.
- S3 je češći pristup koji čini sučelje jednostavnijim po cijenu manjeg prilagođavanja određenim vrstama opterećenja.
Naravno, u želji da pružimo funkcionalnost cijelom ClickHouse ekosistemu i obavimo zadatak koji je potreban unutar Yandex.Cloud-a, odlučili smo osigurati da će cijela ClickHouse zajednica imati koristi od toga. Implementirali smo ClickHouse preko S3, a ne ClickHouse preko MDS-a. A ovo je puno posla.
Reference:
"Sloj apstrakcije sistema datoteka"
"AWS SDK S3 integracija"
“Osnovna implementacija IDisk interfejsa za S3”
"Integracija motora za skladištenje dnevnika sa IDisk interfejsom"
"Podrška motora dnevnika za S3 i SeekableReadBuffer"
"Podrška za Stripe Log S3"
"Storage MergeTree početna podrška za S3"
"MergeTree puna podrška za S3"
"Podrška ReplicatedMergeTree preko S3"
“Dodajte zadane vjerodajnice i prilagođena zaglavlja za s3 pohranu”
"S3 sa dinamičkom proxy konfiguracijom"
"S3 sa proxy rezoverom"
Ovo je lista zahtjeva za povlačenje za implementaciju virtuelnog sistema datoteka u ClickHouse. Ovo je veliki broj zahtjeva za povlačenjem.
Reference:
"Optimalna implementacija DiskS3 hardlinks"
“S3 HTTP klijent — Izbjegavajte kopiranje toka odgovora u memoriju”
“Izbjegavajte kopiranje cijelog toka odgovora u memoriju u S3 HTTP
klijent"
“Mogućnost keširanja datoteka za označavanje i indeksiranje za S3 disk”
"Premjesti dijelove sa DiskLocal na DiskS3 paralelno"
Ali posao se tu nije završio. Nakon što je funkcija napravljena, bilo je potrebno još malo rada kako bi se ova funkcionalnost optimizirala.
Reference:
"Dodaj događaje SelectedRows i SelectedBytes"
"Dodaj događaje profiliranja iz S3 zahtjeva u system.events"
"Dodaj QueryTimeMicroseconds, SelectQueryTimeMicroseconds i InsertQueryTimeMicroseconds"
A onda je bilo potrebno to učiniti dijagnostičkim, postaviti monitoring i učiniti ga upravljivim.
I sve je to urađeno kako bi cijela zajednica, cijeli ClickHouse ekosistem, dobila rezultat ovog rada.
Pređimo na transakcione baze podataka, na OLTP baze podataka, koje su meni lično bliže.
Ovo je odjel za razvoj DBMS otvorenog koda. Ovi momci 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 šta radimo, je Connection Pooler u Postgresu.
Postgres je procesna baza podataka. To znači da baza podataka treba da ima što manje mrežnih veza koje upravljaju transakcijama.
S druge strane, u okruženju oblaka, tipična situacija je kada hiljadu konekcija dođe na jedan klaster odjednom. A zadatak spremišta veza je da spakuje hiljadu veza u mali broj serverskih veza.
Možemo reći da je prikupljač konekcija telefonski operater koji preuređuje bajtove tako da efikasno dođu do baze podataka.
Nažalost, ne postoji dobra ruska riječ za povezivanje bazena. Ponekad se to naziva i multiplekserske veze. Ako znate kako da nazovete prikupljač konekcija, onda mi svakako recite, vrlo rado ću govoriti ispravan ruski tehnički jezik.
Istražili smo spremišta veze koji su bili prikladni za upravljani postgres klaster. A PgBouncer je bio najbolji izbor za nas. Ali naišli smo na brojne probleme sa PgBouncer-om. Prije mnogo godina, Volodya Borodin je dao izvještaje da koristimo PgBouncer, sve nam se sviđa, ali postoje nijanse, ima na čemu raditi.
I radili smo. Rešili smo probleme na koje smo naišli, zakrpili smo Bouncer i pokušali da gurnemo pull zahteve uzvodno. Ali bilo je teško raditi s fundamentalnim single-threadingom.
Morali smo skupljati kaskade od zakrpljenih izbacivača. Kada imamo mnogo izbacivača sa jednim navojem, veze na gornjem sloju se prenose na unutrašnji sloj izbacivača. Ovo je loše vođen sistem koji je teško izgraditi i skalirati naprijed-nazad.
Došli smo do zaključka da smo kreirali svoj vlastiti pooler veza, koji se zove Odyssey. Napisali smo ga od nule.
2019. godine, na PgCon konferenciji, predstavio sam ovaj pooler zajednici programera. Sada imamo nešto manje od 2 zvjezdica na GitHubu, tj. projekat je živ, projekat je popularan.
A ako kreirate Postgres klaster u Yandex.Cloud-u, onda će to biti klaster sa ugrađenim Odyssey-om, koji se rekonfiguriše prilikom skaliranja klastera naprijed-nazad.
Šta smo naučili iz ovog projekta? Pokretanje konkurentskog projekta je uvijek agresivan korak, ekstremna je mjera kada kažemo da postoje problemi koji se ne rješavaju dovoljno brzo, ne rješavaju u vremenskim intervalima koji bi nama odgovarali. Ali ovo je efikasna 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. Oni teže sličnim ciljevima i implementiraju slične ideje, ali, naravno, sa svojim specifičnostima, koje su bliže pgagroal programerima.
Još jedan slučaj rada sa postgres zajednicom je vraćanje u određeno vrijeme. Ovo je oporavak nakon kvara, ovo je oporavak iz sigurnosne kopije.
Postoji mnogo rezervnih kopija i sve su različite. Gotovo svaki dobavljač Postgresa ima svoje vlastito backup rješenje.
Ako uzmete sve rezervne sisteme, napravite matricu karakteristika i u šali izračunate determinantu u ovoj matrici, ona će biti nula. Šta to znači? Šta ako uzmete određenu sigurnosnu kopiju, onda se ona ne može sastaviti od dijelova svih ostalih. Jedinstven je po svojoj implementaciji, jedinstven je po svojoj namjeni, jedinstven je po idejama koje su u njega ugrađene. I svi su specifični.
Dok smo radili na ovom pitanju, CitusData je pokrenuo WAL-G projekat. Ovo je backup sistem koji je napravljen s obzirom na okruženje u oblaku. Sada je CitusData već dio Microsofta. I u tom trenutku su nam se jako svidjele ideje koje su bile postavljene u početnim izdanjima WAL-G. I mi smo počeli da doprinosimo ovom projektu.
Sada postoji mnogo desetina programera u ovom projektu, ali prvih 10 koji doprinose WAL-G uključuju 6 Yandexoida. Tamo smo doneli mnogo naših ideja. I, naravno, sami smo ih implementirali, sami ih testirali, sami ih uveli u proizvodnju, sami ih koristimo, sami smišljamo kuda dalje, dok smo u interakciji sa velikom WAL-G zajednicom.
I sa naše tačke gledišta, sada je ovaj backup sistem, uključujući i naše napore, postao optimalan za okruženje u oblaku. Ovo je najbolja cijena sigurnosne kopije Postgresa u oblaku.
Šta to znači? Promovirali smo prilično veliku ideju: sigurnosna kopija bi trebala biti sigurna, jeftina za rad i što je brža za obnavljanje.
Zašto bi trebao biti jeftin za rad? Kada ništa nije pokvareno, ne biste trebali znati da imate rezervne kopije. Sve radi dobro, trošite što manje CPU-a, koristite što manje resursa na disku i šaljete što manje bajtova u mrežu kako ne biste ometali teret vaših vrijednih usluga.
A kad se sve pokvari, na primjer, admin je ispustio podatke, nešto je krenulo po zlu, a ti se hitno treba vratiti u prošlost, oporavljaš se sa svim novcem, jer želiš da ti se podaci vrate brzo i netaknuto.
I mi smo promovirali ovu jednostavnu ideju. I, čini nam se, uspjeli smo to implementirati.
Ali to nije sve. Htjeli smo još jednu malu stvar. Željeli smo mnogo različitih baza podataka. Ne koriste svi naši klijenti Postgres. Neki ljudi koriste MySQL, MongoDB. U zajednici, drugi programeri su podržali FoundationDB. I ova lista se stalno proširuje.
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 izraditi zajedno sa Postgresom sa našim sistemom za pravljenje rezervnih kopija.
Šta smo naučili iz ove priče? Naš proizvod, kao razvojni odjel, nisu linije koda, nisu izjave, nisu datoteke. Naš proizvod nije pull requests. To su ideje koje prenosimo zajednici. Ovo je tehnološka ekspertiza i kretanje tehnologije prema cloud okruženju.
Postoji takva baza podataka kao što je Postgres. Najviše mi se sviđa Postgres jezgro. Provodim dosta vremena razvijajući Postgres jezgro sa zajednicom.
Ali ovdje se mora reći da Yandex.Cloud ima internu instalaciju upravljanih baza podataka. A počelo je davno u Yandex.Mail. Stručnost koja je sada dovela do upravljanog Postgresa akumulirana je kada je pošta htjela da se preseli u Postgres.
Mail ima vrlo slične zahtjeve kao i oblak. Potrebno je da budete u mogućnosti da se povećate do neočekivanog eksponencijalnog rasta u bilo kojoj tački vaših podataka. A pošta je već bila opterećena stotinama miliona poštanskih sandučića ogromnog broja korisnika koji stalno postavljaju mnogo zahtjeva.
A ovo je bio prilično ozbiljan izazov za tim koji je razvijao Postgres. Tada su svi problemi na koje smo naišli prijavljivani zajednici. I ovi problemi su ispravljeni, a ponegde ispravljeni od strane zajednice čak i na nivou plaćene podrške za neke druge baze podataka i još bolje. Odnosno, 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še greške.
Sada je interna instalacija Postgresa nekoliko petabajta podataka. To su neki milioni zahtjeva u sekundi. Ovo su hiljade klastera. Veoma je velikih razmera.
Ali postoji nijansa. Ne živi na otmjenim mrežnim diskovima, već na prilično jednostavnom hardveru. A postoji i testno okruženje posebno za zanimljive nove stvari.
I u određenom trenutku u testnom okruženju dobili smo poruku koja ukazuje da su interne invarijante indeksa baze podataka narušene.
Invarijanta je neka vrsta odnosa za koju očekujemo da se uvijek drži.
Veoma kritična situacija za nas. To ukazuje da su neki podaci možda izgubljeni. A gubitak podataka je nešto sasvim 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 njihovo odsustvo tokom dužeg vremenskog perioda. Sigurnost podataka je religija koju prilično marljivo slijedimo.
I ovdje se javlja situacija koja sugerira da može doći do situacije za koju možda nismo spremni. I počeli smo da se pripremamo za ovu situaciju.
Prvo što smo uradili je zakopali trupce iz ovih hiljada grozdova. Pronašli smo koji se od klastera nalaze na diskovima sa problematičnim firmverom koji su gubili ažuriranja stranica sa podacima. Označen sav Postgres podatkovni kod. A one poruke koje ukazuju na kršenje internih invarijanti označili smo kodom koji je dizajniran da otkrije oštećenje podataka.
Ovu zakrpu je zajednica praktično prihvatila bez mnogo diskusije, jer je u svakom konkretnom slučaju bilo očigledno da se nešto loše dogodilo i da je potrebno prijaviti u dnevnik.
Nakon ovoga smo došli do toga da imamo monitoring koji skenira dnevnike. A u slučaju sumnjivih poruka, budi dežurnog, a dežurni ga popravlja.
Ali! Skeniranje dnevnika je jeftina operacija na jednom klasteru i katastrofalno skupa za hiljadu klastera.
Napisali smo ekstenziju tzv . Kreira prikaz baze podataka u kojoj možete jeftino i brzo odabrati statistiku o prošlim greš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 spremištu za . Ako želite da ga koristite, možete ga sami instalirati. Naravno da je otvorenog koda.
Ali to nije sve. Počeli smo da koristimo Amcheck, proširenje izgrađeno u zajednici, da pronađemo nepromenljiva kršenja u indeksima.
I otkrili smo da ako ga koristite u velikim količinama, postoje greške. Počeli smo da ih popravljamo. Naše ispravke su prihvaćene.
Otkrili smo da ova ekstenzija ne može analizirati GiST & GIT indekse. Natjerali smo ih da podrže. Ali ova podrška se još uvijek raspravlja u zajednici, jer je ovo relativno nova funkcionalnost i tu ima puno detalja.
Takođe smo otkrili da kada provjeravamo indekse za kršenja na vođi replikacije, na masteru, sve radi dobro, ali na replikama, na sljedbeniku, potraga za korupcijom nije toliko efikasna. Nisu provjerene sve invarijante. I jedna invarijanta nam je jako smetala. I proveli smo godinu i po u komunikaciji sa zajednicom kako bismo omogućili ovu provjeru replika.
Napisali smo kod koji treba da prati sve can... protokole. O ovoj zakrpi smo razgovarali neko vrijeme sa Peterom Gaghanom iz Crunchy Data. Morao je malo modificirati postojeće B-stablo u Postgresu kako bi prihvatio ovu zakrpu. Bio je prihvaćen. A sada je provjera indeksa na replikama također postala dovoljno efikasna da otkrije kršenja na koja smo naišli. Odnosno, ovo su kršenja koja mogu biti uzrokovana greškama u firmveru diska, greškama u Postgresu, greškama u Linux kernelu i hardverskim problemima. Prilično opširna lista izvora problema za koje smo se pripremali.
Ali pored indeksa, postoji i dio kao što je hrpa, odnosno mjesto gdje se pohranjuju podaci. I nema mnogo invarijanti koje bi se mogle provjeriti.
Imamo ekstenziju pod nazivom Heapcheck. Počeli smo da ga razvijamo. I paralelno sa nama, kompanija EnterpriseDB je takođe počela da piše modul, koji su na isti način nazvali Heapcheck. Samo smo mi to nazvali PgHeapcheck, a oni su ga jednostavno zvali Heapcheck. Imaju ga sa sličnim funkcijama, malo drugačijim potpisom, ali sa istim idejama. Na nekim mjestima su ih malo bolje implementirali. I ranije su to objavili u otvorenom kodu.
I sada razvijamo njihovu ekspanziju, jer to više nije njihovo širenje, već širenje zajednice. I u budućnosti, ovo je dio kernela koji će biti dostavljen svima kako bi unaprijed znali o budućim problemima.
Na nekim mjestima smo čak došli do zaključka da imamo lažne pozitivne rezultate u našim sistemima za praćenje. Na primjer, 1C sistem. Kada koristi bazu podataka, Postgres ponekad upisuje podatke u nju koje može pročitati, ali pg_dump ne može čitati.
Ova situacija je izgledala kao korupcija za naš sistem za otkrivanje problema. Probuđen je dežurni. Dežurni je pogledao šta se dešava. Nakon nekog vremena došao je klijent i rekao da imam problema. Poslužitelj je objasnio u čemu je problem. Ali problem je u Postgres jezgri.
Našao sam raspravu o ovoj funkciji. I napisao je da smo naišli na ovu osobinu i bilo je neprijatno, čovek se budio noću da bi shvatio šta je to.
Zajednica je odgovorila: "Oh, stvarno moramo to popraviti."
Imam jednostavnu analogiju. Ako hodate u cipeli koja ima zrno pijeska, onda, u principu, možete nastaviti dalje - nema problema. Ako prodajete čizme hiljadama ljudi, onda hajde da pravimo čizme bez peska uopšte. A ako će neko od korisnika vaših cipela trčati maraton, onda želite da napravite jako dobre cipele, a zatim ih proširite na sve svoje korisnike. I takvi neočekivani korisnici su uvijek u cloud okruženju. Uvijek postoje korisnici koji iskorištavaju klaster na neki originalan način. Uvek se morate pripremiti za ovo.
Šta smo naučili ovdje? Naučili smo jednostavnu stvar: najvažnije je objasniti zajednici da postoji problem. Ako je zajednica prepoznala problem, onda se javlja prirodna konkurencija da se problem riješi. Jer svi žele da reše važan problem. Svi prodavci, svi hakeri shvataju da i sami mogu stati na ove grablje, pa žele da ih eliminišu.
Ako radite na problemu, ali on nikome osim vama ne smeta, ali radite na njemu sistematski i na kraju se smatra problemom, onda će vaš zahtjev za povlačenjem sigurno biti prihvaćen. Vaša zakrpa će biti prihvaćena, vaša poboljšanja ili čak zahtjevi za poboljšanja će biti pregledani od strane zajednice. Na kraju dana, mi činimo bazu podataka boljom jedni za druge.
Zanimljiva baza podataka je Greenplum. To je vrlo paralelna baza podataka zasnovana na Postgres kodnoj bazi koju sam vrlo dobro upoznat.
A Greenplum ima zanimljivu funkcionalnost - dodaj optimizovane tabele. Ovo su tabele u koje možete brzo dodati. Mogu biti stupasti ili redovi.
Ali nije bilo grupisanja, odnosno nije bilo funkcionalnosti u kojoj možete rasporediti podatke koji se nalaze u tabeli prema redosledu koji je u jednom od indeksa.
Došli su mi momci iz taksija i rekli: “Andrey, znaš Postgres. I ovdje je skoro isto. Prebacite se na 20 minuta. Uzmi to i uradi to.” Mislio sam da da, znam Postgres, prebacivanje na 20 minuta - moram ovo da uradim.
Ali ne, nije bilo 20 minuta, pisao sam to mjesecima. Na konferenciji PgConf.Russia, prišao sam Heikkiju Linakangasu iz Pivotala i pitao: „Ima li problema s ovim? Zašto nema optimizovanog klasterisanja tabela za dodavanje?“ On kaže: „Vi uzmite podatke. Vi sortirate, preuredite. To je samo posao." Ja: “O, da, samo treba da uzmeš i uradiš.” On kaže: „Da, trebaju nam slobodne ruke da bismo ovo uradili.” Mislio sam da ovo svakako moram uraditi.
I nekoliko mjeseci kasnije poslao sam zahtjev za povlačenjem koji je implementirao ovu funkcionalnost. Ovaj zahtjev za povlačenjem je pregledao Pivotal zajedno sa zajednicom. Naravno, bilo je grešaka.
Ali najzanimljivije je to što su, kada je ovaj zahtjev za povlačenjem spojen, pronađene greške u samom Greenplum-u. Otkrili smo da tabele hrpe ponekad prekidaju transakcije kada su grupisane. I ovo je stvar koju treba popraviti. I ona je na mestu koje sam upravo dodirnuo. I moja prirodna reakcija je bila – u redu, dozvolite mi da uradim i ovo.
Ispravio sam ovu grešku. Poslao zahtjev za povlačenje popravljačima. On je ubijen.
Nakon čega se pokazalo da je ovu funkcionalnost potrebno nabaviti u Greenplum verziji za PostgreSQL 12. Odnosno, 20-minutna avantura se nastavlja novim zanimljivim avanturama. Bilo je zanimljivo dotaknuti se sadašnjeg razvoja, gdje zajednica kroji nove i najvažnije karakteristike. Zamrznuto je.
Ali tu nije bio kraj. Nakon svega, ispostavilo se da za sve ovo trebamo napisati dokumentaciju.
Počeo sam pisati dokumentaciju. Srećom, naišli su dokumentarista iz Pivotala. Engleski je njihov maternji jezik. Pomogli su mi oko dokumentacije. U stvari, oni su sami prepisali ono što sam predložio na pravi engleski.
I tu je, čini se, avantura završila. I znate li šta se tada dogodilo? Došli su mi momci iz taksija i rekli: “Imaju još dvije avanture, svaka po 10 minuta.” I šta da im kažem? Rekao sam da ću sada dati izvještaj o razmjerima, pa ćemo vidjeti vaše avanture, jer ovo je zanimljiv posao.
Šta smo naučili iz ovog slučaja? Budući da rad s otvorenim kodom uvijek znači rad sa određenom osobom, to je uvijek rad sa zajednicom. Zato što sam u svakoj fazi radio sa nekim programerom, nekim testerom, nekim hakerom, nekim dokumentaristom, nekim arhitektom. Nisam radio sa Greenplum-om, radio sam sa ljudima oko Greenpluma.
Ali! Postoji još jedna važna stvar - to je samo posao. Odnosno, dođeš, popiješ kafu, napišeš kod. Rade sve vrste jednostavnih invarijanti. Uradite to normalno - biće dobro! I to je prilično zanimljiv posao. Postoji zahtjev za ovaj posao od Yandex.Cloud klijenata, korisnika naših klastera kako unutar Yandexa tako i izvan njega. I mislim da će se povećati broj projekata u kojima učestvujemo i dubina našeg angažmana.
To je sve. Pređ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š izvještaj sada nije u potpunosti o Cloud-u, ali smo u isto vrijeme bazirani na takvim tehnologijama. Bez onoga što ste uradili unutar Yandexa, ne bi bilo usluge u Yandex.Cloud-u, pa hvala vam od mene lično. I prvo pitanje iz emisije: „Na čemu je napisan svaki od projekata koje ste spomenuli?“
Rezervni sistem u WAL-G je napisan u Go. Ovo je jedan od novijih projekata na kojima smo radili. Bukvalno ima samo 3 godine. A baza podataka se često odnosi na pouzdanost. A to znači da su baze podataka prilično stare i obično su napisane u C-u. Postgres projekat je počeo prije otprilike 30 godina. Onda je C89 bio pravi izbor. I na njemu je napisan Postgres. Modernije baze podataka kao što je ClickHouse obično su napisane na C++. Sav razvoj sistema je baziran na C i C++.
Pitanje našeg finansijskog menadžera, koji je odgovoran za troškove u Cloud-u: “Zašto Cloud troši novac na podršku otvorenog koda?”
Ovdje postoji jednostavan odgovor za finansijskog menadžera. Ovo radimo kako bismo naše usluge poboljšali. Na koje načine možemo bolje? Možemo raditi stvari efikasnije, brže i učiniti stvari skalabilnijim. Ali za nas se ova priča prvenstveno odnosi na pouzdanost. Na primjer, u sistemu rezervnih kopija pregledavamo 100% zakrpa koje se odnose na njega. Znamo šta je šifra. I ugodnije nam je uvođenje novih verzija u proizvodnju. To je, prije svega, riječ o povjerenju, o spremnosti za razvoj i o pouzdanosti
Drugo pitanje: "Da li se zahtjevi vanjskih korisnika koji žive u Yandex.Cloud-u razlikuju od internih korisnika koji žive u internom Cloud-u?"
Profil opterećenja je, naravno, drugačiji. Ali sa stanovišta mog odjela, svi posebni i zanimljivi slučajevi nastaju na nestandardnom opterećenju. Programeri sa maštom, programeri koji rade neočekivano, vjerovatno će se naći i interno i eksterno. U tom pogledu svi smo otprilike isti. I, vjerovatno, jedina važna karakteristika unutar Yandex rada baza podataka će biti da unutar Yandexa imamo učenje. U nekom trenutku, neka zona dostupnosti potpuno odlazi u sjenu, a sve usluge Yandexa moraju nekako nastaviti funkcionirati uprkos tome. Ovo je mala razlika. Ali stvara mnogo razvoja istraživanja na interfejsu baze podataka i mrežnog stoga. Inače, vanjske i interne instalacije generiraju iste zahtjeve za karakteristikama i slične zahtjeve za poboljšanje pouzdanosti i performansi.
Sljedeće pitanje: “Kako se vi lično osjećate u vezi sa činjenicom da drugi Oblaci koriste mnogo toga što radite?” Nećemo imenovati konkretne, ali mnogi projekti koji su rađeni u Yandex.Cloudu koriste se u tuđim oblacima.
Ovo je super. Prvo, to je znak da smo uradili nešto kako treba. I grebe ego. 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 trećih korisnika. Većinu problema na GitHubu kreiraju individualni sistem administratori, pojedinačni DBA, pojedinačni arhitekti, pojedinačni inženjeri, ali ponekad ljudi sa sistematskim iskustvom dođu i kažu da u 30% određenih slučajeva imamo ovaj problem i hajde da razmislimo kako da ga riješimo. Ovo je ono čemu se najviše radujemo. Radujemo se razmjeni iskustava sa drugim cloud platformama.
Mnogo ste pričali o maratonu. Znam da si trčao maraton u Moskvi. Kao rezultat? Prestigao momke iz PostgreSQL-a?
Ne, Oleg Bartunov trči veoma brzo. Završio je sat vremena ispred mene. Sve u svemu, zadovoljan sam koliko sam daleko stigao. Za mene je samo završetak bio uspjeh. Sve u svemu, iznenađujuće je da ima toliko mnogo trkača u postgres zajednici. Čini mi se da postoji neka vrsta veze između aerobnih sportova i želje za sistemskim programiranjem.
Hoćete da kažete da u ClickHouseu nema trkača?
Znam sigurno da su tamo. ClickHouse je također baza podataka. Inače, Oleg mi sada piše: "Hoćemo li da trčimo posle izveštaja?" Ovo je odlična ideja.
Još jedno pitanje iz emisije Nikite: "Zašto ste sami popravili grešku u Greenplum-u, a niste je dali juniorima?" Istina, nije baš jasno šta je greška i u kom servisu, ali vjerovatno znači onaj o kojem ste govorili.
Da, u principu, moglo se dati nekome. To je bio samo kod koji sam upravo promijenio. I bilo je prirodno nastaviti to raditi odmah. U principu, ideja o dijeljenju stručnosti s timom je dobra ideja. Svakako ćemo podijeliti Greenplum zadatke među svim članovima našeg odjela.
Pošto je riječ o juniorima, evo pitanja. Osoba je odlučila da kreira prvo urezivanje u Postgresu. Šta treba da uradi da izvrši prvo obavezivanje?
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 lista zadataka. Ali u stvari, ovo je list onoga što su pokušali učiniti, ali nisu uspjeli. To su komplikovane stvari. I obično možete pronaći neke uslužne programe u ekosistemu, neke ekstenzije koje se mogu poboljšati, koje privlače manje pažnje programera kernela. I, shodno tome, tamo ima više bodova za rast. Na Google Summer of code programu, svake godine postgres zajednica iznosi mnogo različitih tema koje bi se mogle obrađivati. Ove godine smo imali, mislim, tri studenta. 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 zahtjeve za povlačenjem i odmah počnu pregledavati. Slanje zakrpe na Postgres je pitanje mjeseci, ali Greenplum će doći za jedan dan i vidjeti šta ste uradili. Druga stvar je da Greenplum treba da riješi trenutne probleme. Greenplum nije široko rasprostranjen, pa je pronalaženje vašeg problema prilično teško. I prije svega, moramo riješiti probleme, naravno.
izvor: www.habr.com