DBA-botti Joe. Anatoli Stansler (Postgres.ai)

Kuinka taustakehittäjä ymmärtää, että SQL-kysely toimii hyvin "tuotetuotteessa"? Suurissa tai nopeasti kasvavissa yrityksissä kaikilla ei ole pääsyä "tuotteeseen". Ja pääsyn avulla kaikkia pyyntöjä ei voida tarkistaa kivuttomasti, ja tietokannan kopion luominen kestää usein tunteja. Näiden ongelmien ratkaisemiseksi loimme keinotekoisen DBA:n - Joe. Se on jo otettu onnistuneesti käyttöön useissa yrityksissä ja auttaa yli tusinaa kehittäjää.

Video:

Hei kaikki! Nimeni on Anatoli Stansler. Työskentelen yrityksessä postgres.ai. Olemme sitoutuneet nopeuttamaan kehitysprosessia poistamalla Postgresin työhön liittyvät viiveet kehittäjiltä, ​​DBA:ilta ja laadunvarmistuksilta.

Meillä on mahtavia asiakkaita ja tänään osa raportista on omistettu tapauksille, joita tapasimme heidän kanssaan työskennellessämme. Puhun siitä, kuinka auttoimme heitä ratkaisemaan melko vakavia ongelmia.

Kun kehitämme ja teemme monimutkaisia ​​suuren kuormituksen migraatioita, esitämme itseltämme kysymyksen: "Nouseeko tämä migraatio?". Käytämme arvostelua, käytämme kokeneempien kollegoiden, DBA-asiantuntijoiden tietoja. Ja he voivat sanoa, lentääkö se vai ei.

Mutta ehkä olisi parempi, jos voisimme testata sitä itse täysikokoisilla kopioilla. Ja tänään puhumme vain siitä, mitkä lähestymistavat testaukseen ovat nyt ja miten se voidaan tehdä paremmin ja millä työkaluilla. Puhumme myös tällaisten lähestymistapojen eduista ja haitoista sekä siitä, mitä voimme korjata täällä.

Kuka on koskaan tehnyt indeksejä suoraan tuotantoon tai tehnyt muutoksia? Aika vähän. Ja kenelle tämä johti siihen, että tiedot katosivat tai oli seisokkeja? Tiedä sitten tämän kivun. Luojan kiitos on varmuuskopioita.

Ensimmäinen lähestymistapa on testaus tuotannossa. Tai kun kehittäjä istuu paikallisella koneella, hänellä on testidataa, on jonkinlainen rajoitettu valikoima. Ja siirrymme tuottamaan, ja saamme tämän tilanteen.

Se sattuu, se on kallista. On varmaan parasta olla tekemättä.

Ja mikä on paras tapa tehdä se?

Otetaan lavastus ja valitaan sieltä jokin osa tuotannosta. Tai parhaimmillaan otetaan todellinen tuote, kaikki tiedot. Ja kun olemme kehittäneet sen paikallisesti, tarkistamme lisäksi lavastuksen.

Näin voimme poistaa osan virheistä eli estää niitä olemasta tuotantotilassa.

Mitkä ovat ongelmat?

• Ongelmana on, että jaamme tämän lavastuksen kollegoiden kanssa. Ja hyvin usein tapahtuu, että teet jonkinlaisen muutoksen, bam - eikä ole tietoa, työ on hukassa. Lavastus oli usean teratavun mittainen. Ja sinun on odotettava pitkään, että se nousee jälleen. Ja päätämme viimeistellä sen huomenna. Siinä se, meillä on kehitystä.
• Ja tietysti meillä työskentelee siellä monia kollegoita, monia tiimejä. Ja se on tehtävä manuaalisesti. Ja tämä on epämukavaa.

Ja on syytä sanoa, että meillä on vain yksi yritys, yksi laukaus, jos haluamme tehdä joitain muutoksia tietokantaan, koskettaa tietoja, muuttaa rakennetta. Ja jos jokin meni pieleen, jos siirrossa tapahtui virhe, emme palaa nopeasti takaisin.

Tämä on parempi kuin edellinen lähestymistapa, mutta on silti suuri todennäköisyys, että jonkinlainen virhe menee tuotantoon.

Mikä estää meitä antamasta jokaiselle kehittäjälle testipenkkiä, täysikokoista kopiota? Mielestäni on selvää, mikä on tiellä.

Kenellä on teratavua suurempi tietokanta? Yli puolet huoneesta.

Ja on selvää, että jokaisen kehittäjän koneiden pitäminen, kun on niin suuri tuotanto, on erittäin kallista, ja lisäksi se kestää kauan.

