Yandex bidrag till följande databaser kommer att övervÀgas.
- klickhus
- Odyssey
- à terstÀllning till en tidpunkt (WAL-G)
- PostgreSQL (inklusive logerrors, Amcheck, heapcheck)
- Greenplum
videor:
Hej vÀrlden! Jag heter Andrey Borodin. Och vad jag gör pÄ Yandex.Cloud Àr att utveckla öppna relationsdatabaser i Yandex.Cloud- och Yandex.Cloud-kundernas intresse.
I det hÀr föredraget kommer vi att prata om de utmaningar som öppna databaser stÄr inför i stor skala. Varför Àr det viktigt? För smÄ, smÄ problem som, som myggor, sedan blir elefanter. De blir stora nÀr man har mÄnga kluster.
Men det Àr inte huvudsaken. Otroliga saker hÀnder. Saker som hÀnder i ett pÄ en miljon fall. Och i en molnmiljö mÄste man vara beredd pÄ det, för otroliga saker blir högst sannolika nÀr nÄgot finns i stor skala.
Men! Vilka Àr fördelarna med öppna databaser? Det faktum att du har en teoretisk möjlighet att hantera vilket problem som helst. Du har kÀllkoden, du har kunskap om programmering. Vi kombinerar och jobbar.
Vilka tillvÀgagÄngssÀtt finns det att arbeta med programvara med öppen kÀllkod?
- Det mest förstÄeliga tillvÀgagÄngssÀttet Àr att anvÀnda programvara. Om du anvÀnder protokoll, om du anvÀnder standarder, om du anvÀnder format, om du skriver förfrÄgningar pÄ programvara med öppen kÀllkod, sÄ stöder du det redan.
- Du gör dess ekosystem större. Du gör det mer sannolikt att hitta en bugg tidigt. Du ökar tillförlitligheten i detta system. Du ökar tillgÀngligheten för utvecklare pÄ marknaden. Du förbÀttrar denna programvara. Du Àr redan en bidragsgivare om du bara lyckades fÄ stil och pysslade med det.
- Ett annat förstÄeligt tillvÀgagÄngssÀtt Àr att sponsra programvara med öppen kÀllkod. Till exempel det vÀlkÀnda Google Summer of Code-programmet, dÄ Google betalar ett stort antal studenter frÄn hela vÀrlden förstÄeliga pengar sÄ att de utvecklar öppna mjukvaruprojekt som uppfyller vissa licenskrav.
- Detta Àr ett mycket intressant tillvÀgagÄngssÀtt eftersom det lÄter dig utveckla programvaran utan att flytta fokus frÄn samhÀllet. Google, som en teknikjÀtte, sÀger inte att vi vill ha den hÀr funktionen, vi vill fixa den hÀr buggen, och det Àr dÀr vi mÄste grÀva. Google sÀger: "Gör vad du gör. FortsÀtt bara jobba som du har jobbat sÄ kommer allt att bli bra."
- NÀsta tillvÀgagÄngssÀtt för att delta i öppen kÀllkod Àr deltagande. NÀr du har ett problem med öppen kÀllkod och det finns utvecklare börjar dina utvecklare lösa problemen. De börjar göra din infrastruktur mer effektiv, dina program snabbare och mer tillförlitliga.
Ett av de mest kÀnda Yandex open source-projekten Àr ClickHouse. Detta Àr en databas som föddes som ett svar pÄ de utmaningar som Yandex.Metrica stÄr inför.
Och som en databas gjordes den i öppen kÀllkod för att skapa ett ekosystem och utveckla det tillsammans med andra utvecklare (inte bara inom Yandex). Och nu Àr det hÀr ett stort projekt dÀr mÄnga olika företag Àr inblandade.
I Yandex.Cloud gjorde vi ClickHouse ovanpÄ Yandex Object Storage, alltsÄ ovanpÄ molnlagring.
Varför Àr det viktigt i molnet? Eftersom vilken databas som helst fungerar i denna triangel, i denna pyramid, i denna hierarki av minnestyper. Du har snabba men smÄ register och billiga stora men lÄngsamma SSD:er, hÄrddiskar och andra blockenheter. Och om du Àr effektiv i toppen av pyramiden, dÄ har du en snabb databas. om du Àr effektiv i botten av denna pyramid, sÄ har du en skalad databas. Och i detta avseende Àr att lÀgga till ytterligare ett lager frÄn botten en logisk metod för att öka skalbarheten av databasen.
Hur kunde det göras? Detta Àr en viktig punkt i denna rapport.
- Vi skulle kunna implementera ClickHouse över MDS. MDS Àr ett internt Yandex molnlagringsgrÀnssnitt. Det Àr mer komplext Àn det vanliga S3-protokollet, men det Àr mer lÀmpligt för en blockenhet. Den Àr bÀttre lÀmpad för att skriva data. Det krÀver mer programmering. Programmerare kommer att programmera, det Àr till och med bra, intressant.
- S3 Àr ett vanligare tillvÀgagÄngssÀtt som gör grÀnssnittet enklare till priset av mindre anpassning till vissa typer av arbetsbelastningar.
Naturligtvis, eftersom vi ville tillhandahÄlla funktionalitet till hela ClickHouse-ekosystemet och utföra den uppgift som behövs i Yandex.Cloud, bestÀmde vi oss för att göra det sÄ att hela ClickHouse-gemenskapen skulle dra nytta av det. Vi implementerade ClickHouse över S3, inte ClickHouse över MDS. Och det Àr mycket jobb.
LĂ€nkar:
"Filsystemabstraktionslager"
AWS SDK S3 integration
"Basimplementering av IDisk-grÀnssnitt för S3"
"Integration av logglagringsmotorer med IDisk-grÀnssnitt"
"Loggmotorstöd för S3 och SeekableReadBuffer"
"Stöd för Storage Stripe Log S3"
"Storage MergeTree initialt stöd för S3"
MergeTree fullt stöd för S3
"Stöd ReplicatedMergeTree över S3"
"LÀgg till standardinloggningsuppgifter och anpassade rubriker för s3-lagring"
"S3 med dynamisk proxykonfiguration"
"S3 med proxy resolver"
Detta Àr en pull-förfrÄgningslista för att implementera ett virtuellt filsystem i ClickHouse. Detta Àr ett stort antal pull-förfrÄgningar.
LĂ€nkar:
"DiskS3 hardlinks optimal implementering"
"S3 HTTP-klient - Undvik att kopiera svarsström till minnet"
"Undvik att kopiera hela svarsströmmen till minnet i S3 HTTP
klient"
"Möjlighet att cachemÀrka och indexera filer för S3-disk"
"Flytta delar frÄn DiskLocal till DiskS3 parallellt"
Men arbetet slutade inte dÀr. Efter att funktionen skapades tog det lite mer arbete att optimera denna funktionalitet.
LĂ€nkar:
"LÀgg till SelectedRows och SelectedBytes-hÀndelser"
"LÀgg till profileringshÀndelser frÄn S3-förfrÄgan till system.events"
"LĂ€gg till QueryTimeMicroseconds, SelectQueryTimeMicroseconds och InsertQueryTimeMicroseconds"
Och dÄ var det nödvÀndigt att göra det diagnoserbart, sÀtta upp övervakning och göra det hanterbart.
Och allt detta gjordes för att hela samhÀllet, hela ClickHouse ekosystem skulle fÄ resultatet av detta arbete.
LÄt oss gÄ vidare till transaktionsdatabaser, till OLTP-databaser, som ligger nÀrmare mig personligen.
Detta Àr DBMS-utvecklingsavdelningen med öppen kÀllkod. Dessa killar gör gatumagi för att förbÀttra transaktionella öppna databaser.
Ett av projekten som vi kan anvÀnda som exempel för att prata om hur och vad vi gör Àr Connection Pooler i Postgres.
Postgres Àr en processdatabas. Det betyder att databasen ska innehÄlla sÄ fÄ nÀtverksanslutningar som möjligt som fungerar med transaktioner.
à andra sidan, i en molnmiljö Àr en typisk situation nÀr tusen anslutningar kommer till ett kluster samtidigt. Och anslutningspoolarens uppgift Àr att packa tusen anslutningar i ett litet antal serveranslutningar.
Vi kan sÀga att anslutningspoolaren Àr en telefonoperatör som flyttar byten sÄ att de effektivt nÄr databasen.
TyvÀrr finns det inget bra ryskt ord för en anslutningspoolare. Det kallas ibland för multiplexeranslutningar. Om du vet vad du ska kalla anslutningspoolaren, var noga med att berÀtta för mig, jag kommer mycket gÀrna att tala det korrekta ryska tekniska sprÄket.
Vi utforskade anslutningspooler som var lÀmpliga för ett hanterat postgres-kluster. Och PgBouncer passade oss bÀst. Men vi har stött pÄ ett antal problem med PgBouncer. För mÄnga Är sedan gjorde Volodya Borodin rapporter om att vi anvÀnder PgBouncer, vi gillar allt, men det finns nyanser, det finns nÄgot att jobba pÄ.
Och vi jobbade. Vi fixade problemen som vi stötte pÄ, vi patchade Bouncer, vi försökte tillskriva pull-begÀran till uppströms. Men grundlÀggande enkeltrÄdning var svÄr att arbeta med.
Vi var tvungna att samla kaskader frÄn lappade Bouncers. NÀr vi har mÄnga enkelgÀngade Bouncers överförs anslutningarna pÄ det översta lagret till det inre lagret av Bouncers. Detta Àr ett dÄligt hanterat system som Àr svÄrt att bygga och skala fram och tillbaka.
Vi kom fram till att vi skapade vÄr egen anslutningspooler, som heter Odyssey. Vi skrev det frÄn grunden.
Under 2019, pÄ PgCon, presenterade jag denna avdragare för utvecklargemenskapen. Nu har vi lite mindre Àn 2 000 stjÀrnor pÄ GitHub, det vill sÀga projektet lever, projektet Àr populÀrt.
Och om du skapar ett Postgres-kluster i Yandex.Cloud, sÄ blir det ett kluster med inbyggd Odyssey, som omkonfigureras nÀr klustret skalas fram och tillbaka.
Vad har vi lÀrt oss av detta projekt? Att lansera ett konkurrerande projekt Àr alltid ett aggressivt steg, det Àr en sista utvÀg nÀr vi sÀger att det finns problem som inte löses tillrÀckligt snabbt, inte lösas i de tidsintervaller som skulle passa oss. Men det Àr en effektiv ÄtgÀrd.
PgBouncer började utvecklas snabbare.
Och nu finns det andra projekt. Till exempel pgagroal, som Àr utvecklad av Red Hat-utvecklare. De strÀvar efter liknande mÄl och implementerar liknande idéer, men, naturligtvis, med sina egna detaljer, som ligger nÀrmare pgagroals utvecklare.
Ett annat fall av att arbeta med postgres-gemenskapen Àr att ÄterstÀlla till en tidpunkt. Detta Àr en katastrofÄterstÀllning, detta Àr en ÄterstÀllning frÄn en sÀkerhetskopia.
Det finns mÄnga sÀkerhetskopior och de Àr alla olika. NÀstan varje Postgres-leverantör har sin egen backuplösning.
Om vi ââtar alla backup-system, gör en matris av funktioner och skĂ€mtsamt berĂ€knar determinanten i denna matris, dĂ„ blir den noll. Vad betyder det hĂ€r? TĂ€nk om du tar en viss sĂ€kerhetskopia, dĂ„ kan den inte sĂ€ttas ihop av alla de andras delar. Den Ă€r unik i sin implementering, den Ă€r unik i sitt syfte, den Ă€r unik i de idĂ©er som Ă€r inbĂ€ddade i den. Och de Ă€r alla specifika.
Medan vi tittade pÄ det hÀr problemet lanserade CitusData WAL-G-projektet. Detta Àr ett backup-system som gjordes med ett öga pÄ molnmiljön. CitusData Àr nu en del av Microsoft. Och i det ögonblicket gillade vi verkligen idéerna som lades ner pÄ de första utgÄvorna av WAL-G. Och vi började bidra till detta projekt.
Nu finns det mÄnga dussintals utvecklare i detta projekt, men de 10 bÀsta WAL-G-bidragsgivarna inkluderar 6 Yandexoider. Vi tog med mÄnga av vÄra idéer dit. Och, naturligtvis, implementerade vi dem sjÀlva, testade dem sjÀlva, rullade ut dem i produktion sjÀlva, anvÀnder dem sjÀlva, rÀknar ut vart vi ska gÄ hÀrnÀst, samtidigt som vi interagerar med det stora WAL-G-communityt.
Och ur vÄr synvinkel har nu detta backupsystem, inklusive att ta hÀnsyn till vÄra anstrÀngningar, blivit optimalt för molnmiljön. Det hÀr Àr bÀttre Àn att sÀkerhetskopiera Postgres till molnet.
Vad betyder det? Vi drev en ganska stor idé: sÀkerhetskopior ska vara sÀkra, billiga att köra och sÄ snabbt som möjligt att ÄterstÀlla.
Varför ska det vara billigt i drift? NÀr inget Àr trasigt ska du inte veta att du har sÀkerhetskopior. Allt fungerar bra, du slösar sÄ lite CPU som möjligt, du anvÀnder sÄ lite av dina diskresurser som möjligt och du skickar sÄ fÄ bytes till nÀtverket som möjligt för att inte störa nyttolasten av dina vÀrdefulla tjÀnster.
Och nÀr allt gÄr sönder, till exempel, slÀppte administratören data, nÄgot gick fel, och du behöver snabbt gÄ tillbaka till det förflutna, du ÄterhÀmtar dig med alla pengar, eftersom du vill ha tillbaka din data snabbt och intakt.
Och vi har utvecklat denna enkla idé. Och, som det verkar för oss, lyckades vi inse det.
Men det Àr inte allt. Vi ville ha en liten sak till. Vi ville ha mÄnga olika databaser. Alla vÄra kunder anvÀnder inte Postgres. Vissa anvÀnder MySQL, MongoDB. I communityn har andra utvecklare stött FoundationDB. Och den hÀr listan utökas hela tiden.
Gemenskapen Àlskar tanken pÄ att ha en databas som körs i en hanterad miljö i molnet. Och utvecklare underhÄller sina databaser, som kan kopieras enhetligt tillsammans med Postgres av vÄrt backupsystem.
Vad har vi lÀrt oss av den hÀr historien? VÄr produkt, som en utvecklingsavdelning, Àr inte rader kod, det Àr inte uttalanden, det Àr inte filer. VÄr produkt Àr inte pull-förfrÄgningar. Det Àr de idéer som vi förmedlar till samhÀllet. Detta Àr teknisk expertis och teknikens rörelse mot en molnmiljö.
Det finns en sÄdan databas som Postgres. Jag gillar Postgres-kÀrnan bÀst. Jag lÀgger mycket tid pÄ att utveckla Postgres-kÀrnan med samhÀllet.
Men hÀr mÄste jag sÀga att Yandex.Cloud har en intern installation av hanterade databaser. Och det började för lÀnge sedan i Yandex.Mail. Den sorts expertis som nu ledde till hanterade Postgres ackumulerades nÀr posten ville komma in pÄ Postgres.
Mail har mycket liknande krav som molnet. Det krÀver att du kan skala till ovÀntad exponentiell tillvÀxt nÀr som helst i dina data. Och posten hade redan en last med nÄgra hundratals miljoner brevlÄdor frÄn ett stort antal anvÀndare som stÀndigt gör mÄnga förfrÄgningar.
Och detta var en ganska allvarlig utmaning för teamet som utvecklade Postgres. DÄ rapporterades alla problem vi stötte pÄ till samhÀllet. Och dessa problem korrigerades och korrigerades av samhÀllet pÄ vissa stÀllen Àven pÄ nivÄn av betald support för vissa andra databaser och Ànnu bÀttre. Det vill sÀga att du kan skicka ett brev till PgSQL hacker och fÄ svar inom 40 minuter. Betald support i vissa databaser kan tro att det finns fler prioriterade saker Àn din bugg.
Nu Àr den interna installationen av Postgres nÄgra petabyte data. Det hÀr Àr nÄgra miljoner förfrÄgningar per sekund. Dessa Àr tusentals kluster. Det Àr vÀldigt storskaligt.
Men det finns en nyans. Hon lever inte pÄ moderiktiga nÀtverksenheter, utan pÄ ganska enkel hÄrdvara. Och det finns en testmiljö speciellt för intressanta nya saker.
Och nÄgon gÄng i testmiljön fick vi ett sÄdant meddelande, som indikerar att de interna invarianterna för databasindex har brutits.
En invariant Àr nÄgon form av relation som vi förvÀntar oss att alltid ha.
En mycket kritisk situation för oss. Det indikerar att vissa data kan ha gÄtt förlorade. Och dataförlust Àr nÄgot rent ut sagt katastrofalt.
Den allmĂ€nna idĂ©n som vi följer i hanterade databaser Ă€r att Ă€ven med anstrĂ€ngning kommer det att vara svĂ„rt att förlora data. Ăven om du medvetet tar bort dem, kommer du fortfarande att behöva ignorera deras frĂ„nvaro under en lĂ„ng period. DatasĂ€kerhet Ă€r en religion som vi följer ganska flitigt.
Och dÄ uppstÄr en situation som antyder att det kan finnas en situation som vi kanske inte Àr redo för. Och vi började förbereda oss för denna situation.
Det första vi gjorde var att begrava stockarna frÄn dessa tusentals kluster. Vi hittade vilka av klustren som fanns pÄ diskar med problematisk firmware som förlorade uppdateringar av datasidor. Markerade all Postgres datakod. Och vi markerade de meddelanden som indikerar övertrÀdelser av interna invarianter med kod som Àr designad för att upptÀcka datakorruption.
Denna patch accepterades praktiskt taget av samhÀllet utan mycket diskussion, eftersom det i varje specifikt fall var uppenbart att nÄgot dÄligt hade hÀnt och behövde rapporteras till loggen.
Efter detta kom vi till den punkten att vi har övervakning som skannar loggar. Och vid misstÀnkta meddelanden vÀcker han vakthavande befÀl, och vakthavande befÀl reparerar det.
Men! Att skanna loggar Àr en billig operation pÄ ett kluster och katastrofalt dyrt för tusentals kluster.
Vi skrev en förlÀngning som heter . Det skapar en vy av databasen dÀr tidigare felstatistik kan fyllas i billigt och snabbt. Och om du behöver vÀcka skötaren, kommer vi att ta reda pÄ det inte genom att skanna gigabytefiler, utan genom att extrahera nÄgra byte frÄn hashtabellen.
Denna förlÀngning har antagits till exempel i förvaret för . Om du vill anvÀnda den kan du installera den sjÀlv. SjÀlvklart Àr det öppen kÀllkod.
Men det Àr inte allt. Vi började anvÀnda Amcheck, ett communitybyggt tillÀgg, för att hitta oförÀnderliga övertrÀdelser i index.
Och vi fick reda pÄ att om du utnyttjar det i en skala, sÄ finns det buggar. Vi började göra dem. VÄra korrigeringar har godkÀnts.
Vi upptÀckte att det hÀr tillÀgget inte kan analysera GiST- och GIT-index. Vi fick dem att stödja. Men det hÀr stödet diskuteras fortfarande av communityn, eftersom detta Àr en relativt ny funktionalitet och det finns mÄnga detaljer.
Och vi fann ocksÄ att nÀr det gÀller att kontrollera index för övertrÀdelser pÄ replikeringsledaren, fungerar allt bra pÄ mastern, men pÄ repliker, pÄ följaren, Àr sökandet efter korruption inte sÄ effektivt. Alla invarianter Àr inte verifierade. Och en invariant störde oss vÀldigt mycket. Och vi pratade med samhÀllet i ett och ett halvt Är för att möjliggöra denna kontroll av repliker.
Vi skrev kod som borde följa alla kan... protokoll. Vi diskuterade den hÀr patchen ganska lÀnge med Peter Gaghan frÄn Crunchy Data. Han var tvungen att modifiera det befintliga B-trÀdet i Postgres nÄgot för att acceptera denna patch. Han blev accepterad. Och nu har kontroll av index pÄ repliker ocksÄ blivit tillrÀckligt effektiv för att upptÀcka de övertrÀdelser som vi stötte pÄ. Det vill sÀga detta Àr de övertrÀdelser som kan orsakas av fel i hÄrddiskens firmware, buggar i Postgres, buggar i Linux-kÀrnan och hÄrdvaruproblem. En ganska omfattande lista över kÀllor till problem som vi förberedde oss för.
Men förutom index finns det en sÄdan del som heap, det vill sÀga platsen dÀr data lagras. Och det finns inte mÄnga invarianter som skulle kunna kontrolleras.
Vi har en tillĂ€gg som heter Heapcheck. Vi började utveckla det. Och parallellt med oss ââbörjade Ă€ven EnterpriseDB-företaget skriva en modul, som de kallade Heapcheck pĂ„ samma sĂ€tt. Bara vi kallade det PgHeapcheck, och de kallade det bara Heapcheck. De har det med liknande funktioner, med en lite annorlunda signatur, men med samma idĂ©er. De implementerade dem lite bĂ€ttre pĂ„ sina stĂ€llen. Och tidigare lagt ut i öppen kĂ€llkod.
Och nu Àr vi i fÀrd med att utveckla deras förlÀngning, eftersom det hÀr inte lÀngre Àr deras förlÀngning, utan en community-förlÀngning. Och i framtiden Àr detta en del av kÀrnan som kommer att levereras till alla för att kunna veta om framtida problem i förvÀg.
PÄ vissa stÀllen kom vi till och med fram till att vi har falska positiva resultat i vÄra monitorer. Till exempel system 1C. NÀr man anvÀnder en databas skriver Postgres ibland data till den som den kan lÀsa sjÀlv, men pg_dump kan inte lÀsa.
Den hÀr situationen sÄg ut som korruption för vÄrt problemupptÀckningssystem. Vakthavande befÀl vÀcktes. BefÀlhavaren tittade pÄ vad som hÀnde. Efter en tid kom en kund och sa att jag hade problem. Skötaren förklarade vad problemet var. Men problemet ligger i Postgres kÀrna.
Jag hittade en diskussion om den hÀr funktionen. Och han skrev att vi stötte pÄ denna funktion och det var obehagligt, en person vaknade pÄ natten för att ta reda pÄ vad det var.
SamhÀllet svarade: "à h, verkligen, det mÄste fixas."
Jag har en enkel analogi. Om du gÄr i en sko som har ett sandkorn i sig, sÄ kan du i princip gÄ vidare - inga problem. Om du sÀljer stövlar till tusentals mÀnniskor, lÄt oss göra stövlar utan sand alls. Och om en av anvÀndarna av dina skor ska springa ett maraton, dÄ vill du göra vÀldigt bra skor och sedan skala dem till alla dina anvÀndare. Och sÄdana ovÀntade anvÀndare finns alltid i molnmiljön. Det finns alltid anvÀndare som utnyttjar klustret pÄ nÄgot originellt sÀtt. Du mÄste alltid förbereda dig pÄ detta.
Vad har vi lÀrt oss hÀr? Vi lÀrde oss en enkel sak: det viktigaste Àr att förklara för samhÀllet att det finns ett problem. Om samhÀllet har erkÀnt problemet, uppstÄr naturlig konkurrens för att lösa problemet. För alla vill lösa ett viktigt problem. Alla leverantörer, alla hackare förstÄr att de sjÀlva kan trampa pÄ denna rake, sÄ de vill eliminera dem.
Om du arbetar med nÄgot problem, men det inte stör nÄgon förutom dig, men du arbetar med det systematiskt och det till slut ansÄgs vara ett problem, sÄ kommer din pull-förfrÄgan definitivt att accepteras. Din patch kommer att accepteras, dina förbÀttringar eller till och med önskemÄl om förbÀttringar kommer att övervÀgas av communityn. Vi gör trots allt databasen bÀttre för varandra.
En intressant databas Àr Greenplum. Det Àr en mycket parallell databas baserad pÄ Postgres kodbas som jag Àr bekant med.
Och Greenplum har intressant funktionalitet - lÀgg till optimerade tabeller. Det hÀr Àr tabeller som du snabbt kan lÀgga till. De kan vara antingen kolumnÀra eller rader.
Men det fanns ingen klustring, det vill sÀga det fanns ingen funktionalitet nÀr du kan bestÀlla data som finns i tabellen i enlighet med den ordning som finns i ett av indexen.
Killarna frÄn taxin kom till mig och sa: "Andrey, du vet Postgres. Och det Àr nÀstan likadant hÀr. Byter i 20 minuter. Ta det och gör det." Jag tÀnkte, ja, jag vet Postgres, byter till 20 minuter - jag mÄste göra det hÀr.
Men nej, det var inte 20 minuter, jag har skrivit det hĂ€r i mĂ„nader. PĂ„ PgConf.Russia-konferensen kontaktade jag Heikki Linakangas frĂ„n Pivotal och frĂ„gade: âFinns det nĂ„gra problem med detta? Varför finns det ingen klustring av bifogade optimerade tabeller?â. Han sĂ€ger: "Du tar data. Sortera, översĂ€tta. Det Ă€r bara jobb." Jag: "Ă h, ja, du mĂ„ste bara gĂ„ och göra det." Han sĂ€ger, "Ja, vi behöver fria hĂ€nder för att göra det." Jag tĂ€nkte att det Ă€r precis vad jag behöver göra.
Och nÄgra mÄnader senare skickade jag in en pull-förfrÄgan som implementerade den hÀr funktionen. Denna pull-begÀran granskades av Pivotal tillsammans med communityn. Naturligtvis fanns det buggar.
Men det mest intressanta Àr att nÀr denna pull-begÀran slogs samman, hittades buggar i sjÀlva Greenplum. Vi har funnit att heaptabeller ibland bryter transaktionaliteten nÀr de klustras. Och det Àr det som mÄste fixas. Och hon Àr pÄ den plats jag just rörde vid. Och min naturliga reaktion var - ja, lÄt mig göra det hÀr ocksÄ.
Jag fixade denna bugg. Skickade en pull-förfrÄgan till fixar. Han dödades.
Efter det visade det sig att denna funktionalitet behöver skaffas i Greenplum-versionen för PostgreSQL 12. Det vill sÀga Àventyren i 20 minuter fortsÀtter med nya intressanta Àventyr. Det var intressant att beröra den nuvarande utvecklingen, dÀr samhÀllet sÄg nya och viktigaste funktioner. Den har varit död.
Men det slutade inte dÀr. Efter allt visade det sig att vi behövde skriva dokumentation för allt detta.
Jag började skriva dokumentation. Lyckligtvis kom handlingar frÄn Pivotal med. För dem Àr engelska deras modersmÄl. De hjÀlpte mig med dokumentationen. Faktum Àr att de sjÀlva skrev om det jag föreslog till riktig engelska.
Och hÀr, verkar det som, tog Àventyret slut. Och vet du vad som hÀnde dÄ? Killarna frÄn taxin kom till mig och sa: "Det finns fortfarande tvÄ Àventyr, vardera i 10 minuter." Och vad ska jag sÀga till dem? Jag sa att nu ska jag ge en rapport i skala, sÄ fÄr vi se dina Àventyr, för det hÀr Àr ett intressant jobb.
Vad har vi lÀrt oss av det hÀr fallet? Eftersom att arbeta med öppen kÀllkod alltid Àr att arbeta med en specifik person, Àr det alltid att arbeta med samhÀllet. För i varje steg arbetade jag med nÄgon utvecklare, nÄgon testare, nÄgon hackare, nÄgon dokumentÀr, nÄgon arkitekt. Jag jobbade inte med Greenplum, jag jobbade med mÀnniskor runt Greenplum.
Men! Det finns en annan viktig punkt - det Àr bara arbete. Det vill sÀga du kommer, dricker kaffe, skriver kod. Alla möjliga enkla invarianter fungerar. Gör det som vanligt - det blir bra! Och det Àr ett ganska intressant jobb. Det finns en begÀran om detta arbete frÄn Yandex.Cloud-klienter, anvÀndare av vÄra kluster bÄde inom Yandex och utanför. Och jag tror att antalet projekt som vi deltar i kommer att öka och djupet i vÄrt engagemang kommer ocksÄ att öka.
Det Àr allt. LÄt oss gÄ vidare till frÄgorna.
FrÄgestund
HallÄ! Vi har ytterligare en frÄgestund. Och i studion Andrey Borodin. Det hÀr Àr personen som just berÀttade om bidraget frÄn Yandex.Cloud och Yandex till öppen kÀllkod. VÄr rapport handlar inte helt om molnet, men samtidigt Àr vi baserade pÄ sÄdana teknologier. Om det inte var för det du gjorde inne i Yandex sÄ fanns det ingen tjÀnst i Yandex.Cloud, sÄ tack frÄn mig personligen. Och den första frÄgan frÄn sÀndningen: "Vad stÄr det i vart och ett av projekten som du nÀmnde?".
SÀkerhetskopieringssystemet i WAL-G Àr skrivet i Go. Detta Àr ett av de senaste projekten vi har arbetat med. Han Àr bokstavligen bara 3 Är gammal. Och databasen handlar ofta om tillförlitlighet. Och det betyder att databaserna Àr ganska gamla och de Àr oftast skrivna i C. Postgres-projektet startade för cirka 30 Är sedan. DÄ var C89 rÀtt val. Och Postgres stÄr skrivet pÄ den. Modernare databaser som ClickHouse Àr vanligtvis redan skrivna i C++. All systemutveckling bygger pÄ C och C++.
En frÄga frÄn vÄr ekonomichef, som Àr ansvarig för utgifterna i molnet: "Varför spenderar molnet pengar pÄ att stödja öppen kÀllkod?".
Det finns ett enkelt svar för ekonomichefen. Vi gör detta för att förbÀttra vÄra tjÀnster. PÄ vilket sÀtt kan vi göra bÀttre? Vi kan göra saker mer effektiva, snabbare, göra saker mer skalbara. Men för oss handlar den hÀr historien i första hand om tillförlitlighet. Till exempel, i backupsystemet kommer vi att granska 100 % av de patchar som gÀller för det. Vi vet vad koden Àr. Och vi Àr mer avslappnade nÀr vi rullar ut nya versioner till produktion. Det vill sÀga, för det första handlar det om förtroende, om beredskap för utveckling och om tillförlitlighet
En annan frĂ„ga: "Ăr kraven för externa anvĂ€ndare som bor i Yandex.Cloud annorlunda Ă€n interna anvĂ€ndare som bor i det interna molnet?"
Belastningsprofilen Àr förstÄs annorlunda. Men frÄn min avdelnings synvinkel skapas alla speciella och intressanta fall pÄ en icke-standardiserad belastning. Utvecklare med fantasi, utvecklare som gör ovÀntade saker, de Àr lika sannolikt att hitta bÄde inuti och utanför. I detta avseende Àr vi alla ungefÀr likadana. Och förmodligen kommer den enda viktiga egenskapen i Yandex-driften av databaser att vara att vi har en undervisning i Yandex. Vid nÄgon tidpunkt gÄr nÄgon Ätkomstzon helt i skuggan, och alla Yandex-tjÀnster mÄste pÄ nÄgot sÀtt fortsÀtta att fungera, trots detta. HÀr Àr en liten skillnad. Men det skapar mycket forskning och utveckling i grÀnssnittet mellan databasen och nÀtverksstacken. Annars skapar externa och interna installationer samma funktionsförfrÄgningar och liknande önskemÄl för förbÀttrad tillförlitlighet och prestanda.
NÀsta frÄga Àr: "Hur kÀnner du personligen om det faktum att mycket av det du gör anvÀnds av andra moln?". Vi kommer inte att nÀmna specifika, men mÄnga av projekten som vi gjorde i Yandex.Cloud anvÀnds i andras moln.
Detta Àr coolt. För det första Àr det ett tecken pÄ att vi har gjort nÄgot rÀtt. Och det kliar pÄ egot. Och vi Àr mer sÀkra pÄ att vi tog rÀtt beslut. à andra sidan Àr detta förhoppningen att detta i framtiden kommer att ge oss nya idéer, nya önskemÄl frÄn tredjepartsanvÀndare. De flesta problem pÄ GitHub skapas av enskilda systemadministratörer, individuella DBA:er, enskilda arkitekter, enskilda ingenjörer, men ibland kommer personer med systematisk erfarenhet och sÀger att vi i 30% av vissa fall har det hÀr problemet och lÄt oss fundera pÄ hur vi ska lösa det. Detta Àr vad vi ser fram emot mest. Vi ser fram emot att dela erfarenheter med andra molnplattformar.
Du pratade mycket om maraton. Jag vet att du sprang ett maraton i Moskva. Som ett resultat? Körde om killarna frÄn PostgreSQL?
Nej, Oleg Bartunov springer vÀldigt fort. Han slutade en timme före mig. Sammantaget Àr jag nöjd med det jag sprang. För mig var bara att avsluta en prestation. I allmÀnhet Àr det förvÄnande att det finns sÄ mÄnga löpare i postgres-gemenskapen. Det verkar för mig att det finns ett samband mellan aerob sport och önskan om systemprogrammering.
SÀger du att det inte finns nÄgra löpare pÄ ClickHouse?
Jag vet med sÀkerhet att de finns dÀr. ClickHouse Àr ocksÄ en databas. Förresten, nu skriver Oleg till mig: "LÄt oss springa efter rapporten?". Det hÀr Àr en bra idé.
En annan frÄga frÄn sÀndningen frÄn Nikita: "Varför fixade du felet i Greenplum sjÀlv och gav det inte till juniorer?" Det Àr visserligen inte sÀrskilt tydligt hÀr vilken typ av bugg och i vilken tjÀnst, men förmodligen Àr den du pratade om menad.
Ja, i princip skulle man kunna ge det till nÄgon. Det var bara koden som jag just Àndrade. Och det var naturligt att fortsÀtta göra det just dÀr. I princip Àr idén att dela expertis med ett team en bra idé. Vi kommer definitivt att dela Greenplum-uppgifter mellan alla medlemmar i vÄr division.
Eftersom vi pratar om juniorer, en sÄdan frÄga. Personen bestÀmde sig för att skapa den första commiten i Postgres. Vad behöver han göra för att göra det första commit?
Detta Àr en intressant frÄga: "Var ska man börja?". Det brukar vara svÄrt att börja med nÄgot i kÀrnan. Postgres har till exempel en att göra-lista. Men i sjÀlva verket Àr det hÀr en lista över vad de försökte göra, men inte lyckades. Det hÀr Àr svÄra saker. Och du kan vanligtvis hitta nÄgra verktyg i ekosystemet, nÄgra tillÀgg som kan förbÀttras, som fÄr mindre uppmÀrksamhet frÄn kÀrnutvecklarna. Och följaktligen finns det fler punkter för tillvÀxt. PÄ Google Summer of code-programmet varje Är lÀgger postgres-communityt upp mÄnga olika Àmnen som kan tas upp. I Är verkar vi ha haft tre elever. En skrev till och med i WAL-G om Àmnen som Àr viktiga för Yandex. Saker och ting Àr lÀttare i Greenplum Àn i Postgres-communityt eftersom Greenplum-hackarna Àr vÀldigt bra med pull-förfrÄgningar och börjar granska direkt. Att skicka en patch till Postgres Àr nÄgon slags historia i mÄnader, och Greenplum kommer om en dag och ser vad du har gjort. En annan sak Àr att Greenplum behöver lösa faktiska problem. Greenplum Àr inte allmÀnt utnyttjad, sÄ att hitta ditt problem Àr ganska svÄrt. Och först av allt Àr det nödvÀndigt att lösa, naturligtvis, problem.
KĂ€lla: will.com