Yandex' bidrag til følgende databaser vil blive gennemgået.
- klikhus
- Odyssey
- Gendannelse til et tidspunkt (WAL-G)
- PostgreSQL (inklusive logerrors, Amcheck, heapcheck)
- Greenplum
Video:
Hej Verden! Mit navn er Andrey Borodin. Og det, jeg gør hos Yandex.Cloud, er at udvikle åbne relationsdatabaser i Yandex.Cloud- og Yandex.Cloud-kundernes interesse.
I dette foredrag vil vi tale om de udfordringer, åbne databaser står over for i stor skala. Hvorfor er det vigtigt? Fordi små, små problemer, der som myg så bliver til elefanter. De bliver store, når man har mange klynger.
Men det er ikke det vigtigste. Der sker utrolige ting. Ting, der sker i én ud af en million tilfælde. Og i et cloudmiljø skal man være forberedt på det, for utrolige ting bliver højst sandsynlige, når noget eksisterer i skala.
Men! Hvad er fordelen ved åbne databaser? Faktum er, at du har en teoretisk mulighed for at håndtere ethvert problem. Du har kildekoden, du har viden om programmering. Vi kombinerer det, og det virker.
Hvilke tilgange er der i arbejdet med open source-software?
- Den mest ligetil tilgang er at bruge software. Hvis du bruger protokoller, hvis du bruger standarder, hvis du bruger formater, hvis du skriver forespørgsler i open source-software, så understøtter du det allerede.
- Du gør dets økosystem større. Du gør sandsynligheden for tidlig opdagelse af en fejl større. Du øger pålideligheden af dette system. Du øger tilgængeligheden af udviklere på markedet. Du forbedrer denne software. Du er allerede en bidragyder, hvis du bare fik stilet dig og puslede med noget der.
- En anden forståelig tilgang er sponsorering af open source-software. For eksempel det velkendte Google Summer of Code-program, hvor Google betaler et stort antal studerende fra hele verden forståelige penge, så de udvikler åbne softwareprojekter, der opfylder visse licenskrav.
- Dette er en meget interessant tilgang, fordi den giver softwaren mulighed for at udvikle sig uden at flytte fokus væk fra fællesskabet. Google, som en teknologigigant, siger ikke, at vi vil have denne funktion, vi vil rette denne fejl, og det er her, vi skal grave. Google siger: "Gør, hvad du gør. Bare fortsæt med at arbejde, som du har arbejdet, og alt vil være godt."
- Den næste tilgang til at deltage i open source er deltagelse. Når du har et problem i open source-software, og der er udviklere, begynder dine udviklere at løse problemerne. De begynder at gøre din infrastruktur mere effektiv, dine programmer hurtigere og mere pålidelige.
Et af de mest berømte Yandex-projekter inden for open source-software er ClickHouse. Dette er en database, der blev født som et svar på de udfordringer, Yandex.Metrica står over for.
Og som en database blev den lavet i open source for at skabe et økosystem og udvikle det sammen med andre udviklere (ikke kun inden for Yandex). Og nu er der tale om et stort projekt, hvor mange forskellige virksomheder er involveret.
I Yandex.Cloud skabte vi ClickHouse oven på Yandex Object Storage, altså oven på cloud storage.
Hvorfor er dette vigtigt i skyen? Fordi enhver database fungerer i denne trekant, i denne pyramide, i dette hierarki af hukommelsestyper. Du har hurtige men små registre og billige store men langsomme SSD'er, harddiske og nogle andre blokenheder. Og hvis du er effektiv i toppen af pyramiden, så har du en hurtig database. hvis du er effektiv i bunden af denne pyramide, så har du en skaleret database. Og i denne henseende er tilføjelse af endnu et lag nedefra en logisk tilgang til at øge skalerbarheden af databasen.
Hvordan kunne det lade sig gøre? Dette er et vigtigt punkt i denne betænkning.
- Vi kunne implementere ClickHouse over MDS. MDS er en intern Yandex cloud storage-grænseflade. Den er mere kompleks end den almindelige S3-protokol, men den er mere velegnet til en blokenhed. Det er bedre til at optage data. Det kræver mere programmering. Programmører vil programmere, det er endda godt, det er interessant.
- S3 er en mere almindelig tilgang, der gør grænsefladen enklere på bekostning af mindre tilpasning til visse typer arbejdsbelastninger.
Da vi naturligvis ville levere funktionalitet til hele ClickHouse-økosystemet og udføre den opgave, der er nødvendig i Yandex.Cloud, besluttede vi os for at sikre, at hele ClickHouse-fællesskabet ville drage fordel af det. Vi implementerede ClickHouse over S3, ikke ClickHouse over MDS. Og det er meget arbejde.
referencer:
"Filsystemabstraktionslag"
"AWS SDK S3 integration"
"Basisimplementering af IDisk-interface til S3"
"Integration af log storage engines med IDisk interface"
"Logmotorunderstøttelse til S3 og SeekableReadBuffer"
"Storage Stripe Log S3 support"
"Storage MergeTree initial support for S3"
"MergeTree fuld understøttelse af S3"
"Support ReplicatedMergeTree over S3"
"Tilføj standardlegitimationsoplysninger og brugerdefinerede overskrifter til s3-lagring"
"S3 med dynamisk proxy-konfiguration"
"S3 med proxy resolver"
Dette er en pull request-liste til implementering af et virtuelt filsystem i ClickHouse. Dette er et stort antal pull-anmodninger.
referencer:
"DiskS3 hardlinks optimal implementering"
"S3 HTTP-klient — Undgå at kopiere svarstrøm til hukommelsen"
"Undgå at kopiere hele svarstrømmen ind i hukommelsen i S3 HTTP
klient"
"Evne til at cachemærke og indeksere filer til S3-disk"
"Flyt dele fra DiskLocal til DiskS3 parallelt"
Men arbejdet sluttede ikke der. Efter funktionen blev lavet, krævede der noget mere arbejde for at optimere denne funktionalitet.
referencer:
"Tilføj SelectedRows og SelectedBytes begivenheder"
"Tilføj profileringsbegivenheder fra S3-anmodning til system.events"
"Tilføj QueryTimeMicroseconds, SelectQueryTimeMicroseconds og InsertQueryTimeMicroseconds"
Og så var det nødvendigt at gøre det diagnosticerbart, sætte overvågning op og gøre det overskueligt.
Og alt dette blev gjort, så hele samfundet, hele ClickHouse-økosystemet, modtog resultatet af dette arbejde.
Lad os gå videre til transaktionsdatabaser, til OLTP-databaser, som er tættere på mig personligt.
Dette er open source DBMS-udviklingsafdelingen. Disse fyre laver gademagi for at forbedre transaktionelle åbne databaser.
Et af projekterne, hvor vi ved hjælp af et eksempel kan tale om hvordan og hvad vi gør, er Connection Pooler i Postgres.
Postgres er en procesdatabase. Det betyder, at databasen skal have så få netværksforbindelser som muligt, der håndterer transaktioner.
På den anden side, i et cloudmiljø, er en typisk situation, når tusind forbindelser kommer til en klynge på én gang. Og forbindelsespoolerens opgave er at pakke tusinde forbindelser ind i et lille antal serverforbindelser.
Vi kan sige, at forbindelsespooleren er telefonoperatøren, der omarrangerer bytes, så de effektivt når databasen.
Desværre er der ikke noget godt russisk ord for forbindelsespooler. Nogle gange kaldes det multiplekserforbindelser. Hvis du ved, hvad du skal kalde forbindelsespooleren, så sørg for at fortælle mig, jeg vil meget gerne tale det korrekte russiske tekniske sprog.
Vi undersøgte forbindelsespoolere, der var egnede til en administreret postgres-klynge. Og PgBouncer var det bedste valg for os. Men vi stødte på en række problemer med PgBouncer. For mange år siden gav Volodya Borodin rapporter om, at vi bruger PgBouncer, vi kan lide alt, men der er nuancer, der er noget at arbejde på.
Og vi arbejdede. Vi løste de problemer, vi stødte på, vi lappede Bouncer og forsøgte at skubbe pull-anmodninger opstrøms. Men grundlæggende single-threading var svær at arbejde med.
Vi var nødt til at samle kaskader fra lappede Bouncers. Når vi har mange enkelttrådede Bouncers, overføres forbindelserne på det øverste lag til det inderste lag af Bouncers. Dette er et dårligt styret system, som er svært at bygge og skalere frem og tilbage.
Vi kom frem til, at vi lavede vores egen forbindelsespooler, som hedder Odyssey. Vi skrev det fra bunden.
I 2019, på PgCon-konferencen, præsenterede jeg denne pooler for udviklerfællesskabet. Nu har vi lidt mindre end 2 stjerner på GitHub, dvs. projektet er i live, projektet er populært.
Og hvis du opretter en Postgres-klynge i Yandex.Cloud, så bliver det en klynge med indbygget Odyssey, som omkonfigureres, når du skalerer klyngen frem eller tilbage.
Hvad har vi lært af dette projekt? At lancere et konkurrerende projekt er altid et aggressivt skridt, det er en ekstrem foranstaltning, når vi siger, at der er problemer, der ikke bliver løst hurtigt nok, ikke bliver løst i de tidsintervaller, der ville passe os. Men dette er en effektiv foranstaltning.
PgBouncer begyndte at udvikle sig hurtigere.
Og nu er der dukket andre projekter op. For eksempel pgagroal, som er udviklet af Red Hat-udviklere. De forfølger lignende mål og implementerer lignende ideer, men selvfølgelig med deres egne specifikationer, som er tættere på pgagroal-udviklere.
Et andet tilfælde af at arbejde med postgres-samfundet er at genoprette til et tidspunkt. Dette er gendannelse efter en fejl, dette er gendannelse fra en sikkerhedskopi.
Der er mange sikkerhedskopier, og de er alle forskellige. Næsten alle Postgres-leverandører har sin egen backup-løsning.
Hvis du tager alle backup-systemerne, opretter en funktionsmatrix og i spøg beregner determinanten i denne matrix, vil den være nul. Hvad betyder det? Hvad hvis du tager en specifik backup-fil, så kan den ikke samles af stykker af alle de andre. Den er unik i sin implementering, den er unik i sit formål, den er unik i de ideer, der er indlejret i den. Og de er alle specifikke.
Mens vi arbejdede på dette problem, lancerede CitusData WAL-G-projektet. Dette er et backup-system, der er lavet med øje for cloud-miljøet. Nu er CitusData allerede en del af Microsoft. Og i det øjeblik kunne vi virkelig godt lide de ideer, der blev fastlagt i de første udgivelser af WAL-G. Og vi begyndte at bidrage til dette projekt.
Nu er der mange snesevis af udviklere i dette projekt, men de 10 bedste bidragydere til WAL-G inkluderer 6 Yandexoider. Vi bragte mange af vores ideer der. Og selvfølgelig implementerede vi dem selv, testede dem selv, rullede dem ud i produktionen selv, vi bruger dem selv, vi finder selv ud af, hvor vi skal flytte videre, mens vi interagerer med det store WAL-G-fællesskab.
Og set fra vores synspunkt er dette backupsystem nu, herunder at tage hensyn til vores indsats, blevet optimalt til et cloudmiljø. Dette er den bedste pris for at sikkerhedskopiere Postgres i skyen.
Hvad betyder det? Vi promoverede en ret stor idé: backup skal være sikker, billig i drift og så hurtig som muligt at gendanne.
Hvorfor skal det være billigt i drift? Når intet er i stykker, skal du ikke vide, at du har sikkerhedskopier. Alt fungerer fint, du spilder så lidt CPU som muligt, du bruger så lidt af dine diskressourcer som muligt, og du sender så få bytes til netværket som muligt for ikke at forstyrre nyttelasten af dine værdifulde tjenester.
Og når alt går i stykker, f.eks. droppede administratoren dataene, noget gik galt, og du har akut brug for at gå tilbage til fortiden, du kommer dig med alle pengene, fordi du vil have dine data tilbage hurtigt og intakte.
Og vi promoverede denne enkle idé. Og, det ser ud til, at vi formåede at implementere det.
Men det er ikke alt. Vi ville have en lille ting mere. Vi ville have mange forskellige databaser. Ikke alle vores kunder bruger Postgres. Nogle mennesker bruger MySQL, MongoDB. I fællesskabet har andre udviklere støttet FoundationDB. Og denne liste udvides konstant.
Fællesskabet kan lide ideen om, at databasen køres i et administreret miljø i skyen. Og udviklere vedligeholder deres databaser, som kan sikkerhedskopieres ensartet sammen med Postgres med vores backup-system.
Hvad har vi lært af denne historie? Vores produkt, som en udviklingsafdeling, er ikke kodelinjer, det er ikke udsagn, det er ikke filer. Vores produkt er ikke pull-anmodninger. Det er de ideer, vi formidler til samfundet. Dette er teknologisk ekspertise og teknologiens bevægelse mod et cloudmiljø.
Der er sådan en database som Postgres. Jeg kan bedst lide Postgres-kernen. Jeg bruger meget tid på at udvikle Postgres-kernen med fællesskabet.
Men her skal det siges, at Yandex.Cloud har en intern installation af administrerede databaser. Og det startede for længe siden i Yandex.Mail. Den ekspertise, der nu har ført til administreret Postgres, blev oparbejdet, da posten ville flytte ind i Postgres.
Mail har meget lignende krav til skyen. Det kræver, at du kan skalere til uventet eksponentiel vækst på et hvilket som helst tidspunkt i dine data. Og mailen havde allerede en belastning med nogle hundrede millioner postkasser fra et enormt antal brugere, som konstant laver mange forespørgsler.
Og dette var en ganske alvorlig udfordring for holdet, der udviklede Postgres. Dengang blev alle problemer, vi stødte på, rapporteret til fællesskabet. Og disse problemer blev rettet og rettet af fællesskabet nogle steder, endda på niveau med betalt støtte til nogle andre databaser og endnu bedre. Det vil sige, at du kan sende et brev til PgSQL hacker og modtage et svar inden for 40 minutter. Betalt support i nogle databaser tror måske, at der er flere prioriterede ting end din fejl.
Nu er den interne installation af Postgres nogle petabyte data. Det er nogle millioner af anmodninger pr. sekund. Det er tusindvis af klynger. Det er meget storstilet.
Men der er en nuance. Den lever ikke på fancy netværksdrev, men på ret simpel hardware. Og der er et testmiljø specielt til interessante nye ting.
Og på et bestemt tidspunkt i testmiljøet modtog vi en besked, der indikerede, at de interne invarianter af databaseindekserne blev overtrådt.
En invariant er en slags forhold, som vi forventer altid at have.
En meget kritisk situation for os. Det indikerer, at nogle data kan være gået tabt. Og tab af data er noget direkte katastrofalt.
Den generelle idé, som vi følger i administrerede databaser, er, at selv med indsats, vil det være svært at miste data. Selvom du bevidst fjerner dem, bliver du stadig nødt til at ignorere deres fravær i en længere periode. Datasikkerhed er en religion, som vi følger ganske flittigt.
Og her opstår der en situation, der tyder på, at der kan være en situation, som vi måske ikke er forberedt på. Og vi begyndte at forberede os på denne situation.
Det første, vi gjorde, var at begrave stammerne fra disse tusindvis af klynger. Vi fandt, hvilke af klyngerne, der var placeret på diske med problematisk firmware, der mistede datasideopdateringer. Markeret alle Postgres datakode. Og vi markerede de beskeder, der indikerer overtrædelser af interne invarianter, med kode, der er designet til at opdage datakorruption.
Denne patch blev praktisk taget accepteret af fællesskabet uden megen diskussion, fordi det i hvert enkelt tilfælde var tydeligt, at der var sket noget slemt og skulle rapporteres til loggen.
Herefter kom vi til det punkt, at vi har overvågning, der scanner logs. Og i tilfælde af mistænkelige beskeder vækker han vagtchefen, og vagtchefen reparerer den.
Men! Scanning af logs er en billig operation på én klynge og katastrofalt dyr for tusinde klynger.
Vi skrev en udvidelse kaldet . Det skaber et overblik over databasen, hvor du billigt og hurtigt kan udvælge statistik over tidligere fejl. Og hvis vi skal vække vagthavende, så finder vi ud af dette uden at scanne gigabyte-filer, men ved at udtrække et par bytes fra hash-tabellen.
Denne udvidelse er f.eks. taget i brug i depotet for . Hvis du vil bruge det, kan du installere det selv. Det er selvfølgelig open source.
Men det er ikke alt. Vi begyndte at bruge Amcheck, en community-bygget udvidelse, til at finde invariable overtrædelser i indekser.
Og vi fandt ud af, at hvis du betjener det i stor skala, er der fejl. Vi begyndte at reparere dem. Vores rettelser er blevet accepteret.
Vi opdagede, at denne udvidelse ikke kan analysere GiST- og GIT-indekser. Vi fik dem til at støtte. Men denne support bliver stadig diskuteret af fællesskabet, fordi dette er en relativt ny funktionalitet, og der er mange detaljer der.
Og vi opdagede også, at når man tjekker indekser for overtrædelser på replikeringslederen, på masteren, fungerer alt godt, men på replikaerne, på følgeren, er søgningen efter korruption ikke så effektiv. Ikke alle invarianter er kontrolleret. Og en invariant generede os meget. Og vi brugte halvandet år på at kommunikere med samfundet for at aktivere denne kontrol af replikaer.
Vi skrev kode, der skulle følge alle kan... protokoller. Vi diskuterede denne patch i et stykke tid med Peter Gaghan fra Crunchy Data. Han var nødt til at ændre lidt på det eksisterende B-træ i Postgres for at acceptere denne patch. Han blev accepteret. Og nu er kontrol af indekser på replikaer også blevet effektiv nok til at opdage de overtrædelser, vi stødte på. Det vil sige, det er de overtrædelser, der kan være forårsaget af fejl i diskfirmware, fejl i Postgres, fejl i Linux-kernen og hardwareproblemer. En ret omfattende liste over kilder til problemer, som vi forberedte os på.
Men udover indekser er der sådan en del som heap, det vil sige det sted, hvor dataene er gemt. Og der er ikke mange invarianter, der kunne kontrolleres.
Vi har en udvidelse kaldet Heapcheck. Vi begyndte at udvikle det. Og sideløbende begyndte EnterpriseDB-virksomheden sammen med os også at skrive et modul, som de på samme måde kaldte Heapcheck. Kun vi kaldte det PgHeapcheck, og de kaldte det bare Heapcheck. De har det med lignende funktioner, en lidt anderledes signatur, men med de samme ideer. De implementerede dem lidt bedre nogle steder. Og de postede det i open source før.
Og nu udvikler vi deres udvidelse, for det er ikke længere deres udvidelse, men udvidelsen af fællesskabet. Og i fremtiden er dette en del af kernen, der vil blive leveret til alle, så de på forhånd kan vide om fremtidige problemer.
Nogle steder kom vi endda frem til, at vi har falske positiver i vores overvågningssystemer. For eksempel 1C-systemet. Når du bruger en database, skriver Postgres nogle gange data ind i den, som den kan læse, men pg_dump kan ikke læse.
Denne situation lignede korruption i vores problemregistreringssystem. Vagtchefen blev vækket. Vagtchefen så på, hvad der skete. Efter noget tid kom en kunde og sagde, at jeg havde problemer. Lederen forklarede, hvad problemet var. Men problemet ligger i Postgres-kernen.
Jeg fandt en diskussion om denne funktion. Og han skrev, at vi stødte på denne funktion, og det var ubehageligt, en person vågnede om natten for at finde ud af, hvad det var.
Samfundet svarede: "Åh, vi er virkelig nødt til at ordne det."
Jeg har en simpel analogi. Går du i en sko, der har et sandkorn i, så kan du i princippet komme videre - ikke noget problem. Hvis du sælger støvler til tusindvis af mennesker, så lad os lave støvler uden sand overhovedet. Og hvis en af brugerne af dine sko skal løbe et maraton, så vil du lave rigtig gode sko, og så skalere dem til alle dine brugere. Og sådanne uventede brugere er altid i skymiljøet. Der er altid brugere, der udnytter klyngen på en original måde. Du skal altid forberede dig på dette.
Hvad har vi lært her? Vi lærte en simpel ting: Det vigtigste er at forklare samfundet, at der er et problem. Hvis samfundet har erkendt problemet, så opstår der naturlig konkurrence om at løse problemet. Fordi alle ønsker at løse et vigtigt problem. Alle leverandører, alle hackere forstår, at de selv kan træde på denne rake, så de ønsker at eliminere dem.
Hvis du arbejder på et problem, men det generer ingen andre end dig, men du arbejder på det systematisk og det i sidste ende betragtes som et problem, så vil din pull-anmodning helt sikkert blive accepteret. Din patch vil blive accepteret, dine forbedringer eller endda anmodninger om forbedringer vil blive gennemgået af fællesskabet. I sidste ende gør vi databasen bedre for hinanden.
En interessant database er Greenplum. Det er en meget parallel database baseret på Postgres-kodebasen, som jeg er meget fortrolig med.
Og Greenplum har interessant funktionalitet - tilføj optimerede tabeller. Det er tabeller, som du hurtigt kan tilføje til. De kan enten være søjleformede eller rækker.
Men der var ingen clustering, dvs. der var ingen funktionalitet, hvor du kan arrangere dataene i tabellen i overensstemmelse med den rækkefølge, der er i et af indekserne.
Fyrene fra taxaen kom til mig og sagde: "Andrey, du kender Postgres. Og her er det næsten det samme. Skift til 20 minutter. Du tager det og gør det." Jeg tænkte, at ja, jeg kender Postgres, skiftende i 20 minutter - jeg skal gøre dette.
Men nej, det var ikke 20 minutter, jeg skrev det over måneder. Ved PgConf.Russia-konferencen henvendte jeg mig til Heikki Linakangas fra Pivotal og spurgte: “Er der nogen problemer med dette? Hvorfor er der ingen tilføjelsesoptimeret tabelklynger?" Han siger: "Du tager dataene. Du sorterer, du omarrangerer. Det er bare et arbejde." Mig: "Åh, ja, du skal bare tage det og gøre det." Han siger: "Ja, vi har brug for frie hænder til at gøre dette." Jeg tænkte, at det her skulle jeg bestemt gøre.
Og et par måneder senere indsendte jeg en pull-anmodning, der implementerede denne funktionalitet. Denne pull-anmodning blev gennemgået af Pivotal sammen med fællesskabet. Selvfølgelig var der fejl.
Men det mest interessante er, at da denne pull-anmodning blev slået sammen, blev der fundet fejl i selve Greenplum. Vi har fundet ud af, at heap-tabeller nogle gange bryder transaktionaliteten, når de klynges. Og det er en ting, der skal rettes. Og hun er på det sted, jeg lige har rørt ved. Og min naturlige reaktion var - okay, lad mig også gøre dette.
Jeg har rettet denne fejl. Sendte en pull-anmodning til fixerne. Han blev dræbt.
Hvorefter det viste sig, at denne funktionalitet skal skaffes i Greenplum-versionen til PostgreSQL 12. Det vil sige, at det 20 minutter lange eventyr fortsætter med nye interessante eventyr. Det var interessant at røre ved den aktuelle udvikling, hvor samfundet skærer nye og vigtigste funktioner. Det er frosset.
Men det sluttede ikke der. Efter alt viste det sig, at vi skulle skrive dokumentation for alt dette.
Jeg begyndte at skrive dokumentation. Heldigvis kom dokumentaristerne fra Pivotal med. Engelsk er deres modersmål. De hjalp mig med dokumentationen. Faktisk omskrev de selv, hvad jeg foreslog, til rigtig engelsk.
Og her, ser det ud til, endte eventyret. Og ved du, hvad der skete så? Fyrene fra taxaen kom til mig og sagde: "Der er stadig to eventyr, hver i 10 minutter." Og hvad skal jeg fortælle dem? Jeg sagde, at nu vil jeg give en rapport på skala, så vil vi se dine eventyr, for det er et interessant job.
Hvad lærte vi af denne sag? Fordi arbejde med open source altid er at arbejde med en bestemt person, er det altid at arbejde med fællesskabet. For på hvert eneste trin arbejdede jeg med en udvikler, en tester, en hacker, en dokumentarist, en eller anden arkitekt. Jeg arbejdede ikke med Greenplum, jeg arbejdede med folk omkring Greenplum.
Men! Der er en anden vigtig pointe - det er bare arbejde. Det vil sige, du kommer, drikker kaffe, skriver kode. Alle mulige simple invarianter virker. Gør det normalt - det bliver fint! Og det er et ret interessant job. Der er en anmodning om dette arbejde fra Yandex.Cloud-klienter, brugere af vores klynger både i Yandex og udenfor. Og jeg tror, at antallet af projekter, vi deltager i, vil stige, og dybden af vores involvering vil også stige.
Det er alt. Lad os gå videre til spørgsmålene.
Spørgsmål session
Hej! Vi har endnu en spørgsmål og svar session. Og i studiet Andrei Borodin. Dette er den person, der lige har fortalt dig om bidraget fra Yandex.Cloud og Yandex til open source. Vores rapport nu handler ikke udelukkende om skyen, men samtidig er vi baseret på sådanne teknologier. Uden det, du gjorde i Yandex, ville der ikke være nogen service i Yandex.Cloud, så tak fra mig personligt. Og det første spørgsmål fra udsendelsen: "Hvad er hvert af de projekter, du nævnte, skrevet på?"
Sikkerhedskopieringssystemet i WAL-G er skrevet i Go. Dette er et af de nyere projekter, vi har arbejdet på. Han er bogstaveligt talt kun 3 år gammel. Og en database handler ofte om pålidelighed. Og det betyder, at databaserne er ret gamle, og de er normalt skrevet i C. Postgres-projektet startede for omkring 30 år siden. Så var C89 det rigtige valg. Og Postgres er skrevet på den. Mere moderne databaser som ClickHouse er normalt skrevet i C++. Al systemudvikling er baseret på C og C++.
Et spørgsmål fra vores økonomichef, som er ansvarlig for udgifterne i Cloud: "Hvorfor bruger Cloud penge på at understøtte open source?"
Der er et enkelt svar til økonomichefen her. Det gør vi for at gøre vores tjenester bedre. På hvilke måder kan vi gøre det bedre? Vi kan gøre tingene mere effektivt, hurtigere og gøre tingene mere skalerbare. Men for os handler denne historie primært om pålidelighed. For eksempel gennemgår vi i et backup-system 100 % af de patches, der gælder for det. Vi ved, hvad koden er. Og vi er mere komfortable med at udrulle nye versioner til produktion. Det vil sige, at det først og fremmest handler om tillid, om parathed til udvikling og om pålidelighed
Et andet spørgsmål: "Er kravene til eksterne brugere, der bor i Yandex.Cloud, forskellige fra interne brugere, der bor i den interne sky?"
Belastningsprofilen er naturligvis anderledes. Men fra min afdelings synspunkt er alle de specielle og interessante sager skabt på en ikke-standard belastning. Udviklere med fantasi, udviklere, der gør det uventede, er lige så tilbøjelige til at blive fundet både internt og eksternt. I denne henseende er vi alle nogenlunde ens. Og sandsynligvis vil den eneste vigtige funktion i Yandex-driften af databaser være, at vi inde i Yandex har en undervisning. På et tidspunkt går en eller anden tilgængelighedszone fuldstændig i skygge, og alle Yandex-tjenester skal på en eller anden måde fortsætte med at fungere på trods af dette. Dette er en lille forskel. Men det skaber en masse forskningsudvikling i grænsefladen af databasen og netværksstakken. Ellers genererer eksterne og interne installationer de samme anmodninger om funktioner og lignende anmodninger om at forbedre pålideligheden og ydeevnen.
Næste spørgsmål: "Hvordan har du det personligt med det faktum, at meget af det, du laver, bliver brugt af andre skyer?" Vi vil ikke nævne specifikke, men mange projekter, der blev udført i Yandex.Cloud, bruges i andre menneskers skyer.
Det her er sejt. For det første er det et tegn på, at vi har gjort noget rigtigt. Og det kradser egoet. Og vi er mere sikre på, at vi har truffet den rigtige beslutning. På den anden side er dette håbet om, at dette i fremtiden vil bringe os nye ideer, nye anmodninger fra tredjepartsbrugere. De fleste problemer på GitHub er skabt af individuelle systemadministratorer, individuelle DBA'er, individuelle arkitekter, individuelle ingeniører, men nogle gange kommer folk med systematisk erfaring og siger, at vi i 30% af visse tilfælde har dette problem, og lad os tænke over, hvordan vi løser det. Det er det, vi glæder os mest til. Vi ser frem til at dele erfaringer med andre cloud-platforme.
Du talte meget om maraton. Jeg ved, at du løb et maraton i Moskva. Som resultat? Overhalede gutterne fra PostgreSQL?
Nej, Oleg Bartunov løber meget hurtigt. Han sluttede en time før mig. Alt i alt er jeg tilfreds med, hvor langt jeg er nået. For mig var bare at afslutte en præstation. Samlet set er det overraskende, at der er så mange løbere i postgres-samfundet. Det forekommer mig, at der er en form for sammenhæng mellem aerob sport og ønsket om systemprogrammering.
Siger du, at der ikke er nogen løbere på ClickHouse?
Jeg ved med sikkerhed, at de er der. ClickHouse er også en database. Forresten skriver Oleg nu til mig: "Skal vi løbe en tur efter rapporten?" Det er en god idé.
Et andet spørgsmål fra udsendelsen fra Nikita: "Hvorfor rettede du selv fejlen i Greenplum og ikke gav den til juniorer?" Sandt nok er det ikke særlig klart, hvad fejlen er og i hvilken tjeneste, men det betyder sandsynligvis den, du talte om.
Ja, det kunne i princippet være givet til nogen. Det var bare koden, jeg lige har ændret. Og det var naturligt at fortsætte med det med det samme. I princippet er ideen om at dele ekspertise med teamet en god idé. Vi vil helt sikkert dele Greenplum-opgaver blandt alle medlemmer af vores division.
Da vi taler om juniorer, er her et spørgsmål. Personen besluttede at oprette den første commit i Postgres. Hvad skal han gøre for at foretage den første forpligtelse?
Dette er et interessant spørgsmål: "Hvor skal man starte?" Det er normalt ret svært at starte med noget i kernen. I Postgres er der for eksempel en huskeliste. Men faktisk er dette et ark over, hvad de forsøgte at gøre, men ikke lykkedes. Det er komplicerede ting. Og normalt kan du finde nogle hjælpeprogrammer i økosystemet, nogle udvidelser, der kan forbedres, som tiltrækker mindre opmærksomhed fra kerneudviklere. Og derfor er der flere vækstpunkter der. På Google Summer of code-programmet fremlægger postgres-fællesskabet hvert år mange forskellige emner, som kunne behandles. I år havde vi, tror jeg, tre elever. Man skrev endda i WAL-G om emner, der er vigtige for Yandex. I Greenplum er alt enklere end i Postgres-fællesskabet, fordi Greenplum-hackere behandler pull-anmodninger meget godt og begynder at gennemgå med det samme. At sende en patch til Postgres er et spørgsmål om måneder, men Greenplum kommer om en dag og ser, hvad du har gjort. En anden ting er, at Greenplum skal løse aktuelle problemer. Greenplum er ikke udbredt, så det er ret svært at finde dit problem. Og først og fremmest skal vi selvfølgelig løse problemer.
Kilde: www.habr.com