Yandex-ek datu-base hauei egindako ekarpena aztertuko da.
- clickhouse
- Odyssey
- Denbora-puntu batera berreskuratzea (WAL-G)
- PostgreSQL (logerrors, Amcheck, heapcheck barne)
- Aran berdea
Video:
Kaixo Mundua! Nire izena Andrey Borodin da. Eta Yandex.Cloud-en egiten dudana da datu-base erlazional irekiak garatzea Yandex.Cloud eta Yandex.Cloud bezeroen interesen arabera.
Hitzaldi honetan, datu-base irekiek eskalan dituzten erronkei buruz hitz egingo dugu. Zergatik da garrantzitsua? Arazo txiki eta txikiak direlako, eltxoak bezala, gero elefante bihurtzen direnak. Handi egiten dira kluster asko dituzunean.
Baina hori ez da gauza nagusia. Gauza sinestezinak gertatzen dira. Milioi bat kasutan gertatzen diren gauzak. Eta hodei-ingurunean, horretarako prestatuta egon behar duzu, gauza sinestezina oso litekeena da zerbait eskalan dagoenean.
Baina! Zein da datu-base irekien abantaila? Kontua da edozein arazori aurre egiteko aukera teorikoa duzula. Iturburu kodea duzu, programazio ezagutzak dituzu. Konbinatzen dugu eta funtzionatzen du.
Zer ikuspegi daude kode irekiko softwarea lantzeko?
- Planteamendurik errazena softwarea erabiltzea da. Protokoloak erabiltzen badituzu, estandarrak erabiltzen badituzu, formatuak erabiltzen badituzu, kode irekiko softwarean kontsultak idazten badituzu, dagoeneko onartzen duzu.
- Bere ekosistema handitzen ari zara. Akatsen bat goiz detektatzeko probabilitatea handiagoa egiten duzu. Sistema honen fidagarritasuna areagotzen duzu. Garatzaileen erabilgarritasuna areagotzen duzu merkatuan. Software hau hobetzen duzu. Dagoeneko kolaboratzailea zara estiloa lortu eta han zerbait moldatzen baduzu.
- Beste ikuspegi ulergarri bat kode irekiko softwarea babestea da. Adibidez, Google Summer of Code programa ezaguna, Google-k mundu osoko ikasle kopuru handi bati diru ulergarria ordaintzen dionean, lizentzia-baldintza batzuk betetzen dituzten software irekiko proiektuak gara ditzaten.
- Ikuspegi oso interesgarria da softwareari eboluzionatzea ahalbidetzen duelako, komunitatetik fokua aldendu gabe. Google-k, erraldoi teknologiko gisa, ez du esaten funtzio hau nahi dugunik, akats hau konpondu nahi dugu eta hor sakondu behar dugu. Google-k dio: "Egizu egiten duzuna. Jarraitu lanean aritu zaren moduan eta dena ondo egongo daΒ».
- Kode irekian parte hartzeko hurrengo ikuspegia parte hartzea da. Kode irekiko softwarean arazo bat duzunean eta garatzaileak daudenean, zure garatzaileak arazoak konpontzen hasten dira. Zure azpiegitura eraginkorragoa egiten hasten dira, zure programak azkarragoak eta fidagarriagoak izaten.
Kode irekiko softwarearen arloan Yandex proiekturik ospetsuenetako bat ClickHouse da. Yandex.Metricak dituen erronkei erantzuteko sortu den datu-base bat da.
Eta datu-base gisa, kode irekian egin zen ekosistema bat sortzeko eta beste garatzaile batzuekin batera garatzeko (ez bakarrik Yandex-en). Eta orain proiektu handia da, eta enpresa ezberdin askok parte hartzen dute.
Yandex.Cloud-en, ClickHouse sortu dugu Yandex Object Storage-ren gainean, hau da, hodeiko biltegian.
Zergatik da garrantzitsua hodeian? Edozein datu-basek triangelu honetan, piramide honetan, memoria moten hierarkia honetan funtzionatzen duelako. Erregistro azkarrak baina txikiak eta SSD handiak baina motelak, disko gogorrak eta beste bloke-gailu batzuk dituzu. Eta piramidearen goialdean eraginkorra bazara, datu-base azkarra duzu. Piramide honen behealdean eraginkorra bazara, orduan datu-base eskalatua duzu. Eta zentzu horretan, behetik beste geruza bat gehitzea datu-basearen eskalagarritasuna areagotzeko ikuspegi logikoa da.
Nola egin liteke? Txosten honetako puntu garrantzitsu bat da.
- ClickHouse inplementatu genezake MDSren bidez. MDS Yandex-en barneko hodeiko biltegiratze interfazea da. S3 protokolo arrunta baino konplexuagoa da, baina egokiagoa da bloke gailu baterako. Hobe da datuak grabatzeko. Programazio gehiago eskatzen du. Programatzaileek programatuko dute, ona da, interesgarria da.
- S3 ohikoagoa den ikuspegi bat da, interfazea errazagoa egiten duena, lan-karga mota batzuetarako egokitzapen txikiagoaren kostuarekin.
Jakina, ClickHouse ekosistema osoari funtzionalitateak eskaini eta Yandex.Cloud-en barruan behar den zeregina egin nahian, ClickHouse komunitate osoak onura ateratzen duela ziurtatzea erabaki dugu. ClickHouse S3 baino gehiago inplementatu dugu, ez ClickHouse MDS bidez. Eta hau lan handia da.
erreferentziak:
"Fitxategi-sistemaren abstrakzio-geruza"
"AWS SDK S3 integrazioa"
"IDisk interafce-ren oinarrizko ezarpena S3rako"
"Erregistroak biltegiratzeko motorren integrazioa IDisk interfazearekin"
"S3 eta SeekableReadBuffer-en erregistro-motorraren laguntza"
"Storage Stripe Log S3 laguntza"
"Storage MergeTree-ren hasierako laguntza S3rako"
"MergeTree-k S3rako laguntza osoa"
"Onartu ReplicatedMergeTree S3 baino gehiago"
"Gehitu kredentzial lehenetsiak eta goiburu pertsonalizatuak s3 biltegiratzeko"
"S3 proxy konfigurazio dinamikoarekin"
"S3 proxy ebazlearekin"
ClickHouse-n fitxategi sistema birtual bat ezartzeko tira-eskaera zerrenda bat da. Hau tira eskaera kopuru handia da.
erreferentziak:
"DiskS3-k esteka gogorrak inplementazio optimoa du"
"S3 HTTP bezeroa - Saihestu erantzun-jarioa memorian kopiatzea"
"Saihestu erantzun-korronte osoa memorian kopiatzea S3 HTTP-n
bezeroa"
"S3 diskorako fitxategiak markatzeko eta indexatzeko gaitasuna"
"Mugitu piezak DiskLocaletik DiskS3ra paraleloki"
Baina lana ez zen hor amaitu. Eginbidea egin ondoren, lan gehiago behar izan zen funtzionalitate hori optimizatzeko.
erreferentziak:
"Gehitu SelectedRows eta SelectedBytes gertaerak"
"Gehitu profil-gertaerak S3 eskaeratik system.events-era"
"Gehitu QueryTimeMicroseconds, SelectQueryTimeMicroseconds eta InsertQueryTimeMicroseconds"
Eta orduan beharrezkoa zen diagnostikatu egin, monitorizazioa ezarri eta kudeatu.
Eta hori guztia egin zen komunitate osoak, ClickHouse ekosistema osoak, lan honen emaitza jaso zezan.
Goazen transakzio datu-baseetara, OLTP datu-baseetara, pertsonalki hurbilago daudenak.
Hau kode irekiko DBMS garapen dibisioa da. Mutil hauek kaleko magia egiten ari dira datu-base ireki transakzionalak hobetzeko.
Proiektuetako bat, nola eta zer egiten dugun hitz egin dezakegun adibide bat erabiliz, Connection Pooler da Postgres-en.
Postgres prozesu datu-base bat da. Horrek esan nahi du datu-baseak transakzioak kudeatzen dituzten sare-konexio gutxien izan behar dituela.
Bestalde, hodei-ingurunean, ohiko egoera bat da mila konexio aldi berean kluster batera iristen direnean. Eta konexio-biltzailearen zeregina mila konexio zerbitzari-konexio kopuru txiki batean biltzea da.
Esan dezakegu konexio-biltzailea dela byteak berrantolatzen dituen telefono-operatzailea dela datu-basera eraginkortasunez irits daitezen.
Zoritxarrez, ez dago errusierazko hitz onik konexio pooler izendatzeko. Batzuetan multiplexer konexio deitzen zaio. Konexio-biltzaileari nola deitu behar diozun badakizu, esango didazula oso pozik egongo naiz errusiar hizkuntza tekniko egokia hitz egitea.
Kudeatutako postgres kluster baterako egokiak ziren konexio-biltzaileak ikertu ditugu. Eta PgBouncer izan zen guretzat aukerarik onena. Baina PgBouncer-ekin hainbat arazo topatu ditugu. Duela urte asko, Volodya Borodinek PgBouncer erabiltzen dugula txostenak eman zituen, dena gustatzen zaigu, baina Γ±abardurak daude, bada lan egiteko.
Eta lan egin genuen. Aurkitu genituen arazoak konpondu genituen, Bouncer-en adabakia jarri genuen eta tira-eskaerak korronte gora bultzatzen saiatu ginen. Baina oinarrizko hari bakarrarekin lan egitea zaila zen.
Adabakitako Bouncers-en kaskadak bildu behar izan genituen. Hari bakarreko Bouncers asko ditugunean, goiko geruzako konexioak Bouncers barruko geruzara transferitzen dira. Gaizki kudeatutako sistema bat da, zaila da eraikitzea eta aurrera eta aurrera eskalatzea.
Odisea deitzen den gure konexio pooler sortu genuela ondorioztatu genuen. Hutsetik idatzi genuen.
2019an, PgCon konferentzian, biltzaile hau garatzaileen komunitateari aurkeztu nion. Orain 2 izar baino gutxiago ditugu GitHub-en, hau da, proiektua bizirik dago, proiektua ezaguna da.
Eta Yandex.Cloud-en Postgres kluster bat sortzen baduzu, Odyssey integratua duen kluster bat izango da, klusterra atzera edo aurrera eskalatzean birkonfiguratzen dena.
Zer ikasi dugu proiektu honetatik? Lehian dagoen proiektu bat martxan jartzea beti da pauso oldarkorra, muturreko neurria da nahikoa azkar konpontzen ez diren arazoak daudela esaten dugunean, komeni zaigun denbora tarteetan konpontzen ez direla. Baina hau neurri eraginkorra da.
PgBouncer azkarrago garatzen hasi zen.
Eta orain beste proiektu batzuk agertu dira. Adibidez, pgagroal, Red Hat-eko garatzaileek garatutakoa. Antzeko helburuak bilatzen dituzte eta antzeko ideiak ezartzen dituzte, baina, noski, beren berezitasunekin, pgagroal garatzaileengandik hurbilago daudenak.
Postgres komunitatearekin lan egiteko beste kasu bat denbora-puntu bat berreskuratzen ari da. Hau hutsegite baten ondoren berreskuratzea da, hau babeskopia batetik berrezartzea da.
Babeskopia asko daude eta guztiak desberdinak dira. Ia Postgres saltzaile guztiek dute bere babeskopia irtenbidea.
Backup-sistema guztiak hartzen badituzu, ezaugarri-matrize bat sortu eta txantxetan matrize honetako determinantea kalkulatzen baduzu, zero izango da. Zer esan nahi du honek? Zer gertatzen da segurtasun-kopia fitxategi zehatz bat hartzen baduzu, ezin da beste guztien zatietatik muntatu. Bere inplementazioan, berezia da bere helburuan, berezia da bertan txertatuta dauden ideietan. Eta denak zehatzak dira.
Gai hau lantzen ari ginela, CitusData-k WAL-G proiektua jarri zuen martxan. Hau hodei inguruneari begira egindako babeskopia sistema da. Orain CitusData Microsoft-en parte da dagoeneko. Eta momentu horretan, asko gustatu zitzaizkigun WAL-G-ren hasierako bertsioetan ezarritako ideiak. Eta proiektu honetan laguntzen hasi ginen.
Orain dozenaka garatzaile daude proiektu honetan, baina WAL-G-ren 10 laguntzaile nagusien artean 6 Yandexoid daude. Gure ideia asko ekarri ditugu bertara. Eta, noski, guk geuk inplementatu ditugu, geuk probatu, produkziora zabaldu, guk geuk erabiltzen ditugu, guk geuk asmatzen dugu nora mugitu, WAL-G komunitate handiarekin elkarreraginean.
Eta gure ikuspuntutik, orain segurtasun-kopia sistema hau, gure ahaleginak kontuan hartuta barne, hobetu da hodeiko ingurune baterako. Hau da Postgres hodeian babeskopia egiteko kosturik onena.
Zer esan nahi du? Ideia handi samarra sustatzen ari ginen: babeskopiak segurua izan behar du, funtzionatzeko merkea eta leheneratzeko ahalik eta azkarren.
Zergatik izan behar da merkea funtzionatzea? Ezer apurtzen ez denean, ez zenuke jakin behar babeskopiak dituzunik. Dena ondo funtzionatzen du, CPU ahalik eta gutxien alferrik galtzen duzu, zure disko-baliabideetatik ahalik eta gutxien erabiltzen dituzu eta sarera ahalik eta byte gutxien bidaltzen dituzu zure zerbitzu baliotsuen karga ez oztopatzeko.
Eta dena apurtzen denean, adibidez, administratzaileak datuak bota ditu, zerbait gaizki joan da, eta premiazko iraganera itzuli behar duzu, diru guztiarekin berreskuratzen duzu, zure datuak azkar eta oso-osorik itzuli nahi dituzulako.
Eta ideia sinple hau sustatu genuen. Eta, iruditzen zaigu, gauzatzea lortu dugula.
Baina hori ez da guztia. Gauza txiki bat gehiago nahi genuen. Hainbat datu-base nahi genituen. Gure bezero guztiek ez dute Postgres erabiltzen. Batzuek MySQL, MongoDB erabiltzen dute. Komunitatean, beste garatzaile batzuek FoundationDB onartzen dute. Eta zerrenda hau etengabe zabaltzen ari da.
Komunitateari gustatzen zaio datu-basea hodeian kudeatutako ingurune batean exekutatzen ari den ideia. Eta garatzaileek beren datu-baseak mantentzen dituzte, eta Postgresekin batera babeskopiak modu uniformean egin daitezke gure babeskopia sistemarekin.
Zer ikasi dugu istorio honetatik? Gure produktua, garapen dibisio gisa, ez dira kode lerroak, ez dira adierazpenak, ez dira fitxategiak. Gure produktua ez dira tira eskaerak. Hauek dira komunitateari helarazten dizkiogun ideiak. Espezializazio teknologikoa eta teknologiaren mugimendua hodeiko ingurune batera da.
Postgres bezalako datu-base bat dago. Postgres nukleoa gustatzen zait gehien. Denbora asko ematen dut Postgres nukleoa komunitatearekin garatzen.
Baina hemen esan behar da Yandex.Cloud-ek kudeatutako datu-baseen barne-instalazioa duela. Eta aspaldi hasi zen Yandex.Mail-en. Orain Postgres kudeatua ekarri duen espezializazioa posta Postgresera eraman nahi zuenean metatu zen.
Mailak hodeiaren oso antzeko baldintzak ditu. Zure datuen edozein puntutan ustekabeko hazkunde esponentziala eskalatu ahal izateko behar zaitu. Eta posta-ek zama handia zuen, etengabe eskaera asko egiten dituzten erabiltzaile kopuru handi baten ehunka milioi postontziekin.
Eta hau nahiko erronka serioa zen Postgres garatzen ari zen taldearentzat. Orduan, aurkitu genituen arazoak komunitateari jakinarazi zizkion. Eta arazo horiek zuzendu egin ziren, eta komunitateak zuzendu zituen leku batzuetan nahiz eta beste datu-base batzuetarako ordaindutako laguntza mailan eta are hobeto. Hau da, gutun bat bidal diezaiokezu PgSQL hackerri eta erantzun bat jaso dezakezu 40 minutuko epean. Datu-base batzuetan ordaindutako laguntzak zure akatsak baino lehentasunezko gauza gehiago daudela pentsa dezake.
Orain Postgres-en barne-instalazioa datu petabyte batzuk dira. Hauek segundoko milioika eskaera dira. Hauek milaka kluster dira. Oso eskala handikoa da.
Baina badago Γ±abardura bat. Ez da sareko unitate dotoreetan bizi, hardware nahiko sinplean baizik. Eta gauza berri interesgarrietarako bereziki proba-ingurune bat dago.
Eta proba-ingurunean une jakin batean datu-baseen indizeen barne aldaezinak urratu zirela adierazten zuen mezu bat jaso genuen.
Aldaezina beti edukitzea espero dugun harreman mota bat da.
Oso egoera kritikoa guretzat. Datu batzuk galdu egin direla adierazten du. Eta datuak galtzea guztiz hondamendia da.
Kudeatutako datu-baseetan jarraitzen dugun ideia orokorra da ahalegina eginda ere zaila izango dela datuak galtzea. Nahita kentzen badituzu ere, denbora luzez haien ausentzia baztertu beharko duzu. Datuen segurtasuna ardura handiz jarraitzen dugun erlijioa da.
Eta hemen egoera bat sortzen da, agian prest gauden egoera bat egon daitekeela iradokitzen duena. Eta egoera honetarako prestatzen hasi ginen.
Egin genuen lehenengo gauza milaka multzo hauetako enborrak lurperatzea izan zen. Datu-orrien eguneraketak galtzen ari ziren firmware arazotsuak dituzten diskoetan kokatuta zeuden klusterrak aurkitu ditugu. Postgres datu-kode guztiak markatu ditu. Eta barne aldaezinen urraketak adierazten dituzten mezu horiek datuen ustelkeria detektatzeko diseinatutako kodearekin markatu ditugu.
Adabaki hau komunitateak eztabaida handirik gabe onartu zuen ia, kasu zehatz bakoitzean nabaria baitzen zerbait txarra gertatu zela eta erregistroan jakinarazi behar zela.
Honen ostean, erregistroak aztertzen dituen monitorizazioa daukagula iritsi ginen. Eta mezu susmagarrien kasuan, betebeharra esnatzen du, eta betebeharra konpontzen du.
Baina! Erregistroak eskaneatzea eragiketa merkea da kluster batean eta hondamendia garestia mila klusterrentzat.
izeneko luzapena idatzi genuen . Datu-basearen ikuspegi bat sortzen du, eta bertan iraganeko erroreei buruzko estatistikak merke eta azkar hauta ditzakezu. Eta betebeharko ofiziala esnatu behar badugu, gigabyte fitxategiak eskaneatu gabe jakingo dugu honi buruz, baina hash taulatik byte batzuk ateraz.
Luzapen hau hartu da, adibidez, for biltegian . Erabili nahi baduzu, zuk zeuk instala dezakezu. Noski kode irekia da.
Baina hori ez da guztia. Amcheck erabiltzen hasi ginen, komunitateak eraikitako luzapena, indizeetan urraketa aldaezinak aurkitzeko.
Eta jakin dugu eskalan funtzionatzen baduzu, akatsak daudela. Haiek konpontzen hasi ginen. Gure zuzenketak onartu dira.
Luzapen honek ezin dituela GiST eta GIT indizeak aztertu aurkitu dugu. Guk laguntza eman genien. Baina laguntza hau komunitatean eztabaidatzen ari da oraindik, funtzionalitate nahiko berria delako eta xehetasun asko daudelako.
Eta, gainera, aurkitu dugu erreplikaren lidergoan, maisuan, dena ondo funtzionatzen duela, baina errepliketan, jarraitzailean, ustelkeriaren bilaketa ez dela hain eraginkorra. Aldagabe guztiak ez dira egiaztatzen. Eta aldaezin batek asko gogaitzen gintuen. Eta urte eta erdi eman genuen komunitatearekin komunikatzen, errepliken egiaztapen hau gaitzeko.
Protokolo guztiak jarraitu behar dituen kodea idatzi dugu. Crunchy Data-ko Peter Gaghanekin denbora dezente eztabaidatu genuen adabaki hau. Postgres-en zegoen B zuhaitza apur bat aldatu behar izan zuen adabaki hau onartzeko. Onartua izan zen. Eta orain errepliketako indizeak egiaztatzea ere nahikoa eraginkorra bihurtu da aurkitu ditugun urraketak detektatzeko. Hau da, hauek dira diskoaren firmwareko akatsek, Postgres-eko akatsek, Linux nukleoko akatsek eta hardware-arazoek eragin ditzaketen urraketak. Prestatzen ari ginen arazoen iturrien zerrenda nahiko zabala.
Baina indizeez gain, pila bat bezalako zati bat dago, hau da, datuak gordetzen diren lekua. Eta ez dago aldaezin asko egiaztatu ahal izateko.
Heapcheck izeneko luzapena dugu. Garatzen hasi ginen. Eta paraleloan, gurekin batera, EnterpriseDB konpainia ere modulu bat idazten hasi zen, Heapcheck deitzen zioten modu berean. Guk bakarrik PgHeapcheck deitzen genion, eta Heapcheck deitzen zioten. Antzeko funtzioekin dute, sinadura apur bat ezberdina, baina ideia berdinekin. Leku batzuetan apur bat hobeto inplementatu zituzten. Eta aurretik kode irekian argitaratu zuten.
Eta orain haien hedapena garatzen ari gara, jada ez baita haien hedapena, komunitatearen hedapena baizik. Eta etorkizunean, denei emango zaien nukleoaren zati bat da, etorkizuneko arazoen berri aldez aurretik jakin dezaten.
Zenbait tokitan, gure monitorizazio sistemetan positibo faltsuak ditugula ondorioztatu genuen. Adibidez, 1C sistema. Datu-base bat erabiltzean, Postgres-ek batzuetan irakur ditzakeen datuak idazten ditu, baina pg_dump-ek ezin du irakurri.
Egoera honek ustelkeria zirudien gure arazoak detektatzeko sistemari. Begiraleko ofiziala esnatu zen. Begiraleko ofizialak zer gertatzen ari zen begiratu zuen. Denbora pixka bat igaro ondoren, bezero bat etorri zen eta arazoak nituela esan zuen. Arazoa zein den azaldu zuen arduradunak. Baina arazoa Postgres nukleoan dago.
Ezaugarri honi buruzko eztabaida bat aurkitu dut. Eta ezaugarri honekin topo egin genuela idatzi zuen eta desatsegina zela, pertsona bat gauez esnatu zen zer zen jakiteko.
Komunitateak erantzun zuen: "Oh, benetan konpondu behar dugu".
Analogia sinple bat dut. Hondar ale bat duen oinetako batean ibiltzen bazara, printzipioz, aurrera egin dezakezu - ez dago arazorik. Milaka pertsonari botak saltzen badiezu, egin ditzagun harearik gabeko botak. Eta zure oinetakoen erabiltzaileren batek maratoi bat egingo badu, orduan oso oinetako onak egin nahi dituzu eta, ondoren, zure erabiltzaile guztiei eskalatu. Eta ustekabeko erabiltzaile horiek hodeiko ingurunean daude beti. Beti daude klusterra modu original batean ustiatzen duten erabiltzaileak. Beti prestatu behar duzu horretarako.
Zer ikasi dugu hemen? Gauza sinple bat ikasi dugu: garrantzitsuena komunitateari arazo bat dagoela azaltzea da. Komunitateak arazoa aitortu badu, orduan lehia naturala sortzen da arazoa konpontzeko. Denek arazo garrantzitsu bat konpondu nahi dutelako. Saltzaile guztiek, hacker guztiek ulertzen dute beraiek zapal dezaketela rake hau, beraz, ezabatu nahi dituzte.
Arazo batean lanean ari bazara, baina inor ez baduzu molestatzen, baina sistematikoki lan egiten baduzu eta azkenean arazotzat hartzen baduzu, zure tira eskaera onartuko da behin betiko. Zure adabakia onartuko da, zure hobekuntzak edo hobekuntza eskaerak komunitateak berrikusiko ditu. Azkenean, datu-basea hobetzen dugu elkarren artean.
Datu-base interesgarri bat Greenplum da. Oso ondo ezagutzen dudan Postgres kode-basean oinarritutako datu-base oso paraleloa da.
Eta Greenplum-ek funtzionalitate interesgarriak ditu: gehitu taula optimizatuak. Hauek azkar gehi ditzakezun taulak dira. Zutabeak edo errenkadakoak izan daitezke.
Baina ez zegoen clustering, hau da, ez zegoen funtzionalitaterik, non taulan kokatutako datuak indizeetako batean dagoen ordenaren arabera antolatzeko.
Taxiko mutilak etorri zitzaizkidan eta esan zidan: βAndrey, ezagutzen duzu Postgres. Eta hemen ia berdina da. Aldatu 20 minutura. Hartu eta eginΒ». Pentsatu nuen baietz, ezagutzen dudala Postgres, 20 minutuz aldatzen - hau egin behar dut.
Baina ez, ez zen 20 minutu izan, hilabeteetan idatzi nuen. PgConf.Russia konferentzian, Pivotaleko Heikki Linakangasengana jo nuen eta galdetu nion: βArazorik al dago honekin? Zergatik ez dago eranskin optimizatutako taula multzorik?" Honela dio: βZuk hartzen dituzu datuak. Ordenatzen duzu, berrantolatzen duzu. Lan bat besterik ez daΒ». Ni: "A, bai, hartu eta egin besterik ez duzu behar". Berak dio: "Bai, esku libreak behar ditugu hau egiteko". Pentsatu nuen behin betiko hau egin behar nuela.
Eta hilabete batzuk geroago funtzionalitate hau inplementatzen zuen pull request bat aurkeztu nuen. Pivotal-ek komunitatearekin batera aztertu zuen tira-eskaera hau. Jakina, akatsak zeuden.
Baina interesgarriena da tira eskaera hau batu zenean Greenplum-en bertan akatsak aurkitu zirela. Aurkitu dugu pilatutako taulak batzuetan transakzionaltasuna apurtzen dutela multzokatuta daudenean. Eta hori konpondu beharreko gauza da. Eta ukitu berri dudan tokian dago. Eta nire erreakzio naturala izan zen: ados, utz iezadazu hau ere egiten.
Akats hau konpondu dut. Tiraketa eskaera bat bidali die konpontzaileei. Hil zuten.
Horren ostean, funtzionalitate hau PostgreSQL 12rako Greenplum bertsioan lortu behar dela ikusi zen. Hau da, 20 minutuko abenturak abentura interesgarri berriekin jarraitzen du. Interesgarria izan zen egungo garapena ukitzea, non komunitatea ezaugarri berriak eta garrantzitsuenak mozten ari den. Izoztuta dago.
Baina ez zen hor amaitu. Azken finean, hori guztiaren dokumentazioa idatzi behar genuela atera zen.
Dokumentazioa idazten hasi nintzen. Zorionez, Pivotaleko dokumentalistak etorri ziren. Ingelesa da euren jatorrizko hizkuntza. Dokumentazioan lagundu didate. Izan ere, beraiek berridatzi zuten nik proposatutakoa benetako ingelesera.
Eta hemen, dirudienez, abentura amaitu zen. Eta ba al dakizu zer gertatu zen orduan? Taxiko mutilak etorri zitzaizkidan eta esan zuten: "Oraindik bi abentura daude, bakoitza 10 minutukoa". Eta zer esan behar diet? Esan nuen orain erreportaje bat emango dudala eskalan, gero zure abenturak ikusiko ditugula, lan interesgarria delako.
Zer ikasi dugu kasu honetatik? Kode irekiarekin lan egitea beti pertsona zehatz batekin lan egitea delako, beti komunitatearekin lan egitea da. Etapa guztietan garatzaile batzuekin, probatzaile batzuekin, hacker batzuekin, dokumentalista batzuekin, arkitekto batzuekin lan egin nuelako. Ez nuen Greenplum-ekin lan egin, Greenplum inguruko jendearekin lan egin nuen.
Baina! Bada beste puntu garrantzitsu bat - lana besterik ez da. Hau da, etortzen zara, kafea edan, kodea idatzi. Era guztietako aldaezin sinpleek funtzionatzen dute. Egin normalean - ondo egongo da! Eta nahiko lan interesgarria da. Yandex.Cloud bezeroek, Yandex barruko zein kanpoko gure klusterren erabiltzaileek lan hau egiteko eskaera egin dute. Eta uste dut parte hartzen dugun proiektuen kopurua handituko dela eta gure inplikazioaren sakontasuna ere handituko dela.
Hori da dena. Goazen galderetara.
Galderak saioa
Kaixo! Beste galdera-erantzun saio bat dugu. Eta Andrei Borodin estudioan. Hau da Yandex.Cloud eta Yandex-ek kode irekiari egindako ekarpena kontatu berri dizun pertsona. Orain gure txostena ez da guztiz Hodeiari buruzkoa, baina, aldi berean, horrelako teknologietan oinarritzen gara. Yandex-en egin zenuena gabe, ez litzateke zerbitzurik egongo Yandex.Cloud-en, beraz, eskerrik asko pertsonalki. Eta emankizuneko lehen galdera: βZertan dago idatzita aipatu dituzun proiektuetako bakoitza?β.
WAL-G-n babeskopia-sistema Go-n idatzita dago. Hau da landu dugun proiektu berrienetako bat. Literalki 3 urte besterik ez ditu. Eta datu-base bat fidagarritasunari buruzkoa da askotan. Eta horrek esan nahi du datu-baseak nahiko zaharrak direla eta normalean C-n idatzita daudela. Postgres proiektua duela 30 bat urte hasi zen. Orduan C89 aukera egokia izan zen. Eta Postgres idatzita dago. ClickHouse bezalako datu-base modernoagoak C++-n idatzi ohi dira. Sistemaren garapen guztia C eta C++-en inguruan oinarritzen da.
Gure finantza-kudeatzaileak, Cloud-en gastuen arduraduna denaren galdera bat: "Zergatik gastatzen du Cloud-ek dirua kode irekian laguntzeko?"
Finantza-kudeatzailearentzat erantzun sinple bat dago hemen. Hau egiten dugu gure zerbitzuak hobetzeko. Zein modutan egin dezakegu hobeto? Gauzak eraginkorrago, azkarrago eta eskalagarriagoak egin ditzakegu. Baina guretzat, istorio hau fidagarritasunari buruzkoa da batez ere. Adibidez, babeskopia-sistema batean aplikatzen zaizkion adabakien % 100 berrikusten dugu. Badakigu zein den kodea. Eta erosoago gaude bertsio berriak produkziora zabaltzen. Hau da, lehenik eta behin, konfiantzaz, garapenerako prestutasunaz eta fidagarritasunaz
Beste galdera bat: "Yandex.Cloud-en bizi diren kanpoko erabiltzaileen eskakizunak desberdinak al dira barne Hodeian bizi diren barne erabiltzaileen aldean?"
Karga-profila, noski, ezberdina da. Baina nire sailaren ikuspuntutik, kasu berezi eta interesgarri guztiak estandar ez den karga batean sortzen dira. Irudimena duten garatzaileak, ustekabekoak egiten dituzten garatzaileak, barrutik zein kanpotik aurki daitezke. Alde horretatik, denok gara gutxi gorabehera berdinak. Eta, ziurrenik, Yandex datu-baseen funtzionamenduaren barruan dagoen ezaugarri garrantzitsu bakarra Yandex-en barruan irakaskuntza bat dugula izango da. Noizbait, erabilgarritasun-eremu batzuk erabat itzalean geratzen dira, eta Yandex zerbitzu guztiek nolabait funtzionatzen jarraitu behar dute hala ere. Hau diferentzia txiki bat da. Baina datu-basearen eta sareko pilaren interfazean ikerketa-garapen handia sortzen du. Bestela, kanpoko eta barneko instalazioek ezaugarrien eskaera berdinak eta fidagarritasuna eta errendimendua hobetzeko antzeko eskaerak sortzen dituzte.
Hurrengo galdera: "Zer sentitzen zara pertsonalki egiten duzunaren zati handi bat beste Hodei batzuek erabiltzen dutela?" Ez dugu zehatzik izendatuko, baina Yandex.Cloud-en egin ziren proiektu asko besteen hodeietan erabiltzen dira.
Hau polita da. Lehenik eta behin, zerbait ondo egin dugun seinale da. Eta egoa urratzen du. Eta seguruago gaude erabaki zuzena hartu dugula. Bestalde, hau da etorkizunean ideia berriak ekarriko dizkiguten itxaropena, hirugarren erabiltzaileen eskaera berriak. GitHub-eko arazo gehienak sistema-administratzaile indibidualek, DBA indibidualek, arkitekto indibidualek, ingeniari indibidualek sortzen dituzte, baina batzuetan esperientzia sistematikoa duten pertsonak etortzen dira eta kasu batzuen %30ean arazo hau dugula eta pentsa dezagun nola konpondu. Hau da gehien itxaroten duguna. Espero dugu hodeiko beste plataforma batzuekin esperientziak partekatzea.
Asko hitz egin duzu maratoiaz. Badakit Moskun maratoi bat egin zenuela. Hori dela eta? PostgreSQL-ko mutilak gainditu dituzu?
Ez, Oleg Bartunov oso azkar dabil. Ni baino ordubete lehenago amaitu zuen. Orokorrean, pozik nago noraino iritsi naizenarekin. Niretzat, amaitzea besterik ez zen lorpen bat. Orokorrean, harrigarria da postgres komunitatean hainbeste korrikalari egotea. Kirol aerobikoen eta sistemen programazio nahiaren artean nolabaiteko harremana dagoela iruditzen zait.
ClickHousen lasterkaririk ez dagoela esaten al duzu?
Ziur badakit hor daudela. ClickHouse datu-base bat ere bada. Bide batez, orain Oleg idazten ari zait: "Txostenaren ondoren korrika egitera joango al gara?" Ideia bikaina da hau.
Nikitaren emankizuneko beste galdera bat: "Zergatik konpondu zenuten Greenplum-en akatsa zuk zeuk eta ez zien juniorrei eman?" Egia da, ez dago oso argi zein den akatsa eta zein zerbitzutan, baina ziurrenik hitz egin duzuna esan nahi du.
Bai, printzipioz, norbaiti eman zitekeen. Aldatu berri dudan kodea besterik ez da. Eta naturala zen berehala egiten jarraitzea. Printzipioz, taldearekin esperientzia partekatzeko ideia ona da. Zalantzarik gabe, Greenplum zereginak gure dibisioko kide guztien artean partekatuko ditugu.
Jubenilez ari garenez, hona galdera bat. Pertsonak Postgres-en lehen konpromisoa sortzea erabaki zuen. Zer egin behar du lehen konpromisoa hartzeko?
Galdera interesgarria da: "Non hasi?" Normalean nahiko zaila da nukleoko zerbaitekin hastea. Postgres-en, adibidez, egiteko zerrenda bat dago. Baina, hain zuzen ere, hau egiten saiatu zirenaren fitxa da, baina ez zuten lortu. Gauza konplexuak dira. Eta normalean erabilgarritasun batzuk aurki ditzakezu ekosisteman, hobetu daitezkeen luzapen batzuk, nukleoko garatzaileen arreta gutxiago erakartzen dutenak. Eta, horren arabera, hazkuntzarako puntu gehiago daude hor. Google Summer of code programan, urtero, postgres komunitateak jorratu daitezkeen hainbat gai planteatzen ditu. Aurten, nire ustez, hiru ikasle izan ditugu. Batek WAL-G-n idatzi zuen Yandexentzat garrantzitsuak diren gaiei buruz. Greenplum-en, dena Postgres komunitatean baino sinpleagoa da, Greenplum-eko hacker-ek tira-eskaerak oso ondo tratatzen dituztelako eta berehala hasten direlako berrikusten. Postgres-era adabaki bat bidaltzea hilabeteko kontua da, baina Greenplum egun batean etorriko da eta ikusiko duzu zer egin duzun. Beste gauza bat da Greenplum-ek egungo arazoak konpondu behar dituela. Greenplum ez da oso erabilia, beraz, zure arazoa aurkitzea nahiko zaila da. Eta lehenik eta behin, arazoak konpondu behar ditugu, noski.
Iturria: www.habr.com