Kallis DELETE. Nikolai Samohvalov (Postgres.ai)

Kaugemas tulevikus muutub automaatne hävitamine ebaolulistest andmetest üheks oluliseks andmebaasi ülesandeks [1]. Praegu peame ise hoolitsema ebaoluliste andmete kustutamise või vähem kulukatele salvestuslahendustele liikumise eest. Oletame, et soovite kustutada mitu miljonit rida. Suhteliselt lihtne ülesanne, eriti kui tingimus on teada ja õige indeks olemas. "DELETE FROM table1 WHERE col1 = :value" — mis võiks olla lihtsam, eks?

Video:

• Olen olnud Highloadi programmikomitees alates esimesest aastast, st 2007. aastast.

• Ja Postgresiga olen ma alates 2005. aastast. Olen kasutanud seda paljudes projektides.

• Rühm RuPostgresest on samuti alates 2007. aastast.

• Meie Meetupil on osalejate arv tõusnud 2100+ni. See on maailmas teine koht pärast New Yorki, oleme San Franciscost ammu ette jõudnud.

• Mõned aastad olen elanud Californias. Tegelen enamasti Ameerika ettevõtetega, sealhulgas suurtega. Need on aktiivsed Postgresi kasutajad. Seal tekivad igasugused huvitavad olukorrad.

https://postgres.ai/ – see on minu ettevõte. Tegeleme ülesannete automatiseerimisega, mis eemaldavad arenduse aeglustumist.

Kui teete midagi, siis Postgres'i ümber tekivad vahel ummikud. Oletame, et peate ootama, kuni administraator käivitab teile testkeskkonna, või peate ootama, kuni DBA teie peale reageerib. Leiame selliseid kitsaskohti arenduse, testimise ja haldamise protsessis ja püüame neid kõrvaldada automatiseerimise ja uute lähenemisviiside abil.

https://www.seagate.com/files/www-content/our-story/trends/files/idc-seagate-dataage-whitepaper.pdf

Hiljuti olin Los Angeleses VLDB konverentsil. See on suurim andmebaaside konverents. Seal oli ettekande teema see, et tulevikus ei säilita andmebaasid mitte ainult andmeid, vaid ka automaatselt kustutavad neid. See on uus teemaarendus.

Andmete hulk maailmas suureneb – zettabait on 1 000 000 petabaiti. Ja praegu hinnatakse, et maailmas on salvestatud üle 100 zettabaiti andmeid. Ja neid on järjest rohkem.

https://vldb2019.github.io/files/VLDB19-keynote-2-slides.pdf

Ja mis sellega teha? Selge on, et need tuleb kustutada. Siin on link sellele huvitavale ettekandele. Kuid praegu ei ole seda andmebaasides realiseeritud.

Need, kes oskavad raha lugeda, soovivad kahte asja. Nad soovivad, et me kustutaksime, seetõttu peaksime tehniliselt suutma seda teha.

Edasi rääkides käsitlen teatud abstraktset olukorda, mis hõlmab hulga reaalseid olukordi, st mingit kompileerimist sellest, mis on minuga ja ümbritsevate andmebaasidega tõeliselt juhtunud korduvalt ja mitme aasta jooksul. Komplikatsioonid on igal pool ning nendesse astuvad pidevalt kõik.

Oletame, et meil on andmebaas või mitu andmebaasi, mis kasvavad. Ja mõned kirjed on selgelt prügi. Näiteks, kasutaja alustas midagi, kuid ei lõpetanud. Ja mingi aja pärast teame, et seda lõpetamata sisu saab juba kustutada. St, et teatud prügi soovime koristada, et säästa ruumi, parandada jõudlust jne.

Üldiselt on eesmärgiks automatiseerida konkreetselt teatud asjade, teatud ridade eemaldamine mingist tabelist.

Ja meil on selline päring, millest me täna räägime, st prahi eemaldamisest.

Palusime kogenud arendajal see teostada. Ta võttis selle päringu, kontrollis enda juures – kõik töötab. Testis stagingus – kõik on hästi. Läbi viidud – kõik töötab. Kord päevas käivitame seda – kõik on hästi.

Andmed kasvavad pidevalt. Iga päev DELETE hakkab natuke aeglasemalt töötama.

Siis mõistame, et meil on nüüd turunduskampaania ja liiklus suureneb mitu korda, mistõttu otsustame ajutiselt mõningad tarbetud asjad pausile panna. Ja unustame need tagasi tuua.

Mõne kuu pärast meenutame. Ja see arendaja on lahkunud või on millegi muuga hõivatud, usaldame selle teise inimese kätte.

Ta kontrollis dev-is, staging-is – kõik on korras. Loomulikult, tuleb veel puhastada see, mis on kogunenud. Ta kontrollis, kõik töötab.

Mis edasi juhtub? Edasi läheb kõik katki. Juhtuma hakkab nii, et mingil hetkel kukub kõik kokku. Kõik on šokis, keegi ei saa aru, mis toimub. Ja siis selgub, et asi oli selle DELETE'is.

Mis läks valesti? Siin on nimekiri sellest, mis võis valesti minna. Mis on neist kõige tähtsam?

• Näiteks, ei olnud review'd, see tähendab, et DBA-spetsialist ei vaadanud. Tema oleks oma kogemusega kohe probleemi leidnud, tal on ju juurdepääs prod'ile, kus on kogunenud mitmeid miljoneid ridasid.