Meillä on asiakkaita, jotka ovat ymmärtäneet, että on erittäin tärkeää testata kaikki muutokset täysikokoisilla kopioilla, mutta heidän tietokantansa on alle teratavun, eikä ole resursseja pitää testipenkkiä jokaiselle kehittäjälle. Siksi heidän on ladattava kaatopaikat paikallisesti koneelleen ja testattava tällä tavalla. Se vie paljon aikaa.

Vaikka tekisit sen infrastruktuurin sisällä, yhden teratavun tiedon lataaminen tunnissa on jo erittäin hyvä. Mutta he käyttävät loogisia kaatopaikkoja, he lataavat paikallisesti pilvestä. Heille nopeus on noin 200 gigatavua tunnissa. Ja vielä kestää aikaa kääntyä loogiselta kaatopaikalta, kääriä indeksit jne.

Mutta he käyttävät tätä lähestymistapaa, koska sen avulla he voivat pitää tuotteen luotettavana.

Mitä voimme tehdä täällä? Tehdään testipenkeistä edullisia ja annetaan jokaiselle kehittäjälle oma testipenkki.

Ja tämä on mahdollista.

Ja tässä lähestymistavassa, kun teemme ohuita klooneja jokaiselle kehittäjälle, voimme jakaa sen yhdellä koneella. Jos sinulla on esimerkiksi 10 Tt tietokanta ja haluat antaa sen 10 kehittäjälle, sinulla ei tarvitse olla XNUMX x XNUMX Tt tietokantoja. Tarvitset vain yhden koneen ohuiden eristettyjen kopioiden tekemiseen kullekin kehittäjälle yhdellä koneella. Kerron vähän myöhemmin kuinka se toimii.

Todellinen esimerkki:

• DB - 4,5 teratavua.

• Saamme itsenäisiä kopioita 30 sekunnissa.

Sinun ei tarvitse odottaa testitelinettä ja riippua sen koosta. Saat sen sekunneissa. Ne ovat täysin eristettyjä ympäristöjä, jotka jakavat tietoja keskenään.

Tämä on suurenmoista. Tässä puhumme taikuudesta ja rinnakkaisuniversumista.

Meidän tapauksessamme tämä toimii OpenZFS-järjestelmän avulla.

OpenZFS on kopiointi-kirjoitustiedostojärjestelmä, joka tukee tilannekuvia ja klooneja heti valmiina. Se on luotettava ja skaalautuva. Häntä on erittäin helppo hallita. Se voidaan kirjaimellisesti käyttää kahdessa ryhmässä.

On muitakin vaihtoehtoja:

• lvm,

• Varastointi (esimerkiksi Pure Storage).

Tietokantalaboratorio, josta puhun, on modulaarinen. Voidaan toteuttaa käyttämällä näitä vaihtoehtoja. Mutta toistaiseksi olemme keskittyneet OpenZFS:ään, koska LVM:n kanssa oli ongelmia.

Kuinka se toimii? Sen sijaan, että korvaamme tiedot joka kerta, kun muutamme niitä, tallennamme ne yksinkertaisesti merkitsemällä, että nämä uudet tiedot ovat uudesta ajankohdasta, uudesta tilannevedosta.

Ja tulevaisuudessa, kun haluamme peruuttaa tai haluamme tehdä uuden kloonin jostain vanhemmasta versiosta, sanomme vain: "OK, anna meille nämä tietolohkot, jotka on merkitty näin."

Ja tämä käyttäjä työskentelee tällaisen tietojoukon kanssa. Hän muuttaa niitä vähitellen, tekee omia tilannekuvia.

Ja me haaraudumme. Jokaisella meidän tapauksessamme kehittäjällä on mahdollisuus saada oma klooni, jota hän muokkaa, ja jaettu data jaetaan kaikkien kesken.

Jos haluat ottaa tällaisen järjestelmän käyttöön kotona, sinun on ratkaistava kaksi ongelmaa:

• Ensimmäinen on tiedon lähde, josta otat ne. Voit määrittää replikoinnin tuotannon kanssa. Toivon, että voit jo käyttää määrittämiäsi varmuuskopioita. WAL-E, WAL-G tai Barman. Ja vaikka käytät jonkinlaista pilviratkaisua, kuten RDS tai Cloud SQL, voit käyttää loogisia kaatopaikkoja. Suosittelemme kuitenkin käyttämään varmuuskopioita, koska tällä lähestymistavalla säilytät myös tiedostojen fyysisen rakenteen, jonka avulla pääset vielä lähemmäksi tuotannossa näkemiäsi mittareita, jotta saataisiin kiinni olemassa olevista ongelmista.

