Jonakin päivänä kaukaisessa tulevaisuudessa tarpeettomien tietojen automaattinen poistaminen on yksi DBMS:n tärkeistä tehtävistä [1]. Sillä välin meidän on itse huolehdittava tarpeettomien tietojen poistamisesta tai siirtämisestä halvempiin tallennusjärjestelmiin. Oletetaan, että päätät poistaa useita miljoonia rivejä. Melko yksinkertainen tehtävä, varsinkin jos ehto on tiedossa ja sopiva indeksi löytyy. "DELETE FROM table1 WHERE col1 = :value" - mikä voisi olla yksinkertaisempaa, eikö?
Video:
-
Olen ollut Highload-ohjelmakomiteassa ensimmäisestä vuodesta, eli vuodesta 2007 lähtien.
-
Ja olen ollut Postgresissa vuodesta 2005. Käytti sitä monissa projekteissa.
-
Ryhmä on ollut myös RuPostgesin palveluksessa vuodesta 2007.
-
Meetupissa osallistujamäärämme on kasvanut yli 2100:aan. Tämä on toinen paikka maailmassa New Yorkin jälkeen, ohitettuaan San Franciscon kauan sitten.
-
Olen asunut Kaliforniassa useita vuosia. Työskentelen enimmäkseen amerikkalaisten yritysten, myös suurten, kanssa. He ovat aktiivisia Postgres-käyttäjiä. Ja siellä syntyy kaikenlaista mielenkiintoista.
– tämä on minun yritykseni. Pyrimme automatisoimaan tehtäviä, jotka poistavat kehityksen hidastumiset.
Jos teet jotain, Postgresin ympärillä on joskus virheitä. Oletetaan, että sinun on odotettava, kunnes järjestelmänvalvoja saa sinulle testipenkin, tai sinun on odotettava, kunnes DBA vastaa sinulle. Ja tällaisia pullonkauloja löydämme kehitys-, testaus- ja hallintoprosessista ja yritämme poistaa ne automaation ja uusien lähestymistapojen avulla.
Olin äskettäin VLDB:ssä Los Angelesissa. Tämä on suurin tietokantakonferenssi. Ja siellä oli raportti, että tulevaisuudessa DBMS:t eivät vain tallenna, vaan myös poistavat tietoja automaattisesti. Tämä on uusi aihe.
Maailmassa on yhä enemmän dataa. Zetatavut ovat 1 000 000 petatavua. Ja nyt on jo arvioitu, että meillä on yli 100 zettatavua dataa tallennettuna maailmassa. Ja niitä tulee koko ajan lisää.
Ja mitä tehdä sen kanssa? On selvää, että se on poistettava. Tässä on linkki mielenkiintoiseen raporttiin. Mutta toistaiseksi tätä ei ole otettu käyttöön DBMS:ssä.
Ne, jotka osaavat laskea rahaa, haluavat kaksi asiaa. He haluavat meidän poistavan, joten teknisesti meidän on kyettävä tekemään se.
Seuraavaksi kerron abstraktin tilanteen, joka sisältää joukon todellisia tilanteita, eli tietyn koosteen siitä, mitä minulle ja ympäröiville tietokannoille todella tapahtui monta kertaa, monta vuotta. Haravat ovat kaikkialla ja kaikki astuvat niiden päälle koko ajan.
Oletetaan, että meillä on yksi tai useampi tukikohta, jotka kasvavat. Ja osa tietueista on ilmeistä roskaa. Esimerkiksi käyttäjä alkoi tehdä jotain siellä, mutta ei lopettanut. Ja jonkin ajan kuluttua tiedämme, että tätä keskeneräistä työtä ei voi enää säilyttää. Toisin sanoen haluaisimme puhdistaa joitain roskatuotteita säästääksemme tilaa, parantaaksemme suorituskykyä jne.
Yleensä tehtävänä on automatisoida tiettyjen asioiden, tiettyjen rivien poistaminen taulukosta.
Ja meillä on pyyntö, josta puhumme tänään, toisin sanoen jätteiden poistamisesta.
Pyysimme kokenutta kehittäjää tekemään tämän. Hän otti tämän pyynnön, tarkisti sen itse - kaikki toimii. Testasin sitä lavastuksessa - kaikki on kunnossa. Rullattu ulos - kaikki toimii. Teemme tämän kerran päivässä - kaikki on hyvin.
Tietokanta kasvaa ja kasvaa. Päivittäinen DELETE alkaa toimia hieman hitaammin.
Sitten ymmärrämme, että olemme nyt markkinointiyhtiö ja liikenne tulee olemaan moninkertainen, joten päätämme keskeyttää turhat asiat väliaikaisesti. Ja unohdamme palauttaa sen.
Muutamaa kuukautta myöhemmin he muistivat. Ja se kehittäjä lopetti tai oli varattu johonkin muuhun, he määräsivät toisen palauttamaan sen.
Hän tarkisti kehitystä, lavastusta - kaikki on kunnossa. Luonnollisesti sinun on vielä siivottava, mitä on kertynyt. Hän tarkisti, kaikki toimii.
Mitä tapahtuu seuraavaksi? Sitten kaikki hajoaa meille. Se putoaa niin paljon, että jossain vaiheessa kaikki kaatuu. Kaikki ovat shokissa, kukaan ei ymmärrä mitä tapahtuu. Ja sitten käy ilmi, että tämä DELETE oli ongelma.
Jotain meni pieleen? Tässä on luettelo asioista, jotka voivat mennä pieleen. Mikä näistä on tärkein?
-
Esimerkiksi arvostelua ei tehty, eli DBA-asiantuntija ei katsonut. Kokeneen silmän avulla hän löytäisi ongelman välittömästi, ja lisäksi hänellä on käytössään tuote, johon on kertynyt useita miljoonia rivejä.
-
Ehkä he ovat tarkistaneet jotain väärin.
-
Ehkä laitteisto on vanhentunut ja sinun on päivitettävä tämä tietokanta.
-
Tai jotain on vialla itse tietokannassa, ja meidän on siirryttävä Postgresista MySQL: ään.
-
Tai ehkä operaatiossa on jotain vikaa.
-
Ehkä työn organisoinnissa on virheitä ja sinun täytyy irtisanoa joku ja palkata parempia ihmisiä?
Ei ollut DBA-tarkistusta. Jos olisi DBA, hän näkisi nämä useat miljoonat rivit ja sanoisi jopa ilman mitään kokeita: "He eivät tee sitä." Oletetaan, että jos tämä koodi olisi GitLabissa, GitHubissa ja siellä olisi koodin tarkistusprosessi, eikä ole olemassa sellaista asiaa, että tämä toiminto tapahtuisi ilman DBA:n hyväksyntää prod:lla, niin DBA sanoisi ilmeisesti: "Et voi tehdä sitä. ”
Ja hän sanoisi, että sinulla tulee olemaan ongelmia levyn IO:n kanssa ja kaikki prosessit menevät hulluksi, saattaa olla lukkoja ja estät myös automaattisen tyhjiön muutaman minuutin ajan, joten tämä ei ole hyvä.
Toinen virhe on, että he tarkastivat väärässä paikassa. Näimme sen jälkeen, että paljon roskadataa oli kertynyt tuotantoon, mutta kehittäjällä ei ollut kertynyt dataa tähän tietokantaan, eikä kukaan todellakaan luonut tätä roskaa lavastusta varten. Vastaavasti rivejä oli 1, jotka valmistuivat nopeasti.
Ymmärrämme, että testimme ovat heikkoja, eli rakennettu prosessi ei tartu ongelmiin. Riittävää DB-koetta ei suoritettu.
Ihanteellinen koe tulisi mieluiten suorittaa samoilla laitteilla. Tätä ei aina ole mahdollista tehdä samalla laitteistolla, mutta on erittäin tärkeää, että se on täysikokoinen kopio tietokannasta. Tätä olen saarnannut jo useita vuosia. Ja vuosi sitten puhuin tästä, voit katsoa sen kaiken YouTubesta.
Ehkä laitteistomme on huono? Jos katsot, latenssi on hypännyt. Näimme, että kierrätys oli 100 %. Tietysti, jos nämä olisivat nykyaikaisia NVMe-asemia, se olisi todennäköisesti meille paljon helpompaa. Ja ehkä emme menisi makuulle sen takia.
Jos sinulla on pilviä, päivitys on helppoa. Julkaisimme uusia kopioita uudella laitteistolla. Siirtyä. Ja kaikki on hyvin. Aika helppo.
Onko mahdollista jotenkin koskettaa pienempiä levyjä? Ja tässä DBA:n avulla sukeltamme tiettyyn aiheeseen, jota kutsutaan tarkistuspisteen virittämiseksi. Osoittautuu, että emme suorittaneet tarkistuspisteen viritystä.
Mikä on tarkistuspiste? Tämä on saatavilla missä tahansa DBMS:ssä. Kun muistissasi olevat tiedot muuttuvat, niitä ei heti kirjoiteta levyille. Tieto tietojen muuttumisesta kirjoitetaan ensin eteenpäinkirjoituslokiin. Ja jossain vaiheessa DBMS päättää, että on aika heittää oikeat sivut levylle, jotta voimme tehdä vähemmän REDO:ta, jos meillä on vika. Se on kuin lelu. Jos meidät tapetaan, aloitamme pelin viimeisestä tarkistuspisteestä. Ja kaikki DBMS-järjestelmät toteuttavat tämän.
Postgresin asetukset ovat myöhässä. Ne on suunniteltu 10-15 vuotta vanhoille tietomäärille ja operaatioille. Ja tarkistuspiste ei ole poikkeus.
Nämä tiedot ovat raportistamme Postgres-tarkastuksella eli automaattisella terveystarkastuksella. Ja tässä on tietokanta useista teratavuista. Ja on selvää, että tarkastuspisteet pakotetaan lähes 90 prosentissa tapauksista.
Mitä se tarkoittaa? Siellä on kaksi asetusta. Tarkistuspiste voi tapahtua aikakatkaisussa, esimerkiksi 10 minuutissa. Tai se voi tapahtua, kun melko paljon tietoja on täytetty.
Ja oletuksena max_wal_saze on 1 gigatavu. Itse asiassa tämä tapahtuu Postgresissa 300-400 megatavun jälkeen. Olet muuttanut niin paljon tietoja ja sinulla on tarkistuspiste.
Ja jos kukaan ei virittänyt sitä, mutta palvelu on kasvanut ja yritys ansaitsee paljon rahaa, sillä on paljon tapahtumia, niin tarkistuspiste tapahtuu kerran minuutissa, joskus kerran 30 sekunnissa, ja joskus ne jopa menevät päällekkäin. . Tämä on todella huono.
Ja meidän on varmistettava, että se tulee harvemmin. Eli voimme nostaa max_wal_sizea. Ja hän hyökkää harvemmin.
Mutta olemme kehittäneet kokonaisen menetelmän, kuinka tämä tehdään oikein, eli kuinka tehdä päätöksiä asetusten valinnasta selkeästi tiettyjen tietojen perusteella.
Tämän mukaisesti suoritamme kaksi tietokantakokeilusarjaa.
Ensimmäinen sarja - muutamme max_wal_size. Ja teemme massiivisen operaation. Ensin teemme sen oletusasetuksena 1 gigatavu. Ja teemme valtavan monien miljoonien rivien DELETE-toiminnon.
Näet kuinka vaikeaa se on meille. Näemme, että levyn IO on erittäin huono. Katsotaan, kuinka paljon WAL:ia tuotimme, koska tämä on erittäin tärkeää. Katsotaan kuinka monta kertaa tarkistuspiste tapahtui. Ja näemme, että se ei ole hyvä.
Seuraavaksi lisäämme max_wal_size. Toistamme. Lisää, toista. Ja niin monta kertaa. Periaatteessa 10 pistettä on hyvä, missä 1, 2, 4, 8 gigatavua. Ja tarkastelemme tietyn järjestelmän käyttäytymistä. On selvää, että laitteiden täällä pitäisi olla kuin prodissa. Sinulla pitäisi olla samat levyt, sama määrä muistia ja samat Postgres-asetukset.
Ja tällä tavalla vaihdamme järjestelmäämme ja tiedämme kuinka DBMS käyttäytyy huonon massan DELETE tapauksessa, kuinka se tarkistaa.
Checkpoint tarkoittaa venäjäksi tarkastuspisteitä.
Esimerkki: POISTA useita miljoonia rivejä indeksin mukaan, rivit ovat "hajallaan" sivuilla.
Tässä on esimerkki. Tämä on jonkinlainen perusta. Ja kun max_wal_size-oletusasetus on 1 gigatavu, on erittäin selvää, että tallennuslevymme menevät hyllylle. Tämä kuva on tyypillinen oire hyvin sairaalle potilaalle, eli hän tunsi olonsa todella pahaksi. Ja siellä oli vain yksi toimenpide, tässä oli vain POISTA useista miljoonista riveistä.
Jos tällainen operaatio sallitaan prod:ssa, kaadumme vain alas, koska on selvää, että yksi DELETE tappaa meidät hyllyssä.
Edelleen, missä on 16 gigatavua, voit nähdä, että hampaat ovat jo alkaneet näkyä. Hampaat ovat jo paremmat, eli koputetaan kattoon, mutta ei niin pahasti. Siellä näkyi vähän vapautta. Oikealla on tallenne. Ja operaatioiden määrä on toinen kaavio. Ja on selvää, että hengitämme jo hieman helpommin 16 gigatavun ansiosta.
Ja missä 64 gigatavua on näkyvissä, siitä on tullut täysin parempi. Jo hampaat näkyvät selvästi, on enemmän mahdollisuuksia selviytyä muista leikkauksista ja tehdä jotain levyn kanssa.
Miksi niin?
Sukellan hieman yksityiskohtiin, mutta tämä tarkistuspisteen virityksen suorittamisen aihe voi johtaa kokonaiseen raporttiin, joten en mene liian yksityiskohtiin, mutta hahmotan hieman, mitä vaikeuksia siinä on.
Jos tarkistuspiste tapahtuu liian usein, emmekä päivitä rivejämme peräkkäin, vaan etsimme ne indeksin perusteella, mikä on hyvä, koska emme poista koko taulukkoa, niin voi käydä niin, että ensin kosketimme ensimmäistä sivua, sitten tuhannesosaa, ja palasi sitten ensimmäiseen. Ja jos näiden ensimmäisellä sivulla käyntien välillä tarkistuspiste on jo tallentanut sen levylle, se tallentaa sen uudelleen, koska olemme likaaneet sen toisen kerran.
Ja pakotamme tarkastuspisteen pelastamaan sen monta kertaa. Ihan kuin sille olisi ylimääräisiä toimintoja.
Mutta siinä ei vielä kaikki. Postgresissa sivut painavat 8 kilotavua ja Linuxissa 4 kilotavua. Ja siinä on asetus full_page_writes. Se on oletuksena käytössä. Ja tämä on oikein, koska jos sammutamme sen, on olemassa vaara, että jos tapahtuu vika, vain puolet sivusta tallennetaan.
Lähetyslokin WAL-merkinnän käyttäytyminen on sellainen, että kun meillä on tarkistuspiste ja vaihdamme sivua ensimmäistä kertaa, koko sivu, eli kaikki 8 kilotavua, päätyy edelleenlähetyslokiin, vaikka muutti vain riviä, joka painaa 100 tavua. Ja meidän on pakko kirjoittaa koko sivu ylös.
Myöhemmissä muutoksissa on vain tietty monikko, mutta ensimmäistä kertaa kirjoitamme kaiken ylös.
Ja vastaavasti, jos tarkistuspiste toistuu, meidän on aloitettava kaikki alusta ja täytettävä koko sivu. Toistuvissa tarkistuspisteissä, kun kävelemme samojen sivujen läpi, full_page_writes = on suurempi kuin se voisi olla, eli tuotamme enemmän WAL:ia. Lisää lähetetään replikoihin, arkistoon, levylle.
Ja vastaavasti meillä on kaksi irtisanomista.
Jos lisäämme max_wal_sizea, käy ilmi, että helpotamme sekä checkpointin että wal writerin työtä. Ja se on hienoa.
Asennataan teratavu ja eletään sen kanssa. Mitä pahaa siinä on? Tämä on huono asia, koska epäonnistumisen sattuessa nousemme tuntikausia, koska tarkistuspiste oli kauan sitten ja paljon on jo muuttunut. Ja meidän on tehtävä REDO kaiken tämän vuoksi. Ja niin teemme toista sarjaa kokeita.
Teemme operaation ja katsomme kun tarkastuspiste on lähellä valmistumista, teemme tarkoituksella tappamisen -9 Postgres.
Ja sen jälkeen käynnistetään uudestaan ja katsotaan kuinka kauan kestää nousta tällä laitteistolla, eli kuinka paljon REDO tekee tässä huonossa tilanteessa.
Huomautan kahdesti, että tilanne on huono. Ensinnäkin putosimme juuri ennen tarkastuspisteen loppua, joten meillä on paljon menetettävää. Ja toiseksi, meillä oli valtava leikkaus. Ja jos tarkistuspisteillä olisi aikakatkaisu, niin todennäköisesti vähemmän WAL:a olisi luotu edellisen tarkistuspisteen jälkeen. Eli tämä on kahdesti häviäjä.
Mittaamme tämän tilanteen eri max_wal_sizelle ja ymmärrämme, että jos max_wal_size on 64 gigatavua, niin tupla-pahimmassa tilanteessa nousemme 10 minuuttia. Ja mietimme sopiiko tämä meille vai ei. Tämä on liiketoimintakysymys. Meidän on näytettävä tämä kuva liiketoimintapäätöksistä vastaaville ja kysyttävä: ”Mikä on enimmäisaika, jonka voimme odottaa ongelman sattuessa? Voimmeko makaamaan huonommassa tilanteessa 3-5 minuuttia? Ja sinä teet päätöksen.
Ja tässä on mielenkiintoinen kohta. Meillä on pari raporttia Patronista konferenssissa. Ja ehkä käytät sitä. Tämä on automaattinen vikasieto Postgresille. GitLab ja Data Egret puhuivat tästä.
Ja jos sinulla on automaattinen vikasieto, joka tapahtuu 30 sekunnissa, voimme ehkä makaamaan 10 minuuttia? Koska tässä vaiheessa siirrymme kopioon, ja kaikki on hyvin. Tämä on kiistanalainen kysymys. En tiedä selkeää vastausta. Minusta vain tuntuu, että tämä aihe ei koske vain katastrofipalautusta.
Jos meillä on pitkä toipuminen epäonnistumisesta, tunnemme olomme epämukavaksi monissa muissa tilanteissa. Esimerkiksi samoissa kokeissa, kun teemme jotain ja joskus joudumme odottamaan 10 minuuttia.
En silti menisi liian pitkälle, vaikka meillä olisi automaattinen vikasieto. Yleensä arvot, kuten 64, 100 gigatavua, ovat hyviä arvoja. Joskus kannattaa jopa valita vähemmän. Yleensä tämä on hienovaraista tiedettä.
Jos haluat iteroida esimerkiksi max_wal_size = 1, 8, sinun on toistettava massaoperaatio monta kertaa. Teit sen. Ja haluat tehdä sen uudelleen samalla pohjalla, mutta olet jo poistanut kaiken. Mitä tehdä?
Kerron sinulle myöhemmin ratkaisustamme ja siitä, mitä teemme toistuaksemme tällaisissa tilanteissa. Ja tämä on oikea lähestymistapa.
Mutta tässä tapauksessa meillä oli onnea. Jos, kuten tässä sanotaan "ALUE, POISTA, PALAUTTA", voimme toistaa POISTA. Eli jos peruutimme sen itse, voimme toistaa sen. Ja fyysisesti tietosi ovat siellä. Et saa edes turvotusta. Voit toistaa tällaista DELETE-toimintoa.
Tämä DELETE, jossa on ROLLBACK, on ihanteellinen tarkistuspisteiden viritykseen, vaikka sinulla ei olisikaan oikein asennettua tietokantalaboratoriota.
Teimme kyltin yhdellä sarakkeella "i". Postgresilla on palvelusarakkeita. Ne ovat näkymättömiä, ellei niitä erikseen pyydetä. Nämä ovat: ctid, xmid, xmax.
Ctid on fyysinen osoite. Sivu nolla, sivun ensimmäinen monikko.
Voidaan nähdä, että ROOLBACKin jälkeen monikko pysyi samassa paikassa. Eli voimme yrittää uudelleen, se käyttäytyy samalla tavalla. Tämä on pääasia.
Xmax on tuplen kuolinaika. Se on syötetty, mutta Postgres tietää, että tämä tapahtuma peruutettiin, joten sillä ei ole väliä, onko se 0 vai peruutettu tapahtuma. Tämä viittaa siihen, että DELETE:tä voidaan käyttää järjestelmän käyttäytymisen massiivisten toimintojen iterointiin ja testaamiseen. Voit tehdä tietokantalaboratorioita köyhille.
Tämä koskee ohjelmoijia. Myös DBA:n osalta he aina moittivat ohjelmoijia tästä: "Miksi teet niin pitkiä ja vaikeita operaatioita?" Tämä on täysin erilainen kohtisuora aihe. Ennen oli hallintoa, mutta nyt tulee kehitystä.
Ilmeisesti emme ole jakaneet sitä osiin. Se on selvää. Tällaista DELETE-toimintoa on mahdotonta jakaa osiin miljooniksi riveiksi. Sen tekemiseen menee 20 minuuttia, ja kaikki makaa. Mutta valitettavasti jopa kokeneet kehittäjät tekevät virheitä, jopa erittäin suurissa yrityksissä.
Miksi rikkoutuminen on tärkeää?
-
Jos näemme levyn olevan kova, hidastetaan sitä. Ja jos olemme rikki, voimme lisätä taukoja, voimme hidastaa kuristusta.
-
Emmekä estä muita pitkään aikaan. Joissakin tapauksissa sillä ei ole väliä, jos poistat todellista roskaa, jonka parissa kukaan ei työskentele, et todennäköisesti estä ketään paitsi autovacuum-työtä, koska se odottaa tapahtuman valmistumista. Mutta jos poistat jotain, jota joku muu saattaa pyytää, niin ne estetään, syntyy jonkinlainen ketjureaktio. Nettisivuilla ja mobiilisovelluksissa tulee välttää pitkiä tapahtumia.
Tämä on mielenkiintoista. Näen usein kehittäjien kysyvän: "Mikä pakkauskoko minun pitäisi valita?"
On selvää, että mitä suurempi eräkoko, sitä pienemmät tapahtuman yleiskustannukset eli tapahtuman lisäkustannukset. Mutta samaan aikaan tämän tapahtuman aika pitenee.
Minulla on hyvin yksinkertainen sääntö: ota niin monta kuin mahdollista, mutta älä ylitä suoritusta sekunnissa.
Miksi sekunti? Selitys on hyvin yksinkertainen ja ymmärrettävä kaikille, myös ei-teknisille ihmisille. Näemme reaktion. Otetaan 50 millisekuntia. Jos jokin on muuttunut, silmämme reagoi. Jos se on vähemmän, se on vaikeampaa. Jos jokin vastaa 100 millisekunnin jälkeen, esimerkiksi napsautit hiirellä ja se vastasi sinulle 100 millisekunnin kuluttua, tunnet jo tämän pienen viiveen. Sekunti nähdään jo jarruna.
Vastaavasti, jos jaamme massaoperaatiomme 10 sekunnin purskeisiin, vaarana on, että estämme jonkun. Ja se toimii muutaman sekunnin, ja ihmiset jo huomaavat sen. Siksi en halua tehdä sitä sekuntia kauempaa. Mutta samaan aikaan, älä pilkko sitä liian pieneksi, koska tapahtuman yleiskustannukset ovat huomattavat. Se on pohjalle raskaampaa, ja monia muita ongelmia saattaa ilmetä.
Valitsemme pakkauskoon. Kussakin tapauksessa voimme tehdä tämän eri tavalla. Voidaan automatisoida. Ja olemme vakuuttuneita yhden pakkauksen käsittelyn tehokkuudesta. Toisin sanoen poistamme yhden paketin tai PÄIVITYSTÄ.
Muuten, kaikki, mitä kerron, ei koske vain POISTAA. Kuten arvasit, nämä ovat mitä tahansa datan joukkotoimintoja.
Ja näemme, että suunnitelma on erinomainen. Voit nähdä hakemistoskannauksen, vielä paremmin vain indeksiskannauksen. Ja meillä on pieni määrä dataa. Ja kaikki toimii alle sekunnissa. Super.
Ja meidän on silti varmistettava, ettei huononemista tapahdu. Tapahtuu, että ensimmäiset erät valmistetaan nopeasti, ja sitten kaikki pahenee ja pahenee. Prosessi on sellainen, että sinun on testattava paljon. Juuri tähän tietokantalaboratorioita tarvitaan.
Ja meidän on vielä valmisteltava jotain, jotta voimme valvoa tätä oikein tuotannossa. Voimme esimerkiksi kirjoittaa lokiin ajan, voimme kirjoittaa missä olemme nyt ja kenet olemme nyt poistaneet. Ja tämä antaa meille mahdollisuuden ymmärtää myöhemmin, mitä tapahtuu. Ja jos jokin menee pieleen, löydä ongelma nopeasti.
Jos meidän on tarkistettava kyselyiden tehokkuus ja meidän on iteroitava useita kertoja, on olemassa sellainen asia kuin kaveribot. Hän on jo valmis. Sitä käyttävät kymmenet kehittäjät päivittäin. Ja hän voi tarjota valtavan teratavun tietokannan pyynnöstä 30 sekunnissa, oma kopiosi. Ja voit poistaa jotain sieltä ja sanoa RESET ja poistaa sen uudelleen. Voit kokeilla sitä tällä tavalla. Näen tässä asiassa tulevaisuutta. Ja tätä me jo teemme.
Mitkä ovat osiointistrategiat? Näen kolme erilaista osiointistrategiaa, joita kehittäjät käyttävät pakkauksessa.
Ensimmäinen on hyvin yksinkertainen. Meillä on numeerinen tunnus. Jaetaan se eri aikaväleihin ja työskennellään sen kanssa. Huono puoli on selvä. Ensimmäisessä osassa meillä voi olla 100 riviä oikeaa roskaa, toisessa 5 riviä tai ei ollenkaan, tai kaikki 1 riviä osoittautuvat roskaksi. Erittäin epätasainen työ, mutta helppo rikkoa. He ottivat suurimman tunnuksen ja murskasivat sen. Tämä on naiivi lähestymistapa.
Toinen strategia on tasapainoinen lähestymistapa. Sitä käytetään Gitlabissa. Otimme ja skannatimme pöydän. Löysimme ID-pakettien rajat siten, että jokainen paketti sisälsi täsmälleen 10 000 tietuetta. Ja he laittoivat minut jonkinlaiseen jonoon. Ja käsittelemme edelleen. Voit tehdä tämän useissa säikeissä.
Ensimmäisessä strategiassa voit muuten tehdä tämän myös useissa säikeissä. Se ei ole vaikeaa.
Mutta on olemassa viileämpi ja optimaalisempi lähestymistapa. Tämä on kolmas strategia. Ja jos mahdollista, on parempi valita se. Teemme tämän erityisen indeksin perusteella. Tässä tapauksessa se on todennäköisesti indeksi, joka perustuu roskatilanteeseen ja tunnukseemme. Lisäämme tunnuksen, jotta se on vain indeksiskannaus, jotta emme mene kasaan.
Tyypillisesti vain hakemistoskannaus on nopeampi kuin indeksiskannaus.
Ja löydämme nopeasti tunnuksemme, jotka haluamme poistaa. Valitsemme BATCH_SIZE etukäteen. Emme vain vastaanota niitä, vaan otamme ne vastaan erityisellä tavalla ja korjaamme ne välittömästi. Mutta lukitsemme ne niin, että jos ne ovat jo lukossa, emme lukitse niitä, vaan siirrymme eteenpäin ja otamme seuraavat. Tämä on päivityksen ohitus lukittu. Tämä Postgres-superominaisuus antaa meille mahdollisuuden työskennellä useissa säikeissä, jos haluamme. Mahdollisesti yhdessä ketjussa. Ja sitten on CTE - tämä on yksi pyyntö. Ja meillä on todellinen poisto tämän CTE:n toisessa kerroksessa - returning *. Voit palauttaa tunnuksen, mutta se on parempi *, jos kullakin rivillä on vähän tietoja.
Miksi me tarvitsemme tätä? Tarvitsemme tämän raportoidaksemme. Olemme itse asiassa nyt poistaneet niin monta riviä. Ja ID- tai Created_at -rajamme ovat tällaiset. Voit tehdä min, max. Jotain muuta voidaan tehdä. Tänne mahtuu paljon. Ja tämä on erittäin kätevä seurantaan.
On vielä yksi huomautus indeksistä. Jos päätämme, että tarvitsemme erityisen indeksin tätä tiettyä tehtävää varten, meidän on varmistettava, että se ei pilaa kasa vain tuples -päivityksiä. Eli Postgresilla on tällaiset tilastot. Tämä näkyy taulukosi kohdassa pg_stat_user_tables. Voit nähdä, käytetäänkö kuumia päivityksiä vai ei.
On tilanteita, joissa uusi hakemistosi voi yksinkertaisesti katkaista ne. Ja kaikki muut jo käynnissä olevat päivitykset hidastuvat. Ei vain siksi, että indeksi ilmestyi (jokainen indeksi hidastaa päivityksiä hieman, mutta vain vähän), mutta tässä se silti sotkee asioita. Ja tälle taulukolle on mahdotonta tehdä erityistä optimointia. Tätä tapahtuu joskus. Tämä on hienovaraisuus, jonka harva muistaa. Ja tälle haravalle on helppo astua. Joskus käy niin, että sinun täytyy löytää lähestymistapa toiselta puolelta ja silti pärjätä ilman tätä uutta indeksiä tai tehdä toinen indeksi tai tehdä jotain muuta, esimerkiksi voit käyttää toista menetelmää.
Mutta tämä on optimaalinen strategia, kuinka jakaa se eriin ja ampua erissä yhdellä pyynnöstä, poistaa vähän kerrallaan jne.
Pitkät kaupat -
Tukkeutunut tyhjiö
Esto-ongelma
Virhe 5 on suuri. Nikolay Okmeteristä puhui Postgres-valvonnasta. Valitettavasti täydellistä Postgres-seurantaa ei ole olemassa. Jotkut ovat lähempänä, jotkut kauempana. Okmeter on tarpeeksi lähellä ollakseen täydellinen, mutta paljon puuttuu ja pitää lisätä. Sinun on oltava valmis tähän.
Esimerkiksi kuolleita ketjuja on parempi seurata. Jos pöydälläsi on paljon kuollutta tavaraa, jokin on vialla. On parempi reagoida nyt, muuten siellä voi tapahtua huononemista ja voimme mennä makuulle. Se tapahtuu.
Jos on suuri IO, on selvää, että tämä ei ole hyvä.
Myös pitkät kaupat. Pitkiä tapahtumia ei pitäisi sallia OLTP:ssä. Ja tässä on linkki katkelmaan, jonka avulla voit ottaa tämän katkelman ja jo seurata pitkiä tapahtumia.
Miksi pitkät kaupat ovat huonoja? Koska kaikki lukot vapautetaan vasta lopussa. Ja me suljemme kaikki. Lisäksi estämme automaattisen tyhjiön kaikille pöydille. Tämä ei ole ollenkaan hyvä. Vaikka kopiossa olisi käytössä kuuma valmiustila, tämä on silti huono. Yleensä on parempi välttää pitkiä liiketoimia missä tahansa.
Jos meillä on monia pöytiä, joita ei imuroida, meillä on oltava hälytys. Tällainen tilanne on mahdollinen täällä. Voimme vaikuttaa epäsuorasti autotyhjiön toimintaan. Tämä on katkelma Avitosta, jota paransin hieman. Ja se osoittautui mielenkiintoiseksi työkaluksi nähdä, mitä meillä on automaattisen tyhjiön kanssa. Siellä on esimerkiksi pöytiä odottamassa, eivätkä he odota vuoroaan. Sinun on myös laitettava se valvontaan ja oltava hälytys.
Ja ongelmat lohkot. Tukkipuiden metsä. Haluan ottaa joltain jotain ja parantaa sitä. Tässä otin Data Egretistä siistin rekursiivisen CTE:n, jossa näkyy lukittuvien puiden metsä. Tämä on hyvä asia diagnostiikassa. Ja sen pohjalle voidaan rakentaa myös seurantaa. Mutta tämä on tehtävä huolellisesti. Sinun on tehtävä itsellesi pieni lausunto_aikakatkaisu. Ja lock_timeout on toivottava.
Joskus kaikki nämä virheet esiintyvät yhdessä.
Mielestäni tärkein virhe tässä on organisatorinen. Se on organisatorista, koska tekniikka ei toimi. Tämä on numero 2 - he tarkistivat väärästä paikasta.
Emme tarkistaneet siellä, koska meillä ei ollut tuotantokloonia, joka olisi helppo tarkistaa. Kehittäjällä ei ehkä ole pääsyä tuotantoon ollenkaan.
Ja tarkistimme väärässä paikassa. Jos he olisivat tarkastaneet siellä, olisimme nähneet sen itse. Kehittäjä näki kaiken tämän myös ilman DBA:ta, jos hän tarkistaisi sen hyvässä ympäristössä, jossa on sama määrä dataa ja identtinen järjestely. Hän olisi nähnyt kaiken tämän rappeutumisen ja häpeännyt.
Lisää auton imurista. Kun olemme tehneet massiivisen useiden miljoonien rivien siivouksen, meidän on vielä tehtävä UUDELLEENPAKKAUS. Tämä on erityisen tärkeää indekseille. Heille tulee paha mieli, kun olemme puhdistaneet kaiken siellä.
Ja jos haluat palauttaa arjen strippauksen, niin suosittelen tekemään sen useammin, mutta pienempinä. Se voi olla kerran minuutissa tai jopa useammin vähän. Ja meidän on valvottava kahta asiaa: sitä, että tässä asiassa ei ole virheitä ja että se ei jää jälkeen. Näyttämäni tempun avulla voit ratkaista tämän.
Se, mitä teemme, on avointa lähdekoodia. Tämä on julkaistu GitLabissa. Ja teemme sen niin, että ihmiset voivat tarkistaa myös ilman DBA:ta. Teemme tietokantalaboratorion, eli kutsumme peruskomponenttia, jonka parissa Joe parhaillaan työskentelee. Ja voit napata kopion tuotannosta. Nyt on olemassa Joe for slack -toteutus, voit sanoa siellä: "selitä sellainen ja sellainen pyyntö" ja saat heti tuloksen tietokannan kopiollesi. Voit jopa tehdä DELETE-toiminnon siellä, eikä kukaan huomaa.
Oletetaan, että sinulla on 10 teratavua, teemme tietokantalaboratorion myös 10 teratavua. Ja 10 kehittäjää voi työskennellä samanaikaisesti samanaikaisten 10 teratavun tietokantojen kanssa. Jokainen saa tehdä mitä haluaa. Voi poistaa, pudottaa jne. Tämä on upeaa. Puhumme tästä huomenna.
Tätä kutsutaan ohueksi varaukseksi. Tämä on hienovaraista tarjontaa. Tämä on jonkinlainen fantasia, joka eliminoi suuresti viiveet kehitys- ja testaustyössä ja tekee maailmasta paremman paikan tässä suhteessa. Eli sen avulla voit vain välttää ongelmia massaoperaatioissa.
Esimerkki: 5 teratavun tietokanta, kopion saaminen alle 30 sekunnissa. Eikä se edes riipu koosta, eli sillä ei ole väliä kuinka monta teratavua.
Tänään voit mennä ja kaivaa työkaluihimme. Voit rekisteröityä ja katsoa mitä siellä on. Voit asentaa tämän botin itse. Se on ilmainen. Kirjoittaa.
kysymykset
Hyvin usein todellisissa tilanteissa käy ilmi, että dataa, jonka pitäisi jäädä taulukkoon, on paljon vähemmän kuin mitä pitäisi poistaa. Eli tällaisessa tilanteessa on usein helpompi toteuttaa tämä lähestymistapa, kun on helpompi luoda uusi objekti, kopioida sinne vain tarvittavat tiedot ja litteroida vanha taulukko. On selvää, että tarvitset ohjelmistolähestymistapaa tällä hetkellä vaihtaessasi. Miten tämä lähestymistapa on?
Tämä on erittäin hyvä lähestymistapa ja erittäin hyvä tehtävä. Se on hyvin samanlainen kuin mitä pg_repack tekee, se on hyvin samankaltainen kuin mitä sinun on tehtävä, kun tunnistat ihmiset 4 tavua. Monet puitteet tekivät tämän useita vuosia sitten, ja levyt ovat juuri kasvaneet ja ne on muutettava 8 tavuksi.
Tämä tehtävä on melko vaikea. Me teimme sen. Ja sinun on oltava erittäin varovainen. Siellä on lukot jne. Mutta se on tehty. Eli tavallinen lähestymistapa on käyttää pg_repackia. Ilmoitat sellaisesta merkistä. Ja ennen kuin aloitat sen täyttämisen tilannekuvatiedoilla, määrität myös yhden taulukon, joka seuraa kaikkia muutoksia. Siinä on temppu, että et ehkä edes seuraa joitain muutoksia. On hienouksia. Ja sitten vaihdat ja otat muutokset käyttöön. Tulee lyhyt tauko, kun lukitsimme kaikki, mutta kaiken kaikkiaan näin tehdään.
Jos katsot pg_repackia GitHubissa, niin kun oli tehtävä muuntaa tunnus int 4:stä int 8:ksi, tuli idea käyttää pg_repackia itse. Tämä on myös mahdollista, mutta tämä on vähän hakkerimenetelmä, mutta se toimii myös tähän. Voit puuttua pg_repackia käyttävään triggeriin ja sanoa siellä: "Emme tarvitse näitä tietoja", eli siirrämme vain tarvitsemamme. Ja sitten hän vain vaihtaa ja se on siinä.
Tällä lähestymistavalla saamme myös toisen kopion taulukosta, jossa tiedot on jo indeksoitu ja aseteltu erittäin sujuvasti kauniilla indekseillä.
Ei, tämä on hyvä lähestymistapa. Mutta tiedän, että tähän on yritetty kehittää automaatiota, eli tehdä universaali ratkaisu. Voin esitellä sinulle tämän automaation. Se on kirjoitettu Pythonilla, hyvä juttu.
Olen vain vähän MySQL-maailmasta, joten tulin kuuntelemaan. Ja me käytämme tätä lähestymistapaa.
Mutta se on vain, jos meillä on 90 prosenttia. Jos meillä on 5%, sitä ei ole kovin hyvä käyttää.
Kiitos raportista! Jos ei ole resursseja tuotteen täydellisen kopion tekemiseen, onko olemassa algoritmia tai kaavaa kuorman tai koon laskemiseen?
Hyvä kysymys. Toistaiseksi olemme pystyneet löytämään usean teratavun tietokantoja. Vaikka laitteisto ei olisikaan sama, esimerkiksi vähemmän muistia, vähemmän prosessoria ja levyt eivät ole aivan samat, teemme sen silti. Jos ei ole missään, sinun on mietittävä sitä. Anna minun ajatella sitä huomiseen asti, tulit, puhumme, tämä on hyvä kysymys.
Kiitos raportista! Aloit ensin puhua siitä, että on olemassa siisti Postgres, jolla on sellaiset rajoitukset, mutta se kehittyy. Ja tämä kaikki on pitkälti kainalosauva. Eikö tämä kaikki ole ristiriidassa itse Postgresin kehityksen kanssa, jossa tulee esiin jonkinlainen DELETE-puolustus tai jotain muuta, jonka pitäisi pitää matalalla tasolla se, mitä yritämme täällä peitellä omilla oudoilla keinoillamme?
Jos SQL:ssä sanoimme useiden tietueiden poistamisen tai päivittämisen yhdessä tapahtumassa, kuinka Postgres voi jakaa tämän? Olemme fyysisesti rajoitettuja toiminnassamme. Teemme tätä vielä pitkään. Ja me lukitaan tähän aikaan jne.
He tekivät samoin indeksien kanssa.
Voin olettaa, että sama tarkistuspisteen viritys voitaisiin automatisoida. Jonakin päivänä tämä voi tapahtua. Mutta sitten en oikein ymmärrä kysymystä.
Kysymys kuuluu: onko olemassa kehitysvektoria, joka menee juuri sinne ja kulkee rinnakkain sinun kanssasi täällä? Nuo. Eivätkö he vielä ajattele sitä?
Puhuin periaatteista, joita voidaan nyt käyttää. On toinenkin botti , tällä voit tehdä automaattisen tarkistuspisteen virityksen. Tapahtuuko tämä koskaan Postgresissa? En tiedä, tästä ei edes keskustella vielä. Tästä ollaan vielä kaukana. Mutta on tiedemiehiä, jotka luovat uusia järjestelmiä. Ja he työntävät meidät automaattisiin indekseihin. Kehitystä on. Voit esimerkiksi tarkastella automaattista viritystä. Se valitsee parametrit automaattisesti. Mutta hän ei vielä tee tarkistuspisteviritystä puolestasi. Eli se valitsee suorituskyvyn, kuoripuskurin jne.
Ja tarkistuspisteen virittämiseen voit tehdä seuraavan asian: jos sinulla on tuhat klusteria ja erilaisia laitteita, erilaisia virtuaalikoneita pilvessä, voit käyttää bottiamme tehdä automaatiota. Ja max_wal_size valitaan automaattisesti kohdeasetustesi mukaan. Mutta toistaiseksi tämä ei valitettavasti ole lähelläkään ytimessä olemista.
Hyvää iltapäivää Puhuit pitkien liiketoimien vaaroista. Sanoit, että automaattinen tyhjiö on estetty poistojen varalta. Miten tämä muuten haittaa meitä? Koska puhumme enemmän tilan vapauttamisesta ja sen käytöstä. Mitä muuta meillä on menetettävää?
Automaattinen tyhjiö ei ehkä ole suurin ongelma tässä. Ja se, että pitkä tapahtuma voi estää muita tapahtumia, on vaarallisempi mahdollisuus. Hän voi tavata tai ei tapaa. Jos hän tapaa, asiat voivat olla erittäin huonoja. Ja autovakuumissa tämä on myös ongelma. OLTP:n pitkissä tapahtumissa on kaksi ongelmaa: lukot ja automaattinen tyhjiö. Ja jos sinulla on kuuma valmiustilan palaute käytössä replikassa, niin automaattinen tyhjiön esto saapuu myös masterille, se tulee replikalta. Mutta siellä ei ainakaan ole lukkoja. Ja täällä tulee olemaan lukot. Puhumme tietojen muutoksista, joten lukot ovat tärkeä asia tässä. Ja jos tämä jatkuu pitkään, pitkään, yhä useammat tapahtumat estetään. He voivat saada muut ansaan. Ja lukkopuita ilmestyy. Annoin linkin katkelmaan. Ja tästä ongelmasta tulee nopeasti havaittavampi kuin autotyhjiön ongelma, joka voi vain kertyä.
Kiitos raportista! Aloitit raporttisi sanomalla, että testasit väärin. Jatkoimme ajatustamme, että meidän on otettava samat laitteet, täysin samalla pohjalla. Oletetaan, että annoimme kehittäjälle perustan. Ja hän suostui pyyntöön. Ja hän näyttää voivan hyvin. Mutta se ei tarkista livenä, vaan esimerkiksi livenä meidän kuormitus on 60-70%. Ja vaikka käytämme tätä viritystä, se ei onnistu kovin hyvin
On tärkeää, että tiimissäsi on asiantuntija ja käytät DBA-asiantuntijoita, jotka voivat ennustaa, mitä tapahtuu todellisessa taustakuormituksessa. Kun vain ajoimme puhtaiden muutostemme läpi, näemme kuvan. Mutta edistyneempi lähestymistapa oli, kun teimme saman asian uudelleen, mutta simuloidulla tuotantokuormalla. Tämä on aivan siistiä. Meidän on vielä kasvattava tähän pisteeseen. Se on kypsä. Katsoimme puhtaasti sitä, mitä meillä on, ja myös, onko meillä tarpeeksi resursseja. Se on hyvä kysymys.
Kun teemme jo roskavalinnan ja meillä on esimerkiksi poistettu lippu
Tämän autovacuum tekee automaattisesti Postgresissa.
Ai, tekeekö hän niin?
Autovacuum on roskien kerääjä.
Kiitos!
Kiitos raportista! Onko mahdollista suunnitella välittömästi tietokanta osioituna niin, että kaikki roskat poistetaan päätaulukosta jonnekin sivuun?
Tietysti on.
Voimmeko sitten suojautua, jos olemme lukinneet pöydän, jota ei pitäisi käyttää?
Tietysti on. Mutta tämä on kana ja muna kysymys. Jos me kaikki tiedämme, mitä tulevaisuudessa tapahtuu, teemme tietysti kaiken hienosti. Mutta liiketoiminta muuttuu, uusia sarakkeita ja uusia pyyntöjä ilmestyy. Ja sitten - hups, haluamme poistaa sen. Mutta tämä on ihanteellinen tilanne; sitä tapahtuu elämässä, mutta ei aina. Mutta kaiken kaikkiaan se on hyvä idea. Katkaise vain ja se on siinä.
Lähde: will.com