Kunagi kauges tulevikus saab mittevajalike andmete automaatne eemaldamine DBMS-i üheks oluliseks ülesandeks [1]. Seni peame ise hoolitsema mittevajalike andmete kustutamise või teisaldamise eest odavamatesse salvestussüsteemidesse. Oletame, et otsustate kustutada paar miljonit rida. Üsna lihtne ülesanne, eriti kui seisund on teada ja sobiv indeks olemas. "DELETE FROM table1 WHERE col1 = :value" – mis saaks olla lihtsam, eks?
Video:
-
Olen Highload programmikomitees olnud alates esimesest aastast, s.o alates 2007. aastast.
-
Ja ma olen olnud Postgresiga alates 2005. aastast. Kasutas seda paljudes projektides.
-
Grupp RuPostgesiga ka alates 2007. aastast.
-
Oleme Meetupis kasvanud 2100+ osalejani. See on New Yorgi järel maailmas teisel kohal, San Francisco edestas pikka aega.
-
Olen elanud Californias mitu aastat. Tegelen rohkem Ameerika ettevõtetega, ka suurtega. Nad on aktiivsed Postgresi kasutajad. Ja seal on igasuguseid huvitavaid asju.
on minu firma. Tegeleme selliste ülesannete automatiseerimisega, mis kõrvaldavad arengu aeglustused.
Kui sa midagi teed, siis vahel on Postgresi ümber mingid pistikud. Oletame, et peate ootama, kuni administraator teie jaoks katsestendi seadistab, või peate ootama, kuni DBA teile vastab. Ja selliseid kitsaskohti leiame arendus-, testimis- ja haldusprotsessis ning püüame neid automatiseerimise ja uute lähenemiste abil kõrvaldada.
Olin hiljuti Los Angeleses VLDB-s. See on suurim andmebaaside konverents. Ja seal oli aruanne, et tulevikus DBMS mitte ainult ei salvesta, vaid ka kustutab automaatselt andmeid. See on uus teema.
Zetabaitide maailmas on üha rohkem andmeid – see on 1 000 000 petabaiti. Ja praegu arvatakse juba, et meil on maailmas salvestatud rohkem kui 100 zettabaiti andmeid. Ja neid tuleb aina juurde.
Ja mida sellega teha? Ilmselgelt tuleb see eemaldada. Siin on link sellele huvitavale raportile. Kuid siiani pole seda DBMS-is rakendatud.
Need, kes oskavad raha lugeda, tahavad kahte asja. Nad tahavad, et me kustutaksime, seega peaksime tehniliselt suutma seda teha.
Järgmisena räägin mingist abstraktsest olukorrast, mis sisaldab hunnikut reaalseid olukordi, st omamoodi kokkuvõtet sellest, mis minu ja ümbritsevate andmebaasidega tegelikult mitu korda, palju aastaid juhtus. Rehad on kõikjal ja kõik astuvad neile kogu aeg peale.
Oletame, et meil on baas või mitu alust, mis kasvavad. Ja mõned plaadid on ilmselgelt prügi. Näiteks hakkas kasutaja seal midagi tegema, kuid ei lõpetanud seda. Ja mõne aja pärast teame, et seda lõpetamata ei saa enam säilitada. See tähendab, et ruumi kokkuhoiuks, jõudluse parandamiseks jne soovime koristada mõnda prügi.
Üldiselt on ülesanne automatiseerida konkreetsete asjade, konkreetsete ridade eemaldamist mõnes tabelis.
Ja meil on selline palve, millest me täna räägime, ehk siis prügi äraveo kohta.
Palusime seda teha kogenud arendajal. Ta võttis selle taotluse vastu, kontrollis seda ise - kõik töötab. Lavastusel testitud - kõik on korras. Rullitud - kõik töötab. Kord päevas käime selle läbi – kõik on korras.
Andmebaas kasvab ja kasvab. Igapäevane DELETE hakkab veidi aeglasemalt töötama.
Siis saame aru, et meil on nüüd turundusfirma ja liiklus läheb kordades suuremaks, seega otsustame mittevajalikud asjad ajutiselt peatada. Ja unusta tagasi tulla.
Paar kuud hiljem tuli neile meelde. Ja see arendaja lõpetas tegevuse või on millegi muuga hõivatud, andis teisele käsu see tagastada.
Ta kontrollis arendajat ja lavastust – kõik on korras. Loomulikult tuleb kogunenud ikka ära koristada. Ta kontrollis, et kõik töötab.
Mis järgmisena juhtub? Siis laguneb meie jaoks kõik. See langeb nii, et ühel hetkel kukub kõik maha. Kõik on šokis, keegi ei saa aru, mis toimub. Ja siis selgub, et asi oli selles DELETE.
Midagi läks valesti? Siin on nimekiri sellest, mis võis valesti minna. Milline neist on kõige olulisem?
-
Näiteks puudus ülevaade, st DBA ekspert ei vaadanud seda. Ta leiaks kogenud pilguga kohe probleemi üles ja pealegi on tal ligipääs prod-ile, kuhu on kogunenud mitu miljonit rida.
-
Võib-olla kontrollisid nad midagi valesti.
-
Võib-olla on riistvara aegunud ja peate selle baasi uuendama.
-
Või on andmebaasi endaga midagi valesti ja me peame minema Postgresilt MySQL-ile.
-
Või äkki on operatsiooniga midagi valesti.
-
Võib-olla on töökorralduses mingid vead ja on vaja keegi vallandada ja parimad inimesed tööle võtta?
DBA kontrolli ei tehtud. Kui DBA oleks, näeks ta neid mitut miljonit rida ja ütleks isegi ilma igasuguste katseteta: "Nad ei tee seda." Oletame, et kui see kood oleks GitLabis, GitHubis ja seal toimuks koodi ülevaatuse protsess ja poleks sellist asja, et ilma DBA heakskiiduta see toiming toimuks tootes, siis ilmselt ütleks DBA: "Seda ei saa teha .”
Ja ta ütleks, et teil on ketta IO-ga probleeme ja kõik protsessid lähevad hulluks, võib esineda lukke ja ka blokeerite autovaakumi mõneks minutiks, nii et see pole hea.
Teine viga – kontrolliti vales kohas. Pärast nägime, et tootele kogunes palju rämpsandmeid, kuid arendajal ei olnud sellesse andmebaasi kogutud andmeid ja keegi ei loonud seda rämpsu lavastuse ajal. Sellest lähtuvalt oli 1 rida, mis said kiiresti hakkama.
Mõistame, et meie testid on nõrgad, see tähendab, et ülesehitatud protsess ei taba probleeme. Adekvaatset DB-katset ei tehtud.
Ideaalne katse viiakse eelistatavalt läbi sama seadmega. Alati ei ole seda võimalik teha sama seadmega, kuid on väga oluline, et see oleks andmebaasi täissuuruses koopia. Seda olen ma juba mitu aastat jutlustanud. Ja aasta tagasi ma rääkisin sellest, saate seda kõike YouTube'is vaadata.
Võib-olla on meie varustus halb? Kui vaadata, siis latentsusaeg hüppas. Oleme näinud, et kasutamine on 100%. Muidugi, kui need oleksid kaasaegsed NVMe-draivid, siis oleks meil ilmselt palju lihtsam. Ja võib-olla me ei heidaks selle pärast pikali.
Kui teil on pilved, on uuendamine seal hõlpsasti teostatav. Tõstas uuele riistvarale uued koopiad. ümber lülituma. Ja kõik on hästi. Päris lihtne.
Kas väiksemaid kettaid on võimalik kuidagi katsuda? Ja siin, lihtsalt DBA abiga, sukeldume teatud teemasse, mida nimetatakse kontrollpunktide häälestamiseks. Selgub, et meil polnud kontrollpunkti häälestamist.
Mis on kontrollpunkt? See on mis tahes DBMS-is. Kui teie mälus on andmeid, mis muutuvad, ei kirjutata neid kohe kettale. Teave, et andmed on muutunud, kirjutatakse esmalt ettekirjutuslogi. Ja ühel hetkel otsustab DBMS, et on aeg tõelised lehed kettale visata, et tõrke korral saaksime teha vähem REDO. See on nagu mänguasi. Kui meid tapetakse, alustame mängu viimasest kontrollpunktist. Ja kõik DBMS-id rakendavad seda.
Postgresi seaded on maha jäänud. Need on mõeldud 10-15 aasta vanuste andmemahtude ja tehingute jaoks. Ja kontrollpunkt pole erand.
Siin on teave meie Postgresi kontrolliaruandest, st automaatsest tervisekontrollist. Ja siin on mõni mitme terabaidi andmebaas. Ja hästi on näha, et sunnitud kontrollpunktid ligi 90% juhtudest.
Mida see tähendab? Seal on kaks seadet. Kontrollpunkt võib tulla timeoutiga näiteks 10 minuti pärast. Või võib see tulla siis, kui päris palju andmeid on täidetud.
Ja vaikimisi on max_wal_saze seatud 1 gigabaidile. Tegelikult juhtub see Postgresis pärast 300–400 megabaiti. Olete muutnud nii palju andmeid ja teie kontrollpunkt juhtub.
Ja kui keegi seda ei häälestanud ja teenus kasvas ja ettevõte teenib palju raha, sellel on palju tehinguid, siis tuleb kontrollpunkt kord minutis, mõnikord iga 30 sekundi järel ja mõnikord isegi kattub. See on üsna halb.
Ja me peame tagama, et seda tuleks harvemini. See tähendab, et saame suurendada max_wal_size. Ja seda tuleb harvemini.
Kuid oleme välja töötanud terve metoodika, kuidas seda õigesti teha, st kuidas teha otsus seadete valimise kohta, selgelt konkreetsete andmete põhjal.
Vastavalt sellele teeme andmebaasidega kaks katseseeriat.
Esimene seeria - muudame max_wal_size. Ja me teeme tohutut operatsiooni. Esiteks teeme seda vaikeseadel 1 gigabait. Ja me teeme tohutult paljudest miljonitest ridadest koosneva DELETE'i.
Näete, kui raske see meie jaoks on. Näeme, et ketta IO on väga halb. Vaatame, kui palju WAL-e oleme loonud, sest see on väga oluline. Vaatame, mitu korda kontrollpunkti juhtus. Ja me näeme, et see pole hea.
Järgmisena suurendame max_wal_size. Kordame. Suurendame, kordame. Ja nii mitu korda. Põhimõtteliselt on hea 10 punkti, kus 1, 2, 4, 8 gigabaiti. Ja me vaatame konkreetse süsteemi käitumist. Selge see, et siin peaks varustus olema nagu prod-l. Teil peavad olema samad kettad, sama hulk mälu ja samad Postgresi sätted.
Ja sel viisil vahetame oma süsteemi ja teame, kuidas DBMS käitub halva massi DELETE korral, kuidas see kontrollpunkti teeb.
Kontrollpunkt vene keeles on kontrollpunktid.
Näide: KUSTUTAGE mitu miljonit rida indeksi järgi, read on lehtedel laiali.
Siin on näide. See on mingi alus. Ja kui max_wal_size vaikeseade on 1 gigabait, on väga selge, et meie kettad lähevad salvestamiseks riiulisse. See pilt on väga haige patsiendi tüüpiline sümptom, see tähendab, et ta tundis end tõesti halvasti. Ja seal oli üksainus operatsioon, oli vaid mitme miljoni rea DELETE.
Kui prod-is on selline operatsioon lubatud, siis heidame lihtsalt pikali, sest on selge, et üks DELETE tapab meid riiulis.
Edasi, kus 16 gigabaiti, on selge, et hambad on juba läinud. Hambad on juba paremad ehk koputame lakke, aga mitte nii hullusti. Seal oli teatud vabadus. Paremal on rekord. Ja toimingute arv - teine graafik. Ja selge on see, et juba 16 gigabaiti hingame veidi kergemini.
Ja kus 64 gigabaiti on näha, et täitsa paremaks on läinud. Juba hambad on hääldatud, on rohkem võimalusi muid operatsioone üle elada ja kettaga midagi ette võtta.
Miks nii?
Sukeldun pisut üksikasjadesse, kuid see teema, kuidas kontrollpunktide häälestamist läbi viia, võib anda tulemuseks terve aruande, nii et ma ei laadi palju, kuid kirjeldan veidi, millised raskused sellega kaasnevad.
Kui kontrollpunkt toimub liiga sageli ja me ei uuenda oma ridu järjest, vaid leiame indeksi järgi, mis on hea, sest me ei kustuta tervet tabelit, siis võib juhtuda, et algul puudutasime esimest, siis tuhandendat, ja siis pöördus tagasi esimese juurde. Ja kui nende esimese lehe külastuste vahel on kontrollpunkt selle juba kettale salvestanud, siis salvestab ta selle uuesti, sest saime selle teist korda mustaks.
Ja me sunnime kontrollpunkti seda mitu korda salvestama. Kuidas oleks tema jaoks üleliigsed operatsioonid.
Kuid see pole veel kõik. Leheküljed on Postgresis 8 kilobaiti ja Linuxis 4 kilobaiti. Ja seal on säte full_page_writes. See on vaikimisi lubatud. Ja see on õige, sest kui me selle välja lülitame, siis on oht, et kokkujooksmisel salvestatakse ainult pool lehte.
Edastamise logi WAL-i kirjutamise käitumine on selline, et kui meil on kontrollpunkt ja me muudame lehte esimest korda, siis kogu leht, st kõik 8 kilobaiti, satub edasisuunamislogi, kuigi muutsime ainult rida, mis kaalub 100 baiti . Ja me peame kogu lehe üles kirjutama.
Järgnevates muudatustes on ainult konkreetne korteež, kuid esimest korda kirjutame kõik üles.
Ja vastavalt sellele, kui kontrollpunkt kordus, peame alustama kõike uuesti nullist ja lükkama kogu lehe. Sagedaste kontrollpunktide korral on samu lehti läbides full_page_writes = on rohkem, kui see võiks olla, st genereerime rohkem WAL-i. Rohkem saadetakse koopiatesse, arhiivi, kettale.
Ja vastavalt sellele on meil kaks koondamist.
Kui suurendame väärtust max_wal_size, selgub, et muudame selle lihtsamaks nii kontrollpunkti kui ka wali kirjutaja jaoks. Ja see on suurepärane.
Paneme terabaidi sisse ja elame kaasa. Mis selles halba on? See on halb, sest rikke korral ronime tundideks, kuna kontrollpunkt oli ammu ja palju on juba muutunud. Ja me peame kõik selle REDO tegema. Ja nii teeme teise katseseeria.
Teeme operatsiooni ja vaatame, millal kontrollpunkt on lõppemas, tapame meelega -9 Postgres.
Ja pärast seda käivitame selle uuesti ja vaatame, kui kaua see sellel seadmel tõuseb, st kui palju see selles halvas olukorras TAASTAB.
Kaks korda märgin, et olukord on halb. Esiteks põrutasime vahetult enne kontrollpunkti lõppu, seega on meil palju kaotada. Ja teiseks oli meil tohutu operatsioon. Ja kui kontrollpunktid oleksid aegunud, genereeritaks tõenäoliselt vähem WAL-i alates viimasest kontrollpunktist. See tähendab, et see on kahekordne kaotaja.
Mõõdame sellist olukorda erinevate max_wal_size suuruste puhul ja saame aru, et kui max_wal_size on 64 gigabaiti, siis topelt halvimal juhul ronime 10 minutit. Ja me mõtleme, kas see sobib meile või mitte. See on äriline küsimus. Peame seda pilti näitama äriotsuste eest vastutavatele isikutele ja küsima: „Kui kaua saame probleemi korral maksimaalselt pikali olla? Kas me saame kõige halvemas olukorras 3-5 minutit pikali heita? Ja teete otsuse.
Ja siin on huvitav punkt. Meil on konverentsil Patroni kohta paar ettekannet. Ja võib-olla kasutate seda. See on Postgresi automaatne ebaõnnestumine. GitLab ja Data Egret rääkisid sellest.
Ja kui teil on automaatne tõrkeotsing, mis tuleb 30 sekundiga, siis võib-olla saame 10 minutit pikali heita? Sest me läheme selleks hetkeks üle koopiale ja kõik saab korda. See on vaieldav küsimus. Ma ei tea selget vastust. Ma lihtsalt tunnen, et see teema ei puuduta ainult krahhi taastamist.
Kui pärast ebaõnnestumist taastume kaua, tunneme end ebamugavalt ka paljudes muudes olukordades. Näiteks samades katsetes, kui me midagi teeme ja vahel peame 10 minutit ootama.
Ma ei läheks ikkagi liiga kaugele, isegi kui meil on automaatne ebaõnnestumine. Reeglina on head väärtused sellised väärtused nagu 64, 100 gigabaiti. Mõnikord tasub isegi vähem valida. Üldiselt on see peen teadus.
Iteratsioonide tegemiseks, näiteks max_wal_size =1, 8, peate massioperatsiooni kordama mitu korda. Sa said hakkama. Ja samal alusel soovite seda uuesti teha, kuid olete juba kõik kustutanud. Mida teha?
Räägin hiljem meie lahendusest, mida me teeme, et sellistes olukordades korduda. Ja see on kõige õigem lähenemine.
Aga sel juhul meil vedas. Kui, nagu siin on kirjas "ALUSTAMINE, KUSTUTAMINE, TAGASI", võime korrata KUSTUTAMIST. See tähendab, et kui me selle ise tühistasime, võime seda korrata. Ja füüsiliselt teie juures asuvad andmed samas kohas. Sul ei teki isegi paistetust. Saate korrata selliseid DELETE-sid.
See DELETE koos ROLLBACKiga sobib ideaalselt kontrollpunktide häälestamiseks, isegi kui teil pole korralikult juurutatud andmebaasilaborit.
Tegime plaadi ühe veeruga "i". Postgresil on utiliidi veerud. Need on nähtamatud, kui neid pole spetsiaalselt palutud. Need on: ctid, xmid, xmax.
Ctid on füüsiline aadress. Nullleht, lehe esimene korteež.
On näha, et peale ROOLBACKi jäi korteež samale kohale. See tähendab, et võime uuesti proovida, see käitub samamoodi. See on peamine.
Xmax on korteeži surmaaeg. See oli tembeldatud, kuid Postgres teab, et tehing tühistati, seega pole vahet, kas see on 0 või tühistatud tehing. See viitab sellele, et on võimalik itereerida üle DELETE ja kontrollida süsteemi käitumise hulgitoiminguid. Saate teha andmebaasilaboreid vaestele.
See puudutab programmeerijaid. Ka DBA kohta kiidavad nad programmeerijaid alati selle eest: "Miks te nii pikki ja keerulisi toiminguid teete?". See on täiesti erinev perpendikulaarne teema. Varem oli administratsioon ja nüüd tuleb areng.
Ilmselgelt pole me tükkideks murdunud. See on selge. Sellist DELETE'i on võimatu miljonite ridade jaoks osadeks mitte jagada. Seda tehakse 20 minutit ja kõik jääb pikali. Kuid kahjuks teevad isegi kogenud arendajad vigu isegi väga suurtes ettevõtetes.
Miks on oluline murda?
-
Kui näeme, et ketas on kõva, siis aeglustame seda. Ja kui oleme katki, siis saame lisada pause, saame pidurdamist aeglustada.
-
Ja me ei blokeeri teisi kaua. Mõnel juhul pole vahet, kui kustutate tõelist prügi, mille kallal keegi ei tööta, siis suure tõenäosusega ei blokeeri te kedagi peale automaatvaakumi töö, sest see ootab tehingu lõpuleviimist. Aga kui eemaldate midagi, mida keegi teine saab taotleda, siis ta blokeeritakse, tekib mingi ahelreaktsioon. Veebilehtedel ja mobiilirakendustes tuleks vältida pikki tehinguid.
See on huvitav. Näen sageli, et arendajad küsivad: "Mis pakendi suuruse peaksin valima?".
On selge, et mida suurem on kogumi suurus, seda väiksem on tehingu üldkulu, st tehingutest tulenev täiendav üldkulu. Kuid samal ajal pikeneb selle tehingu aeg.
Mul on väga lihtne reegel: võtke nii palju kui võimalik, kuid ärge ületage käivitatavaid faile sekundis.
Miks sekund? Seletus on väga lihtne ja arusaadav kõigile, ka mittetehnilistele inimestele. Me näeme reaktsiooni. Võtame 50 millisekundit. Kui midagi on muutunud, siis meie silm reageerib. Kui vähem, siis raskem. Kui miski reageerib 100 millisekundi pärast, näiteks klõpsasite hiirt ja see vastas teile 100 millisekundi pärast, tunnete juba seda väikest viivitust. Sekund on juba tajutav piduritena.
Järelikult, kui jagame oma massioperatsioonid 10-sekundilisteks rünnakuteks, on meil oht, et blokeerime kellegi. Ja see töötab mõne sekundi ja inimesed märkavad seda juba. Seetõttu eelistan mitte teha rohkem kui sekundi. Kuid samal ajal ärge tükeldage seda väga peeneks, sest tehingu üldkulud on märgatavad. Alus on kõvem ja võib tekkida muid erinevaid probleeme.
Valime paki suuruse. Igal juhul saame seda teha erinevalt. Saab automatiseerida. Ja me oleme veendunud ühe paki töötlemise tõhususes. See tähendab, et me teeme ühe paki KUSTUTAMISE või VÄRSKENDAMISE.
Muide, kõik, millest ma räägin, ei puuduta ainult DELETE'i. Nagu arvasite, on need andmetega tehtavad hulgitoimingud.
Ja me näeme, et plaan on suurepärane. Näete indeksi skannimist, ainult indeksiga skannimine on veelgi parem. Ja meil on väike hulk andmeid. Ja vähem kui sekund täidab. Super.
Ja me peame ikkagi veenduma, et degradeerumist ei toimu. Juhtub, et esimesed pakid saavad kiiresti läbi ja siis läheb aina hullemaks ja hullemaks. Protsess on selline, et peate palju katsetama. Just selleks on andmebaasilaborid.
Ja me peame ikkagi midagi ette valmistama, et see võimaldaks meil seda tootmises õigesti järgida. Näiteks saame logisse kirjutada kellaaja, saame kirjutada, kus me praegu oleme ja kelle oleme nüüd kustutanud. Ja see võimaldab meil hiljem toimuvast aru saada. Ja kui midagi läheb valesti, leidke probleem kiiresti.
Kui meil on vaja kontrollida päringute tõhusust ja me peame kordama mitu korda, siis on olemas selline asi nagu kaasrobot. Ta on juba valmis. Seda kasutavad kümned arendajad iga päev. Ja ta teab, kuidas anda nõudmisel 30 sekundiga tohutu terabaidine andmebaas, teie enda koopia. Ja saate seal midagi kustutada ja öelda RESET ja uuesti kustutada. Saate sellega katsetada sel viisil. Ma näen sellel asjal tulevikku. Ja me juba teeme seda.
Mis on jaotusstrateegiad? Näen kolme erinevat partitsioonistrateegiat, mida paketi arendajad kasutavad.
Esimene on väga lihtne. Meil on numbriline ID. Ja jagame selle erinevateks intervallideks ja töötame sellega. Miinus on selge. Esimeses segmendis võib meil olla 100 rida päris prügi, teises 5 rida või üldse mitte, või kõik 1 rida osutuvad prügiks. Väga ebaühtlane töö, kuid see on kergesti purunev. Nad võtsid maksimaalse ID ja purustasid selle. See on naiivne lähenemine.
Teine strateegia on tasakaalustatud lähenemisviis. Seda kasutatakse Gitlabis. Nad võtsid ja skannisid laua. Leidsime ID-pakkide piirid nii, et igas pakis oli täpselt 10 000 kirjet. Ja pange nad järjekorda. Ja siis töötleme. Seda saate teha mitmes lõimes.
Muide, ka esimeses strateegias saate seda teha mitmes lõimes. See ei ole raske.
Kuid on lahedam ja parem lähenemine. See on kolmas strateegia. Ja kui võimalik, on parem see valida. Teeme seda spetsiaalse indeksi alusel. Sel juhul on see suure tõenäosusega meie prügiseisundile ja ID-le vastav indeks. Lisame ID, et see oleks ainult indeksiga skannimine, et me ei läheks hunnikusse.
Üldiselt on ainult indeksi skannimine kiirem kui indeksiga skannimine.
Ja leiame kiiresti oma ID-d, mille tahame eemaldada. BATCH_SIZE valime eelnevalt. Ja me mitte ainult ei saa neid, vaid saame need erilisel viisil ja häkkime kohe sisse. Meie aga paneme lukku, et kui need juba lukus on, siis me ei pane neid lukku, vaid liigume edasi ja võtame järgmised. See on uuenduste vahelejätmise jaoks lukustatud. See Postgresi superfunktsioon võimaldab meil soovi korral töötada mitmes lõimes. See on võimalik ühes voolus. Ja siin on CTE - see on üks taotlus. Ja selle CTE teisel korrusel toimub tõeline kustutamine - returning *. Saate ID tagastada, kuid see on parem *kui teil pole iga rea kohta palju andmeid.
Miks me seda vajame? See on see, mida me peame tagasi andma. Oleme nüüd tegelikult nii palju ridu kustutanud. Ja meil on piirid ID või loodud_at järgi. Saate teha min, max. Midagi muud saab teha. Siin saab palju asju kraamida. Ja see on jälgimiseks väga mugav.
Indeksi kohta on veel üks märkus. Kui otsustame, et vajame selle ülesande jaoks spetsiaalset indeksit, siis peame veenduma, et see ei rikuks ainult korteeži värskendusi. See tähendab, et Postgresil on selline statistika. Seda saab näha teie tabeli jaotises pg_stat_user_tables. Saate vaadata, kas kuumi värskendusi kasutatakse või mitte.
On olukordi, kus teie uus register võib need lihtsalt ära lõigata. Ja teil on kõik muud värskendused, mis juba töötavad, aeglustage. Mitte ainult sellepärast, et indeks ilmus (iga indeks aeglustab värskendusi veidi, aga veidi), kuid siin see ikkagi rikub. Ja selle tabeli jaoks on võimatu spetsiaalset optimeerimist teha. Seda juhtub mõnikord. See on nii peen, mida vähesed mäletavad. Ja sellele rehale on lihtne astuda. Vahel juhtub nii, et tuleb leida lähenemine teiselt poolt ja ikkagi ilma selle uue indeksita hakkama saada või teha mõni muu indeks või mõnel muul moel näiteks kasutada teist meetodit.
Aga see on kõige optimaalsem strateegia, kuidas partiideks jagada ja ühe palvega partiidesse tulistada, natukene kustutada jne.
Pikad tehingud
Blokeeritud autovaakum -
blokeerimise probleem -
Viga nr 5 on suur. Nikolai Okmeterist rääkis Postgresi monitooringust. Ideaalset Postgresi jälgimist kahjuks ei eksisteeri. Mõni on lähemal, mõni kaugemal. Okmeter on piisavalt lähedal täiuslikkusele, kuid palju on puudu ja vajab lisamist. Peate selleks valmis olema.
Näiteks on kõige parem jälgida surnud kortereid. Kui teil on tabelis palju surnud asju, siis on midagi valesti. Parem on kohe reageerida, muidu võib tekkida degradatsioon ja me võime pikali heita. Juhtub.
Kui on suur IO, siis on selge, et see pole hea.
Pikad tehingud ka. Pikad tehingud ei tohiks OLTP-s olla lubatud. Ja siin on link katkendile, mis võimaldab teil seda juppi võtta ja juba pikkade tehingute jälgimist teha.
Miks on pikad tehingud halvad? Sest kõik lukud vabastatakse alles lõpus. Ja me segame kõik. Lisaks blokeerime autovaakumi kõigi laudade jaoks. See pole üldse hea. Isegi kui teil on koopial kuum ooterežiim lubatud, on see endiselt halb. Üldiselt pole kusagil parem pikki tehinguid vältida.
Kui meil on palju laudu, mida ei puhastata tolmuimejaga, siis peab meil olema hoiatus. Siin on selline olukord võimalik. Kaudselt saame mõjutada autovaakumi tööd. See on väljavõte Avitost, mida ma veidi parandasin. Ja see osutus huvitavaks tööriistaks, et näha, mis meil autovaakumiga on. Näiteks mõned lauad ootavad seal ega oota oma korda. Samuti peate selle jälgima ja hoiatama.
Ja väljastab plokke. Plokkpuude mets. Mulle meeldib kelleltki midagi võtta ja seda parandada. Siin võtsin Data Egreti laheda rekursiivse CTE, mis näitab lukupuude metsa. See on hea diagnostikavahend. Ja selle põhjal saate ka seiret ehitada. Kuid seda tuleb teha hoolikalt. Peate enda jaoks tegema väikese avalduse_aeg. Ja lock_timeout on soovitav.
Mõnikord esinevad kõik need vead kokkuvõttes.
Minu arvates on siin peamine viga korralduslik. See on korralduslik, sest tehnika ei tõmba. See on number 2 – nad kontrollisid vales kohas.
Kontrollisime vales kohas, kuna meil polnud tootmisklooni, mida on lihtne kontrollida. Arendajal ei pruugi olla üldse juurdepääsu tootmisele.
Ja me ei kontrollinud seal. Kui oleksime seal kontrollinud, oleksime seda ise näinud. Arendaja nägi seda kõike ka ilma DBA-ta, kui ta kontrollis seda heas keskkonnas, kus on sama hulk andmeid ja identne asukoht. Ta oleks näinud kogu seda allakäiku ja tal oleks häbi.
Veel autovaakumi kohta. Pärast seda, kui oleme teinud tohutu mitme miljoni rea pühkimise, peame siiski tegema Ümberpakkimise. See on eriti oluline indeksite puhul. Nad tunnevad end halvasti pärast seda, kui oleme seal kõik ära puhastanud.
Ja kui soovite igapäevast koristustööd tagasi tuua, siis soovitan seda teha sagedamini, kuid väiksemana. See võib olla kord minutis või isegi sagedamini natuke. Ja peate jälgima kahte asja: et sellel asjal poleks vigu ja et see ei jääks maha. Trikk, mida näitasin, lahendab selle lihtsalt.
See, mida me teeme, on avatud lähtekoodiga. See on postitatud GitLabisse. Ja me teeme selle nii, et inimesed saaksid kontrollida isegi ilma DBAta. Teeme andmebaasilaborit, st kutsume baaskomponendi, mille kallal Joe praegu töötab. Ja võite haarata toodangu koopia. Nüüd on olemas Joe for slack rakendus, seal saate öelda: "selgitage sellist ja sellist taotlust" ja saate kohe oma andmebaasi koopia tulemuse. Seal saate isegi KUSTUTADA ja keegi ei märka seda.
Oletame, et teil on 10 terabaiti, teeme andmebaasilabori ka 10 terabaiti. Ja samaaegsete 10 terabaidiste andmebaasidega saavad samaaegselt töötada 10 arendajat. Igaüks võib teha, mida tahab. Saab kustutada, maha visata jne. See on selline fantaasia. Sellest räägime homme.
Seda nimetatakse õhukeseks varundamiseks. See on peen varustamine. See on omamoodi fantaasia, mis eemaldab oluliselt viivitusi arenduses ja testimises ning muudab maailma selles osas paremaks. See tähendab, et see võimaldab teil lihtsalt hulgitoimingutega probleeme vältida.
Näide: 5 terabaidine andmebaas, koopia hankimine vähem kui 30 sekundiga. Ja see ei sõltu isegi suurusest, see tähendab, pole vahet, mitu terabaiti.
Täna võite minna ja süvenege meie tööriistadesse. Saate registreeruda, et näha, mis seal on. Saate selle roboti installida. See on tasuta. Kirjutage.
küsimused
Väga sageli selgub reaalsetes olukordades, et andmeid, mis peaksid tabelisse jääma, on palju vähem kui neid, mida tuleb kustutada. See tähendab, et sellises olukorras on sageli lihtsam sellist lähenemist rakendada, kui on lihtsam luua uus objekt, kopeerida sinna ainult vajalikud andmed ja tühjendada vana tabel. Selge on see, et sel hetkel, kui te vahetate, on vaja programmilist lähenemist. Kuidas see lähenemine on?
See on väga hea lähenemine ja väga hea ülesanne. See on väga sarnane sellega, mida pg_repack teeb, see on väga sarnane sellega, mida peate tegema, kui teete ID-d 4 baidiseks. Paljud raamistikud tegid seda paar aastat tagasi ja lihtsalt plaadid on suureks kasvanud ning need tuleb teisendada 8-baidiseks.
See ülesanne on üsna raske. Me tegime seda. Ja sa pead olema väga ettevaatlik. Seal on lukud jne Aga seda tehakse. See tähendab, et tavaline lähenemisviis on pg_repack. Te deklareerite sellise sildi. Ja enne kui hakkate sinna hetktõmmise andmeid üles laadima, deklareerite ka ühe plaadi, mis jälgib kõiki muudatusi. On nipp, et te ei pruugi isegi jälgida mõnda muudatust. Seal on peensusi. Ja siis vahetate muudatusi veeretades. Kui kõik kinni paneme, tuleb väike paus, kuid üldiselt seda tehakse.
Kui vaadata GitHubis pg_repacki, siis seal, kui oli ülesanne konverteerida ID int 4-st int 8-ks, siis tekkis mõte pg_repack ise kasutada. See on ka võimalik, kuid see on natuke häkkimine, kuid see töötab ka selle jaoks. Saate sekkuda päästikusse, mida pg_repack kasutab, ja öelda seal: "Me ei vaja neid andmeid", st me edastame ainult seda, mida vajame. Ja siis ta lihtsalt lülitub ümber ja kõik.
Sellise lähenemisega saame ikkagi tabeli teise eksemplari, milles andmed on juba indekseeritud ja laotud väga ühtlaselt ilusate indeksitega.
Punetust ei esine, see on hea lähenemine. Aga tean, et selleks üritatakse välja töötada automatiseerimist ehk teha universaalset lahendust. Võin teid selle automaatikaga ühendust võtta. See on kirjutatud Pythonis, mis on hea asi.
Ma olen lihtsalt natuke MySQL-i maailmast, nii et tulin kuulama. Ja me kasutame seda lähenemisviisi.
Kuid see on ainult siis, kui meil on 90%. Kui meil on 5%, siis pole seda eriti hea kasutada.
Täname raporti eest! Kui toote täieliku koopia tegemiseks pole ressursse, kas on koormuse või suuruse arvutamiseks mingi algoritm või valem?
Hea küsimus. Siiani on meil võimalik leida mitme terabaidiseid andmebaase. Isegi kui sealne riistvara ei ole sama, näiteks vähem mälu, vähem protsessorit ja kettad pole täpselt samad, aga ikkagi teeme seda. Kui absoluutselt kuskil pole, siis tuleb mõelda. Las ma mõtlen homseni, sa tulid, me räägime, see on hea küsimus.
Täname raporti eest! Alustasite kõigepealt sellest, et on lahe Postgres, millel on sellised ja sellised piirangud, aga see areneb. Ja see kõik on üldiselt kark. Kas see kõik pole mitte vastuolus Postgresi enda arenguga, millesse ilmub mõni DELETE deferent või midagi muud, mis peaks hoidma madalal tasemel seda, mida me siin mingite oma kummaliste vahenditega üritame määrida?
Kui SQL-is ütlesime, et kustutage või värskendage ühe tehinguga palju kirjeid, siis kuidas saab Postgres seda seal levitada? Oleme tegevuses füüsiliselt piiratud. Teeme seda ikka kaua. Ja paneme sel ajal lukku jne.
Indeksidega tehtud.
Võin eeldada, et sama kontrollpunkti häälestamist võiks automatiseerida. Ühel päeval võib see olla. Aga siis ma ei saa tegelikult küsimusest aru.
Küsimus on selles, kas on olemas selline arenguvektor, mis läheb siia-sinna ja siin läheb sinu oma paralleelselt? Need. Kas nad pole sellele veel mõelnud?
Rääkisin põhimõtetest, mida nüüd kasutada saab. On veel üks bot , selle abil saate teha automaatset kontrollpunkti häälestamist. Kas see on kunagi Postgresis? Ma ei tea, seda pole isegi veel arutatud. Oleme sellest veel kaugel. Kuid on teadlasi, kes loovad uusi süsteeme. Ja nad suruvad meid automaatsetesse indeksitesse. On arenguid. Näiteks võite vaadata automaathäälestust. See valib parameetrid automaatselt. Kuid ta ei tee veel teie eest kontrollpunkti häälestamist. See tähendab, et see elavneb jõudluse, kestapuhvri jne jaoks.
Ja kontrollpunktide häälestamiseks saate seda teha: kui teil on pilves tuhat klastrit ja erinev riistvara, erinevad virtuaalsed masinad, saate kasutada meie robotit teha automatiseerimist. Ja max_wal_size valitakse automaatselt vastavalt teie sihtseadetele. Kuid siiani pole see kahjuks isegi lähedal.
Tere päevast Rääkisite pikkade tehingute ohtudest. Ütlesite, et autovaakum blokeeritakse kustutamiste korral. Kuidas see meid muidu kahjustab? Sest me räägime rohkem ruumi vabastamisest ja selle kasutamise võimalusest. Millest meil veel puudu on?
Autovaakum pole siin võib-olla suurim probleem. Ja asjaolu, et pikaajaline tehing võib lukustada ka teisi tehinguid, on see võimalus ohtlikum. Ta võib kohtuda või mitte. Kui ta kohtub, võib see olla väga halb. Ja autovaakumiga - see on ka probleem. Pikkade tehingutega OLTP-s on kaks probleemi: lukud ja autovaakum. Ja kui teil on replical lubatud kuuma ooterežiimi tagasiside, siis saate ikkagi kaptenil autovaakumluku, see saabub koopiast. Aga vähemalt lukke ei tule. Ja loks tuleb. Me räägime andmete muutumisest, nii et lukud on siin oluline punkt. Ja kui see kõik kestab kaua-kaua, siis läheb järjest rohkem tehinguid lukku. Nad võivad teisi varastada. Ja lok puud ilmuvad. Andsin väljavõttele lingi. Ja see probleem muutub märgatavamaks kiiremini kui probleem autovaakumiga, mis võib ainult koguneda.
Täname raporti eest! Alustasite aruannet sellega, et ütlesite, et testisite valesti. Jätkasime mõtet, et tuleb võtta sama varustus, alusega samamoodi. Oletame, et andsime arendajale baasi. Ja ta täitis palve. Ja tundub, et tal on kõik korras. Aga ta ei kontrolli live'i, vaid live'i jaoks on meil näiteks koormus 60-70%. Ja isegi kui me seda häälestust kasutame, siis see väga hästi ei tööta.
Oluline on omada meeskonnas asjatundjat ja kasutada DBA eksperte, kes suudavad ennustada, mis tegeliku taustakoormusega juhtub. Kui me just oma puhtaid muudatusi tegime, näeme pilti. Kuid arenenum lähenemine, kui tegime sama asja uuesti, kuid tootmisega simuleeritud koormusega. See on päris lahe. Kuni selle ajani tuleb suureks saada. See on nagu täiskasvanu. Vaatasime lihtsalt, mis meil on, ja ka seda, kas meil on piisavalt ressursse. See on hea küsimus.
Kui teeme juba prügivalikut ja meil on näiteks lipp kustutatud
Seda teeb autovaakum Postgresis automaatselt.
Oh, kas ta teeb seda?
Autovaakum on prügikoguja.
Tänan!
Täname raporti eest! Kas on võimalus kohe kujundada andmebaas koos partitsiooniga nii, et kogu prügi määrdub põhitabelist kuhugi kõrvale?
Muidugi on.
Kas siis on võimalik end kaitsta, kui oleme lukustanud laua, mida ei tohiks kasutada?
Muidugi on. Aga see on nagu kana ja muna küsimus. Kui me kõik teame, mis tulevikus juhtuma hakkab, siis loomulikult teeme kõik lahedalt. Kuid äri muutub, on uued veerud, uued taotlused. Ja siis – oi, me tahame selle eemaldada. Kuid see ideaalne olukord elus tuleb ette, kuid mitte alati. Aga üldiselt on see hea mõte. Lihtsalt kärbi ja ongi kõik.
Allikas: www.habr.com