• Toinen on paikka, jossa haluat isännöidä tietokantalaboratorion. Se voi olla pilvi, se voi olla On-premise. Tässä on tärkeää sanoa, että ZFS tukee tietojen pakkausta. Ja se tekee sen varsin hyvin.

Kuvittele, että jokaiselle tällaiselle kloonille, riippuen toiminnoista, joita teemme perustan kanssa, jonkinlainen kehittäjä kasvaa. Tätä varten kehittäjä tarvitsee myös tilaa. Mutta koska otimme 4,5 teratavun pohjan, ZFS pakkaa sen 3,5 teratavuun. Tämä voi vaihdella asetuksista riippuen. Ja meillä on vielä tilaa kehittäjälle.

Tällaista järjestelmää voidaan käyttää erilaisiin tapauksiin.

• Nämä ovat kehittäjiä, DBA:ita kyselyn validointia ja optimointia varten.

• Tätä voidaan käyttää laadunvarmistustestauksessa tietyn siirron testaamiseen ennen sen julkaisemista tuotantoon. Ja voimme myös nostaa laadunvarmistukseen erityisiä ympäristöjä todellisilla tiedoilla, joissa he voivat testata uusia toimintoja. Ja se kestää sekunteja odotustuntien sijaan ja ehkä päiviä joissakin muissa tapauksissa, joissa ohuita kopioita ei käytetä.

• Ja toinen tapaus. Jos yrityksellä ei ole valmiina analytiikkajärjestelmää, voimme eristää ohuen kloonin tuotekannasta ja antaa sen pitkille kyselyille tai erityisille indekseille, joita voidaan käyttää analytiikassa.

Tällä lähestymistavalla:

1. Alhainen virhetodennäköisyys "tuotteessa", koska testasimme kaikki muutokset täysikokoisilla tiedoilla.

2. Meillä on testauskulttuuri, sillä nyt sinun ei tarvitse odottaa tuntikausia omaa osastoasi.

3. Eikä ole estettä, ei odottelua testien välillä. Voit todellakin mennä tarkistamaan. Ja se tulee olemaan parempi näin, kun nopeutamme kehitystä.

• Refaktorointia tulee vähemmän. Vähemmän bugeja päätyy tuotantoon. Reaktioimme niitä vähemmän myöhemmin.

• Voimme peruuttaa peruuttamattomat muutokset. Tämä ei ole standardi lähestymistapa.

1. Tästä on hyötyä, koska jaamme testipenkkien resurssit.

Se on jo hyvä, mutta mitä muuta voisi nopeuttaa?

Tällaisen järjestelmän ansiosta voimme merkittävästi pienentää kynnystä tällaiseen testaukseen.

Nyt on muodostumassa noidankehä, jolloin kehittäjän on ryhdyttävä asiantuntijaksi päästäkseen käsiksi todelliseen täysikokoiseen dataan. Hänelle on luotettava tällainen pääsy.

Mutta kuinka kasvaa, jos sitä ei ole olemassa. Mutta entä jos käytettävissäsi on vain hyvin pieni joukko testitietoja? Silloin ei saa todellista kokemusta.

Kuinka päästä pois tästä ympyrästä? Ensimmäiseksi käyttöliittymäksi, joka on kätevä kaiken tason kehittäjille, valitsimme Slack-botin. Mutta se voi olla mikä tahansa muu käyttöliittymä.

Mitä se antaa sinun tehdä? Voit ottaa tietyn kyselyn ja lähettää sen tietokannan erityiseen kanavaan. Otamme automaattisesti käyttöön ohuen kloonin sekunneissa. Suoritetaan tämä pyyntö. Keräämme mittareita ja suosituksia. Esitetään visualisointi. Ja sitten tämä klooni jää, jotta tämä kysely voidaan jotenkin optimoida, lisätä indeksejä jne.

Ja myös Slack antaa meille mahdollisuuden yhteistyöhön. Koska tämä on vain kanava, voit aloittaa keskustelun tästä pyynnöstä juuri tällaisen pyynnön säikeessä, pingillä kollegoillesi, yrityksen sisällä oleville DBA:ille.

Mutta ongelmia on tietysti. Koska tämä on todellinen maailma ja käytämme palvelinta, joka isännöi useita klooneja kerralla, meidän on pakattava kloonien käytettävissä oleva muisti ja suoritinteho.

Mutta jotta nämä testit olisivat uskottavia, sinun on jotenkin ratkaistava tämä ongelma.

On selvää, että tärkeä asia on samat tiedot. Mutta meillä on se jo. Ja haluamme saavuttaa saman kokoonpanon. Ja voimme antaa tällaisen melkein identtisen kokoonpanon.

Olisi siistiä käyttää samaa laitteistoa kuin tuotannossa, mutta se voi vaihdella.

