Yandex se bydrae tot die volgende databasisse sal hersien word.
- klikhuis
- Odyssey
- Herstel tot 'n tydstip (WAL-G)
- PostgreSQL (insluitend logerrors, Amcheck, heapcheck)
- Groenpruim
Video:
Hello Wêreld! My naam is Andrey Borodin. En wat ek by Yandex.Cloud doen, is om oop relasionele databasisse te ontwikkel in die belang van Yandex.Cloud en Yandex.Cloud-kliënte.
In hierdie praatjie sal ons praat oor die uitdagings wat oop databasisse op skaal in die gesig staar. Hoekom is dit belangrik? Want klein, klein probleme wat, soos muskiete, dan olifante word. Hulle word groot as jy baie trosse het.
Maar dit is nie die belangrikste ding nie. Ongelooflike dinge gebeur. Dinge wat in een uit 'n miljoen gevalle gebeur. En in 'n wolkomgewing moet jy daarop voorbereid wees, want ongelooflike dinge word hoogs waarskynlik wanneer iets op skaal bestaan.
Maar! Wat is die voordeel van oop databasisse? Die feit is dat jy 'n teoretiese geleentheid het om enige probleem te hanteer. Jy het die bronkode, jy het programmeringskennis. Ons kombineer dit en dit werk.
Watter benaderings is daar om aan oopbronsagteware te werk?
- Die mees eenvoudige benadering is om sagteware te gebruik. As jy protokolle gebruik, as jy standaarde gebruik, as jy formate gebruik, as jy navrae in oopbronsagteware skryf, dan ondersteun jy dit reeds.
- Jy maak sy ekosisteem groter. Jy maak die waarskynlikheid van vroeë opsporing van 'n fout groter. Jy verhoog die betroubaarheid van hierdie stelsel. Jy verhoog die beskikbaarheid van ontwikkelaars in die mark. Jy verbeter hierdie sagteware. Jy is reeds 'n bydraer as jy net opgehou het om styl te kry en met iets daar gepeuter het.
- Nog 'n verstaanbare benadering is die borg van oopbronsagteware. Byvoorbeeld, die bekende Google Summer of Code-program, wanneer Google 'n groot aantal studente van regoor die wêreld verstaanbare geld betaal sodat hulle oop sagtewareprojekte ontwikkel wat aan sekere lisensievereistes voldoen.
- Dit is 'n baie interessante benadering, want dit laat die sagteware toe om te ontwikkel sonder om die fokus weg te skuif van die gemeenskap. Google, as 'n tegnologiereus, sê nie dat ons hierdie funksie wil hê nie, ons wil hierdie fout regmaak en dit is waar ons moet grawe. Google sê: “Doen wat jy doen. Hou net aan werk soos jy gewerk het en alles sal reg wees.”
- Die volgende benadering tot deelname aan oopbron is deelname. Wanneer jy 'n probleem in oopbronsagteware het en daar is ontwikkelaars, begin jou ontwikkelaars die probleme oplos. Hulle begin om jou infrastruktuur doeltreffender te maak, jou programme vinniger en meer betroubaar te maak.
Een van die bekendste Yandex-projekte op die gebied van oopbronsagteware is ClickHouse. Dit is 'n databasis wat gebore is as 'n reaksie op die uitdagings wat Yandex.Metrica in die gesig staar.
En as 'n databasis is dit in oopbron gemaak om 'n ekosisteem te skep en dit saam met ander ontwikkelaars te ontwikkel (nie net binne Yandex nie). En nou is dit 'n groot projek waarby baie verskillende maatskappye betrokke is.
In Yandex.Cloud het ons ClickHouse bo-op Yandex Object Storage geskep, dit wil sê bo-op wolkberging.
Hoekom is dit belangrik in die wolk? Omdat enige databasis in hierdie driehoek, in hierdie piramide, in hierdie hiërargie van geheuetipes werk. Jy het vinnige maar klein registers en goedkoop groot maar stadige SSD's, hardeskywe en 'n paar ander bloktoestelle. En as jy doeltreffend aan die bopunt van die piramide is, dan het jy 'n vinnige databasis. as jy doeltreffend aan die onderkant van hierdie piramide is, dan het jy 'n geskaalde databasis. En in hierdie verband is die byvoeging van nog 'n laag van onder 'n logiese benadering om die skaalbaarheid van die databasis te verhoog.
Hoe kon dit gedoen word? Dit is 'n belangrike punt in hierdie verslag.
- Ons kan ClickHouse oor MDS implementeer. MDS is 'n interne Yandex-wolkbergingskoppelvlak. Dit is meer kompleks as die algemene S3-protokol, maar dit is meer geskik vir 'n bloktoestel. Dit is beter om data op te neem. Dit verg meer programmering. Programmeerders sal programmeer, dit is selfs goed, dit is interessant.
- S3 is 'n meer algemene benadering wat die koppelvlak eenvoudiger maak ten koste van minder aanpassing by sekere soorte werkladings.
Natuurlik, omdat ons funksionaliteit aan die hele ClickHouse-ekosisteem wou verskaf en die taak wat nodig is binne Yandex.Cloud doen, het ons besluit om seker te maak dat die hele ClickHouse-gemeenskap daarby sal baat. Ons het ClickHouse oor S3 geïmplementeer, nie ClickHouse oor MDS nie. En dit is baie werk.
verwysings:
"Lêerstelsel-abstraksielaag"
"AWS SDK S3-integrasie"
"Basis-implementering van IDisk-koppelvlak vir S3"
"Integrasie van log stoor enjins met IDisk koppelvlak"
"Logmotorondersteuning vir S3 en SeekableReadBuffer"
"Storage Stripe Log S3-ondersteuning"
"Stoor MergeTree aanvanklike ondersteuning vir S3"
"MergeTree volle ondersteuning vir S3"
"Ondersteun ReplicatedMergeTree oor S3"
"Voeg verstek geloofsbriewe en pasgemaakte opskrifte by vir s3-berging"
"S3 met dinamiese proxy-konfigurasie"
"S3 met proxy resolver"
Dit is 'n trekversoeklys vir die implementering van 'n virtuele lêerstelsel in ClickHouse. Dit is 'n groot aantal trekversoeke.
verwysings:
"DiskS3 hardlinks optimale implementering"
"S3 HTTP-kliënt - Vermy die kopiëring van reaksiestroom na die geheue"
"Vermy die kopiëring van die hele reaksiestroom in die geheue in S3 HTTP
kliënt"
"Vermoë om te kasmerk en lêers vir S3-skyf te indekseer"
"Skuif dele parallel van DiskLocal na DiskS3"
Maar die werk het nie daar geëindig nie. Nadat die kenmerk gemaak is, was nog werk nodig om hierdie funksionaliteit te optimaliseer.
verwysings:
"Voeg SelectedRows en SelectedBytes-geleenthede by"
"Voeg profielgebeurtenisse vanaf S3-versoek by system.events"
"Voeg QueryTimeMicroseconds, SelectQueryTimeMicroseconds en InsertQueryTimeMicroseconds by"
En toe was dit nodig om dit diagnoseerbaar te maak, monitering op te stel en hanteerbaar te maak.
En dit alles is gedoen sodat die hele gemeenskap, die hele ClickHouse-ekosisteem, die resultaat van hierdie werk ontvang het.
Kom ons gaan oor na transaksionele databasisse, na OLTP databasisse, wat nader aan my persoonlik is.
Dit is die oopbron DBMS-ontwikkelingsafdeling. Hierdie ouens doen straatmagie om transaksionele oop databasisse te verbeter.
Een van die projekte, met 'n voorbeeld waarvan ons kan praat oor hoe en wat ons doen, is die Connection Pooler in Postgres.
Postgres is 'n proses databasis. Dit beteken dat die databasis so min moontlik netwerkverbindings moet hê wat transaksies hanteer.
Aan die ander kant, in 'n wolkomgewing, is 'n tipiese situasie wanneer 'n duisend verbindings gelyktydig na een groep kom. En die verbindingpooler se taak is om 'n duisend verbindings in 'n klein aantal bedienerverbindings te pak.
Ons kan sê dat die verbindingpooler die telefoonoperateur is wat die grepe herrangskik sodat hulle die databasis doeltreffend bereik.
Ongelukkig is daar geen goeie Russiese woord vir verbindingpoeler nie. Soms word dit multiplekserverbindings genoem. As jy weet wat om die verbinding-poeler te noem, vertel my dan, ek sal baie bly wees om die korrekte Russiese tegniese taal te praat.
Ons het konneksiepoelers ondersoek wat geskik is vir 'n bestuurde postgres-kluster. En PgBouncer was die beste keuse vir ons. Maar ons het 'n aantal probleme met PgBouncer ondervind. Baie jare gelede het Volodya Borodin berigte gegee dat ons PgBouncer gebruik, ons hou van alles, maar daar is nuanses, daar is iets om aan te werk.
En ons het gewerk. Ons het die probleme opgelos wat ons teëgekom het, ons het Bouncer gelap en probeer om trekversoeke stroomop te druk. Maar fundamentele enkeldraad was moeilik om mee te werk.
Ons moes kaskenades van gelapte Bouncers versamel. Wanneer ons baie enkel-draad Bouncers het, word die verbindings op die boonste laag na die binneste laag Bouncers oorgedra. Dit is 'n swak bestuurde stelsel wat moeilik is om te bou en heen en weer te skaal.
Ons het tot die gevolgtrekking gekom dat ons ons eie verbindingpooler geskep het, wat Odyssey genoem word. Ons het dit van voor af geskryf.
In 2019, by die PgCon-konferensie, het ek hierdie poeler aan die ontwikkelaargemeenskap aangebied. Nou het ons 'n bietjie minder as 2 000 sterre op GitHub, dit wil sê die projek is lewendig, die projek is gewild.
En as jy 'n Postgres-kluster in Yandex.Cloud skep, dan sal dit 'n groep wees met ingeboude Odyssey, wat herkonfigureer word wanneer die groep heen of weer skaal.
Wat het ons uit hierdie projek geleer? Om 'n mededingende projek te loods is altyd 'n aggressiewe stap, dit is 'n uiterste maatstaf as ons sê dat daar probleme is wat nie vinnig genoeg opgelos word nie, nie opgelos word in die tydsintervalle wat ons sal pas nie. Maar dit is 'n effektiewe maatreël.
PgBouncer het vinniger begin ontwikkel.
En nou het ander projekte verskyn. Byvoorbeeld, pgagroal, wat ontwikkel is deur Red Hat-ontwikkelaars. Hulle streef soortgelyke doelwitte na en implementeer soortgelyke idees, maar natuurlik met hul eie besonderhede, wat nader aan pgagroal-ontwikkelaars is.
Nog 'n geval van werk met die postgres-gemeenskap is herstel tot 'n tydstip. Dit is herstel na 'n mislukking, dit is herstel vanaf 'n rugsteun.
Daar is baie rugsteun en hulle verskil almal. Byna elke Postgres-verkoper het sy eie rugsteunoplossing.
As jy al die rugsteunstelsels neem, 'n kenmerkmatriks skep en grappenderwys die determinant in hierdie matriks bereken, sal dit nul wees. Wat beteken dit? Wat as jy 'n spesifieke rugsteunlêer neem, dan kan dit nie uit stukke van al die ander saamgestel word nie. Dit is uniek in sy implementering, dit is uniek in sy doel, dit is uniek in die idees wat daarin ingebed is. En hulle is almal spesifiek.
Terwyl ons aan hierdie kwessie gewerk het, het CitusData die WAL-G-projek van stapel gestuur. Dit is 'n rugsteunstelsel wat gemaak is met die oog op die wolkomgewing. Nou is CitusData reeds deel van Microsoft. En op daardie oomblik het ons baie gehou van die idees wat in die aanvanklike uitgawes van WAL-G neergelê is. En ons het begin bydra tot hierdie projek.
Nou is daar baie dosyne ontwikkelaars in hierdie projek, maar die top 10 bydraers tot WAL-G sluit 6 Yandexoids in. Ons het baie van ons idees daarheen gebring. En natuurlik het ons dit self geïmplementeer, dit self getoets, dit self in produksie uitgerol, ons gebruik dit self, ons vind self uit waarheen om volgende te beweeg, terwyl ons met die groot WAL-G-gemeenskap kommunikeer.
En uit ons oogpunt, nou het hierdie rugsteunstelsel, insluitend met inagneming van ons pogings, optimaal geword vir 'n wolkomgewing. Dit is die beste koste om Postgres in die wolk te rugsteun.
Wat beteken dit? Ons het 'n redelik groot idee bevorder: rugsteun moet veilig wees, goedkoop om te bedryf en so vinnig as moontlik om te herstel.
Hoekom moet dit goedkoop wees om te bedryf? Wanneer niks stukkend is nie, moet jy nie weet jy het rugsteun nie. Alles werk goed, jy mors so min CPU as moontlik, jy gebruik so min as moontlik van jou skyfhulpbronne, en jy stuur so min as moontlik grepe na die netwerk om nie in te meng met die loonvrag van jou waardevolle dienste nie.
En wanneer alles breek, byvoorbeeld, het die admin die data laat val, iets het verkeerd geloop, en jy moet dringend teruggaan na die verlede, herstel jy met al die geld, want jy wil jou data vinnig en ongeskonde terughê.
En ons het hierdie eenvoudige idee bevorder. En, dit lyk vir ons, het ons daarin geslaag om dit te implementeer.
Maar dit is nie al nie. Ons wou nog een klein dingetjie hê. Ons wou baie verskillende databasisse hê. Nie al ons kliënte gebruik Postgres nie. Sommige mense gebruik MySQL, MongoDB. In die gemeenskap het ander ontwikkelaars FoundationDB ondersteun. En hierdie lys brei voortdurend uit.
Die gemeenskap hou van die idee dat die databasis in 'n bestuurde omgewing in die wolk bestuur word. En ontwikkelaars hou hul databasisse in stand, wat eenvormig saam met Postgres met ons rugsteunstelsel gerugsteun kan word.
Wat het ons uit hierdie storie geleer? Ons produk, as 'n ontwikkelingsafdeling, is nie kodereëls nie, dit is nie stellings nie, dit is nie lêers nie. Ons produk is nie trekversoeke nie. Dit is die idees wat ons aan die gemeenskap oordra. Dit is tegnologiese kundigheid en die beweging van tegnologie na 'n wolkomgewing.
Daar is so 'n databasis soos Postgres. Ek hou die meeste van die Postgres-kern. Ek spandeer baie tyd om die Postgres-kern saam met die gemeenskap te ontwikkel.
Maar hier moet gesê word dat Yandex.Cloud 'n interne installasie van bestuurde databasisse het. En dit het lank gelede in Yandex.Mail begin. Die kundigheid wat nou tot bestuurde Postgres gelei het, is opgehoop toe die pos na Postgres wou intrek.
Pos het baie soortgelyke vereistes as die wolk. Dit vereis dat jy op enige punt in jou data kan skaal tot onverwagte eksponensiële groei. En die pos het reeds 'n vrag gehad met 'n paar honderdmiljoene posbusse van 'n groot aantal gebruikers wat voortdurend baie versoeke rig.
En dit was nogal 'n ernstige uitdaging vir die span wat Postgres ontwikkel het. Destyds is enige probleme wat ons teëgekom het aan die gemeenskap gerapporteer. En hierdie probleme is reggestel en op sommige plekke deur die gemeenskap reggestel, selfs op die vlak van betaalde ondersteuning vir sommige ander databasisse en selfs beter. Dit wil sê, jy kan 'n brief aan PgSQL-kraker stuur en binne 40 minute 'n antwoord ontvang. Betaalde ondersteuning in sommige databasisse mag dink dat daar meer prioriteite is as jou fout.
Nou is die interne installasie van Postgres 'n paar petagrepe data. Dit is 'n paar miljoene versoeke per sekonde. Dit is duisende trosse. Dit is baie grootskaalse.
Maar daar is 'n nuanse. Dit leef nie op fancy netwerkaandrywers nie, maar op redelik eenvoudige hardeware. En daar is 'n toetsomgewing spesifiek vir interessante nuwe dinge.
En op 'n sekere oomblik in die toetsomgewing het ons 'n boodskap ontvang wat aandui dat die interne invariante van die databasisindekse geskend is.
'n Onveranderlike is 'n soort verhouding wat ons verwag om altyd te hou.
'n Baie kritieke situasie vir ons. Dit dui aan dat sommige data dalk verlore gegaan het. En die verlies van data is iets heeltemal katastrofies.
Die algemene idee wat ons in bestuurde databasisse volg, is dat dit selfs met moeite moeilik sal wees om data te verloor. Selfs as jy hulle doelbewus verwyder, sal jy steeds hul afwesigheid vir 'n lang tydperk moet ignoreer. Datasekuriteit is 'n godsdiens wat ons nogal ywerig volg.
En hier ontstaan 'n situasie wat daarop dui dat daar 'n situasie kan wees waarvoor ons dalk nie voorbereid is nie. En ons het begin voorberei vir hierdie situasie.
Die eerste ding wat ons gedoen het, was om die stompe van hierdie duisende trosse te begrawe. Ons het gevind watter van die groepe op skywe met problematiese firmware geleë is wat databladsyopdaterings verloor het. Het alle Postgres-datakode gemerk. En ons het daardie boodskappe gemerk wat oortredings van interne invariante aandui met kode wat ontwerp is om datakorrupsie op te spoor.
Hierdie pleister is feitlik sonder veel bespreking deur die gemeenskap aanvaar, want in elke spesifieke geval was dit duidelik dat iets ergs gebeur het en aan die log gerapporteer moes word.
Hierna het ons by die punt gekom dat ons monitering het wat logs skandeer. En in geval van verdagte boodskappe maak hy die diensbeampte wakker, en die diensbeampte herstel dit.
Maar! Om logs te skandeer is 'n goedkoop operasie op een kluster en katastrofies duur vir 'n duisend clusters.
Ons het 'n uitbreiding geskryf genaamd . Dit skep 'n aansig van die databasis waarin jy goedkoop en vinnig statistieke oor vorige foute kan kies. En as ons die diensbeampte moet wakker maak, dan sal ons hiervan uitvind sonder om gigagreep-lêers te skandeer, maar deur 'n paar grepe uit die hash-tabel te onttrek.
Hierdie uitbreiding is byvoorbeeld aangeneem in die bewaarplek vir . As jy dit wil gebruik, kan jy dit self installeer. Natuurlik is dit oopbron.
Maar dit is nie al nie. Ons het Amcheck, 'n gemeenskapsgeboude uitbreiding, begin gebruik om onveranderlike oortredings in indekse te vind.
En ons het uitgevind dat as jy dit op skaal gebruik, daar foute is. Ons het hulle begin regmaak. Ons regstellings is aanvaar.
Ons het ontdek dat hierdie uitbreiding nie GiST- en GIT-indekse kan ontleed nie. Ons het hulle laat ondersteun. Maar hierdie ondersteuning word steeds deur die gemeenskap bespreek, want dit is 'n relatief nuwe funksionaliteit en daar is baie besonderhede daar.
En ons het ook ontdek dat wanneer indekse nagegaan word vir oortredings op die replikasieleier, op die meester, alles goed werk, maar op die replikas, op die volger, is die soektog na korrupsie nie so effektief nie. Nie alle invariante word nagegaan nie. En een onveranderlike het ons baie gepla. En ons het 'n jaar en 'n half spandeer om met die gemeenskap te kommunikeer om hierdie kontrole op replikas moontlik te maak.
Ons het kode geskryf wat alle kan ... protokolle moet volg. Ons het hierdie pleister geruime tyd met Peter Gaghan van Crunchy Data bespreek. Hy moes die bestaande B-boom in Postgres effens verander om hierdie pleister te aanvaar. Hy is aanvaar. En nou het die nagaan van indekse op replikas ook doeltreffend genoeg geword om die oortredings op te spoor wat ons teëgekom het. Dit wil sê, dit is die oortredings wat veroorsaak kan word deur foute in skyffirmware, foute in Postgres, foute in die Linux-kern en hardewareprobleme. Nogal 'n uitgebreide lys van bronne van probleme waarvoor ons voorberei het.
Maar behalwe indekse, is daar so 'n deel soos heap, dit wil sê die plek waar die data gestoor word. En daar is nie baie invariante wat nagegaan kan word nie.
Ons het 'n uitbreiding genaamd Heapcheck. Ons het dit begin ontwikkel. En in parallel het die EnterpriseDB-maatskappy saam met ons ook 'n module begin skryf, wat hulle Heapcheck op dieselfde manier genoem het. Net ons het dit PgHeapcheck genoem, en hulle het dit net Heapcheck genoem. Hulle het dit met soortgelyke funksies, 'n effens ander handtekening, maar met dieselfde idees. Hulle het dit op sommige plekke 'n bietjie beter geïmplementeer. En hulle het dit voorheen in oopbron geplaas.
En nou ontwikkel ons hul uitbreiding, want dit is nie meer hul uitbreiding nie, maar die uitbreiding van die gemeenskap. En in die toekoms is dit deel van die kern wat aan almal verskaf sal word sodat hulle vooraf van toekomstige probleme kan weet.
Op sommige plekke het ons selfs tot die gevolgtrekking gekom dat ons vals positiewe in ons moniteringstelsels het. Byvoorbeeld, die 1C-stelsel. Wanneer 'n databasis gebruik word, skryf Postgres soms data daarin wat dit kan lees, maar pg_dump kan nie lees nie.
Hierdie situasie het gelyk soos korrupsie vir ons probleemopsporingstelsel. Die diensbeampte is wakker gemaak. Die diensbeampte het gekyk wat gebeur. Na 'n ruk het 'n kliënt gekom en gesê ek het probleme. Die bediende het verduidelik wat die probleem was. Maar die probleem is in die Postgres-kern.
Ek het 'n bespreking oor hierdie kenmerk gevind. En hy het geskryf dat ons hierdie kenmerk teëgekom het en dit was onaangenaam, 'n persoon het in die nag wakker geword om uit te vind wat dit was.
Die gemeenskap het geantwoord: "O, ons moet dit regtig regmaak."
Ek het 'n eenvoudige analogie. As jy in 'n skoen loop wat 'n sandkorrel in het, dan kan jy in beginsel aanbeweeg - geen probleem nie. As jy stewels aan duisende mense verkoop, kom ons maak dan stewels sonder sand. En as een van die gebruikers van jou skoene 'n marathon gaan hardloop, dan wil jy baie goeie skoene maak, en dit dan vir al jou gebruikers skaal. En sulke onverwagte gebruikers is altyd in die wolkomgewing. Daar is altyd gebruikers wat die groep op een of ander oorspronklike manier ontgin. Hiervoor moet jy altyd voorberei.
Wat het ons hier geleer? Ons het 'n eenvoudige ding geleer: die belangrikste ding is om aan die gemeenskap te verduidelik dat daar 'n probleem is. As die gemeenskap die probleem erken het, dan ontstaan natuurlike mededinging om die probleem op te los. Want almal wil 'n belangrike probleem oplos. Alle verkopers, alle hackers verstaan dat hulle self op hierdie hark kan trap, so hulle wil hulle uitskakel.
As jy aan 'n probleem werk, maar dit pla niemand behalwe jou nie, maar jy werk sistematies daaraan en dit word uiteindelik as 'n probleem beskou, dan sal jou trekversoek beslis aanvaar word. Jou pleister sal aanvaar word, jou verbeterings of selfs versoeke vir verbeterings sal deur die gemeenskap hersien word. Aan die einde van die dag maak ons die databasis beter vir mekaar.
'n Interessante databasis is Greenplum. Dit is 'n hoogs parallelle databasis gebaseer op die Postgres-kodebasis, waarmee ek baie vertroud is.
En Greenplum het interessante funksionaliteit - voeg geoptimaliseerde tabelle by. Dit is tabelle waarby jy vinnig kan byvoeg. Hulle kan kolomvormig of ry wees.
Maar daar was geen groepering nie, dit wil sê daar was geen funksionaliteit waar jy die data in die tabel kan rangskik in ooreenstemming met die volgorde wat in een van die indekse is nie.
Die ouens van die taxi het na my toe gekom en gesê: “Andrey, jy ken Postgres. En hier is dit amper dieselfde. Skakel oor na 20 minute. Jy vat dit en doen dit.” Ek het gedink dat ja, ek ken Postgres, skakel vir 20 minute - ek moet dit doen.
Maar nee, dit was nie 20 minute nie, ek het dit oor maande geskryf. By die PgConf.Russia-konferensie het ek Heikki Linakangas van Pivotal genader en gevra: “Is daar enige probleme hiermee? Waarom is daar geen byvoeg-geoptimaliseerde tabelgroepering nie?” Hy sê: “Jy vat die data. Jy sorteer, jy herrangskik. Dit is net 'n werk." Ek: "O, ja, jy moet dit net vat en doen." Hy sê: "Ja, ons het vrye hande nodig om dit te doen." Ek het gedink ek moet dit beslis doen.
En 'n paar maande later het ek 'n trekversoek ingedien wat hierdie funksionaliteit geïmplementeer het. Hierdie trekversoek is deur Pivotal saam met die gemeenskap hersien. Natuurlik was daar goggas.
Maar die interessantste is dat toe hierdie trekversoek saamgevoeg is, foute in Greenplum self gevind is. Ons het gevind dat hooptabelle soms transaksionaliteit verbreek wanneer dit gegroepeer word. En dit is 'n ding wat reggemaak moet word. En sy is op die plek wat ek sopas aangeraak het. En my natuurlike reaksie was – goed, laat ek dit ook doen.
Ek het hierdie fout reggemaak. Het 'n trekversoek aan die fixers gestuur. Hy is vermoor.
Waarna dit geblyk het dat hierdie funksionaliteit verkry moet word in die Greenplum weergawe vir PostgreSQL 12. Dit wil sê, die 20 minute avontuur gaan voort met nuwe interessante avonture. Dit was interessant om die huidige ontwikkeling aan te raak, waar die gemeenskap nuwe en belangrikste kenmerke sny. Dis gevries.
Maar dit het nie daar geëindig nie. Na alles het dit geblyk dat ons dokumentasie vir dit alles moes skryf.
Ek het begin om dokumentasie te skryf. Gelukkig het die dokumentariërs van Pivotal saamgekom. Engels is hul moedertaal. Hulle het my gehelp met die dokumentasie. Om die waarheid te sê, hulle het self wat ek voorgestel het in regte Engels oorgeskryf.
En hier, wil dit voorkom, het die avontuur geëindig. En weet jy wat toe gebeur het? Die ouens van die taxi het na my toe gekom en gesê: "Daar is nog twee avonture, elk vir 10 minute." En wat moet ek vir hulle sê? Ek het gesê dat ek nou 'n verslag op skaal sal gee, dan sal ons jou avonture sien, want dit is 'n interessante werk.
Wat het ons uit hierdie saak geleer? Omdat om met oopbron te werk is altyd om met 'n spesifieke persoon te werk, is dit altyd om met die gemeenskap te werk. Want in elke stadium het ek saam met een of ander ontwikkelaar, een of ander toetser, een of ander hacker, een of ander dokumentêr, een of ander argitek gewerk. Ek het nie met Greenplum gewerk nie, ek het met mense rondom Greenplum gewerk.
Maar! Daar is nog 'n belangrike punt - dit is net werk. Dit wil sê, jy kom, drink koffie, skryf kode. Allerhande eenvoudige invariante werk. Doen dit normaalweg - dit sal goed wees! En dit is nogal 'n interessante werk. Daar is 'n versoek vir hierdie werk van Yandex.Cloud-kliënte, gebruikers van ons groepe beide binne Yandex en buite. En ek dink dat die aantal projekte waaraan ons deelneem sal toeneem en die diepte van ons betrokkenheid sal ook toeneem.
Dis al. Kom ons gaan aan na die vrae.
Vrae sessie
Hallo! Ons het nog 'n vraag-en-antwoord-sessie. En in die ateljee Andrei Borodin. Dit is die persoon wat jou sopas vertel het van die bydrae van Yandex.Cloud en Yandex tot oopbron. Ons verslag gaan nou nie heeltemal oor die Wolk nie, maar terselfdertyd is ons op sulke tegnologieë gebaseer. Sonder wat jy binne Yandex gedoen het, sou daar geen diens in Yandex.Cloud wees nie, so dankie van my persoonlik af. En die eerste vraag van die uitsending: "Waarop is elkeen van die projekte wat jy genoem het geskryf?"
Die rugsteunstelsel in WAL-G is in Go geskryf. Dit is een van die nuwer projekte waaraan ons gewerk het. Hy is letterlik net 3 jaar oud. En 'n databasis gaan dikwels oor betroubaarheid. En dit beteken dat die databasisse redelik oud is en gewoonlik in C geskryf is. Die Postgres-projek het sowat 30 jaar gelede begin. Dan was die C89 die regte keuse. En Postgres is daarop geskryf. Meer moderne databasisse soos ClickHouse word gewoonlik in C++ geskryf. Alle stelselontwikkeling is gebaseer op C en C++.
'n Vraag van ons finansiële bestuurder, wat verantwoordelik is vir uitgawes by Cloud: "Waarom spandeer Cloud geld om oopbron te ondersteun?"
Hier is 'n eenvoudige antwoord vir die finansiële bestuurder. Ons doen dit om ons dienste beter te maak. Op watter maniere kan ons beter doen? Ons kan dinge meer doeltreffend, vinniger doen en dinge meer skaalbaar maak. Maar vir ons gaan hierdie storie hoofsaaklik oor betroubaarheid. Byvoorbeeld, in 'n rugsteunstelsel hersien ons 100% van die pleisters wat daarop van toepassing is. Ons weet wat die kode is. En ons is meer gemaklik om nuwe weergawes na produksie uit te rol. Dit is, eerstens, dit gaan oor selfvertroue, oor gereedheid vir ontwikkeling en oor betroubaarheid
Nog 'n vraag: "Is die vereistes van eksterne gebruikers wat in Yandex.Cloud woon anders as interne gebruikers wat in die interne Wolk woon?"
Die lasprofiel is natuurlik anders. Maar uit die oogpunt van my departement word al die spesiale en interessante gevalle op 'n nie-standaard vrag geskep. Ontwikkelaars met verbeelding, ontwikkelaars wat die onverwagte doen, sal so waarskynlik beide intern en ekstern gevind word. In hierdie verband is ons almal ongeveer dieselfde. En, waarskynlik, die enigste belangrike kenmerk binne die Yandex-werking van databasisse sal wees dat ons binne Yandex 'n lering het. Op 'n sekere tyd gaan 'n sekere beskikbaarheidsone heeltemal in die skadu, en alle Yandex-dienste moet op een of ander manier voortgaan om ten spyte daarvan te funksioneer. Dit is 'n klein verskil. Maar dit skep baie navorsingsontwikkeling by die koppelvlak van die databasis en netwerkstapel. Andersins genereer eksterne en interne installasies dieselfde versoeke vir kenmerke en soortgelyke versoeke vir die verbetering van betroubaarheid en werkverrigting.
Volgende vraag: "Hoe voel jy persoonlik oor die feit dat baie van wat jy doen deur ander Wolke gebruik word?" Ons sal nie spesifiekes noem nie, maar baie projekte wat in Yandex.Cloud gedoen is, word in ander mense se wolke gebruik.
Dit is gaaf. Eerstens is dit 'n teken dat ons iets reg gedoen het. En dit krap die ego. En ons is meer vol vertroue dat ons die regte besluit geneem het. Aan die ander kant is dit die hoop dat dit in die toekoms vir ons nuwe idees, nuwe versoeke van derdeparty-gebruikers sal bring. Die meeste kwessies op GitHub word geskep deur individuele stelseladministrateurs, individuele DBA's, individuele argitekte, individuele ingenieurs, maar soms kom mense met sistematiese ervaring en sê dat ons in 30% van sekere gevalle hierdie probleem het en kom ons dink oor hoe om dit op te los. Dit is waarna ons die meeste uitsien. Ons sien uit daarna om ervarings met ander wolkplatforms te deel.
Jy het baie oor die marathon gepraat. Ek weet dat jy 'n marathon in Moskou gehardloop het. As gevolg daarvan? Het die ouens van PostgreSQL verbygesteek?
Nee, Oleg Bartunov hardloop baie vinnig. Hy het 'n uur voor my klaargemaak. Oor die algemeen is ek tevrede met hoe ver ek gekom het. Vir my was net klaarmaak 'n prestasie. In die algemeen is dit verbasend dat daar soveel hardlopers in die postgres-gemeenskap is. Dit lyk vir my of daar 'n soort verband is tussen aërobiese sport en die begeerte vir stelselprogrammering.
Sê jy daar is geen hardlopers by ClickHouse nie?
Ek weet verseker dat hulle daar is. ClickHouse is ook 'n databasis. Terloops, Oleg skryf nou vir my: "Sal ons gaan hardloop na die verslag?" Dit is 'n goeie idee.
Nog 'n vraag uit die uitsending van Nikita: "Hoekom het jy self die fout in Greenplum reggemaak en dit nie vir juniors gegee nie?" Dit is waar, dit is nie baie duidelik wat die fout is en in watter diens nie, maar dit beteken waarskynlik die een waarvan jy gepraat het.
Ja, in beginsel kon dit aan iemand gegee gewees het. Dit was net die kode wat ek sopas verander het. En dit was natuurlik om dadelik voort te gaan om dit te doen. In beginsel is die idee om kundigheid met die span te deel 'n goeie idee. Ons sal beslis Greenplum-take onder alle lede van ons afdeling deel.
Aangesien ons oor juniors praat, hier is 'n vraag. Die persoon het besluit om die eerste commit in Postgres te skep. Wat moet hy doen om die eerste commit te maak?
Dit is 'n interessante vraag: "Waar om te begin?" Dit is gewoonlik nogal moeilik om met iets in die kern te begin. In Postgres is daar byvoorbeeld 'n doenlys. Maar in werklikheid is dit 'n blad van wat hulle probeer doen het, maar nie daarin geslaag het nie. Dit is komplekse dinge. En gewoonlik kan jy 'n paar nutsprogramme in die ekosisteem vind, sommige uitbreidings wat verbeter kan word, wat minder aandag van kernontwikkelaars trek. En dienooreenkomstig is daar meer punte vir groei daar. By die Google Summer of code-program stel die postgres-gemeenskap elke jaar baie verskillende onderwerpe voor wat aangespreek kan word. Hierdie jaar het ons, dink ek, drie studente gehad. Een het selfs in WAL-G geskryf oor onderwerpe wat belangrik is vir Yandex. In Greenplum is alles eenvoudiger as in die Postgres-gemeenskap, want Greenplum-krakers hanteer trekversoeke baie goed en begin dadelik hersien. Om 'n pleister na Postgres te stuur is 'n kwessie van maande, maar Greenplum sal binne 'n dag kom en kyk wat jy gedoen het. Nog iets is dat Greenplum huidige probleme moet oplos. Greenplum word nie algemeen gebruik nie, so dit is nogal moeilik om jou probleem te vind. En eerstens moet ons natuurlik probleme oplos.
Bron: will.com