Yandex sitt bidrag til følgende databaser vil bli vurdert.
- ClickHouse
- Odyssey
- Gjenoppretting til et tidspunkt (WAL-G)
- PostgreSQL (inkludert logerrors, Amcheck, heapcheck)
- Greenplum
Video:
Hei Verden! Mitt navn er Andrey Borodin. Og det jeg gjør hos Yandex.Cloud er å utvikle åpne relasjonsdatabaser i interessene til Yandex.Cloud- og Yandex.Cloud-klienter.
I denne foredraget skal vi snakke om utfordringene åpne databaser står overfor i stor skala. Hvorfor er det viktig? Fordi små, små problemer som, som mygg, så blir til elefanter. De blir store når du har mange klynger.
Men det er ikke hovedsaken. Utrolige ting skjer. Ting som skjer i én av en million tilfeller. Og i et skymiljø må du være forberedt på det, for utrolige ting blir høyst sannsynlige når noe eksisterer i stor skala.
Men! Hva er fordelen med åpne databaser? Faktum er at du har en teoretisk mulighet til å håndtere ethvert problem. Du har kildekoden, du har kunnskap om programmering. Vi kombinerer det og det fungerer.
Hvilke tilnærminger er det i arbeid med åpen kildekode-programvare?
- Den enkleste tilnærmingen er å bruke programvare. Hvis du bruker protokoller, hvis du bruker standarder, hvis du bruker formater, hvis du skriver spørringer i åpen kildekode-programvare, så støtter du det allerede.
- Du gjør dets økosystem større. Du øker sannsynligheten for tidlig oppdagelse av en feil. Du øker påliteligheten til dette systemet. Du øker tilgjengeligheten for utviklere i markedet. Du forbedrer denne programvaren. Du er allerede en bidragsyter hvis du bare klarte å få stil og fiklet med noe der.
- En annen forståelig tilnærming er å sponse programvare med åpen kildekode. For eksempel det velkjente Google Summer of Code-programmet, når Google betaler et stort antall studenter fra hele verden forståelige penger slik at de utvikler åpne programvareprosjekter som oppfyller visse lisenskrav.
- Dette er en veldig interessant tilnærming fordi den lar programvaren utvikle seg uten å flytte fokus bort fra fellesskapet. Google, som en teknologigigant, sier ikke at vi vil ha denne funksjonen, vi vil fikse denne feilen og det er her vi må grave. Google sier: «Gjør det du gjør. Bare fortsett å jobbe slik du har jobbet, så blir alt bra."
- Den neste tilnærmingen til å delta i åpen kildekode er deltakelse. Når du har et problem i åpen kildekode-programvare og det er utviklere, begynner utviklerne å løse problemene. De begynner å gjøre infrastrukturen din mer effektiv, programmene dine raskere og mer pålitelige.
Et av de mest kjente Yandex-prosjektene innen åpen kildekode-programvare er ClickHouse. Dette er en database som ble født som et svar på utfordringene Yandex.Metrica står overfor.
Og som en database ble den laget i åpen kildekode for å skape et økosystem og utvikle det sammen med andre utviklere (ikke bare innenfor Yandex). Og nå er dette et stort prosjekt der mange ulike bedrifter er involvert.
I Yandex.Cloud opprettet vi ClickHouse på toppen av Yandex Object Storage, det vil si på toppen av skylagring.
Hvorfor er dette viktig i skyen? Fordi enhver database fungerer i denne trekanten, i denne pyramiden, i dette hierarkiet av minnetyper. Du har raske, men små registre og billige store, men trege SSD-er, harddisker og noen andre blokkenheter. Og hvis du er effektiv på toppen av pyramiden, så har du en rask database. hvis du er effektiv i bunnen av denne pyramiden, så har du en skalert database. Og i denne forbindelse er å legge til et nytt lag nedenfra en logisk tilnærming for å øke skalerbarheten til databasen.
Hvordan kunne det gjøres? Dette er et viktig poeng i denne rapporten.
- Vi kan implementere ClickHouse over MDS. MDS er et internt Yandex skylagringsgrensesnitt. Den er mer kompleks enn den vanlige S3-protokollen, men den er mer egnet for en blokkenhet. Det er bedre for å registrere data. Det krever mer programmering. Programmerere vil programmere, det er til og med bra, det er interessant.
- S3 er en mer vanlig tilnærming som gjør grensesnittet enklere på bekostning av mindre tilpasning til visse typer arbeidsbelastninger.
Naturligvis, fordi vi ønsket å tilby funksjonalitet til hele ClickHouse-økosystemet og gjøre oppgaven som trengs i Yandex.Cloud, bestemte vi oss for å sørge for at hele ClickHouse-fellesskapet ville dra nytte av det. Vi implementerte ClickHouse over S3, ikke ClickHouse over MDS. Og dette er mye arbeid.
referanser:
"Filsystemabstraksjonslag"
"AWS SDK S3-integrasjon"
"Basisimplementering av IDisk-grensesnitt for S3"
"Integrasjon av logglagringsmotorer med IDisk-grensesnitt"
"Loggmotorstøtte for S3 og SeekableReadBuffer"
"Støtte for Storage Stripe Log S3"
"Storage MergeTree initial støtte for S3"
"MergeTree full støtte for S3"
"Støtt ReplicatedMergeTree over S3"
"Legg til standard påloggingsinformasjon og tilpassede overskrifter for s3-lagring"
"S3 med dynamisk proxy-konfigurasjon"
"S3 med proxy resolver"
Dette er en pull request-liste for implementering av et virtuelt filsystem i ClickHouse. Dette er et stort antall pull-forespørsler.
referanser:
"DiskS3 hardlinks optimal implementering"
"S3 HTTP-klient - Unngå å kopiere svarstrømmen til minnet"
«Unngå å kopiere hele svarstrømmen til minnet i S3 HTTP
klient"
"Mulighet til å bufre merke og indeksere filer for S3-disk"
"Flytt deler fra DiskLocal til DiskS3 parallelt"
Men arbeidet sluttet ikke der. Etter at funksjonen ble laget, var det noe mer arbeid som måtte til for å optimalisere denne funksjonaliteten.
referanser:
"Legg til SelectedRows og SelectedBytes-hendelser"
"Legg til profileringshendelser fra S3-forespørsel til system.events"
"Legg til QueryTimeMicroseconds, SelectQueryTimeMicroseconds og InsertQueryTimeMicroseconds"
Og da var det nødvendig å gjøre det diagnostiserbart, sette opp overvåking og gjøre det håndterbart.
Og alt dette ble gjort slik at hele samfunnet, hele ClickHouse-økosystemet, mottok resultatet av dette arbeidet.
La oss gå videre til transaksjonsdatabaser, til OLTP-databaser, som er nærmere meg personlig.
Dette er DBMS-utviklingsdivisjonen med åpen kildekode. Disse karene gjør gatemagi for å forbedre transaksjonelle åpne databaser.
Et av prosjektene, med et eksempel som vi kan snakke om hvordan og hva vi gjør, er Connection Pooler i Postgres.
Postgres er en prosessdatabase. Dette betyr at databasen skal ha så få nettverksforbindelser som mulig som håndterer transaksjoner.
På den annen side, i et skymiljø, er en typisk situasjon når tusen forbindelser kommer til en klynge på en gang. Og tilkoblingspoolerens oppgave er å pakke tusen tilkoblinger inn i et lite antall servertilkoblinger.
Vi kan si at tilkoblingspooleren er telefonoperatøren som omorganiserer bytene slik at de effektivt når databasen.
Dessverre finnes det ikke noe godt russisk ord for tilkoblingspooler. Noen ganger kalles det multiplekserforbindelser. Hvis du vet hva du skal kalle tilkoblingspooleren, så sørg for å fortelle meg, jeg vil veldig gjerne snakke det korrekte russiske fagspråket.
Vi undersøkte forbindelsespoolere som var egnet for en administrert postgres-klynge. Og PgBouncer var det beste valget for oss. Men vi møtte en rekke problemer med PgBouncer. For mange år siden ga Volodya Borodin rapporter om at vi bruker PgBouncer, vi liker alt, men det er nyanser, det er noe å jobbe med.
Og vi jobbet. Vi løste problemene vi møtte, vi lappet Bouncer og prøvde å presse pull-forespørsler oppstrøms. Men grunnleggende entråding var vanskelig å jobbe med.
Vi måtte samle kaskader fra lappede bouncers. Når vi har mange entrådede Bouncers, overføres forbindelsene på topplaget til det indre laget av Bouncers. Dette er et dårlig administrert system som er vanskelig å bygge og skalere frem og tilbake.
Vi kom frem til at vi laget vår egen forbindelsespooler, som heter Odyssey. Vi skrev det fra bunnen av.
I 2019, på PgCon-konferansen, presenterte jeg denne pooleren for utviklerfellesskapet. Nå har vi litt mindre enn 2 stjerner på GitHub, det vil si at prosjektet er i live, prosjektet er populært.
Og hvis du oppretter en Postgres-klynge i Yandex.Cloud, vil det være en klynge med innebygd Odyssey, som rekonfigureres når du skalerer klyngen frem eller tilbake.
Hva lærte vi av dette prosjektet? Å sette i gang et konkurrerende prosjekt er alltid et aggressivt skritt, det er et ekstremt tiltak når vi sier at det er problemer som ikke blir løst raskt nok, ikke blir løst i de tidsintervallene som ville passe oss. Men dette er et effektivt tiltak.
PgBouncer begynte å utvikle seg raskere.
Og nå har andre prosjekter dukket opp. For eksempel pgagroal, som er utviklet av Red Hat-utviklere. De forfølger lignende mål og implementerer lignende ideer, men selvfølgelig med sine egne spesifikasjoner, som er nærmere pgagroal-utviklere.
Et annet tilfelle av å jobbe med postgres-samfunnet er å gjenopprette til et tidspunkt. Dette er gjenoppretting etter en feil, dette er gjenoppretting fra en sikkerhetskopi.
Det er mange sikkerhetskopier, og de er alle forskjellige. Nesten hver Postgres-leverandør har sin egen backup-løsning.
Hvis du tar alle backupsystemene, lager en funksjonsmatrise og spøkefullt regner ut determinanten i denne matrisen, vil den være null. Hva betyr dette? Hva om du tar en spesifikk sikkerhetskopifil, så kan den ikke settes sammen fra deler av alle de andre. Den er unik i sin implementering, den er unik i sin hensikt, den er unik i ideene som er innebygd i den. Og de er alle spesifikke.
Mens vi jobbet med dette problemet, lanserte CitusData WAL-G-prosjektet. Dette er et backup-system som er laget med tanke på skymiljøet. Nå er CitusData allerede en del av Microsoft. Og i det øyeblikket likte vi virkelig ideene som ble lagt ned i de første utgivelsene av WAL-G. Og vi begynte å bidra til dette prosjektet.
Nå er det mange dusinvis av utviklere i dette prosjektet, men de 10 beste bidragsyterne til WAL-G inkluderer 6 Yandexoider. Vi tok med mange av ideene våre dit. Og selvfølgelig implementerte vi dem selv, testet dem selv, rullet dem ut i produksjon selv, vi bruker dem selv, vi finner selv ut hvor vi skal flytte videre, mens vi samhandler med det store WAL-G-samfunnet.
Og fra vårt ståsted, nå har dette backup-systemet, inkludert å ta hensyn til vår innsats, blitt optimalt for et skymiljø. Dette er den beste kostnaden for å sikkerhetskopiere Postgres i skyen.
Hva betyr det? Vi fremmet en ganske stor idé: sikkerhetskopiering skal være sikker, billig i drift og så raskt som mulig å gjenopprette.
Hvorfor skal det være billig i drift? Når ingenting er ødelagt, bør du ikke vite at du har sikkerhetskopier. Alt fungerer bra, du kaster bort så lite CPU som mulig, du bruker så lite av diskressursene dine som mulig, og du sender så få byte til nettverket som mulig for ikke å forstyrre nyttelasten til dine verdifulle tjenester.
Og når alt går i stykker, for eksempel, droppet administratoren dataene, noe gikk galt, og du må raskt tilbake til fortiden, du kommer deg tilbake med alle pengene, fordi du vil ha dataene tilbake raskt og intakt.
Og vi fremmet denne enkle ideen. Og det ser ut til at vi klarte å implementere det.
Men det er ikke alt. Vi ville ha en liten ting til. Vi ville ha mange forskjellige databaser. Ikke alle våre kunder bruker Postgres. Noen bruker MySQL, MongoDB. I fellesskapet har andre utviklere støttet FoundationDB. Og denne listen utvides stadig.
Samfunnet liker ideen om at databasen kjøres i et administrert miljø i skyen. Og utviklere vedlikeholder databasene sine, som kan sikkerhetskopieres jevnt sammen med Postgres med sikkerhetskopieringssystemet vårt.
Hva har vi lært av denne historien? Vårt produkt, som en utviklingsavdeling, er ikke linjer med kode, det er ikke uttalelser, det er ikke filer. Vårt produkt er ikke pull-forespørsler. Dette er ideene vi formidler til samfunnet. Dette er teknologisk ekspertise og bevegelse av teknologi mot et skymiljø.
Det er en slik database som Postgres. Jeg liker Postgres-kjernen best. Jeg bruker mye tid på å utvikle Postgres-kjernen med samfunnet.
Men her skal det sies at Yandex.Cloud har en intern installasjon av administrerte databaser. Og det startet for lenge siden i Yandex.Mail. Kompetansen som nå har ført til administrert Postgres ble akkumulert da posten ønsket å flytte inn i Postgres.
Mail har svært like krav til skyen. Det krever at du kan skalere til uventet eksponentiell vekst når som helst i dataene dine. Og e-posten hadde allerede en last med noen hundre millioner av postkasser fra et stort antall brukere som stadig kommer med mange forespørsler.
Og dette var en ganske alvorlig utfordring for teamet som utviklet Postgres. Den gang ble alle problemer vi møtte rapportert til fellesskapet. Og disse problemene ble korrigert og rettet av fellesskapet noen steder, selv på nivået med betalt støtte for noen andre databaser og enda bedre. Det vil si at du kan sende et brev til PgSQL hacker og få svar innen 40 minutter. Betalt støtte i noen databaser kan tro at det er flere prioriterte ting enn feilen din.
Nå er den interne installasjonen av Postgres noen petabyte med data. Dette er noen millioner forespørsler per sekund. Dette er tusenvis av klynger. Det er veldig storskala.
Men det er en nyanse. Den lever ikke på fancy nettverksstasjoner, men på ganske enkel maskinvare. Og det er et testmiljø spesielt for interessante nye ting.
Og på et bestemt tidspunkt i testmiljøet mottok vi en melding som indikerte at de interne invariantene til databaseindeksene ble brutt.
En invariant er en slags forhold som vi forventer alltid å ha.
En svært kritisk situasjon for oss. Det indikerer at noen data kan ha gått tapt. Og tap av data er noe direkte katastrofalt.
Den generelle ideen som vi følger i administrerte databaser er at selv med innsats vil det være vanskelig å miste data. Selv om du bevisst fjerner dem, må du fortsatt ignorere deres fravær over en lengre periode. Datasikkerhet er en religion som vi følger ganske flittig.
Og her oppstår det en situasjon som tyder på at det kan være en situasjon vi kanskje ikke er forberedt på. Og vi begynte å forberede oss på denne situasjonen.
Det første vi gjorde var å begrave tømmerstokkene fra disse tusenvis av klyngene. Vi fant hvilke av klyngene som var plassert på disker med problematisk fastvare som mistet datasideoppdateringer. Merket all Postgres datakode. Og vi merket de meldingene som indikerer brudd på interne invarianter med kode som er designet for å oppdage datakorrupsjon.
Denne oppdateringen ble praktisk talt akseptert av samfunnet uten mye diskusjon, fordi det i hvert enkelt tilfelle var åpenbart at noe dårlig hadde skjedd og måtte rapporteres til loggen.
Etter dette kom vi til det punktet at vi har overvåking som skanner logger. Og ved mistenkelige meldinger vekker han vaktmesteren, og vaktleder reparerer den.
Men! Å skanne logger er en billig operasjon på én klynge og katastrofalt dyr for tusen klynger.
Vi skrev en utvidelse kalt . Det skaper en oversikt over databasen der du billig og raskt kan velge statistikk over tidligere feil. Og hvis vi trenger å vekke vakthavende offiser, vil vi finne ut om dette uten å skanne gigabyte-filer, men ved å trekke ut noen byte fra hash-tabellen.
Denne utvidelsen er tatt i bruk for eksempel i depotet for . Hvis du vil bruke den, kan du installere den selv. Selvfølgelig er det åpen kildekode.
Men det er ikke alt. Vi begynte å bruke Amcheck, en fellesskapsbygd utvidelse, for å finne invariante brudd i indekser.
Og vi fant ut at hvis du bruker den i stor skala, er det feil. Vi begynte å fikse dem. Våre rettelser er akseptert.
Vi oppdaget at denne utvidelsen ikke kan analysere GiST- og GIT-indekser. Vi fikk dem til å støtte. Men denne støtten blir fortsatt diskutert av fellesskapet, fordi dette er en relativt ny funksjonalitet og det er mange detaljer der.
Og vi oppdaget også at når du sjekker indekser for brudd på replikeringslederen, på masteren, fungerer alt bra, men på replikaene, på følgeren, er søket etter korrupsjon ikke så effektivt. Ikke alle invarianter er sjekket. Og en invariant plaget oss veldig. Og vi brukte halvannet år på å kommunisere med fellesskapet for å aktivere denne sjekken av kopier.
Vi skrev kode som skulle følge alle kan... protokoller. Vi diskuterte denne oppdateringen en god stund med Peter Gaghan fra Crunchy Data. Han måtte endre det eksisterende B-treet i Postgres litt for å godta denne lappen. Han ble akseptert. Og nå har kontroll av indekser på replikaer også blitt effektiv nok til å oppdage bruddene vi har møtt. Det vil si at dette er bruddene som kan være forårsaket av feil i diskfastvare, feil i Postgres, feil i Linux-kjernen og maskinvareproblemer. En ganske omfattende liste over kilder til problemer som vi forberedte oss på.
Men foruten indekser, er det en slik del som heap, det vil si stedet hvor dataene er lagret. Og det er ikke mange invarianter som kan kontrolleres.
Vi har en utvidelse som heter Heapcheck. Vi begynte å utvikle den. Og parallelt begynte også EnterpriseDB-selskapet sammen med oss å skrive en modul, som de kalte Heapcheck på samme måte. Bare vi kalte det PgHeapcheck, og de kalte det bare Heapcheck. De har den med lignende funksjoner, en litt annen signatur, men med de samme ideene. De implementerte dem litt bedre noen steder. Og de postet det i åpen kildekode før.
Og nå utvikler vi deres ekspansjon, for det er ikke lenger deres ekspansjon, men utvidelsen av fellesskapet. Og i fremtiden er dette en del av kjernen som vil bli levert til alle slik at de kan vite om fremtidige problemer på forhånd.
Noen steder kom vi til og med frem til at vi har falske positiver i overvåkingssystemene våre. For eksempel 1C-systemet. Når du bruker en database, skriver Postgres noen ganger data inn i den som den kan lese, men pg_dump kan ikke lese.
Denne situasjonen så ut som korrupsjon i vårt problemdeteksjonssystem. Vakthavende ble vekket. Vaktmesteren så på hva som skjedde. Etter en tid kom en klient og sa at jeg hadde problemer. Lederen forklarte hva problemet var. Men problemet ligger i Postgres-kjernen.
Jeg fant en diskusjon om denne funksjonen. Og han skrev at vi møtte denne funksjonen og det var ubehagelig, en person våknet om natten for å finne ut hva det var.
Samfunnet svarte: "Å, vi må virkelig fikse det."
Jeg har en enkel analogi. Hvis du går i en sko som har et sandkorn i seg, så kan du i prinsippet gå videre - ikke noe problem. Hvis du selger støvler til tusenvis av mennesker, så la oss lage støvler uten sand i det hele tatt. Og hvis en av brukerne av skoene dine skal løpe et maraton, så vil du lage veldig gode sko, og deretter skalere dem til alle brukerne dine. Og slike uventede brukere er alltid i skymiljøet. Det er alltid brukere som utnytter klyngen på en original måte. Du må alltid forberede deg på dette.
Hva har vi lært her? Vi lærte en enkel ting: det viktigste er å forklare samfunnet at det er et problem. Hvis samfunnet har erkjent problemet, oppstår det naturlig konkurranse for å løse problemet. Fordi alle ønsker å løse et viktig problem. Alle leverandører, alle hackere forstår at de selv kan tråkke på denne raken, så de ønsker å eliminere dem.
Hvis du jobber med et problem, men det plager ingen andre enn deg, men du jobber med det systematisk og det til syvende og sist anses som et problem, vil pull-forespørselen din definitivt bli akseptert. Patchen din vil bli akseptert, forbedringene dine eller til og med forespørsler om forbedringer vil bli vurdert av fellesskapet. På slutten av dagen gjør vi databasen bedre for hverandre.
En interessant database er Greenplum. Det er en svært parallell database basert på Postgres-kodebasen, som jeg er godt kjent med.
Og Greenplum har interessant funksjonalitet - legg til optimaliserte tabeller. Dette er tabeller som du raskt kan legge til. De kan enten være søyleformede eller radformede.
Men det var ingen klynging, det vil si at det ikke var noen funksjonalitet der du kan ordne dataene i tabellen i henhold til rekkefølgen som er i en av indeksene.
Gutta fra taxien kom til meg og sa: «Andrey, du kjenner Postgres. Og her er det nesten det samme. Bytt til 20 minutter. Du tar det og gjør det." Jeg tenkte at ja, jeg kjenner Postgres, bytter i 20 minutter - jeg må gjøre dette.
Men nei, det var ikke 20 minutter, jeg skrev det over måneder. På PgConf.Russia-konferansen henvendte jeg meg til Heikki Linakangas fra Pivotal og spurte: «Er det noen problemer med dette? Hvorfor er det ingen tilleggsoptimalisert tabellklynging?" Han sier: «Du tar dataene. Du sorterer, du omorganiserer. Det er bare en jobb." Meg: "Å, ja, du må bare ta det og gjøre det." Han sier: "Ja, vi trenger frie hender til å gjøre dette." Jeg tenkte at dette må jeg definitivt gjøre.
Og noen måneder senere sendte jeg inn en pull-forespørsel som implementerte denne funksjonaliteten. Denne pull-forespørselen ble gjennomgått av Pivotal sammen med fellesskapet. Selvfølgelig var det feil.
Men det mest interessante er at da denne pull-forespørselen ble slått sammen, ble det funnet feil i selve Greenplum. Vi har funnet ut at heap-tabeller noen ganger bryter transaksjonaliteten når de er gruppert. Og dette er en ting som må fikses. Og hun er på stedet jeg nettopp rørte ved. Og min naturlige reaksjon var – ok, la meg gjøre dette også.
Jeg fikset denne feilen. Sendte en pull-forespørsel til fikserne. Han ble drept.
Deretter viste det seg at denne funksjonaliteten må skaffes i Greenplum-versjonen for PostgreSQL 12. Det vil si at det 20 minutter lange eventyret fortsetter med nye interessante eventyr. Det var interessant å røre ved den nåværende utviklingen, der fellesskapet kutter nye og viktigste funksjoner. Den er frossen.
Men det endte ikke der. Etter alt viste det seg at vi trengte å skrive dokumentasjon for alt dette.
Jeg begynte å skrive dokumentasjon. Heldigvis kom dokumentarene fra Pivotal med. Engelsk er morsmålet deres. De hjalp meg med dokumentasjonen. Faktisk skrev de selv om det jeg foreslo til ekte engelsk.
Og her, ser det ut til, endte eventyret. Og vet du hva som skjedde da? Gutta fra taxien kom til meg og sa: "Det er fortsatt to eventyr, hver i 10 minutter." Og hva skal jeg fortelle dem? Jeg sa at nå skal jeg gi en rapport på skala, så får vi se dine eventyr, for dette er en interessant jobb.
Hva lærte vi av denne saken? Fordi å jobbe med åpen kildekode alltid er å jobbe med en bestemt person, er det alltid å jobbe med fellesskapet. For på hvert eneste trinn jobbet jeg med en utvikler, en tester, en hacker, en dokumentarist, en annen arkitekt. Jeg jobbet ikke med Greenplum, jeg jobbet med folk rundt Greenplum.
Men! Det er et annet viktig poeng - det er bare arbeid. Det vil si at du kommer, drikker kaffe, skriver kode. Alle slags enkle invarianter fungerer. Gjør det på vanlig måte - det blir bra! Og det er en ganske interessant jobb. Det er en forespørsel om dette arbeidet fra Yandex.Cloud-klienter, brukere av våre klynger både innenfor og utenfor Yandex. Og jeg tror at antallet prosjekter vi deltar i vil øke og dybden av vårt engasjement vil også øke.
Det er alt. La oss gå videre til spørsmålene.
Spørsmålsøkt
Hallo! Vi har en ny spørsmål og svar økt. Og i studioet Andrei Borodin. Dette er personen som nettopp fortalte deg om bidraget til Yandex.Cloud og Yandex til åpen kildekode. Rapporten vår nå handler ikke helt om Skyen, men samtidig er vi basert på slike teknologier. Uten det du gjorde inne i Yandex, ville det ikke vært noen tjeneste i Yandex.Cloud, så takk fra meg personlig. Og det første spørsmålet fra sendingen: "Hva er hvert av prosjektene du nevnte skrevet på?"
Sikkerhetskopieringssystemet i WAL-G er skrevet i Go. Dette er et av de nyere prosjektene vi har jobbet med. Han er bokstavelig talt bare 3 år gammel. Og en database handler ofte om pålitelighet. Og dette betyr at databasene er ganske gamle og de er vanligvis skrevet i C. Postgres-prosjektet startet for rundt 30 år siden. Da var C89 det rette valget. Og Postgres er skrevet på den. Mer moderne databaser som ClickHouse er vanligvis skrevet i C++. All systemutvikling er basert på C og C++.
Et spørsmål fra vår økonomisjef, som er ansvarlig for utgiftene i Cloud: "Hvorfor bruker Cloud penger på å støtte åpen kildekode?"
Det er et enkelt svar for økonomisjefen her. Dette gjør vi for å gjøre tjenestene våre bedre. På hvilke måter kan vi gjøre det bedre? Vi kan gjøre ting mer effektivt, raskere og gjøre ting mer skalerbare. Men for oss handler denne historien først og fremst om pålitelighet. For eksempel, i et backup-system gjennomgår vi 100 % av oppdateringene som gjelder for det. Vi vet hva koden er. Og vi er mer komfortable med å rulle ut nye versjoner til produksjon. Det vil si at det for det første handler om tillit, om beredskap for utvikling og om pålitelighet
Et annet spørsmål: "Er kravene til eksterne brukere som bor i Yandex.Cloud forskjellige fra interne brukere som bor i den interne skyen?"
Lastprofilen er selvfølgelig annerledes. Men fra min avdelings synspunkt er alle de spesielle og interessante sakene opprettet på en ikke-standard belastning. Utviklere med fantasi, utviklere som gjør det uventede, er like sannsynlig å bli funnet både internt og eksternt. I denne forbindelse er vi alle omtrent like. Og sannsynligvis vil den eneste viktige funksjonen i Yandex-driften av databaser være at vi har en undervisning i Yandex. På et tidspunkt går en tilgjengelighetssone fullstendig i skyggen, og alle Yandex-tjenester må på en eller annen måte fortsette å fungere til tross for dette. Dette er en liten forskjell. Men det skaper mye forskningsutvikling i grensesnittet til databasen og nettverksstakken. Ellers genererer eksterne og interne installasjoner de samme forespørslene om funksjoner og lignende forespørsler for å forbedre påliteligheten og ytelsen.
Neste spørsmål: "Hva føler du personlig om det faktum at mye av det du gjør brukes av andre skyer?" Vi vil ikke nevne spesifikke, men mange prosjekter som ble gjort i Yandex.Cloud brukes i andres skyer.
Dette er kult. For det første er det et tegn på at vi har gjort noe riktig. Og det skraper egoet. Og vi er mer sikre på at vi tok den riktige avgjørelsen. På den annen side er dette håpet om at dette i fremtiden vil bringe oss nye ideer, nye forespørsler fra tredjepartsbrukere. De fleste problemer på GitHub er opprettet av individuelle systemadministratorer, individuelle DBA-er, individuelle arkitekter, individuelle ingeniører, men noen ganger kommer folk med systematisk erfaring og sier at i 30 % av visse tilfeller har vi dette problemet og la oss tenke på hvordan vi skal løse det. Det er dette vi gleder oss mest til. Vi ser frem til å dele erfaringer med andre skyplattformer.
Du snakket mye om maraton. Jeg vet at du løp et maraton i Moskva. Som et resultat? Overkjørt gutta fra PostgreSQL?
Nei, Oleg Bartunov løper veldig fort. Han kom i mål en time foran meg. Totalt sett er jeg fornøyd med hvor langt jeg har kommet. For meg var bare det å fullføre en prestasjon. Totalt sett er det overraskende at det er så mange løpere i postgres-samfunnet. Det virker for meg som det er en slags sammenheng mellom aerobic sport og ønsket om systemprogrammering.
Sier du at det ikke er noen løpere på ClickHouse?
Jeg vet med sikkerhet at de er der. ClickHouse er også en database. Forresten, Oleg skriver nå til meg: «Skal vi ta en løpetur etter rapporten?» Dette er en god idé.
Et annet spørsmål fra sendingen fra Nikita: "Hvorfor fikset du feilen i Greenplum selv og ikke ga den til juniorer?" Riktignok er det ikke veldig klart hva feilen er og i hvilken tjeneste, men det betyr sannsynligvis den du snakket om.
Ja, i prinsippet kunne den vært gitt til noen. Det var bare koden jeg endret. Og det var naturlig å fortsette med det med en gang. I prinsippet er ideen om å dele kompetanse med teamet en god idé. Vi vil definitivt dele Greenplum-oppgavene mellom alle medlemmene i divisjonen vår.
Siden vi snakker om juniorer, her er et spørsmål. Personen bestemte seg for å opprette den første forpliktelsen i Postgres. Hva må han gjøre for å gjøre den første forpliktelsen?
Dette er et interessant spørsmål: "Hvor skal du begynne?" Det er vanligvis ganske vanskelig å starte med noe i kjernen. I Postgres er det for eksempel en huskeliste. Men faktisk er dette en oversikt over hva de prøvde å gjøre, men ikke lyktes. Dette er komplekse ting. Og vanligvis kan du finne noen verktøy i økosystemet, noen utvidelser som kan forbedres, som tiltrekker seg mindre oppmerksomhet fra kjerneutviklere. Og følgelig er det flere vekstpunkter der. På Google Summer of code-programmet legger postgres-fellesskapet hvert år frem mange forskjellige emner som kan tas opp. I år hadde vi, tror jeg, tre elever. En skrev til og med i WAL-G om temaer som er viktige for Yandex. I Greenplum er alt enklere enn i Postgres-fellesskapet, fordi Greenplum-hackere behandler pull-forespørsler veldig bra og begynner å vurdere med en gang. Å sende en oppdatering til Postgres er et spørsmål om måneder, men Greenplum kommer om en dag og ser hva du har gjort. En annen ting er at Greenplum må løse dagens problemer. Greenplum er ikke mye brukt, så det er ganske vanskelig å finne problemet ditt. Og først og fremst må vi løse problemer, selvfølgelig.
Kilde: www.habr.com