Muistetaan kuinka Postgres toimii muistin kanssa. Meillä on kaksi kätköä. Yksi tiedostojärjestelmästä ja yksi natiivi Postgres, eli jaettu puskurivälimuisti.

On tärkeää huomata, että jaettu puskurivälimuisti varataan, kun Postgres käynnistyy, riippuen määrityksessä määrittämästäsi koosta.

Ja toinen välimuisti käyttää kaiken käytettävissä olevan tilan.

Ja kun teemme useita klooneja yhdellä koneella, käy ilmi, että täytämme muistin vähitellen. Ja hyvällä tavalla jaettu puskurivälimuisti on 25 % koneen käytettävissä olevan muistin kokonaismäärästä.

Ja käy ilmi, että jos emme muuta tätä parametria, voimme ajaa vain 4 esiintymää yhdellä koneella, eli 4 kaikista sellaisista ohuista klooneista. Ja tämä on tietysti huono asia, koska haluamme saada niitä paljon enemmän.

Mutta toisaalta, puskurivälimuistia käytetään indeksien kyselyjen suorittamiseen, eli suunnitelma riippuu siitä, kuinka suuria välimuistimme ovat. Ja jos otamme tämän parametrin ja pienennämme sitä, suunnitelmamme voivat muuttua paljon.

Jos meillä on esimerkiksi suuri välimuisti prod:ssa, Postgres käyttää mieluummin indeksiä. Ja jos ei, niin sitten tulee SeqScan. Ja mitä järkeä olisi, jos suunnitelmamme eivät osuisi yhteen?

Mutta tässä tulemme siihen johtopäätökseen, että itse asiassa Postgresin suunnitelma ei riipu suunnitelman jaetussa puskurissa määritetystä tietystä koosta, se riippuu tehokkaasta_cache_size-arvosta.

Effective_cache_size on arvioitu käytettävissämme olevan välimuistin määrä, eli puskurivälimuistin ja tiedostojärjestelmän välimuistin summa. Tämä asetetaan konfiguraatiossa. Ja tätä muistia ei ole varattu.

Ja tämän parametrin ansiosta voimme huijata Postgresia sanomalla, että meillä on todella paljon tietoa saatavilla, vaikka meillä ei olisikaan näitä tietoja. Ja näin ollen suunnitelmat osuvat täysin yhteen tuotannon kanssa.

Mutta tämä voi vaikuttaa ajoitukseen. Ja optimoimme kyselyt ajoituksen mukaan, mutta on tärkeää, että ajoitus riippuu monista tekijöistä:

• Se riippuu kuormituksesta, joka on tällä hetkellä tuotannossa.

• Se riippuu itse koneen ominaisuuksista.

Ja tämä on epäsuora parametri, mutta itse asiassa voimme optimoida tarkalleen datamäärän, jonka tämä kysely lukee saadakseen tuloksen.

Ja jos haluat ajoituksen olevan lähellä sitä, mitä näemme tuotannossa, meidän on otettava eniten samankaltainen laitteisto ja mahdollisesti vielä enemmän, jotta kaikki kloonit mahtuvat. Mutta tämä on kompromissi, eli saat samat suunnitelmat, näet kuinka paljon tietoa tietty kysely lukee ja voit päätellä, onko tämä kysely hyvä (tai siirto) vai huono, se on vielä optimoitava .

Katsotaanpa, miten Joe on erityisesti optimoitu.

Otetaan pyyntö todellisesta järjestelmästä. Tässä tapauksessa tietokanta on 1 teratavu. Ja haluamme laskea niiden tuoreiden viestien määrän, joilla oli yli 10 tykkäystä.

Kirjoitamme viestiä kanavalle, klooni on otettu käyttöön. Ja näemme, että tällainen pyyntö suoritetaan 2,5 minuutissa. Tämä on ensimmäinen asia, jonka huomaamme.

B Joe näyttää sinulle automaattisia suosituksia suunnitelman ja mittareiden perusteella.

Näemme, että kysely käsittelee liian paljon dataa saadakseen suhteellisen pienen määrän rivejä. Ja jonkinlainen erikoistunut indeksi tarvitaan, koska huomasimme, että kyselyssä on liian monta suodatettua riviä.

Katsotaanpa tarkemmin mitä tapahtui. Näemme todellakin, että olemme lukeneet lähes puolitoista gigatavua tietoa tiedostovälimuistista tai jopa levyltä. Ja tämä ei ole hyvä, koska meillä on vain 142 riviä.

Ja näyttää siltä, ​​että meillä on täällä hakemistoskannaus, ja sen olisi pitänyt toimia nopeasti, mutta koska suodatimme liian monta riviä pois (ne piti laskea), kysely onnistui hitaasti.