• Võib-olla ei kontrollitud kuidagi õigesti.

• Võib-olla on riistvara aegunud ja selle andmebaasi jaoks on vajalik uuendus.

• Või on probleem koos andmebaasiga ning peame Postgreselt MySQL-ile üle minema.

• Või on operatsiooniga midagi valesti.

• Võib-olla on töökorralduses vigu ning peaks kedagi vallandama ja palkama paremaid inimesi?

DBA kontrolli ei olnud. Kui DBA oleks olemas, oleks ta näinud neid paar miljonit rida ja isegi ilma katseteta öelnud: 'Nii ei tehta.' Oletame, et kui see kood oleks GitLabis, GitHubis ja oleks koodie ülevaatamise protsess, siis oleks selgelt DBA öelnud: 'Nii ei saa teha.'

Ja ta oleks öelnud, et teil tekivad disk IO probleemid ning kõik protsessid hakkavad ärrituma, võivad tekkida lukud ning samuti blokeerite automaatse vakueerimise mitmeks minutiks, mis pole hea.

http://bit.ly/nancy-hl2018-2

Teine viga on see, et kontrolliti vale kohta. Järgnevalt nägime, et tootmisjärgsetes andmetes on palju prügi ning arendajal ei olnud selles andmebaasis akumuleeritud andmeid, samuti ei loonud keegi stagingus seda prügi. Seetõttu oli seal 1 000 rida, mis töötasid kiiresti läbi.

Me mõistame, et meie testid on nõrgad, st. protsess, mis on üles ehitatud, ei tuvastanud probleeme. Adekvaatset andmebaasi eksperimenti ei viidud läbi.

Ideaalne eksperiment tuleks teha sarnasel seadmel. Sarnasel seadmel ei pruugi see alati õnnestuda, kuid väga oluline on, et see oleks täismahus andmebaasi koopia. Seda olen ma predikaanud juba mitu aastat. Aasta tagasi rääkisin sellest, võite YouTube'ist kõik vaadata.

Võib-olla on meie seadmed halvad? Kui vaadata, siis latentsus on tõusnud. Oleme näinud, et koormus on 100%. Loomulikult, kui need oleksid kaasaegsed NVMe kettad, siis oleks meil tõenäoliselt palju kergem. Ja võib-olla ei oleks me selle tõttu kokku kukkunud.

Kui teil on pilved, siis seal on uuendamine lihtne. Tõstame uusi replikaid uuel raudvaral. Üleminek. Ja kõik on hästi. Suhteliselt lihtne.

Kas oleks võimalik ketastega mitte nii palju tegeleda? Ja siin saamegi DBA abil sukelduda teemasse, mida tuntakse kui checkpointi häälestamine. Selgub, et meil ei olnud checkpointi häälestamist tehtud.

Mis on checkpoint? See on olemas igas andmebaasisüsteemis. Kui teie andmed mälus muutuvad, ei salvestata neid kohe kettale. Teave selle kohta, et andmed on muutunud, salvestatakse esmalt ettekujutuslogisse, write-ahead log'i. Ja mingil hetkel otsustab andmebaasisüsteem, et on aeg juba reaalsed lehed kettale kirjutada, et juhul, kui meil tekib tõrge, oleks vähem REDO't. See on nagu mängus. Kui meid tapetakse, hakkame mängu mängima viimase checkpoint'ist. Ja kõik andmebaasisüsteemid rakendavad seda.

Postgresi seaded on vananenud. Need on olnud arvutatud 10–15 aasta taguste andmemahu ja toimingute pealt. Ja checkpoint ei ole erand.

See teave on meie Postgresi kontrollimise aruandest, st automaatne tervisekontroll. Ja siin on mõni tera bite suurune andmebaas. On hästi näha, et sunnitud checkpoint'id toimuvad peaaegu 90% juhtudest.

Mida see tähendab? Seal on kaks seadet. Checkpoint võib tekkida näiteks timeout'i järgi, näiteks 10 minuti pärast. Või ta võib tekkida siis, kui on kogunenud piisavalt palju andmeid.

Ja vaikimisi on max_wal_size seadistatud 1 gigabaiti. Tegelikult juhtub see Postgresis tõeliselt umbes 300–400 megabaidi järel. Te olete muutnud nii palju andmeid ja teil toimub checkpoint.

Ja kui see pole keegi tuuninud, kuid teenus on kasvanud ja ettevõte teenib suurt raha, on tal palju tehinguid, siis toimub kontroll iga minuti tagant, mõnikord isegi iga 30 sekundi järel, ja mõnikord kattuvad need üksteisega. See on juba väga halb.

Peame tegema nii, et see juhtuks harvem. Ehk saame suurendada max_wal_size'i. Siis toimub see harvem.

Kuid oleme välja töötanud terve metoodika, kuidas seda õigesti teha, ehk kuidas teha otsuseid seadistuste valikute osas, tuginedes selgelt konkreetsetele andmetele.

Seetõttu viime läbi kaks katseringi andmebaasidega.

Esimene seeria — muudame max_wal_size'i. Ja teeme massilise operatsiooni. Esiteks teeme selle vaikeseadega 1 gigabait. Ja teeme massilise DELETE paljude miljonite ridade kaupa.

