De bijdrage van Yandex aan de volgende databases zal worden beoordeeld.
- Klik op Huis
- Odyssee
- Herstel naar een bepaald tijdstip (WAL-G)
- PostgreSQL (inclusief logerrors, Amcheck, heapcheck)
- Groene pruim
Video:
Hallo Wereld! Mijn naam is Andrey Borodin. En wat ik bij Yandex.Cloud doe, is open relationele databases ontwikkelen in het belang van Yandex.Cloud- en Yandex.Cloud-klanten.
In deze lezing zullen we het hebben over de uitdagingen waarmee open databases op grote schaal worden geconfronteerd. Waarom is het belangrijk? Omdat het kleine, kleine problemen zijn die, net als muggen, olifanten worden. Ze worden groot als je veel clusters hebt.
Maar dat is niet het belangrijkste. Er gebeuren ongelooflijke dingen. Dingen die in één op de miljoen gevallen gebeuren. En in een cloudomgeving moet je daarop voorbereid zijn, want ongelooflijke dingen worden zeer waarschijnlijk als er iets op grote schaal bestaat.
Maar! Wat is het voordeel van open databases? Feit is dat je een theoretische kans hebt om elk probleem aan te pakken. Je hebt de broncode, je hebt programmeerkennis. Wij combineren het en het werkt.
Welke benaderingen zijn er bij het werken aan open source software?
- De meest eenvoudige aanpak is het gebruik van software. Als je protocollen gebruikt, als je standaarden gebruikt, als je formaten gebruikt, als je queries schrijft in open source software, dan ondersteun je het al.
- Je maakt het ecosysteem groter. Je maakt de kans op vroegtijdige detectie van een bug groter. Je vergroot de betrouwbaarheid van dit systeem. Je vergroot de beschikbaarheid van ontwikkelaars in de markt. Jij verbetert deze software. Je levert al een bijdrage als je net stijl hebt gevonden en daar aan iets hebt gesleuteld.
- Een andere begrijpelijke benadering is het sponsoren van open source-software. Bijvoorbeeld het bekende Google Summer of Code programma, waarbij Google een groot aantal studenten van over de hele wereld begrijpelijk geld betaalt zodat zij open softwareprojecten ontwikkelen die aan bepaalde licentievoorwaarden voldoen.
- Dit is een zeer interessante aanpak omdat de software hierdoor kan evolueren zonder de focus van de gemeenschap af te leiden. Google zegt als technologiegigant niet dat we deze functie willen, we willen deze bug oplossen en dit is waar we moeten graven. Google zegt: “Doe wat je doet. Blijf gewoon werken zoals je altijd hebt gewerkt, dan komt alles goed.”
- De volgende benadering van deelname aan open source is participatie. Wanneer je een probleem hebt met open source software en er zijn ontwikkelaars, dan beginnen jouw ontwikkelaars de problemen op te lossen. Ze beginnen uw infrastructuur efficiënter te maken, uw programma's sneller en betrouwbaarder.
Een van de bekendste Yandex-projecten op het gebied van open source software is ClickHouse. Dit is een database die is ontstaan als antwoord op de uitdagingen waarmee Yandex.Metrica wordt geconfronteerd.
En als database is het in open source gemaakt om een ecosysteem te creëren en dit samen met andere ontwikkelaars (niet alleen binnen Yandex) te ontwikkelen. En nu is dit een groot project waarbij veel verschillende bedrijven betrokken zijn.
In Yandex.Cloud hebben we ClickHouse bovenop Yandex Object Storage gemaakt, dat wil zeggen bovenop cloudopslag.
Waarom is dit belangrijk in de cloud? Omdat elke database in deze driehoek, in deze piramide, in deze hiërarchie van geheugentypen werkt. Je hebt snelle maar kleine registers en goedkope grote maar trage SSD's, harde schijven en enkele andere blokapparaten. En als je efficiënt aan de top van de piramide staat, dan heb je een snelle database. als je efficiënt onderaan deze piramide staat, dan heb je een geschaalde database. En in dit opzicht is het toevoegen van een nieuwe laag van onderaf een logische benadering om de schaalbaarheid van de database te vergroten.
Hoe zou het gedaan kunnen worden? Dit is een belangrijk punt in dit rapport.
- We zouden ClickHouse via MDS kunnen implementeren. MDS is een interne Yandex-cloudopslaginterface. Het is complexer dan het gebruikelijke S3-protocol, maar het is geschikter voor een blokapparaat. Het is beter voor het vastleggen van gegevens. Het vereist meer programmering. Programmeurs zullen programmeren, het is zelfs goed, het is interessant.
- S3 is een meer gebruikelijke aanpak die de interface eenvoudiger maakt ten koste van minder aanpassing aan bepaalde soorten werklasten.
Omdat we functionaliteit willen bieden aan het hele ClickHouse-ecosysteem en de taak willen uitvoeren die nodig is binnen Yandex.Cloud, hebben we besloten ervoor te zorgen dat de hele ClickHouse-gemeenschap hiervan profiteert. We hebben ClickHouse via S3 geïmplementeerd, niet ClickHouse via MDS. En dit is veel werk.
referenties:
"Bestandssysteemabstractielaag"
"AWS SDK S3-integratie"
“Basisimplementatie van IDisk-interface voor S3”
"Integratie van logopslag-engines met IDisk-interface"
"Ondersteuning voor log-engine voor S3 en SeekableReadBuffer"
"Storage Stripe Log S3-ondersteuning"
"Storage MergeTree initiële ondersteuning voor S3"
"MergeTree volledige ondersteuning voor S3"
"Ondersteuning ReplicatedMergeTree via S3"
“Standaardgegevens en aangepaste headers toevoegen voor s3-opslag”
"S3 met dynamische proxyconfiguratie"
"S3 met proxy-resolver"
Dit is een lijst met pull-aanvragen voor het implementeren van een virtueel bestandssysteem in ClickHouse. Dit is een groot aantal pull-requests.
referenties:
"DiskS3 hardlinks optimale implementatie"
"S3 HTTP-client - Vermijd het kopiëren van de responsstroom naar het geheugen"
“Vermijd het kopiëren van de hele antwoordstroom naar het geheugen in S3 HTTP
klant"
“Mogelijkheid om bestanden voor S3-schijf te markeren en te indexeren”
"Verplaats onderdelen parallel van DiskLocal naar DiskS3"
Maar daar eindigde het werk niet. Nadat de feature was gemaakt, was er nog wat werk nodig om deze functionaliteit te optimaliseren.
referenties:
"SelectedRows- en SelectedBytes-gebeurtenissen toevoegen"
"Voeg profileringsgebeurtenissen toe van S3-verzoek aan system.events"
"QueryTimeMicroseconds, SelectQueryTimeMicroseconds en InsertQueryTimeMicroseconds toevoegen"
En dan was het nodig om het diagnosticeerbaar te maken, monitoring in te richten en beheersbaar te maken.
En dit alles werd gedaan zodat de hele gemeenschap, het hele ClickHouse-ecosysteem, het resultaat van dit werk ontving.
Laten we verder gaan met transactionele databases, naar OLTP-databases, die dichter bij mij persoonlijk staan.
Dit is de open source DBMS-ontwikkelingsafdeling. Deze jongens doen straatmagie om transactionele open databases te verbeteren.
Een van de projecten, aan de hand van een voorbeeld waarvan we kunnen vertellen hoe en wat we doen, is de Connection Pooler in Postgres.
Postgres is een procesdatabase. Dit betekent dat de database zo min mogelijk netwerkverbindingen moet hebben die transacties afhandelen.
Aan de andere kant is er in een cloudomgeving sprake van een typische situatie waarin duizend verbindingen tegelijk naar één cluster komen. En de taak van de verbindingspooler is om duizend verbindingen in een klein aantal serververbindingen te stoppen.
We kunnen zeggen dat de verbindingspooler de telefoonoperator is die de bytes herschikt zodat ze efficiënt de database bereiken.
Helaas bestaat er geen goed Russisch woord voor verbindingspooler. Soms worden dit multiplexerverbindingen genoemd. Als je weet hoe je de verbindingspooler moet noemen, vertel het me dan zeker, ik zal heel graag de juiste Russische technische taal spreken.
We onderzochten verbindingspoolers die geschikt waren voor een beheerd postgres-cluster. En PgBouncer was voor ons de beste keuze. Maar we kwamen een aantal problemen tegen met PgBouncer. Vele jaren geleden meldde Volodya Borodin dat we PgBouncer gebruiken, we vinden alles leuk, maar er zijn nuances, er is iets om aan te werken.
En wij werkten. We hebben de problemen opgelost die we tegenkwamen, we hebben Bouncer gepatcht en geprobeerd pull-verzoeken stroomopwaarts te pushen. Maar fundamentele single-threading was moeilijk om mee te werken.
We moesten cascades verzamelen van gepatchte Bouncers. Wanneer we veel Bouncers met één schroefdraad hebben, worden de verbindingen op de bovenste laag overgebracht naar de binnenste laag van Bouncers. Dit is een slecht beheerd systeem dat moeilijk te bouwen en heen en weer te schalen is.
We kwamen tot de conclusie dat we onze eigen connectiepooler hebben gemaakt, genaamd Odyssey. We hebben het helemaal opnieuw geschreven.
In 2019 presenteerde ik op de PgCon-conferentie deze pooler aan de ontwikkelaarsgemeenschap. Nu hebben we iets minder dan 2 sterren op GitHub, dat wil zeggen dat het project leeft, het project is populair.
En als je een Postgres-cluster maakt in Yandex.Cloud, dan is het een cluster met ingebouwde Odyssey, die opnieuw wordt geconfigureerd wanneer het cluster heen of weer wordt geschaald.
Wat hebben we van dit project geleerd? Het lanceren van een concurrerend project is altijd een agressieve stap, het is een extreme maatregel als we zeggen dat er problemen zijn die niet snel genoeg worden opgelost, die niet worden opgelost binnen de tijdsintervallen die ons goed uitkomen. Maar dit is een effectieve maatregel.
PgBouncer begon zich sneller te ontwikkelen.
En nu zijn er andere projecten verschenen. Bijvoorbeeld pgagroal, ontwikkeld door Red Hat-ontwikkelaars. Ze streven vergelijkbare doelen na en implementeren vergelijkbare ideeën, maar uiteraard met hun eigen specifieke kenmerken, die dichter bij de pgagroal-ontwikkelaars staan.
Een ander voorbeeld van samenwerking met de postgres-gemeenschap is het herstellen naar een bepaald tijdstip. Dit is herstel na een storing, dit is herstel vanaf een back-up.
Er zijn veel back-ups en ze zijn allemaal verschillend. Bijna elke Postgres-leverancier heeft zijn eigen back-upoplossing.
Als je alle back-upsystemen neemt, een kenmerkenmatrix maakt en gekscherend de determinant in deze matrix berekent, zal deze nul zijn. Wat betekent dit? Wat als u een specifiek back-upbestand neemt, dan kan dit niet worden samengesteld uit delen van alle andere. Het is uniek in zijn implementatie, het is uniek in zijn doel, het is uniek in de ideeën die erin verankerd zijn. En ze zijn allemaal specifiek.
Terwijl we aan dit onderwerp werkten, lanceerde CitusData het WAL-G-project. Dit is een backupsysteem dat gemaakt is met het oog op de cloudomgeving. Nu is CitusData al onderdeel van Microsoft. En op dat moment waren we erg gecharmeerd van de ideeën die waren vastgelegd in de eerste releases van WAL-G. En wij begonnen bij te dragen aan dit project.
Nu zijn er vele tientallen ontwikkelaars in dit project, maar de top 10 bijdragers aan WAL-G omvatten 6 Yandexoids. We hebben veel van onze ideeën daarheen gebracht. En natuurlijk hebben we ze zelf geïmplementeerd, zelf getest, zelf in productie genomen, we gebruiken ze zelf, we zoeken zelf uit waar we heen moeten, terwijl we in interactie zijn met de grote WAL-G-gemeenschap.
En vanuit ons oogpunt is dit back-upsysteem, inclusief rekening houdend met onze inspanningen, nu optimaal geworden voor een cloudomgeving. Dit zijn de beste kosten voor het maken van back-ups van Postgres in de cloud.
Wat betekent het? We propageerden een redelijk groot idee: back-up moet veilig zijn, goedkoop in gebruik en zo snel mogelijk te herstellen.
Waarom zou het goedkoop moeten zijn om te opereren? Als er niets kapot is, mag u niet weten dat u back-ups heeft. Alles werkt prima, je verspilt zo min mogelijk CPU, je gebruikt zo min mogelijk schijfbronnen en je stuurt zo min mogelijk bytes naar het netwerk om de payload van je waardevolle services niet te verstoren.
En als alles kapot gaat, bijvoorbeeld de beheerder de gegevens heeft laten vallen, er iets mis is gegaan en je dringend terug moet naar het verleden, herstel je met al het geld, omdat je je gegevens snel en intact terug wilt hebben.
En we hebben dit eenvoudige idee gepromoot. En het lijkt ons dat we erin zijn geslaagd het te implementeren.
Maar dat is niet alles. We wilden nog een klein ding. We wilden veel verschillende databases. Niet al onze klanten gebruiken Postgres. Sommige mensen gebruiken MySQL, MongoDB. In de community hebben andere ontwikkelaars FoundationDB ondersteund. En deze lijst wordt voortdurend uitgebreid.
De community vindt het een goed idee om de database in een beheerde omgeving in de cloud te laten draaien. En ontwikkelaars onderhouden hun databases, waarvan samen met Postgres een uniforme back-up kan worden gemaakt met ons back-upsysteem.
Wat hebben we van dit verhaal geleerd? Ons product, als ontwikkelingsafdeling, bestaat niet uit coderegels, geen verklaringen, geen bestanden. Ons product is geen pull-request. Dit zijn de ideeën die wij overbrengen aan de gemeenschap. Dit is technologische expertise en de beweging van technologie naar een cloudomgeving.
Er is zo'n database als Postgres. Ik vind de Postgres-kern het leukst. Ik besteed veel tijd aan het ontwikkelen van de Postgres-kern met de community.
Maar hier moet gezegd worden dat Yandex.Cloud een interne installatie van beheerde databases heeft. En het begon lang geleden in Yandex.Mail. De expertise die nu heeft geleid tot het beheer van Postgres is opgebouwd toen de post naar Postgres wilde verhuizen.
Mail heeft zeer vergelijkbare vereisten als de cloud. Het vereist dat u op elk punt in uw data kunt opschalen naar onverwachte exponentiële groei. En de mail had al een lading met enkele honderden miljoenen mailboxen van een groot aantal gebruikers die voortdurend veel verzoeken indienen.
En dit was een behoorlijk serieuze uitdaging voor het team dat Postgres ontwikkelde. Destijds werden alle problemen die we tegenkwamen gerapporteerd aan de gemeenschap. En deze problemen werden gecorrigeerd, en op sommige plaatsen door de gemeenschap zelfs op het niveau van betaalde ondersteuning voor sommige andere databases en zelfs beter. Dat wil zeggen dat u een brief naar de PgSQL-hacker kunt sturen en binnen 40 minuten een reactie ontvangt. Betaalde ondersteuning in sommige databases kan denken dat er meer prioriteit is dan uw bug.
Nu is de interne installatie van Postgres enkele petabytes aan gegevens. Het gaat om enkele miljoenen verzoeken per seconde. Dit zijn duizenden clusters. Het is zeer grootschalig.
Maar er is een nuance. Het leeft niet op mooie netwerkschijven, maar op vrij eenvoudige hardware. En er is een testomgeving speciaal voor interessante nieuwe dingen.
En op een gegeven moment kregen we in de testomgeving een bericht waarin stond dat de interne invarianten van de database-indexen waren geschonden.
Een invariant is een soort relatie waarvan we verwachten dat deze altijd zal blijven bestaan.
Een zeer kritieke situatie voor ons. Het geeft aan dat sommige gegevens mogelijk verloren zijn gegaan. En gegevensverlies is ronduit catastrofaal.
Het algemene idee dat we volgen bij beheerde databases is dat het zelfs met moeite moeilijk zal zijn om gegevens te verliezen. Zelfs als u ze opzettelijk verwijdert, moet u hun afwezigheid nog lange tijd negeren. Gegevensbeveiliging is een religie die we heel ijverig volgen.
En hier doet zich een situatie voor die erop wijst dat er mogelijk een situatie is waarop we misschien niet voorbereid zijn. En we begonnen ons voor te bereiden op deze situatie.
Het eerste wat we deden was de boomstammen van deze duizenden clusters begraven. We hebben ontdekt welke van de clusters zich bevonden op schijven met problematische firmware waardoor updates van de gegevenspagina verloren gingen. Alle Postgres-gegevenscode gemarkeerd. En we hebben de berichten die schendingen van interne invarianten aangeven gemarkeerd met code die is ontworpen om datacorruptie op te sporen.
Deze patch werd vrijwel zonder veel discussie door de gemeenschap geaccepteerd, omdat het in elk specifiek geval duidelijk was dat er iets ergs was gebeurd en dat dit aan het logboek moest worden gerapporteerd.
Hierna kwamen we op het punt dat we monitoring hebben die logs scant. En bij verdachte berichten maakt hij de officier van dienst wakker, en de officier van dienst repareert het.
Maar! Het scannen van logboeken is een goedkope operatie op één cluster en catastrofaal duur voor duizend clusters.
We hebben een extensie geschreven met de naam . Het creëert een weergave van de database waarin u goedkoop en snel statistieken over fouten uit het verleden kunt selecteren. En als we de dienstdoende officier wakker moeten maken, dan zullen we dit ontdekken zonder gigabyte-bestanden te scannen, maar door een paar bytes uit de hash-tabel te extraheren.
Deze extensie is bijvoorbeeld overgenomen in de repository voor . Als u er gebruik van wilt maken, kunt u deze zelf installeren. Natuurlijk is het open source.
Maar dat is niet alles. We zijn begonnen met het gebruik van Amcheck, een door de gemeenschap gebouwde extensie, om onveranderlijke schendingen in indexen te vinden.
En we ontdekten dat als je het op grote schaal gebruikt, er bugs optreden. We zijn begonnen met het repareren ervan. Onze correcties zijn geaccepteerd.
We hebben ontdekt dat deze extensie geen GiST- en GIT-indexen kan analyseren. We hebben ze laten steunen. Maar deze ondersteuning wordt nog steeds besproken door de community, omdat dit een relatief nieuwe functionaliteit is en er veel details zijn.
En we ontdekten ook dat bij het controleren van indexen op overtredingen op de replicatieleider, op de master, alles goed werkt, maar op de replica's, op de volger, is het zoeken naar corruptie niet zo effectief. Niet alle invarianten worden gecontroleerd. En één invariant stoorde ons erg. En we hebben anderhalf jaar lang met de gemeenschap gecommuniceerd om deze controle op replica's mogelijk te maken.
We hebben code geschreven die alle can...-protocollen moet volgen. We hebben deze patch al geruime tijd besproken met Peter Gaghan van Crunchy Data. Hij moest de bestaande B-boom in Postgres enigszins aanpassen om deze patch te accepteren. Hij werd aangenomen. En nu is het controleren van indexen op replica’s ook effectief genoeg geworden om de overtredingen die we tegenkwamen op te sporen. Dat wil zeggen, dit zijn de overtredingen die kunnen worden veroorzaakt door fouten in de schijffirmware, bugs in Postgres, bugs in de Linux-kernel en hardwareproblemen. Een behoorlijk uitgebreide lijst met bronnen van problemen waarop we ons voorbereidden.
Maar naast indexen bestaat er nog zoiets als heap, d.w.z. de plaats waar de gegevens worden opgeslagen. En er zijn niet veel invarianten die kunnen worden gecontroleerd.
We hebben een extensie genaamd Heapcheck. We zijn het gaan ontwikkelen. En parallel daaraan begon het EnterpriseDB-bedrijf ook samen met ons een module te schrijven, die ze op dezelfde manier Heapcheck noemden. Alleen noemden wij het PgHeapcheck, en zij noemden het gewoon Heapcheck. Ze hebben het met vergelijkbare functies, een iets andere signatuur, maar met dezelfde ideeën. Ze hebben ze op sommige plaatsen iets beter geïmplementeerd. En ze hebben het eerder in open source gepost.
En nu ontwikkelen we hun expansie, omdat het niet langer hun expansie is, maar de expansie van de gemeenschap. En in de toekomst maakt dit deel uit van de kernel die aan iedereen zal worden geleverd, zodat ze van tevoren op de hoogte kunnen zijn van toekomstige problemen.
Op sommige plaatsen kwamen we zelfs tot de conclusie dat er valse positieven in onze monitoringsystemen zitten. Bijvoorbeeld het 1C-systeem. Wanneer u een database gebruikt, schrijft Postgres er soms gegevens in die het wel kan lezen, maar pg_dump kan het niet lezen.
Deze situatie leek op corruptie voor ons probleemdetectiesysteem. De dienstdoende officier werd wakker. De dienstdoende officier keek wat er aan de hand was. Na enige tijd kwam er een klant en zei dat ik problemen had. De begeleider legde uit wat het probleem was. Maar het probleem zit in de kern van Postgres.
Ik heb een discussie gevonden over deze functie. En hij schreef dat we deze functie tegenkwamen en dat het onaangenaam was dat iemand 's nachts wakker werd om erachter te komen wat het was.
De gemeenschap antwoordde: "Oh, we moeten het echt repareren."
Ik heb een eenvoudige analogie. Loop je in een schoen waar een zandkorrel in zit, dan kun je in principe zonder problemen verder. Als je laarzen aan duizenden mensen verkoopt, laten we dan laarzen maken zonder zand. En als een van de gebruikers van jouw schoenen een marathon gaat lopen, dan wil je hele goede schoenen maken, en deze vervolgens opschalen naar al je gebruikers. En zulke onverwachte gebruikers bevinden zich altijd in de cloudomgeving. Er zijn altijd gebruikers die het cluster op een originele manier exploiteren. Je moet je hier altijd op voorbereiden.
Wat hebben we hier geleerd? We hebben iets eenvoudigs geleerd: het belangrijkste is om aan de gemeenschap uit te leggen dat er een probleem is. Als de gemeenschap het probleem onderkent, ontstaat er natuurlijke concurrentie om het probleem op te lossen. Omdat iedereen een belangrijk probleem wil oplossen. Alle leveranciers, alle hackers begrijpen dat ze zelf op deze hark kunnen trappen, dus willen ze deze elimineren.
Als u aan een probleem werkt, maar niemand anders dan u er last van heeft, maar u werkt er systematisch aan en het wordt uiteindelijk als een probleem beschouwd, dan zal uw pull-verzoek zeker worden geaccepteerd. Uw patch wordt geaccepteerd, uw verbeteringen of zelfs verzoeken om verbeteringen worden door de community beoordeeld. Uiteindelijk maken we de database beter voor elkaar.
Een interessante database is Greenplum. Het is een zeer parallelle database gebaseerd op de Postgres-codebase, waarmee ik goed bekend ben.
En Greenplum heeft interessante functionaliteit: voeg geoptimaliseerde tabellen toe. Dit zijn tabellen waar u snel aan kunt toevoegen. Ze kunnen kolomvormig of rijvormig zijn.
Maar er was geen clustering, d.w.z. er was geen functionaliteit waarmee je de gegevens in de tabel kunt rangschikken in overeenstemming met de volgorde die in een van de indexen staat.
De jongens van de taxi kwamen naar me toe en zeiden: 'Andrey, je kent Postgres. En hier is het bijna hetzelfde. Schakel over naar 20 minuten. Je neemt het en doet het.” Ik dacht dat ja, ik ken Postgres, 20 minuten schakelen - ik moet dit doen.
Maar nee, het waren geen twintig minuten, ik heb het in maanden geschreven. Op de PgConf.Rusland-conferentie benaderde ik Heikki Linakangas van Pivotal en vroeg: “Zijn er problemen hiermee? Waarom is er geen voor append geoptimaliseerde tabelclustering? Hij zegt: “Je neemt de gegevens. Jij sorteert, jij herschikt. Het is maar een baan." Ik: “O ja, je hoeft het alleen maar te nemen en te doen.” Hij zegt: “Ja, daarvoor hebben we vrije handen nodig.” Ik dacht dat ik dit zeker moet doen.
En een paar maanden later diende ik een pull-request in waarmee deze functionaliteit werd geïmplementeerd. Deze pull request is door Pivotal samen met de community beoordeeld. Natuurlijk waren er bugs.
Maar het meest interessante is dat toen dit pull-verzoek werd samengevoegd, er bugs in Greenplum zelf werden gevonden. We hebben ontdekt dat heap-tabellen soms de transactionaliteit verbreken wanneer ze worden geclusterd. En dit is iets dat moet worden opgelost. En ze is op de plek die ik net heb aangeraakt. En mijn natuurlijke reactie was: oké, laat mij dit ook doen.
Ik heb deze bug opgelost. Stuur een pull request naar de fixers. Hij werd vermoord.
Waarna bleek dat deze functionaliteit te verkrijgen is in de Greenplum-versie voor PostgreSQL 12. Dat wil zeggen, het 20 minuten durende avontuur gaat verder met nieuwe interessante avonturen. Het was interessant om de huidige ontwikkeling te bespreken, waarbij de community nieuwe en belangrijkste functies aanbrengt. Het is bevroren.
Maar daar bleef het niet bij. Na alles bleek dat we hiervoor documentatie moesten schrijven.
Ik begon met het schrijven van documentatie. Gelukkig kwamen de documentairemakers van Pivotal langs. Engels is hun moedertaal. Ze hebben mij geholpen met de documentatie. In feite herschreven ze zelf wat ik voorstelde in echt Engels.
En hier, zo lijkt het, eindigde het avontuur. En weet je wat er toen gebeurde? De jongens van de taxi kwamen naar mij toe en zeiden: “Er zijn nog twee avonturen van elk 10 minuten.” En wat moet ik ze vertellen? Ik zei dat ik nu een rapport op schaal zal geven, dan zullen we je avonturen zien, want dit is een interessante klus.
Wat hebben we van deze casus geleerd? Omdat werken met open source altijd werken met een specifieke persoon is, is het altijd werken met de gemeenschap. Omdat ik in elke fase samenwerkte met een ontwikkelaar, een tester, een hacker, een documentairemaker, een architect. Ik werkte niet met Greenplum, ik werkte met mensen rond Greenplum.
Maar! Er is nog een belangrijk punt: het is gewoon werk. Dat wil zeggen, je komt, drinkt koffie, schrijft code. Allerlei eenvoudige invarianten werken. Doe het normaal - het komt goed! En het is best een interessante baan. Er is een verzoek voor dit werk van Yandex.Cloud-klanten, gebruikers van onze clusters zowel binnen Yandex als daarbuiten. En ik denk dat het aantal projecten waaraan we deelnemen zal toenemen en ook de diepgang van onze betrokkenheid zal toenemen.
Dat is alles. Laten we verder gaan met de vragen.
Vragen sessie
Hallo! We hebben nog een vraag-en-antwoordsessie. En in de studio Andrei Borodin. Dit is de persoon die je zojuist vertelde over de bijdrage van Yandex.Cloud en Yandex aan open source. Ons rapport gaat nu niet geheel over de Cloud, maar tegelijkertijd zijn we gebaseerd op dergelijke technologieën. Zonder wat je binnen Yandex hebt gedaan, zou er geen service zijn in Yandex.Cloud, dus hartelijk dank van mij persoonlijk. En de eerste vraag uit de uitzending: “Op welk project is elk van de door u genoemde projecten geschreven?”
Het back-upsysteem in WAL-G is geschreven in Go. Dit is een van de nieuwere projecten waar we aan hebben gewerkt. Hij is letterlijk nog maar 3 jaar oud. En bij een database gaat het vaak om betrouwbaarheid. En dit betekent dat de databases behoorlijk oud zijn en meestal in C zijn geschreven. Het Postgres-project begon ongeveer 30 jaar geleden. Dan was de C89 de juiste keuze. En er staat Postgres op geschreven. Modernere databases zoals ClickHouse zijn meestal geschreven in C++. Alle systeemontwikkeling is gebaseerd op C en C++.
Een vraag van onze financieel manager, die bij Cloud verantwoordelijk is voor de uitgaven: “Waarom geeft Cloud geld uit aan het ondersteunen van open source?”
Er is hier een eenvoudig antwoord voor de financieel manager. Dit doen wij om onze dienstverlening te verbeteren. Op welke manieren kunnen we het beter doen? We kunnen dingen efficiënter, sneller doen en dingen schaalbaarder maken. Maar voor ons gaat dit verhaal vooral over betrouwbaarheid. In een back-upsysteem beoordelen we bijvoorbeeld 100% van de patches die erop van toepassing zijn. Wij weten wat de code is. En we voelen ons meer op ons gemak bij het uitrollen van nieuwe versies naar productie. Dat wil zeggen dat het in de eerste plaats gaat over vertrouwen, over de bereidheid tot ontwikkeling en over betrouwbaarheid
Nog een vraag: "Zijn de vereisten van externe gebruikers die in Yandex.Cloud wonen anders dan interne gebruikers die in de interne cloud wonen?"
Het belastingsprofiel is uiteraard anders. Maar vanuit het oogpunt van mijn afdeling worden alle speciale en interessante gevallen gemaakt op basis van een niet-standaard belasting. Ontwikkelaars met verbeeldingskracht, ontwikkelaars die het onverwachte doen, zijn zowel intern als extern te vinden. Wat dat betreft zijn we allemaal ongeveer hetzelfde. En waarschijnlijk zal het enige belangrijke kenmerk van de Yandex-werking van databases zijn dat we binnen Yandex een leer hebben. Op een gegeven moment gaat een beschikbaarheidszone volledig in de schaduw en moeten alle Yandex-services desondanks op de een of andere manier blijven functioneren. Dit is een klein verschil. Maar het zorgt voor veel onderzoeksontwikkeling op het grensvlak van de database en de netwerkstack. Anders genereren externe en interne installaties dezelfde verzoeken om functies en soortgelijke verzoeken om de betrouwbaarheid en prestaties te verbeteren.
Volgende vraag: “Wat vindt u persoonlijk van het feit dat veel van wat u doet, door andere Clouds wordt gebruikt?” We zullen geen specifieke noemen, maar veel projecten die in Yandex.Cloud zijn uitgevoerd, worden gebruikt in de clouds van anderen.
Dit is cool. Ten eerste is het een teken dat we iets goed hebben gedaan. En het schaadt het ego. En we hebben er meer vertrouwen in dat we de juiste beslissing hebben genomen. Aan de andere kant is dit de hoop dat dit ons in de toekomst nieuwe ideeën en nieuwe verzoeken van externe gebruikers zal opleveren. De meeste problemen op GitHub worden gemaakt door individuele systeembeheerders, individuele DBA's, individuele architecten, individuele ingenieurs, maar soms komen mensen met systematische ervaring en zeggen dat we in 30% van bepaalde gevallen dit probleem hebben en laten we nadenken over hoe we het kunnen oplossen. Dit is waar wij het meeste naar uitkijken. We kijken ernaar uit om ervaringen te delen met andere cloudplatforms.
Je hebt veel over de marathon gesproken. Ik weet dat je een marathon hebt gelopen in Moskou. Als gevolg? De jongens van PostgreSQL ingehaald?
Nee, Oleg Bartunov rent erg snel. Hij eindigde een uur eerder dan ik. Over het algemeen ben ik blij met hoe ver ik ben gekomen. Voor mij was alleen al het afronden al een prestatie. Over het geheel genomen is het verrassend dat er zoveel hardlopers zijn in de postgres-gemeenschap. Het lijkt mij dat er een soort relatie bestaat tussen aerobe sporten en het verlangen naar systeemprogrammering.
Bedoel je dat er geen hardlopers zijn bij ClickHouse?
Ik weet zeker dat ze er zijn. ClickHouse is ook een database. Oleg schrijft mij trouwens nu: “Zullen we na het rapport gaan hardlopen?” Dit is een geweldig idee.
Nog een vraag uit de uitzending van Nikita: “Waarom heb je de bug in Greenplum zelf opgelost en niet aan de junioren gegeven?” Toegegeven, het is niet erg duidelijk wat de bug is en in welke service, maar het betekent waarschijnlijk degene waar je het over had.
Ja, in principe had het aan iemand gegeven kunnen worden. Het was gewoon de code die ik zojuist heb gewijzigd. En het was logisch om daar meteen mee door te gaan. In principe is het idee om expertise te delen met het team een goed idee. We zullen de Greenplum-taken zeker verdelen onder alle leden van onze divisie.
Aangezien we het over junioren hebben, is hier een vraag. De persoon besloot de eerste commit in Postgres aan te maken. Wat moet hij doen om de eerste commit te maken?
Dit is een interessante vraag: “Waar te beginnen?” Het is meestal vrij moeilijk om met iets in de kernel te beginnen. In Postgres is er bijvoorbeeld een to do-lijst. Maar in feite is dit een blad van wat ze probeerden te doen, maar niet slaagden. Dit zijn ingewikkelde dingen. En meestal kun je in het ecosysteem een aantal hulpprogramma's vinden, een aantal extensies die verbeterd kunnen worden, die minder aandacht trekken van kernelontwikkelaars. En dienovereenkomstig zijn er daar meer groeipunten. Tijdens het Google Summer of code-programma brengt de postgres-gemeenschap elk jaar veel verschillende onderwerpen naar voren die kunnen worden aangepakt. Dit jaar hadden we, denk ik, drie studenten. Eén schreef zelfs in WAL-G over onderwerpen die belangrijk zijn voor Yandex. In Greenplum is alles eenvoudiger dan in de Postgres-gemeenschap, omdat Greenplum-hackers pull-verzoeken heel goed behandelen en meteen beginnen met beoordelen. Een patch naar Postgres sturen is een kwestie van maanden, maar Greenplum komt binnen een dag langs om te kijken wat je hebt gedaan. Een ander ding is dat Greenplum de huidige problemen moet oplossen. Greenplum wordt niet veel gebruikt, dus het vinden van uw probleem is behoorlijk moeilijk. En allereerst moeten we natuurlijk problemen oplossen.
Bron: www.habr.com