Ja tämä tapahtui suunnitelmassa, koska kyselyn ehdot ja indeksin ehdot eivät osittain täsmää.

Yritetään tarkentaa indeksiä ja katsotaan kuinka kyselyn suoritus muuttuu sen jälkeen.

Indeksin luominen kesti melko kauan, mutta nyt tarkistamme kyselyn ja näemme, että aika on 2,5 minuutin sijaan vain 156 millisekuntia, mikä on tarpeeksi hyvä. Ja luimme vain 6 megatavua dataa.

Ja nyt käytämme vain indeksiskannausta.

Toinen tärkeä tarina on se, että haluamme esittää suunnitelman jollakin ymmärrettävämmällä tavalla. Olemme toteuttaneet visualisoinnin Flame Graphsilla.

Tämä on erilainen pyyntö, intensiivisempi. Ja rakennamme Flame Grapheja kahden parametrin mukaan: tämä on datamäärä, jonka tietty solmu laski suunnitelmassa ja ajoituksessa, eli solmun suoritusaika.

Täällä voimme verrata tiettyjä solmuja keskenään. Ja on selvää, kumpi niistä kestää enemmän tai vähemmän, mikä on yleensä vaikeaa tehdä muilla renderöintimenetelmillä.

Tietenkin kaikki tietävät selittää.depesz.com. Tämän visualisoinnin hyvä ominaisuus on, että tallennamme tekstisuunnitelman ja laitamme myös perusparametreja taulukkoon, jotta voimme lajitella.

Ja kehittäjät, jotka eivät ole vielä perehtyneet tähän aiheeseen, käyttävät myös selitystä.depesz.com, koska heidän on helpompi selvittää, mitkä mittarit ovat tärkeitä ja mitkä eivät.

Visualisointiin on uusi lähestymistapa - tämä on selitys.dalibo.com. He tekevät puun visualisoinnin, mutta solmuja on erittäin vaikea verrata toisiinsa. Täällä voit ymmärtää rakenteen hyvin, mutta jos on suuri pyyntö, sinun on vieritettävä edestakaisin, mutta myös vaihtoehto.

yhteistyötä

Ja kuten sanoin, Slack antaa meille mahdollisuuden tehdä yhteistyötä. Jos esimerkiksi törmäämme monimutkaiseen kyselyyn, jonka optimointi ei ole selvä, voimme selvittää tämän ongelman kollegojemme kanssa Slackin säikeessä.

Meistä tuntuu, että on tärkeää testata täysikokoisilla tiedoilla. Tätä varten teimme Update Database Lab -työkalun, joka on saatavilla avoimessa lähdekoodissa. Voit myös käyttää Joe-bottia. Voit ottaa sen heti ja toteuttaa sen kotonasi. Kaikki oppaat löytyvät sieltä.

On myös tärkeää huomata, että ratkaisu itsessään ei ole vallankumouksellinen, koska Delphix on olemassa, mutta se on yritysratkaisu. Se on täysin suljettu, se on erittäin kallista. Olemme erikoistuneet erityisesti Postgresiin. Nämä ovat kaikki avoimen lähdekoodin tuotteita. Liity meihin!

Tähän lopetan. Kiitos!

kysymykset

Hei! Kiitos raportista! Erittäin mielenkiintoinen, varsinkin minusta, koska ratkaisin suunnilleen saman ongelman jokin aika sitten. Ja siksi minulla on useita kysymyksiä. Toivottavasti saan edes osan siitä.

Ihmettelen, miten lasket paikan tälle ympäristölle? Tekniikka tarkoittaa, että tietyissä olosuhteissa kloonisi voivat kasvaa maksimikokoon. Karkeasti sanottuna, jos sinulla on kymmenen teratavun tietokanta ja 10 kloonia, on helppo simuloida tilanne, jossa jokainen klooni painaa 10 ainutlaatuista dataa. Kuinka lasket tämän paikan, eli sen suiston, josta puhuit ja jossa nämä kloonit tulevat asumaan?

Hyvä kysymys. Tässä on tärkeää seurata tiettyjä klooneja. Ja jos kloonissa on liian suuri muutos, se alkaa kasvaa, niin voimme ensin antaa käyttäjälle varoituksen tai pysäyttää tämän kloonin välittömästi, jotta meillä ei ole epäonnistumistilannetta.

Kyllä, minulla on sisäkkäinen kysymys. Eli miten varmistat näiden moduulien elinkaaren? Meillä on tämä ongelma ja täysin erillinen tarina. Miten tämä tapahtuu?

Jokaiselle kloonille on jokin ttl. Periaatteessa meillä on kiinteä ttl.

Mitä jos ei salaisuus?