Näeme, kui raske on. Jälgime, et disk IO on väga halb. Kontrollime, kui palju WAL'i oleme genereerinud, kuna see on väga oluline. Jälgime, kui mitu korda kontroll toimus. Ja näeme, et see ei ole hea.

Jätkame max_wal_size suurendamisega. Kordame. Suurendame, kordame. Ja nii palju kordi. Üldiselt on 10 punkti hea, kus 1, 2, 4, 8 gigabaiti. Ja vaatame konkreetse süsteemi käitumist. Loomulikult peab siinne varustus olema nagu prod. Teil peaksid olema samad ketad, sama palju mälu ja samad Postgresi seadistused.

Nii me vahetame meie süsteemi ja teame, kuidas käitub andmebaas kehva massilise DELETE'i korral ning kuidas see checkpoint'ib.

Checkpoint eesti keeles – see on kontrollpunkt.

Näide: DELETE mitu miljonit rida indeksi kaudu, read on jaotatud lehtedele.

Siin on näide. See on mingi andmebaas. Ja vaikeseadistuses 1 gigabaiti max_wal_size korral on väga hästi näha, et meie kirjutamised lähevad riiulisse. Selline pilt – see on tüüpiline sümptom väga haigest patsiendist, st tal oli tõeliselt halvasti. Ja siin oli ainult üks operatsioon, just DELETE mitu miljonit rida.

Kui sellist operatsiooni prod'isse saata, siis me kindlasti kukume, sest on näha, et üks DELETE tapab meid riiulisse.

Edasi, kus 16 gigabaiti, näeme, et hammastega lähemale. Hambad - see on juba parem, st me koputame lakke, aga see pole enam nii halb. Seal on natuke vabadust. Paremal - see on kirje. Ja operatsioonide arv - teine graafik. Näeme, et meil on nüüd kergem hingata, kui 16 gigabaiti.

Kus 64 gigabaiti, on näha, et asjad on märgatavalt paremaks läinud. Hambad on selgelt väljendunud, tekib rohkem võimalusi, et teistele operatsioonidele ellu jääda ja midagi kettaga teha.

Miks nii?

Ma sukeldun veidi üksikasjadesse, kuid see teema, kuidas läbi viia checkpointi häälestust, võib muutuda tervikuks ettekandeks, seega ma ei koorma end liiga palju, aga mainin mõningaid seal olevaid keerukusi.

Kui checkpoint toimub liiga sageli ja me uuendame oma ridu mitte järjekorras, vaid leiame indeksi järgi, siis see on hea, kuna me ei kustuta kogu tabelit; võib juhtuda, et esmalt puutume kokku esimese lehega, seejärel tuhande lehega ja seejärel naaseme esimesse. Ja kui nende visiitide vahel esimest lehte checkpoint juba kettale salvestas, siis salvestab ta selle veel kord, kuna me mässime seda teist korda.

Ja me sundime checkpoint'i seda palju kordi salvestama. Tekkivad üleliigsed toimingud selle jaoks.

Kuid see pole veel kõik. Postgresis on lehe suurus 8 kilobaiti, Linuxis 4 kilobaiti. On olemas seade full_page_writes. Selle vaikeväärtus on sisse lülitatud. Ja see on õige, sest kui me selle välja lülitame, on oht, et vale äparduse korral salvestub vaid pool lehe sisu.

WAL-i ajakirja kirjutamise käitumine on selline, et kui meil on checkpoint ja me muudame lehte esmakordselt, siis satub kogu leht ajakirja, st kõik 8 kilobaiti, kuigi me muutsime vaid 100 baitist koosneva rea. Oleme sunnitud kogu lehe salvestama.

Järgmistes muudatustes sisaldub ainult konkreetne tupel, kuid esmakordselt salvestame kogu lehe.

Seega, kui checkpoint toimub veel kord, peame jälle nullist alustama ja kogu leht taas salvestama. Tihedate checkpointide korral, kui liigume ühtede ja samade lehtede vahel, on full_page_writes = on genereeritud rohkem, kui see võiks olla, st genereerime rohkem WAL-i. Rohkem saadetakse replikatele, arhiivi, kettale.

Seega tekib meil kaks üleliigsust.

Kui me suurendame max_wal_size'i, kergendame nii checkpointi kui wal writeri tööd. Ja see on suurepärane.

Pange paika terabaidid ja elame sellega. Mis selles halba on? See on halb, sest kui juhtub viga, võib meil tõusmine võtta tunde, sest checkpoint oli kaua tagasi ja palju on juba muutunud. Me peame kõik REDO'i tegema. Seetõttu teeme teise katsetuste seeria.

Me teeme operatsiooni ja vaatame, kui checkpoint on lõpetamisele lähedal, siis teeme kill -9 Postgres'ile spetsiaalselt.

Ja seejärel käivitame selle uuesti ja vaatame, kui kaua tal läheb sellel seadmel üles tõusmiseks, st kui palju ta REDO't selle halva olukorra korral teeb.

Kordan kahekordselt, et olukord on halb. Esiteks, me kukkusime otse enne checkpointi lõpetamist, seega peame palju kaotama. Teiseks, meil oli massiivne operatsioon. Ja kui checkpoints oleks olnud ajautumise järgi, oleks tõenäoliselt vähem WAL'i genereeritud viimase checkpointi hetkest. See tähendab, et see on kahekordne ebaõnnestumine.

