Yandexin panos seuraaviin tietokantoihin tarkistetaan.
- Napsauta taloa
- Odysseia
- Palautuminen tiettyyn ajankohtaan (WAL-G)
- PostgreSQL (mukaan lukien logerrors, Amcheck, heapcheck)
- Vihreäluumu
Video:
Hei maailma! Nimeni on Andrei Borodin. Ja mitä teen Yandex.Cloudilla, on kehittää avoimia relaatiotietokantoja Yandex.Cloud- ja Yandex.Cloud-asiakkaiden edun mukaisesti.
Tässä puheessa puhumme haasteista, joita avoimet tietokannat kohtaavat laajasti. Miksi se on tärkeää? Koska pieniä, pieniä ongelmia, jotka, kuten hyttyset, muuttuvat sitten norsuiksi. Ne kasvavat suuriksi, kun sinulla on useita klustereita.
Mutta se ei ole pääasia. Uskomattomia asioita tapahtuu. Asiat, joita tapahtuu yhdessä miljoonasta tapauksesta. Ja pilviympäristössä siihen on varauduttava, sillä uskomattomat asiat tulevat erittäin todennäköisiksi, kun jotain on olemassa suuressa mittakaavassa.
Mutta! Mitä etua avoimista tietokannoista on? Tosiasia on, että sinulla on teoreettinen mahdollisuus käsitellä mikä tahansa ongelma. Sinulla on lähdekoodi, sinulla on ohjelmointitietoa. Yhdistelemme ja se toimii.
Millaisia lähestymistapoja avoimen lähdekoodin ohjelmistojen parissa on?
- Yksinkertaisin tapa on käyttää ohjelmistoja. Jos käytät protokollia, jos käytät standardeja, jos käytät formaatteja, jos kirjoitat kyselyitä avoimen lähdekoodin ohjelmistoissa, tuet jo sitä.
- Teet sen ekosysteemistä suuremman. Suurennat vian varhaisen havaitsemisen todennäköisyyttä. Lisäät tämän järjestelmän luotettavuutta. Lisäät kehittäjien saatavuutta markkinoilla. Parannat tätä ohjelmistoa. Olet jo avustaja, jos olet vain keksinyt tyyliä ja keksinyt jotain siellä.
- Toinen ymmärrettävä lähestymistapa on avoimen lähdekoodin ohjelmistojen sponsorointi. Esimerkiksi tunnettu Google Summer of Code -ohjelma, jolloin Google maksaa suurelle joukolle opiskelijoita eri puolilta maailmaa ymmärrettävää rahaa, jotta he kehittävät avoimia ohjelmistoprojekteja, jotka täyttävät tietyt lisenssivaatimukset.
- Tämä on erittäin mielenkiintoinen lähestymistapa, koska sen avulla ohjelmisto voi kehittyä siirtämättä painopistettä pois yhteisöstä. Google teknologiajättinä ei sano, että haluamme tämän ominaisuuden, haluamme korjata tämän virheen, ja tässä meidän on kaivettava. Google sanoo: "Tee mitä teet. Jatka vain työskentelyä entiseen tapaan, niin kaikki järjestyy."
- Seuraava lähestymistapa avoimeen lähdekoodiin osallistumiseen on osallistuminen. Kun sinulla on ongelma avoimen lähdekoodin ohjelmistoissa ja kehittäjiä on, kehittäjäsi alkavat ratkaista ongelmia. Ne alkavat tehdä infrastruktuuristasi tehokkaampaa, ohjelmistasi nopeampia ja luotettavampia.
Yksi tunnetuimmista Yandex-projekteista avoimen lähdekoodin ohjelmistojen alalla on ClickHouse. Tämä on tietokanta, joka syntyi vastauksena Yandex.Metrican kohtaamiin haasteisiin.
Ja tietokantana se tehtiin avoimessa lähdekoodissa ekosysteemin luomiseksi ja sen kehittämiseksi yhdessä muiden kehittäjien kanssa (ei vain Yandexin sisällä). Ja nyt tämä on iso projekti, jossa on mukana monia erilaisia yrityksiä.
Yandex.Cloudissa loimme ClickHousen Yandex Object Storagen päälle eli pilvitallennustilan päälle.
Miksi tämä on tärkeää pilvessä? Koska mikä tahansa tietokanta toimii tässä kolmiossa, tässä pyramidissa, tässä muistityyppien hierarkiassa. Sinulla on nopeat mutta pienet rekisterit ja halpoja suuria mutta hitaita SSD-levyjä, kiintolevyjä ja joitain muita lohkolaitteita. Ja jos olet tehokas pyramidin huipulla, sinulla on nopea tietokanta. Jos olet tehokas tämän pyramidin alaosassa, sinulla on skaalattu tietokanta. Ja tässä suhteessa toisen kerroksen lisääminen alhaalta on looginen lähestymistapa tietokannan skaalautuvuuden lisäämiseen.
Miten se voitaisiin tehdä? Tämä on tärkeä kohta tässä mietinnössä.
- Voisimme toteuttaa ClickHousen MDS:n kautta. MDS on sisäinen Yandexin pilvitallennusrajapinta. Se on monimutkaisempi kuin yleinen S3-protokolla, mutta se sopii paremmin lohkolaitteeseen. Se on parempi tietojen tallentamiseen. Se vaatii enemmän ohjelmointia. Ohjelmoijat ohjelmoivat, se on jopa hyvä, se on mielenkiintoista.
- S3 on yleisempi lähestymistapa, joka tekee käyttöliittymästä yksinkertaisemman kustannuksella, koska se mukautuu vähemmän tietyntyyppisiin työkuormiin.
Haluamme luonnollisesti tarjota toimintoja koko ClickHouse-ekosysteemille ja tehdä Yandex.Cloudissa tarvittavat tehtävät, joten päätimme varmistaa, että koko ClickHouse-yhteisö hyötyisi siitä. Otimme käyttöön ClickHouse over S3:n, emme ClickHouse over MDS. Ja tämä on paljon työtä.
viitteet:
"Tiedostojärjestelmän abstraktiokerros"
"AWS SDK S3 -integraatio"
"IDisk-liittymän perustoteutus S3:lle"
"Lokin tallennuskoneiden integrointi IDisk-liittymään"
"Lokimoottorin tuki S3:lle ja SeekableReadBufferille"
"Storage Stripe Log S3 -tuki"
"Storage MergeTreen alustava tuki S3:lle"
"MergeTreen täysi tuki S3:lle"
"Support ReplicatedMergeTree over S3"
"Lisää oletustunnistetiedot ja mukautetut otsikot s3-tallennustilaa varten"
"S3 dynaamisella välityspalvelinkokoonpanolla"
"S3 välityspalvelimen ratkaisijalla"
Tämä on vetopyyntöluettelo virtuaalisen tiedostojärjestelmän toteuttamiseksi ClickHousessa. Tämä on suuri määrä vetopyyntöjä.
viitteet:
"DiskS3 hardlinks optimaalinen toteutus"
"S3 HTTP-asiakas - Vältä kopioimasta vastausvirtaa muistiin"
"Vältä koko vastausvirran kopioimista muistiin S3 HTTP:ssä
asiakas"
"Mahdollisuus välimuistiin merkitä ja indeksoida tiedostoja S3-levylle"
"Siirrä osia DiskLocalista DiskS3:een rinnakkain"
Mutta työ ei päättynyt tähän. Ominaisuuden luomisen jälkeen tarvittiin vielä jonkin verran työtä tämän toiminnon optimoimiseksi.
viitteet:
"Lisää SelectedRows- ja SelectedBytes-tapahtumat"
"Lisää profilointitapahtumat S3-pyynnöstä system.eventsiin"
"Lisää QueryTimeMicroseconds, SelectQueryTimeMicroseconds ja InsertQueryTimeMicroseconds"
Ja sitten oli tarpeen tehdä siitä diagnosoitavissa, perustaa seuranta ja tehdä siitä hallittavissa.
Ja kaikki tämä tehtiin niin, että koko yhteisö, koko ClickHouse-ekosysteemi sai tämän työn tuloksen.
Siirrytäänpä tapahtumatietokantoihin, OLTP-tietokantoihin, jotka ovat minulle henkilökohtaisesti läheisempiä.
Tämä on avoimen lähdekoodin DBMS-kehitysosasto. Nämä kaverit tekevät katutaikuutta parantaakseen avoimia transaktiotietokantoja.
Yksi projekteista, jonka esimerkin avulla voimme puhua siitä, miten ja mitä teemme, on Connection Pooler Postgresissa.
Postgres on prosessitietokanta. Tämä tarkoittaa, että tietokannassa tulisi olla mahdollisimman vähän verkkoyhteyksiä, jotka käsittelevät tapahtumia.
Toisaalta pilviympäristössä tyypillinen tilanne on, kun yhteen klusteriin tulee kerralla tuhat yhteyttä. Ja yhteysvaraajan tehtävänä on pakata tuhat yhteyttä pieneen määrään palvelinyhteyksiä.
Voimme sanoa, että yhteysvaraaja on puhelinoperaattori, joka järjestää tavut uudelleen niin, että ne saavuttavat tehokkaasti tietokannan.
Valitettavasti ei ole olemassa hyvää venäjän sanaa yhteyspoolerille. Joskus sitä kutsutaan multiplekseriyhteyksiksi. Jos tiedät, mitä kutsua yhteysvaraajaksi, kerro minulle, puhun mielelläni oikeaa venäjän teknistä kieltä.
Tutkimme hallittuun postgres-klusteriin soveltuvia yhteyspooliajia. Ja PgBouncer oli meille paras valinta. Mutta kohtasimme useita ongelmia PgBouncerin kanssa. Monta vuotta sitten Volodya Borodin kertoi, että käytämme PgBounceria, pidämme kaikesta, mutta on vivahteita, on jotain työstettävää.
Ja teimme töitä. Korjasimme kohtaamamme ongelmat, korjasimme Bouncerin ja yritimme siirtää vetopyyntöjä ylävirtaan. Mutta perustavanlaatuisen yksisäikeisyyden kanssa oli vaikea työskennellä.
Meidän piti kerätä kaskadeja korjatuilta Bouncereilta. Kun meillä on useita yksisäikeisiä Bouncereita, ylimmän kerroksen liitännät siirretään Bouncersin sisäkerrokseen. Tämä on huonosti hallittu järjestelmä, jota on vaikea rakentaa ja skaalata edestakaisin.
Tulimme siihen tulokseen, että loimme oman yhteysvaraajan, jonka nimi on Odyssey. Kirjoitimme sen tyhjästä.
Vuonna 2019 PgCon-konferenssissa esittelin tämän poolerin kehittäjäyhteisölle. Nyt meillä on vähän alle 2 tähteä GitHubissa, eli projekti on elossa, projekti on suosittu.
Ja jos luot Postgres-klusterin Yandex.Cloudissa, se on klusteri, jossa on sisäänrakennettu Odyssey, joka määritetään uudelleen, kun klusteria skaalataan edestakaisin.
Mitä opimme tästä projektista? Kilpailevan projektin käynnistäminen on aina aggressiivinen askel, se on äärimmäinen toimenpide, kun sanomme, että on ongelmia, jotka eivät ratkea tarpeeksi nopeasti, eivät ratkea meille sopivin aikavälein. Mutta tämä on tehokas toimenpide.
PgBouncer alkoi kehittyä nopeammin.
Ja nyt on ilmestynyt muita projekteja. Esimerkiksi pgagroal, jonka ovat kehittäneet Red Hat -kehittäjät. He tavoittelevat samanlaisia tavoitteita ja toteuttavat samanlaisia ideoita, mutta tietysti omilla erityispiirteillään, jotka ovat lähempänä pgagroal-kehittäjiä.
Toinen tapaus työskennellä postgres-yhteisön kanssa on palautuminen tiettyyn hetkeen. Tämä on palautumista vian jälkeen, tämä on palautusta varmuuskopiosta.
Varmuuskopioita on monia ja ne ovat kaikki erilaisia. Lähes jokaisella Postgres-toimittajalla on oma varmuuskopiointiratkaisunsa.
Jos otat kaikki varmuuskopiojärjestelmät, luot ominaisuusmatriisin ja lasket vitsillä tämän matriisin determinantin, se on nolla. Mitä tämä tarkoittaa? Entä jos otat tietyn varmuuskopiotiedoston, sitä ei voida koota kaikkien muiden osista. Se on ainutlaatuinen toteutuksessaan, se on ainutlaatuinen tarkoituksessaan, se on ainutlaatuinen siihen upotetuissa ideoissa. Ja ne kaikki ovat erityisiä.
Kun työskentelimme tämän asian parissa, CitusData käynnisti WAL-G-projektin. Tämä on varmuuskopiojärjestelmä, joka on tehty pilviympäristöä silmällä pitäen. Nyt CitusData on jo osa Microsoftia. Ja sillä hetkellä pidimme todella ideoista, jotka esitettiin WAL-G:n alkuperäisissä julkaisuissa. Ja aloimme osallistua tähän projektiin.
Nyt tässä projektissa on useita kymmeniä kehittäjiä, mutta WAL-G:n 10 parhaan avustajan joukossa on kuusi Yandexoidia. Toimme paljon ideoitamme sinne. Ja tietysti toteutimme ne itse, testasimme itse, otettiin ne tuotantoon itse, käytämme niitä itse, mietimme itse, minne siirrymme seuraavaksi vuorovaikutuksessa suuren WAL-G-yhteisön kanssa.
Ja meidän näkökulmastamme tästä varmuuskopiojärjestelmästä on nyt ponnistelumme huomioon ottaen tullut optimaalinen pilviympäristöön. Tämä on paras kustannus Postgresin varmuuskopioinnista pilveen.
Mitä se tarkoittaa? Promootioimme melko suurta ideaa: varmuuskopioinnin tulee olla turvallista, halpaa käyttää ja mahdollisimman nopea palauttaa.
Miksi operoinnin pitäisi olla halpaa? Kun mikään ei ole rikki, sinun ei pitäisi tietää, että sinulla on varmuuskopioita. Kaikki toimii hyvin, tuhlaat mahdollisimman vähän prosessoria, käytät mahdollisimman vähän levyresursseja ja lähetät verkkoon mahdollisimman vähän tavuja, jotta et häiritse arvokkaiden palvelujesi hyötykuormaa.
Ja kun kaikki hajoaa, esimerkiksi järjestelmänvalvoja pudotti tiedot, jokin meni pieleen ja sinun on kiireesti palattava menneisyyteen, toivut kaikella rahalla, koska haluat tietosi takaisin nopeasti ja ehjinä.
Ja mainostimme tätä yksinkertaista ideaa. Ja meistä näyttää, että onnistuimme toteuttamaan sen.
Mutta siinä ei vielä kaikki. Halusimme vielä yhden pienen asian. Halusimme monia erilaisia tietokantoja. Kaikki asiakkaamme eivät käytä Postgresia. Jotkut ihmiset käyttävät MySQL:tä, MongoDB:tä. Yhteisössä muut kehittäjät ovat tukeneet FoundationDB:tä. Ja tämä lista laajenee jatkuvasti.
Yhteisö pitää ajatuksesta, että tietokantaa ajetaan hallitussa ympäristössä pilvessä. Ja kehittäjät ylläpitävät tietokantojaan, jotka voidaan varmuuskopioida yhtenäisesti Postgresin kanssa varmuuskopiointijärjestelmämme avulla.
Mitä olemme oppineet tästä tarinasta? Tuotekehitysosastona tuotteemme ei ole koodirivejä, se ei ole lausekkeita, se ei ole tiedostoja. Tuotteemme ei ole vetopyyntöjä. Nämä ovat ajatuksia, jotka välitämme yhteisölle. Tämä on teknologista osaamista ja teknologian liikettä kohti pilviympäristöä.
On olemassa sellainen tietokanta kuin Postgres. Pidän eniten Postgres-ytimestä. Käytän paljon aikaa Postgres-ytimen kehittämiseen yhteisön kanssa.
Mutta tässä on sanottava, että Yandex.Cloudissa on sisäinen hallittujen tietokantojen asennus. Ja se alkoi kauan sitten Yandex.Mailissa. Asiantuntijuus, joka on nyt johtanut hallinnoituun Postgresiin, kertyi, kun posti halusi siirtyä Postgresiin.
Maililla on hyvin samanlaiset vaatimukset kuin pilvellä. Se edellyttää, että pystyt skaalaamaan odottamattoman eksponentiaalisen kasvun missä tahansa datasi kohdassa. Ja postissa oli jo useita satoja miljoonia postilaatikoita valtavalla määrällä käyttäjiä, jotka tekevät jatkuvasti monia pyyntöjä.
Ja tämä oli melko vakava haaste Postgresia kehittävälle tiimille. Tuolloin kaikista kohtaamistamme ongelmista ilmoitettiin yhteisölle. Ja nämä ongelmat korjattiin ja korjattiin yhteisön toimesta paikoin jopa joidenkin muiden tietokantojen maksullisen tuen tasolla ja vielä paremmin. Eli voit lähettää kirjeen PgSQL-hakkerille ja saada vastauksen 40 minuutin kuluessa. Joidenkin tietokantojen maksullinen tuki saattaa ajatella, että on olemassa tärkeämpiä asioita kuin bugisi.
Nyt Postgresin sisäinen asennus sisältää muutaman petatavun dataa. Nämä ovat miljoonia pyyntöjä sekunnissa. Nämä ovat tuhansia klustereita. Se on erittäin laajamittaista.
Mutta siinä on vivahde. Se ei asu hienoilla verkkoasemilla, vaan melko yksinkertaisilla laitteistoilla. Ja siellä on testiympäristö erityisesti mielenkiintoisille uusille asioille.
Ja tietyllä hetkellä testiympäristössä saimme viestin, joka ilmoitti, että tietokantaindeksien sisäisiä invariantteja on rikottu.
Invariantti on jonkinlainen suhde, jonka odotamme jatkuvan aina.
Erittäin kriittinen tilanne meille. Se osoittaa, että osa tiedoista on saattanut kadota. Ja tietojen menetys on jotain suorastaan katastrofaalista.
Yleinen ajatus, jota noudatamme hallituissa tietokannoissa, on, että jopa vaivannäöllä tietojen menettäminen on vaikeaa. Vaikka poistaisit ne tarkoituksella, sinun on silti jätettävä huomioimatta niiden poissaolo pitkään aikaan. Tietoturva on uskonto, jota seuraamme melko ahkerasti.
Ja tässä syntyy tilanne, joka viittaa siihen, että voi olla tilanne, johon emme ehkä ole valmiita. Ja aloimme valmistautua tähän tilanteeseen.
Ensimmäinen asia, jonka teimme, oli haudata tukkia näistä tuhansista klusteista. Löysimme, mitkä klusterit sijaitsivat levyillä, joissa oli ongelmallinen laiteohjelmisto ja jotka menettivät tietosivupäivityksiä. Merkitty kaikki Postgres-datakoodit. Ja merkitsimme viestit, jotka osoittavat sisäisten invarianttien rikkomuksia, koodilla, joka on suunniteltu havaitsemaan tietojen korruptio.
Tämä korjaustiedosto hyväksyttiin käytännössä ilman keskustelua, koska jokaisessa tapauksessa oli ilmeistä, että jotain pahaa oli tapahtunut ja siitä piti ilmoittaa lokiin.
Tämän jälkeen tulimme siihen pisteeseen, että meillä on seuranta, joka tarkistaa lokit. Ja jos tulee epäilyttäviä viestejä, hän herättää päivystäjän ja päivystäjä korjaa sen.
Mutta! Lokien skannaus on halpa toimenpide yhdessä klusterissa ja katastrofaalisen kallista tuhannelle klusterille.
Kirjoitimme laajennuksen nimeltä . Se luo tietokannasta näkymän, josta voit edullisesti ja nopeasti valita tilastoja aiemmista virheistä. Ja jos meidän täytyy herättää päivystäjä, saamme tämän selville ilman gigatavujen tiedostojen skannausta, vaan poimimalla muutaman tavun hash-taulukosta.
Tämä laajennus on otettu käyttöön esimerkiksi arkistoon for . Jos haluat käyttää sitä, voit asentaa sen itse. Tietenkin se on avoimen lähdekoodin.
Mutta siinä ei vielä kaikki. Aloimme käyttää Amcheckiä, yhteisön rakentamaa laajennusta, löytääksemme muuttumattomia rikkomuksia indekseistä.
Ja huomasimme, että jos käytät sitä suuressa mittakaavassa, siinä on virheitä. Aloimme korjata niitä. Korjauksemme on hyväksytty.
Huomasimme, että tämä laajennus ei voi analysoida GiST- ja GIT-indeksejä. Saimme heidät tukemaan. Mutta tästä tuesta keskustellaan edelleen yhteisössä, koska tämä on suhteellisen uusi toiminto ja siinä on paljon yksityiskohtia.
Ja havaitsimme myös, että kun tarkistamme indeksien rikkomuksia replikaation johtajassa, isännässä, kaikki toimii hyvin, mutta replikoissa, seuraajassa, korruption etsintä ei ole niin tehokasta. Kaikkia invariantteja ei tarkisteta. Ja yksi muuttuja vaivasi meitä kovasti. Vietimme puolitoista vuotta kommunikoinnissa yhteisön kanssa, jotta tämä replikoiden tarkistus olisi mahdollista.
Kirjoitimme koodin, jonka pitäisi noudattaa kaikkia can... protokollia. Keskustelimme tästä korjaustiedostosta jonkin aikaa Peter Gaghanin kanssa Crunchy Datasta. Hänen täytyi hieman muokata olemassa olevaa B-puuta Postgresissa hyväksyäkseen tämän korjaustiedoston. Hänet hyväksyttiin. Ja nyt kopioiden indeksien tarkistamisesta on tullut myös tarpeeksi tehokasta havaitsemamme rikkomukset havaitsemiseksi. Toisin sanoen nämä ovat rikkomuksia, jotka voivat johtua levyn laiteohjelmiston virheistä, Postgresin virheistä, Linux-ytimen vioista ja laitteisto-ongelmista. Melko laaja luettelo ongelmalähteistä, joihin valmistauduimme.
Mutta indeksien lisäksi on olemassa sellainen osa kuin kasa, eli paikka, johon tiedot tallennetaan. Eikä ole montaa invarianttia, jotka voitaisiin tarkistaa.
Meillä on laajennus nimeltä Heapcheck. Aloimme kehittää sitä. Ja samanaikaisesti, yhdessä kanssamme, EnterpriseDB-yritys alkoi myös kirjoittaa moduulia, jota he kutsuivat Heapcheckiksi samalla tavalla. Vain me kutsuimme sitä PgHeapcheckiksi, ja he kutsuivat sitä vain Heapcheckiksi. Heillä on samat toiminnot, hieman erilainen allekirjoitus, mutta samat ideat. He toteuttivat ne joissain paikoissa hieman paremmin. Ja he julkaisivat sen avoimessa lähdekoodissa aiemmin.
Ja nyt kehitämme heidän laajentumistaan, koska se ei ole enää heidän, vaan yhteisön laajeneminen. Ja tulevaisuudessa tämä on osa ydintä, joka toimitetaan kaikille, jotta he voivat tietää tulevista ongelmista etukäteen.
Joissain paikoissa tulimme jopa siihen tulokseen, että valvontajärjestelmissämme on vääriä positiivisia tuloksia. Esimerkiksi 1C-järjestelmä. Kun käytetään tietokantaa, Postgres kirjoittaa siihen joskus tietoja, joita se voi lukea, mutta pg_dump ei voi lukea.
Tämä tilanne näytti korruptiolta ongelmien havaitsemisjärjestelmässämme. Päivystäjä herätettiin. Päivystäjä katsoi mitä tapahtui. Jonkin ajan kuluttua asiakas tuli ja sanoi, että minulla on ongelmia. Palvelija selitti, mikä ongelma oli. Mutta ongelma on Postgresin ytimessä.
Löysin keskustelun tästä ominaisuudesta. Ja hän kirjoitti, että kohtasimme tämän ominaisuuden ja se oli epämiellyttävää, henkilö heräsi yöllä selvittääkseen, mikä se oli.
Yhteisö vastasi: "Voi, meidän täytyy todella korjata se."
Minulla on yksinkertainen analogia. Jos kävelet kengässä, jossa on hiekkajyvä, voit periaatteessa jatkaa eteenpäin - ei hätää. Jos myyt saappaita tuhansille ihmisille, niin tehdään saappaat ilman hiekkaa. Ja jos joku kenkien käyttäjistä aikoo juosta maratonin, haluat tehdä erittäin hyviä kenkiä ja skaalata ne sitten kaikille käyttäjillesi. Ja tällaiset odottamattomat käyttäjät ovat aina pilviympäristössä. Aina löytyy käyttäjiä, jotka hyödyntävät klusteria jollain alkuperäisellä tavalla. Tähän pitää aina valmistautua.
Mitä olemme oppineet täällä? Opimme yksinkertaisen asian: tärkeintä on selittää yhteisölle, että ongelma on olemassa. Jos yhteisö on tunnistanut ongelman, syntyy luonnollista kilpailua ongelman ratkaisemiseksi. Koska jokainen haluaa ratkaista tärkeän ongelman. Kaikki myyjät, kaikki hakkerit ymmärtävät, että he itse voivat astua tämän haravan päälle, joten he haluavat eliminoida ne.
Jos työskentelet ongelman parissa, mutta se ei häiritse ketään muuta kuin sinua, mutta työskentelet sen parissa systemaattisesti ja se katsotaan lopulta ongelmaksi, vetopyyntösi hyväksytään ehdottomasti. Korjaustiedostosi hyväksytään, parannukset tai jopa parannuspyyntösi tarkistetaan yhteisössä. Loppujen lopuksi teemme tietokannasta paremman toisillemme.
Mielenkiintoinen tietokanta on Greenplum. Se on hyvin rinnakkainen tietokanta, joka perustuu Postgres-koodikantaan, jonka tunnen hyvin.
Ja Greenplumissa on mielenkiintoisia toimintoja - liitä optimoidut taulukot. Nämä ovat taulukoita, joihin voit nopeasti lisätä. Ne voivat olla joko sarake- tai rivimuotoisia.
Mutta ei ollut klusterointia, eli ei ollut toiminnallisuutta, jossa voit järjestää taulukossa olevat tiedot sen järjestyksen mukaan, joka on jossakin indeksissä.
Taksin tyypit tulivat luokseni ja sanoivat: "Andrey, sinä tunnet Postgresin. Ja tässä se on melkein sama. Vaihda 20 minuuttiin. Ota se ja teet sen." Ajattelin, että kyllä, tiedän Postgresin, vaihtamassa 20 minuutiksi - minun täytyy tehdä tämä.
Mutta ei, se ei ollut 20 minuuttia, kirjoitin sen yli kuukausia. PgConf.Russia-konferenssissa lähestyin Pivotalin Heikki Linakangasta ja kysyin: "Onko tässä ongelmia? Miksi liiteoptimoitua taulukkoklusterointia ei ole?" Hän sanoo: "Otat tiedot. Lajittelet, järjestät uudelleen. Se on vain työtä." Minä: "Voi, kyllä, sinun täytyy vain ottaa se ja tehdä se." Hän sanoo: "Kyllä, tarvitsemme vapaita käsiä tehdäksemme tämän." Ajattelin, että minun on ehdottomasti tehtävä tämä.
Ja muutamaa kuukautta myöhemmin lähetin vetopyynnön, joka toteutti tämän toiminnon. Pivotal tarkasteli tämän vetopyynnön yhdessä yhteisön kanssa. Bugeja tietysti oli.
Mutta mielenkiintoisin asia on, että kun tämä vetopyyntö yhdistettiin, vikoja löydettiin itse Greenplumista. Olemme havainneet, että kasataulukot joskus rikkovat tapahtumia klusteroituina. Ja tämä on asia, joka pitää korjata. Ja hän on siinä paikassa, jota juuri kosketin. Ja luonnollinen reaktioni oli - okei, anna minun tehdä tämä myös.
Korjasin tämän bugin. Lähetti vetopyynnön korjaajille. Hänet tapettiin.
Tämän jälkeen kävi ilmi, että tämä toiminto on hankittava Greenplum-versioon PostgreSQL 12:lle. Eli 20 minuutin seikkailu jatkuu uusilla mielenkiintoisilla seikkailuilla. Oli mielenkiintoista koskettaa nykyistä kehitystä, jossa yhteisö leikkaa uusia ja tärkeimpiä piirteitä. Se on jäässä.
Mutta se ei päättynyt siihen. Kaiken jälkeen kävi ilmi, että meidän piti kirjoittaa dokumentaatio tästä kaikesta.
Aloin kirjoittaa dokumentteja. Onneksi Pivotalin dokumentaarit tulivat mukaan. Englanti on heidän äidinkielensä. He auttoivat minua dokumenttien kanssa. Itse asiassa he itse kirjoittivat ehdotukseni uudelleen oikeaksi englanniksi.
Ja tähän seikkailu näyttää päättyneen. Ja tiedätkö mitä sitten tapahtui? Taksin kaverit tulivat luokseni ja sanoivat: "On vielä kaksi seikkailua, kumpikin 10 minuuttia." Ja mitä minun pitäisi kertoa heille? Sanoin, että nyt annan raportin mittakaavassa, sitten nähdään seikkailunne, koska tämä on mielenkiintoinen työ.
Mitä opimme tästä tapauksesta? Koska avoimen lähdekoodin kanssa työskenteleminen on aina työskentelyä tietyn henkilön kanssa, se on aina työskentelyä yhteisön kanssa. Koska jokaisessa vaiheessa työskentelin jonkun kehittäjän, testaajan, hakkerin, dokumentaarin, arkkitehdin kanssa. En työskennellyt Greenplumin kanssa, vaan Greenplumin ympärillä olevien ihmisten kanssa.
Mutta! On toinen tärkeä kohta - se on vain työtä. Eli tulet, juot kahvia, kirjoitat koodia. Kaikenlaiset yksinkertaiset invariantit toimivat. Tee se normaalisti - siitä tulee hyvä! Ja se on aika mielenkiintoinen työ. Tätä työtä ovat pyytäneet Yandex.Cloud-asiakkaat, klusteriemme käyttäjät sekä Yandexin sisällä että sen ulkopuolella. Ja uskon, että projektien määrä, joihin osallistumme, lisääntyy ja osallistumisemme syvyys myös lisääntyy.
Siinä kaikki. Siirrytään kysymyksiin.
Kysymysistunto
Hei! Meillä on toinen kysymys ja vastaus -tunti. Ja studiossa Andrei Borodin. Tämä on henkilö, joka juuri kertoi sinulle Yandex.Cloudin ja Yandexin panoksesta avoimeen lähdekoodiin. Raporttimme ei nyt koske pelkästään pilvipalvelua, mutta samalla pohjaudumme tällaisiin teknologioihin. Ilman sitä, mitä teit Yandexissä, Yandex.Cloudissa ei olisi palvelua, joten kiitos henkilökohtaisesti. Ja ensimmäinen kysymys lähetyksestä: "Mihin kukin mainitsemistasi projekteista on kirjoitettu?"
WAL-G:n varmuuskopiojärjestelmä on kirjoitettu Go-kielellä. Tämä on yksi uudimmista projekteista, joiden parissa olemme työstäneet. Hän on kirjaimellisesti vain 3-vuotias. Ja tietokannassa on usein kyse luotettavuudesta. Ja tämä tarkoittaa, että tietokannat ovat melko vanhoja ja ne on yleensä kirjoitettu C-kielellä. Postgres-projekti alkoi noin 30 vuotta sitten. Sitten C89 oli oikea valinta. Ja siihen on kirjoitettu Postgres. Nykyaikaisemmat tietokannat, kuten ClickHouse, kirjoitetaan yleensä C++:lla. Kaikki järjestelmäkehitys perustuu C:hen ja C++:aan.
Kysymys talousjohtajaltamme, joka vastaa Cloudin kuluista: "Miksi Cloud käyttää rahaa avoimen lähdekoodin tukemiseen?"
Tässä on yksinkertainen vastaus talousjohtajalle. Teemme tämän parantaaksemme palveluitamme. Millä tavoin voimme tehdä paremmin? Voimme tehdä asioita tehokkaammin, nopeammin ja tehdä asioista skaalautuvampia. Mutta meille tämä tarina on ennen kaikkea luotettavuudesta. Esimerkiksi varmuuskopiojärjestelmässä tarkistamme 100 % siihen liittyvistä korjaustiedostoista. Tiedämme mikä koodi on. Ja meillä on mukavampaa ottaa käyttöön uusia versioita tuotantoon. Kyse on siis ennen kaikkea luottamuksesta, kehitysvalmiudesta ja luotettavuudesta
Toinen kysymys: "Ovatko Yandex.Cloudissa asuvien ulkoisten käyttäjien vaatimukset erilaisia kuin sisäisessä pilvessä asuvien sisäisten käyttäjien vaatimukset?"
Kuormaprofiili on tietysti erilainen. Mutta osastoni näkökulmasta kaikki erityiset ja mielenkiintoiset tapaukset luodaan epätyypillisellä kuormalla. Kehittäjiä, joilla on mielikuvitusta, kehittäjiä, jotka tekevät odottamattomia, löytyy yhtä todennäköisesti sekä sisäisesti että ulkoisesti. Tässä suhteessa olemme kaikki suunnilleen samanlaisia. Ja luultavasti ainoa tärkeä ominaisuus Yandexin tietokantojen toiminnassa on se, että Yandexin sisällä meillä on opetus. Jossain vaiheessa jokin käytettävyysvyöhyke menee täysin varjoon, ja kaikkien Yandex-palvelujen on jotenkin edelleen toimittava tästä huolimatta. Tämä on pieni ero. Mutta se luo paljon tutkimuskehitystä tietokannan ja verkkopinon rajapinnassa. Muutoin ulkoiset ja sisäiset asennukset luovat samat pyynnöt ominaisuuksista ja vastaavat pyynnöt luotettavuuden ja suorituskyvyn parantamiseksi.
Seuraava kysymys: "Mitä sinä itse pidät siitä, että muut pilvet käyttävät paljon tekemistäsi?" Emme nimeä tiettyjä, mutta monia Yandex.Cloudissa tehtyjä projekteja käytetään muiden ihmisten pilvissä.
Tämä on siistiä. Ensinnäkin se on merkki siitä, että olemme tehneet jotain oikein. Ja se raaputtaa egoa. Ja olemme varmempia, että teimme oikean päätöksen. Toisaalta tämä on toivoa, että tämä tuo meille tulevaisuudessa uusia ideoita, uusia pyyntöjä kolmansien osapuolien käyttäjiltä. Suurin osa GitHubin ongelmista on yksittäisten järjestelmänvalvojien, yksittäisten DBA:iden, yksittäisten arkkitehtien, yksittäisten insinöörien luomia, mutta joskus ihmiset, joilla on systemaattista kokemusta, tulevat sanomaan, että 30 prosentissa tapauksista meillä on tämä ongelma, ja mietitään kuinka se ratkaistaan. Tätä odotamme eniten. Odotamme innolla kokemusten jakamista muiden pilvialustojen kanssa.
Puhuit paljon maratonista. Tiedän, että juoksit maratonin Moskovassa. Tuloksena? Ohittiko PostgreSQL:n kaverit?
Ei, Oleg Bartunov juoksee erittäin nopeasti. Hän lopetti tunnin ennen minua. Kaiken kaikkiaan olen tyytyväinen siihen, kuinka pitkälle pääsin. Minulle pelkkä viimeistely oli saavutus. Kaiken kaikkiaan on yllättävää, että postgres-yhteisössä on niin paljon juoksijoita. Minusta näyttää siltä, että aerobisen urheilun ja järjestelmäohjelmoinnin halun välillä on jonkinlainen suhde.
Väitätkö, ettei ClickHousessa ole juoksijoita?
Tiedän varmasti, että ne ovat siellä. ClickHouse on myös tietokanta. Muuten, Oleg kirjoittaa nyt minulle: "Mennäänkö lenkille raportin jälkeen?" Tämä on hieno idea.
Toinen kysymys lähetyksestä Nikitalta: "Miksi korjasit Greenplumin vian itse etkä antanut sitä junioreille?" Totta, ei ole kovin selvää, mikä vika on ja missä palvelussa, mutta se tarkoittaa todennäköisesti sitä, josta puhuit.
Kyllä, periaatteessa se olisi voitu antaa jollekin. Se oli vain koodi, jonka juuri vaihdoin. Ja oli luonnollista jatkaa sitä heti. Periaatteessa ajatus asiantuntemuksen jakamisesta tiimin kanssa on hyvä idea. Jaamme Greenplum-tehtävät ehdottomasti kaikkien divisioonamme jäsenten kesken.
Koska puhumme junioreista, tässä on kysymys. Henkilö päätti luoda ensimmäisen sitoumuksen Postgresissa. Mitä hänen tulee tehdä tehdäkseen ensimmäisen sitoumuksen?
Tämä on mielenkiintoinen kysymys: "Mistä aloittaa?" Yleensä on melko vaikeaa aloittaa jostain ytimessä. Esimerkiksi Postgresissa on tehtävälista. Mutta itse asiassa tämä on arkki siitä, mitä he yrittivät tehdä, mutta eivät onnistuneet. Nämä ovat monimutkaisia asioita. Ja yleensä voit löytää joitain apuohjelmia ekosysteemistä, joitain laajennuksia, joita voidaan parantaa, jotka herättävät vähemmän huomiota ytimen kehittäjiltä. Ja vastaavasti siellä on enemmän kasvupisteitä. Google Summer of code -ohjelmassa postgres-yhteisö esittää joka vuosi monia erilaisia aiheita, joita voitaisiin käsitellä. Tänä vuonna meillä oli mielestäni kolme opiskelijaa. Yksi jopa kirjoitti WAL-G:ssä Yandexille tärkeistä aiheista. Greenplumissa kaikki on yksinkertaisempaa kuin Postgres-yhteisössä, koska Greenplumin hakkerit käsittelevät vetopyyntöjä erittäin hyvin ja aloittavat tarkastelun heti. Korjauksen lähettäminen Postgresille kestää kuukausia, mutta Greenplum tulee päivässä ja katso mitä olet tehnyt. Toinen asia on, että Greenplumin on ratkaistava nykyiset ongelmat. Greenplumia ei käytetä laajalti, joten ongelmasi löytäminen on melko vaikeaa. Ja ennen kaikkea meidän on tietysti ratkaistava ongelmat.
Lähde: will.com