1 tunti, eli tyhjäkäynti - 1 tunti. Jos sitä ei käytetä, lyömme sen. Mutta tässä ei ole yllätystä, koska voimme nostaa kloonin sekunneissa. Ja jos tarvitset sitä uudelleen, ole hyvä.

Olen myös kiinnostunut teknologioiden valinnasta, koska esimerkiksi käytämme useita menetelmiä rinnakkain syystä tai toisesta. Miksi ZFS? Miksi et käyttänyt LVM:ää? Mainitsit, että LVM:n kanssa oli ongelmia. Mitkä olivat ongelmat? Mielestäni optimaalinen vaihtoehto on varastointi, suorituskyvyn kannalta.

Mikä on ZFS:n suurin ongelma? Se, että sinun on suoritettava samassa isännässä, eli kaikki esiintymät elävät samassa käyttöjärjestelmässä. Ja varastoinnin tapauksessa voit liittää erilaisia ​​laitteita. Ja pullonkaula ovat vain ne lohkot, jotka ovat säilytysjärjestelmässä. Ja kysymys teknologioiden valinnasta on mielenkiintoinen. Miksei LVM?

Erityisesti voimme keskustella LVM:stä tapaamisessa. Tietoja varastoinnista - se on vain kallista. Voimme toteuttaa ZFS-järjestelmän missä tahansa. Voit ottaa sen käyttöön koneellesi. Voit yksinkertaisesti ladata arkiston ja ottaa sen käyttöön. ZFS on asennettu melkein kaikkialle, jos puhumme Linuxista. Eli saamme erittäin joustavan ratkaisun. Ja suoraan ZFS antaa paljon. Voit ladata niin paljon tietoa kuin haluat, liittää suuren määrän levyjä, siellä on tilannekuvia. Ja kuten sanoin, sitä on helppo hallita. Eli se näyttää erittäin miellyttävältä käyttää. Hän on testattu, hän on monta vuotta vanha. Hänellä on erittäin laaja yhteisö, joka kasvaa. ZFS on erittäin luotettava ratkaisu.

Nikolai Samokhvalov: Voinko kommentoida lisää? Nimeni on Nikolay, työskentelemme yhdessä Anatolyn kanssa. Olen samaa mieltä, että säilytys on hienoa. Ja joillain asiakkaillamme on Pure Storage jne.

Anatoli huomautti oikein, että olemme keskittyneet modulaarisuuteen. Ja tulevaisuudessa voit toteuttaa yhden käyttöliittymän - ota tilannekuva, tee klooni, tuhoa klooni. Kaikki on helppoa. Ja säilytys on siistiä, jos on.

Mutta ZFS on kaikkien saatavilla. DelPhix on jo tarpeeksi, heillä on 300 asiakasta. Näistä fortune 100:lla on 50 asiakasta, eli ne on suunnattu NASAlle jne. On aika kaikkien hankkia tämä tekniikka. Ja siksi meillä on avoimen lähdekoodin ydin. Meillä on käyttöliittymäosa, joka ei ole avoimen lähdekoodin. Tämä on alusta, jonka näytämme. Mutta haluamme sen olevan kaikkien saatavilla. Haluamme tehdä vallankumouksen, jotta kaikki testaajat lakkaavat arvaamasta kannettavissa tietokoneissa. Meidän täytyy kirjoittaa SELECT ja nähdä heti, että se on hidasta. Älä odota, että DBA kertoo sinulle siitä. Tässä on päätavoite. Ja uskon, että me kaikki tulemme tähän. Ja teemme tämän kaiken kaikkien saatavilla. Siksi ZFS, koska se on saatavilla kaikkialla. Kiitos yhteisölle ongelmien ratkaisemisesta ja avoimen lähdekoodin lisenssistä jne.*

Terveisiä! Kiitos raportista! Nimeni on Maxim. Olemme käsitelleet samoja asioita. He päättivät itse. Kuinka jaat resursseja näiden kloonien välillä? Jokainen klooni voi tehdä oman asiansa milloin tahansa: yksi testaa yhtä asiaa, toinen toista, joku rakentaa indeksin, jollain on raskas työ. Ja jos voit silti jakaa prosessorilla, niin IO:lla, miten jaat? Tämä on ensimmäinen kysymys.

Ja toinen kysymys koskee katsomoiden erilaisuutta. Oletetaan, että minulla on täällä ZFS ja kaikki on siistiä, mutta prod-asiakkaalla ei ole ZFS, vaan esimerkiksi ext4. Miten tässä tapauksessa?