Me mõõdame sellist olukorda erineva max_wal_size suurusega ja mõistame, et kui max_wal_size on 64 gigabaiti, siis kahekordse halvemates situatsioonides tõuseme 10 minuti jooksul. Ja mõtleme – kas see on meist rahuldav või mitte. See on äri küsimus. Me peame selle olukorra näitama neile, kes vastutavad äriliste otsuste eest, ja küsima: „Kui kaua me saame maksimaalselt probleemi korral ootama jääda? Kas saame halvemates tingimustes olla 3–5 minutit?“. Ja teete otsuse.

Ja siin on huvitav moment. Meil on konverentsil paar ettekannet Patroni kohta. Ja juhtub, et kasutate seda. See on Postgresi jaoks autofailover. GitLab ja Data Egret rääkisid sellest.

Ja kui teil on autofailover, mis aktiveerub 30 sekundi jooksul, siis võib-olla saame me oodata ka 10 minutit? Sest selle ajaks lülitame üle replikale ja kõik läheb hästi. See on vaieldav küsimus. Ma ei tea kindlat vastust. Ma lihtsalt tunnen, et see teema ei puuduta ainult tegevusi pärast tõrke taastamist.

Kui meil on pikk tõrke taastamine, siis on meil paljudes teistes olukordades ebamugav. Näiteks katsetes, kui teeme midagi ja oleme sunnitud mõnikord ootama kuni 10 minutit.

Ma siiski ei soovitaks liiga kaugele minna, isegi kui meil on autofailover. Üldiselt on sellised väärtused nagu 64, 100 gigabaiti head. Mõnikord tasub valida isegi vähem. See on üldiselt õrn teadus.

Te peate iteratsioone tegemiseks, näiteks max_wal_size = 1, 8, kordama suurt operatsiooni mitu korda. Te olete selle teinud. Ja samas andmebaasis soovite seda veel kord teha, kuid olete ju kõik juba kustutanud. Mis nüüd teha?

Räägin hiljem meie lahendusest, mida me teeme, et sellistes olukordades iteratsioonide tegemine oleks võimalik. See on kõige õigem lähenemine.

Kuid antud juhul meil vedas. Kui nagu siin on kirjutatud 'BEGIN, DELETE, ROLLBACK', siis saame DELETE'i korrata. See tähendab, et kui me selle ise tühistasime, saame seda korrata. Ja füüsiliselt on teie andmed seal endiselt olemas. Te ei saa isegi mingit bloat’i. Saate selliste DELETE'ide peal iteratsiooni teha.

Selline DELETE koos ROLLBACK'iga on ideaalne checkpointi häälestamiseks, isegi kui teil pole korralikult üles seatud andmebaasist laboratooriume.

Me tegime tabeli, millel on üks veerg 'i'. Postgresel on teenindusveergud. Need on nähtamatud, kui neid spetsiaalselt ei paluta. Need on: ctid, xmid, xmax.

Ctid on füüsiline aadress. Nullleht, esimene korthus lehe sees.

On näha, et pärast ROOLBACKi jääb rida samasse kohta. See tähendab, et võime proovida uuesti ja see käitub samamoodi. See on oluline.

Xmax on rida eluiga. See on määratud, kuid Postgres teab, et see tehing on tagasi võetud, seega on nii 0 kui ka tagasi võetud tehing — see ei ole oluline. See tähendab, et DELETE’i osas saab iterida ja kontrollida süsteemi massiivsete operatsioonide käitumist. Saame teha madala eelarvega andmebaasi laboratooriume.

See räägib juba programmeerijatest. Räägib ka DBA-dest, kes on alati programmeerijate kallal: 'Miks teete selliseid pikalt kestvaid ja keerulisi operatsioone?'. See on täiesti teine, risti vastupidine teema. Varem oli haldamine, nüüd tuleb arendamine.

On ilmne, et me ei jaganud osi. See on arusaadav. Sellist DELETE-d ei saa miljonite ridade korral osadeks jagamata teha. See võtab aega 20 minutit ja kõik seisab. Kuid kahjuks teevad isegi kogenud arendajad vigu, isegi väga suurtes ettevõtetes.

Miks on oluline jagada?

• Kui näeme, et kettale on raske, siis aeglustame. Ja kui meil on see jagatud, saame lisada pause, saame aeglustada throttling'ut.

• Ja me ei blokeeri teisi pikaks ajaks. Mõnel juhul pole oluline, kui kustutate tõelist prügi, millega keegi ei tööta; tõenäoliselt ei blokeeri te kedagi peale autovacuum'i töö, kuna see ootab, kuni tehing on lõpule viidud. Kuid kui kustutate midagi, mida keegi veel küsida võib, siis nad jäävad blokeerituks, tekib mingisugune ahelreaktsioon. Veebisaitidel ja mobiilirakendustes tuleb vältida pikki tehinguid.

https://postgres.ai/products/joe/

See on huvitav. Ma kohtan sageli, et arendajad küsivad: „Milline on sobiv partii suurus?”.

Selge, et mida suurem on partii suurus, seda väiksem on tehingu ülejääk, st täiendavad tehingu kulud. Kuid samas suureneb selle tehingu kestus.

Mul on väga lihtne reegel: võtke nii palju kui võimalik, kuid ärge ületage tehingute täitmist sekundis.

Miks sekundi? Selgitus on väga lihtne ja arusaadav kõigile, isegi mitte-tehnilistele inimestele. Me näeme reaktsiooni. Võtame 50 millisekundit. Kui midagi on muutunud, reageerib meie silm. Kui vähem, siis on keerulisem. Kui midagi vastab 100 millisekundi pärast, näiteks kui te klõpsasite hiirega ja see vastas teile 100 millisekundi pärast, tunnete juba seda väikest viivitust. Sekundit tajutakse juba kui pidurdust.

Seega, kui me jagame meie massilised operatsioonid 10-sekundiliste partii peale, on meil risk, et blokeerime kellegi. Ja ta töötab paar sekundit, ja seda inimesed juba märkavad. Seetõttu eelistan ma rohkem sekundeid mitte teha. Kuid samas ei taha ma ka liiga väikesteks partii kaupa jagada, sest transaction overhead on märgatav. Andmebaasil on raskem, võivad esineda ka teised erinevad probleemid.

Me valime partii suuruse. Igas juhtumis võime seda erinevalt teha. Seda saab automatiseerida. Ja veendume, et ühe partii töötlemine on tõhus. St teeme DELETE ühe partiiga või UPDATE.

Üksikasjalikult, mida ma räägin, kehtib mitte ainult DELETE'i jaoks. Nagu te juba arvasite, on see igasugused massilised operatsioonid andmetega.

Ja me oleme näinud, et plaan on suurepärane. On näha indeksi skaneerimisi, veel paremad on indeksi skaneerimised ainult. Ja meil on väike andmete hulk kaasatud. Ja kõik toimib vähem kui sekundiga. Super.

Ja me peame veenduma, et degradaatsiooni ei esine. Juhtub, et esimesed partiid töötavad kiiresti, kuid seejärel läheb kõik järjest halvemaks. Protsess on selline, et katsetada tuleb palju. Selleks ongi vajalik database labs.

Ja me peame veel valmistama midagi, mis võimaldaks meil produziert õigesti jälgida. Näiteks saame logi kirjutada aega, võime kirja panna, kus me praegu oleme ja keda me praegu kustutasime. See võimaldab meil hiljem mõista, mis toimub. Ja juhul, kui midagi läheb valesti, leida probleem kiiresti.

Kui me peame kontrollima päringute efektiivsust ja peame mitu korda iteratsiooni tegema, siis on olemas selline asi nagu kolleeg bot. Ta on juba valmis. Seda kasutavad kümned arendajad iga päev. Ta suudab anda tohutu terabaiti andmebaasi teie päringu alusel 30 sekundi jooksul, teie enda koopia. Ja te saate midagi seal eemaldada ja öelda RESET ning veel kord eemaldada. Te saate temaga sel viisil eksperimenteerida. Ma näen selle asja taga tulevikku. Ja me teeme seda juba.

https://docs.gitlab.com/ee/development/background_migrations.html

Milliseid jagamise strateegiaid on olemas? Ma näen 3 erinevat jagamise strateegiat, mida arendajad pakis kasutavad.

Esimene on väga lihtne. Meil on numbriline ID. Ja laseme selle erinevatesse vahemikesse jagada ja töötame selle peal. Miinus on arusaadav. Esimeses segmentis võib meile sattuda 100 rida reaalset rämpsu, teises 5 rida või ei satu üldse, või kõik 1 000 rida osutuvad rämpsuks. Töö on väga ebaühtlane, aga jagamine on lihtne. Võtsime maksimaalse ID ja jagasime. See on naiivne lähenemine.

Teine strateegia on tasakaalustatud lähenemine. Seda kasutatakse GitLabis. Tabel uuriti ja leiti ID-de partii piire nii, et igas partis oleks täpselt 10 000 kirjet. Need pandi mingisse järjekorda ja töödeldakse edasi. Seda saab teha mitmes voos.

Esmases strateegias saab samuti teha mitmes voos. See pole keeruline.

https://medium.com/@samokhvalov/how-partial-indexes-affect-update-performance-in-postgres-d05e0052abc

Aga on veel klassikaline ja optimaalsem lähenemine. See on kolmas strateegia. Ja kui see on võimalik, tasub see üle valida. Me kasutame selleks spetsiaalset indeksi. Antud juhul on see tõenäoliselt meie räsi ja ID indeksi alusel. Me lisame ID, et see oleks ainult indeksi skaneerimine, et me ei puutuks heap'iga.

Üldiselt on ainult indeksi skaneerimine kiirem kui indeksi skaneerimine.

Ja me kiiresti leidime need ID-d, mida soovime eemaldada. BATCH_SIZE määrame ette. Ja me neid mitte ainult ei saa, vaid saame need ka spetsiifiliselt ja lukustame kohe. Kuid lukustame nii, et kui need on juba lukustatud, siis ei lukusta me neid uuesti, vaid liigume edasi ja võtame järgmised. See on 'for update skip locked'. See superfunktsioon Postgres võimaldab meil, kui soovime, töötada mitmes voos. Saame kasutada ka ühte voogu. Siin on CTE – see on üks päring. Ja meie CTE teisel tasandil toimub tõeline eemaldamine – returning *. Saame kasutada returning id, kuid parem on *, kui teil on iga rida jaoks vähe andmeid.