Kysymykset ovat erittäin hyviä. Mainitsin tämän ongelman hieman sillä tosiasialla, että jaamme resursseja. Ja ratkaisu on tämä. Kuvittele, että testaat lavastusta. Samalla voi olla myös sellainen tilanne, että joku antaa yhden kuorman, joku muu. Ja seurauksena näet käsittämättömiä mittareita. Sama ongelma voi olla jopa prodin kanssa. Kun haluat tarkistaa jonkin pyynnön ja nähdä, että siinä on jokin ongelma - se toimii hitaasti, niin itse asiassa ongelma ei ollut pyynnössä, vaan siinä, että siinä on jonkinlainen rinnakkaiskuorma.

Ja siksi tässä on tärkeää keskittyä siihen, mikä suunnitelma tulee olemaan, mitä toimenpiteitä suunnitelmassa otamme ja kuinka paljon tietoa keräämme tätä varten. Se, että esimerkiksi levyillemme ladataan jotain, vaikuttaa erityisesti ajoitukseen. Mutta voimme arvioida, kuinka ladattu tämä pyyntö on datamäärän perusteella. Ei ole niin tärkeää, että samaan aikaan tapahtuu jonkinlainen teloitus.

Minulla on kaksi kysymystä. Tämä on erittäin siistiä tavaraa. Onko ollut tapauksia, joissa tuotantotiedot, kuten luottokorttien numerot, ovat kriittisiä? Onko jotain valmiina vai onko se erillinen tehtävä? Ja toinen kysymys - onko jotain tällaista MySQL:lle?

Tietoja tiedoista. Teemme hämärtämistä, kunnes teemme. Mutta jos otat käyttöön täsmälleen Joen, jos et anna pääsyä kehittäjille, tietoihin ei ole pääsyä. Miksi? Koska Joe ei näytä tietoja. Se näyttää vain mittareita, suunnitelmia ja se on siinä. Tämä tehtiin tarkoituksella, koska tämä on yksi asiakkaamme vaatimuksista. He halusivat pystyä optimoimaan antamatta kaikille pääsyä.

Tietoja MySQL:stä. Tätä järjestelmää voidaan käyttää kaikkeen, joka tallentaa tilan levylle. Ja koska teemme Postgresia, teemme nyt kaiken automaation ensin Postgresille. Haluamme automatisoida tietojen saamisen varmuuskopiosta. Määritämme Postgresin oikein. Tiedämme kuinka sovittaa suunnitelmat jne.

Mutta koska järjestelmä on laajennettavissa, sitä voidaan käyttää myös MySQL:lle. Ja tällaisia ​​esimerkkejä on. Yandexillä on samanlainen asia, mutta he eivät julkaise sitä missään. He käyttävät sitä Yandex.Metricassa. Ja siellä on vain tarina MySQL:stä. Mutta tekniikat ovat samat, ZFS.

Kiitos raportista! Minulla on myös pari kysymystä. Mainitsit, että kloonausta voidaan käyttää analytiikkaan, esimerkiksi lisäindeksien rakentamiseen. Voitko kertoa hieman lisää miten se toimii?

Ja kysyn heti toisen kysymyksen katsomoiden samankaltaisuudesta, suunnitelmien samankaltaisuudesta. Suunnitelma riippuu myös Postgresin keräämistä tilastoista. Miten ratkaiset tämän ongelman?

Analytiikan mukaan erityistapauksia ei ole, koska emme ole vielä käyttäneet sitä, mutta sellainen mahdollisuus on olemassa. Jos puhumme indekseistä, kuvittele, että kysely jahtaa taulukkoa, jossa on satoja miljoonia tietueita ja saraketta, jota ei yleensä indeksoida prodissa. Ja haluamme laskea tietoja sieltä. Jos tämä pyyntö lähetetään tuotantoon, on mahdollista, että se on yksinkertainen prod, koska pyyntöä käsitellään siellä minuutin ajan.

Ok, tehdään ohut klooni, jota ei ole kauheaa pysähtyä muutamaksi minuutiksi. Ja jotta analytiikan lukeminen olisi mukavampaa, lisäämme indeksit niille sarakkeille, joiden tiedoista olemme kiinnostuneita.

Indeksi luodaan joka kerta?

Voit tehdä sen niin, että kosketamme tietoja, teemme tilannekuvia, sitten palaamme tästä tilannekuvasta ja teemme uusia pyyntöjä. Eli voit tehdä sen niin, että voit kasvattaa uusia klooneja jo kiinnitetyillä indekseillä.

Mitä tulee kysymykseen tilastoista, jos palautamme varmuuskopiosta, jos teemme replikoinnin, tilastomme ovat täsmälleen samat. Koska meillä on koko fyysinen tietorakenne, eli tuomme tiedot sellaisenaan myös kaikkien tilastotietojen kanssa.