Miks me seda vajame? Me vajame seda, et aru anda. Oleme praegu eemaldanud nii palju ridu tegelikult. Ja meie ID- või created_at piirid on sellised. Saame teha min ja max. Võime teha veel midagi. Siin saab palju asju teha. Ja see on monitoorimiseks väga mugav.

Indeksi kohta on veel üks tähelepanek. Kui me oleme otsustanud, et selle ülesande jaoks on vajalik eriline indeks, siis peame veenduma, et see ei rikuks heap only tuples uuendusi. Postgreses on selline statistika olemas. Seda saab vaadata pg_stat_user_tables tabelis. Saate kontrollida, kas kasutatakse hot updates või mitte.

On olukordi, kus teie uus indeks võib neid lihtsalt katkestada. Ja kõik teised uuendused, mis juba töötavad, hakkavad aeglustuma. Mitte ainult seetõttu, et indeks on lisatud (iga indeks aeglustab veidi uuendusi, aga mitte palju), vaid see rikub ka neid. Ja selle tabeli jaoks ei ole võimalik teha erilist optimeerimist. Selliseid asju juhtub aeg-ajalt. See on detail, millest vähesed mäletavad. Ja nendel kividel on lihtne komistada. Mõnikord tuleb leida teine lähenemine ja ikkagi hakkama saada ilma selle uue indeksita, kas teha teine indeks või leida mingi muu lahendus, näiteks saab kasutada teist meetodit.

Kuid see on kõige optimaalsem strateegia, kuidas jagada partiiidesse ja ühte päringusse rünnata, eemaldada veidi korraga jt.

Pikad tehingud — https://gitlab.com/snippets/1890447

Blokeeritud autovacuum — https://gitlab.com/snippets/1889668

Blokeeriv probleem — https://gitlab.com/snippets/1890428

Viga nr 5 on suur. Nikolai Okmeterist rääkis Postgres'i jälgimisest. Kahjuks ei eksisteeri ideaalseid Postgres'i jälgimise lahendusi. Mõned on lähemal, mõned kaugemal. Okmeter on piisavalt lähedal, et olla ideaalne, kuid palju on puudu ja lisada tuleb. Sellega tuleb arvestada.

Näiteks on dead tuples parem jälgida. Kui teie tabelis on palju surnud ridasid, siis on midagi valesti. Paremini reageerida nüüd, muidu võib tekkida degradatsioon ja meid võib ootamatult välja lülitada. Sedasi juhtub.

Kui I/O on suur, siis on selge, et see ei ole hea.

Pikad tehingud ka. OLTP-s ei tohiks lubada pikki tehinguid. Siin on link klipi juurde, mis võimaldab selle klipi võtta ja juba teha mingit jälgimist pikkade tehingute üle.

Miks on pikad tehingud halvad? Sest kõik lukud vabanevad alles lõpus. Ja me lukustame kõiki. Lisaks blokeerime autovacuum'i töö kõikides tabelites. See ei ole üldse hea. isegi kui teil on replika hot standby sisse lülitatud, on see ikkagi halb. Üldiselt ei tohiks kuskil lubada pikki tehinguid.

Kui meil on palju tabeleid, mis ei vakumeeru, siis peab olema häire. Siin võib selline olukord tekkida. Me saame kaudselt mõjutada autovacuum'i tööd. See on snippet Avitolt, mida ma natuke täiendasin. Tulemuseks on huvitav tööriist, et näha, kuidas autovacuum meil toimib. Näiteks ootavad seal teatud tabelid ja ei saa oma järjekorda. See tuleb ka monitooringusse panna ja häire peab olema.

Ja issue blokkide osas. Lukustuste puu mets. Mulle meeldib kelleltki midagi võtta ja seda täiustada. Siin võtsin Data Egret'ilt toreda rekursiivse CTE, mis näitab lukustuste puu metsa. See on hea tööriist diagnoosimiseks. Ja selle alusel saab ka monitooringu kokku seadma. Kuid seda tuleb teha ettevaatlikult. Tuleb endale seada väikene statement_timeout ja soovitavalt ka lock_timeout.

Mõnikord esinevad kõik need vead kokku.

Minu arvates on siin kõige olulisem viga – see on organisatsiooniline. See on organisatsiooniline, kuna tehnika ei pea vastu. Nummer 2 – me kontrollisime valesti.

Me kontrollisime valesti, kuna meil polnud production'i klooni, millel oleks lihtne testida. Arendajal ei pruugi üldse olla ligipääsu production'ile.

Ja me ei kontrollinud seal. Kui oleksime seal kontrollinud, siis oleksime seda ise näinud. Arendaja märkaks seda kõik ilma DBA-ta, kui ta kontrollib seda heades tingimustes, kus andmeid on sama palju ja sama paigutusega. Ta näeks kogu seda deklareeritud halvenemist ja tal oleks piinlik.

Veel autovakuumist. Pärast seda, kui me tegime massiivse koristamise mitme miljoni rea pealt, tuleb teha veel REPACK. See on eriti oluline indeksite jaoks. Neil läheb kehvasti pärast seda, kui me seal kõik puhtaks tegime.

Ja kui soovite tagasi tuua igapäevase koristamise, siis soovitaksin seda teha sagedamini, aga väiksemate kogustega. Saate seda teha iga minuti või isegi sagedamini pisut. Peate korraldama jälgimise kahe asja üle: et selle asja puhul ei oleks vigu ja et see ei jääks maha. See trikk, mida ma näitasin, aitab selle probleemi lahendada.

Meie tegevus põhineb avatud lähtekoodil. See on saadaval GitLabis. Loome võimalusi, et inimesed saaksid isegi ilma DBA-ta kontrolle teha. Loome andmebaasi labori, st meie nn baaskomponendi, millel praegu töötab Joe. Saate võtta koopia tootmisest. Nüüd on olemas Joe rakendus Slackis, kus saate öelda: „selgita seda päringut” ja saada koheselt vastuse oma andmebaasi koopia kohta. Seal saate isegi DELETE-käsu esitada ja keegi ei märka seda.

Oletame, et teil on 10 terabaiti, meie loome andmebaasi labori ka 10 terabaiti. Ja samas võivad töötada 10 arendajat, kes kasutavad samaaegselt 10 terabaiti andmebaasi. Igaühel on võimalus teha seda, mida soovib. Võib eemaldada, kustutada jne. Just selline fantastika. Sellest me räägime homme.

See on tuntud kui õhuke provisionimine. Õhuke provisionimine on teatud fantastika, mis vähendab arenduse ja testimise viivitusi ning muudab maailma selles osas paremaks. See võimaldab teil vältida probleeme massiliste toimingutega.

Näide: 5 terabaiti andmebaasi koopia saamine alla 30 sekundi. Ja see ei sõltu suurusest, st ei ole tähtis, kui palju terabaites.

Juba täna saate sisse logida Postgres.ai ja uurida meie tööriistu. Saate registreeruda ja vaadata, mis seal on. Saate endale selle boti paigaldada. See on tasuta. Kirjutage.

Küsimused

Tegelikes olukordades juhtub sageli, et andmed, mis peaksid tabelis jääma, on neid oluliselt vähem kui Need, mida tuleb kustutada. Sellises olukorras on sageli lihtsam lähenemine, et luua uus objekt, kopeerida sinna ainult vajalikud andmed ja vanad tabelid tühjendada. Selge, et selleks on vaja programmilist lähenemist, kuni vahetate. Milline on see lähenemine?

See on väga hea lähenemine ja väga hea ülesanne. See on väga sarnane sellele, mida teeb pg_repack, see on väga sarnane sellele, mida peate tegema, kui olete ID-d teinud 4-baidisteks. Paljud raamistikud tegid seda mõned aastat tagasi ja tabelid on tõusnud ning neid tuleb konverteerida 8 baidiks.

See ülesanne on üsna keeruline. Me oleme seda teinud. Ja te peate olema väga ettevaatlikud. Seal on lukud jne. Kuid see on teostatav. Ehk siis standardne lähenemine on pg_repack. Te kuulutate sellise tabeli. Ja enne kui hakkate andmeid snapshot'ina sinna laadima, kuulutate veel ühe tabeli, mis kõik muudatused jälgib. Seal on nipp, et teatud muudatusi ei pea isegi jälgima. Seal on nüansse. Ja siis lülitate üle, rakendades muudatused. Seal on lühike paus, mil me kõiki lukustame, kuid üldiselt on see teostatav.

Kui vaatate pg_repack'i GitHubis, siis seal, kui oli ülesanne konverteerida ID int 4-st int 8-ks, siis oli mõte kasutada ise pg_repack'i. See on samuti võimalik, kuid see on natuke häkkimisviis, aga sobib ka selleks. Te saate sekkuda triggereisse, mida pg_repack kasutab ja öelda: «Need andmed ei ole meile vajalikud», ehk siis me laadime ainult seda, mis meile vajalik. Ja siis see lihtsalt lülitub ja kõik.

Selle lähenemisega saame veel ühe tabeli koopia, kus andmed on juba indekseeritud ja korralikult paigutatud ilusate indeksitega.

Bloat ei ole, see on hea lähenemine. Kuid ma tean, et on tehtud katseid selle automatiseerimiseks, st luua universaalne lahendus. Ma saan teid selle automatiseerimisega ühendusse viia. See on kirjutatud Pythonis, väga hea asi.

Ma olen lihtsalt veidi MySQL maailmast, seetõttu tulin kuulama. Ja me kasutame sellist lähenemist.

Aga see on ainult juhul, kui meil on 90%. Kui meil on 5%, siis ei ole selle rakendamine kuigi hea.

Aitäh ettekande eest! Kui pole ressursse, et teha täis koopiat prod'ist, kas on olemas mingi algoritm või valem, et arvutada koormust või suurust?

Hea küsimus. Praegu suudame leida mitme terabaidi suuruseid andmebaase. Isegi kui seal on teine riistvara, näiteks vähem mälu, vähem protsessorit ja kettad ei ole täpselt samad, saame seda teha. Kui pole üldse kohta, siis tuleb mõelda. Las ma mõtlen homme, kui te tagasi tulete, saame suhelda, see on hea küsimus.

Aitäh ettekande eest! Alguses rääkisite, et on olemas suurepärane Postgres, millel on sellised piirangud, kuid see areneb. Kuid see kõik on tegelikult hüpe. Kas see ei lähe vastuollu Postgres'i enda arenguga, kus võib-olla ilmub mingi DELETE deferent või midagi sarnast, mis peaks madalamal tasemel toetama seda, mida me siin püüame mõne oma kummalise vahendiga katta?