Tässä on toinen ongelma. Jos käytät pilviratkaisua, siellä on vain loogisia kaatopaikkoja, koska Google, Amazon eivät salli fyysisen kopion ottamista. Tulee sellainen ongelma.

Kiitos raportista. Tässä oli kaksi hyvää kysymystä MySQL:stä ja resurssien jakamisesta. Mutta itse asiassa kaikki johtuu siitä, että tämä ei ole tietyn DBMS:n aihe, vaan koko tiedostojärjestelmä. Ja vastaavasti resurssien jakamisen kysymykset pitäisi myös ratkaista sieltä, ei lopulta, että se on Postgres, vaan tiedostojärjestelmässä, esimerkiksi palvelimessa.

Kysymykseni on hieman erilainen. Se on lähempänä monikerroksista tietokantaa, jossa on useita kerroksia. Asensimme esimerkiksi kymmenen teratavun kuvapäivityksen, kopioimme. Käytämme tätä ratkaisua erityisesti tietokantoihin. Replikointi on käynnissä, tietoja päivitetään. Rinnakkain työskentelee 100 työntekijää, jotka käynnistävät jatkuvasti näitä erilaisia ​​laukauksia. Mitä tehdä? Kuinka varmistaa, ettei ristiriitaa ole, että he käynnistivät sellaisen, ja sitten tiedostojärjestelmä muuttui, ja kaikki kuvat menivät?

He eivät mene, koska ZFS toimii näin. Voimme pitää erikseen yhdessä säikeessä replikoinnin aiheuttamat tiedostojärjestelmän muutokset. Ja säilytä kloonit, joita kehittäjät käyttävät datan vanhemmissa versioissa. Ja se toimii meillä, kaikki on kunnossa tämän kanssa.

Osoittautuu, että päivitys tapahtuu lisäkerroksena ja kaikki uudet kuvat menevät jo tämän kerroksen perusteella, eikö niin?

Aiemmista tasoista, jotka olivat aiemmista replikaatioista.

Aiemmat tasot putoavat, mutta viittaavat vanhaan tasoon ja ottavatko ne uusia kuvia viimeisestä päivityksessä vastaanotetusta tasosta?

Yleisesti ottaen kyllä.

Sen seurauksena meillä on jopa viikuna kerroksia. Ja ajan myötä ne on puristettava?

Kyllä kaikki on oikein. On joku ikkuna. Pidämme viikoittain tilannekuvia. Se riippuu siitä, mitä resursseja sinulla on. Jos pystyt tallentamaan paljon tietoa, voit tallentaa tilannekuvia pitkään. Ne eivät katoa itsestään. Tietojen korruptiota ei tapahdu. Jos tilannekuvat ovat vanhentuneita, kuten meistä näyttää, eli se riippuu yrityksen käytännöstä, voimme yksinkertaisesti poistaa ne ja vapauttaa tilaa.

Hei, kiitos raportista! Kysymys Joesta. Sanoit, että asiakas ei halunnut antaa kaikille pääsyä tietoihin. Tarkkaan ottaen, jos henkilöllä on Selitä analyysin tulos, hän voi kurkistaa tietoja.

Se on niin. Voimme esimerkiksi kirjoittaa: "SELECT FROM WHERE email = siihen". Eli emme näe itse dataa, mutta voimme nähdä joitain epäsuoria merkkejä. Tämä on ymmärrettävä. Mutta toisaalta, se on kaikki siellä. Meillä on lokiauditointi, meillä on hallinnassamme muut kollegat, jotka myös näkevät, mitä kehittäjät tekevät. Ja jos joku yrittää tehdä tämän, turvallisuuspalvelu tulee heidän luokseen ja työskentelee tämän asian parissa.

Hyvää iltapäivää Kiitos raportista! Minulla on lyhyt kysymys. Jos yritys ei käytä Slackia, onko siihen nyt olemassa sidontaa, vai voivatko kehittäjät ottaa käyttöön ilmentymiä yhdistääkseen testisovelluksen tietokantoihin?

Nyt on linkki Slackiin, eli ei ole muuta messengeriä, mutta haluan todella tehdä tukea myös muille lähettiläille. Mitä voit tehdä? Voit ottaa DB Labin käyttöön ilman Joeta, mennä REST API:n tai alustamme avulla luomaan klooneja ja muodostamaan yhteyden PSQL:ään. Mutta tämä voidaan tehdä, jos olet valmis antamaan kehittäjillesi pääsyn tietoihin, koska näyttöä ei enää ole.

En tarvitse tätä kerrosta, mutta tarvitsen sellaisen mahdollisuuden.

Sitten kyllä, se voidaan tehdä.

Lähde: will.com