Kui me SQL-is ütleme, et likvideerime või uuendame palju salvestusi ühes tehingus, siis kuidas saab Postgres seda jaotada? Me oleme füüsiliselt piiratud toimingutes. Me peame seda ikkagi tegema aeglaselt. Ja me lukustame selle ajal jne.

Indeksitega on ju nii tehtud.

Ma võin eeldada, et ka checkpoint'i seadistust oleks võinud automatiseerida. Ehk kunagi see juhtumisi toimub. Aga ma ei saa väga hästi küsimusest aru.

Küsimus on, kas seal ei ole mingit arengusuunda, mis liigub sealpool ja teie omad siinpool paralleelselt? See tähendab, et seal ei mõelda veel sellele?

Ma rääkisin põhimõtetest, mida saab praegu kasutada. On olemas teine bot. Nancy, selle abil on võimalik automatiseerida checkpoint'i häälestust. Kas see kunagi PostgreSQL'is olemas on? Ei tea, praegu ei arutata seda. Me oleme sellest veel kaugel. Kuid on teadlasi, kes loovad uusi süsteeme. Ja nad suunavad meid automaatsetesse indeksitesse. On arenguid. Näiteks võite vaadata auto häälestust. See valib parameetreid automaatselt. Kuid see ei tee teile checkpoint'i häälestust. See tähendab, et see valib teie jaoks performance, shell buffer jne.

Ja checkpoint'i häälestamiseks saab teha järgmist: kui teil on tuhat klastrit ja erinevad riistvarad, erinevad virtuaalmasinad pilves, saate kasutada meie boti Nancy automatiseerimise tegemiseks. Ja max_wal_size valitakse automaatselt vastavalt teie sihtseadetele. Kuid kahjuks pole seda tuumas isegi ligidalt.

Tere päevast! Te rääkisite pikaajaliste tehingute kahjulikkusest. Te mainisite, et autovacuum'id blokeeritakse kustutamisel. Mida veel me sellest kaotame? Sest me räägime rohkem ruumi vabastamisest ja selle kasutamise võimalustest. Mida me veel kaotame?

Autovacuum ei pruugi olla siin kõige suurem probleem. Küll aga, pikas tehingus lukustatavus võib teisi tehinguid rohkem ohustada. See olukord võib esineda, aga ei pruugi. Kui see juhtub, on see väga halb. Ja autovacuumiga on samuti probleem. OLTP-s on pikas tehingus kaks peamist probleemi: lukud ja autovacuum. Kui teil on kuum varukoopia tagasiside replikal lubatud, siis te peate veel taluma autovacuum'i lukustamise peamises andmebaasis, mis tuleb replikalt. Kuid seal ei ole lukke. Siin võivad aga lukud tekkida. Me räägime andmete muutmisest, mistõttu lukud on siin oluline aspekt. Ja kui see kõik venib, siis lukustub üha rohkem tehinguid. Nad võivad lukustada teisi tehinguid. Ja lukustuste puude tekkimine on võimalik. Toetasin eelnevalt lingiga snippet’i. See probleem muutub tõenäolisemaks ja silmatorkavamaks kui autovacuum'i probleem, mis võib ainult kuhjuda.

Aitäh ettekande eest! Alustasite oma ettekannet väitega, et testisite valesti. Edasi arendasite ideed, et tuleb kasutada ühte ja sama varustust, samuti sama andmebaasi. Oletame, et andsime arendajale andmebaasi. Ja ta täitis päringu. Ja tal tundub, et kõik on korras. Kuid ta ei kontrolli seda live keskkonnas, näiteks on meil seal koormus 60-70%. Ja isegi kui me kasutame seda häälestust, ei tuli üldiselt välja eriti hästi.

Meeskonnas eksperdi olemasolu ja eksperdi DBA kasutamine, kes võib prognoosi teha, mis juhtub reaalses taustakoormuses, on oluline. Kui me lihtsalt jooksutame meie puhtaid muudatusi, näeme pilti. Kuid edasijõudnud lähenemine on see, et me teeme sama uuesti, kuid simuleeritud tootmiskoormusega. See on tõeliselt äge. Selleks peame veel arenema. See on täiskasvanute tasemel. Vaatasime lihtsalt, mis meil on, ja kontrollisime, kas meil on piisavalt ressursse. See on hea küsimus.

Kui me teeme juba prügi valiku ja meil on näiteks kustutuslipp.

See on see, mida autovacuum Postgres'is automaatselt teeb.

Ah, ta teeb seda?

Autovacuum ongi see prügikoguja.

Aitäh!

Aitäh ettekande eest! Kas on võimalus kohe kujundada andmebaas partitsioneerimisega nii, et kogu prügi eemaldatakse peamisest tabelist kuskile kõrvale?

Muidugi, on.

Kas saame end siis kaitsta, kui lukustame tabeli, mida ei tohiks kasutada?

Muidugi, on. Aga see on küsimus nagu kana ja muna. Kui me kõik teaksime, mis tulevikus juhtuma hakkab, siis muidugi, teeksime kõik suurepäraselt. Aga äri muutub, tekivad uued veerud, uued päringud. Ja siis - oop, me tahame selle eemaldada. Kuid see on ideaalne olukord, elus juhtub seda, aga mitte alati. Kuid üldiselt on see hea idee. Lihtsalt truncate ja kõik.

Allikas: habr.com