Kažkada tolimoje ateityje automatinis nereikalingų duomenų pašalinimas bus viena iš svarbių DBVS užduočių [1]. Tuo tarpu mes patys turime pasirūpinti nereikalingų duomenų ištrynimu ar perkėlimu į pigesnes saugojimo sistemas. Tarkime, kad nusprendėte ištrinti kelis milijonus eilučių. Gana paprasta užduotis, ypač jei būklė žinoma ir yra tinkamas indeksas. „DELETE FROM FROM1 table WHERE col1 = :value“ – kas gali būti paprasčiau, tiesa?
Vaizdo įrašas:
-
„Highload“ programos komitete dirbu nuo pirmųjų metų, t.y. nuo 2007 m.
-
„Postgres“ dirbu nuo 2005 m. Naudojo daugelyje projektų.
-
Grupė su RuPostges taip pat nuo 2007 m.
-
„Meetup“ išaugo iki 2100+ dalyvių. Jis yra antras pasaulyje po Niujorko, kurį ilgą laiką lenkė San Franciskas.
-
Kelerius metus gyvenu Kalifornijoje. Daugiau bendrauju su Amerikos įmonėmis, taip pat ir didelėmis. Jie yra aktyvūs „Postgres“ vartotojai. Ir yra visokių įdomių dalykų.
yra mano įmonė. Mes užsiimame užduočių, kurios pašalina plėtros sulėtėjimus, automatizavimo verslu.
Jei ką nors darote, kartais aplink Postgres yra tam tikrų kamščių. Tarkime, kad turite palaukti, kol administratorius sukurs jums bandymų stendą, arba turite palaukti, kol DBA jums atsakys. O tokių kliūčių randame kūrimo, testavimo ir administravimo procese ir stengiamės jas pašalinti automatizavimo ir naujų metodų pagalba.
Neseniai buvau VLDB Los Andžele. Tai didžiausia duomenų bazių konferencija. Ir buvo pranešimas, kad ateityje DBVS ne tik saugos, bet ir automatiškai ištrins duomenis. Tai nauja tema.
Duomenų zetabaitų pasaulyje atsiranda vis daugiau – tai yra 1 000 000 petabaitų. O dabar jau skaičiuojama, kad pasaulyje turime daugiau nei 100 zettabaitų duomenų. Ir jų daugėja.
Ir ką su juo daryti? Akivaizdu, kad jį reikia pašalinti. Čia yra nuoroda į šį įdomų pranešimą. Tačiau iki šiol tai nebuvo įdiegta DBVS.
Tie, kurie moka skaičiuoti pinigus, nori dviejų dalykų. Jie nori, kad ištrintume, todėl techniškai turime sugebėti tai padaryti.
Toliau papasakosiu abstrakčią situaciją, apimančią daugybę realių situacijų, t. y. savotiškas rinkinys to, kas iš tikrųjų nutiko man ir aplinkinėms duomenų bazėms daug kartų, daug metų. Grėbliai yra visur ir visi ant jų nuolat lipa.
Tarkime, kad turime bazę ar kelias bazes, kurios auga. O kai kurie įrašai akivaizdžiai yra šiukšlės. Pavyzdžiui, vartotojas pradėjo kažką ten daryti, bet to nebaigė. Ir po kurio laiko žinome, kad šito nebaigto saugoti nebegalima. Tai yra, norėtume išvalyti kai kurias šiukšles, kad sutaupytume vietos, pagerintume našumą ir pan.
Apskritai užduotis yra automatizuoti konkrečių dalykų, konkrečių eilučių ištrynimą kokioje nors lentelėje.
Ir mes turime tokį prašymą, apie kurį šiandien ir kalbėsime, tai yra dėl šiukšlių išvežimo.
Tai padaryti paprašėme patyrusio kūrėjo. Jis paėmė šį prašymą, pats patikrino – viskas veikia. Išbandyta scenoje – viskas gerai. Išvyniota - viskas veikia. Kartą per dieną paleidžiame – viskas gerai.
Duomenų bazė auga ir auga. Kasdienis DELETE pradeda veikti šiek tiek lėčiau.
Tada suprantame, kad dabar turime rinkodaros įmonę ir srautas bus kelis kartus didesnis, todėl nusprendžiame laikinai pristabdyti nereikalingus dalykus. Ir pamiršk grįžti.
Po kelių mėnesių jie prisiminė. Ir tas kūrėjas pasitraukė arba yra užsiėmęs kažkuo kitu, nurodė kitam grąžinti.
Jis patikrino kūrėją, pastatymą – viskas gerai. Natūralu, kad dar reikia išvalyti tai, kas susikaupė. Jis patikrino, kad viskas veikia.
Kas bus toliau? Tada mums viskas griūna. Nukrenta taip, kad kažkuriuo momentu viskas nukrenta. Visi yra šoke, niekas nesupranta, kas vyksta. Ir tada paaiškėja, kad reikalas buvo šiame DELETE.
Kažkas nutiko? Štai sąrašas, kas galėjo suklysti. Kuris iš jų yra svarbiausias?
-
Pavyzdžiui, nebuvo peržiūros, t.y. DBA ekspertas jos nežiūrėjo. Patyręs akis iš karto rastų problemą, be to, turi prieigą prie prod, kuriame susikaupė keli milijonai eilučių.
-
Galbūt jie kažką ne taip patikrino.
-
Galbūt aparatinė įranga pasenusi ir jums reikia atnaujinti šią bazę.
-
Arba kažkas negerai su pačia duomenų baze, todėl turime pereiti nuo Postgres prie MySQL.
-
O gal su operacija kažkas negerai.
-
Galbūt darbo organizavime yra klaidų ir reikia ką nors atleisti ir pasamdyti geriausius žmones?
DBA patikrinimo nebuvo. Jei būtų DBA, jis pamatytų šiuos kelis milijonus eilučių ir net be jokių eksperimentų pasakytų: „Jie to nedaro“. Tarkime, jei šis kodas būtų „GitLab“, „GitHub“ ir būtų vykdomas kodo peržiūros procesas ir nebūtų tokio dalyko, kad be DBA patvirtinimo ši operacija vyktų prod, tada akivaizdu, kad DBA pasakytų: „To negalima padaryti. .
Ir jis sakytų, kad turėsite problemų su disko IO ir visi procesai išprotės, gali būti užraktų, taip pat užblokuosite autovakuumą krūvai minučių, todėl tai nėra gerai.
Antra klaida – patikrino ne toje vietoje. Po to pamatėme, kad prod susikaupė daug šlamšto duomenų, tačiau kūrėjas neturėjo sukauptų duomenų šioje duomenų bazėje ir niekas šio šlamšto nesukūrė inscenizacijos metu. Atitinkamai, buvo 1 eilučių, kurios greitai susitvarkė.
Suprantame, kad mūsų testai yra silpni, t. y. kuriamas procesas nepagauna problemų. Tinkamas DB eksperimentas nebuvo atliktas.
Idealų eksperimentą pageidautina atlikti ta pačia įranga. Ne visada tai įmanoma padaryti ta pačia įranga, tačiau labai svarbu, kad tai būtų viso dydžio duomenų bazės kopija. Tai aš skelbiu jau keletą metų. Ir prieš metus apie tai kalbėjau, visa tai galite žiūrėti „YouTube“.
Gal mūsų įranga bloga? Jei pažiūrėsite, vėlavimas šoktelėjo. Matėme, kad panaudojimas yra 100%. Žinoma, jei tai būtų modernūs NVMe diskai, mums tikriausiai būtų daug lengviau. Ir gal nuo to neatsigultume.
Jei turite debesų, atnaujinimą ten lengva atlikti. Sukurtos naujos kopijos naujoje aparatinėje įrangoje. Perjungti. Ir viskas gerai. Gana lengva.
Ar galima kažkaip paliesti mažesnius diskus? Ir čia, tiesiog su DBA pagalba, pasineriame į tam tikrą temą, vadinamą checkpoint tuning. Pasirodo, mes neturėjome patikros punktų derinimo.
Kas yra patikros taškas? Jis yra bet kurioje DBVS. Kai atmintyje yra duomenų, kurie keičiasi, jie nėra iškart įrašomi į diską. Informacija, kad duomenys pasikeitė, pirmiausia įrašoma į išankstinio įrašymo žurnalą. Ir tam tikru momentu DBVS nusprendžia, kad laikas išmesti tikrus puslapius į diską, kad gedimo atveju galėtume atlikti mažiau REDO. Tai kaip žaislas. Jei mus užmuš, pradėsime žaidimą nuo paskutinio kontrolinio punkto. Ir visos DBVS tai įgyvendina.
„Postgres“ nustatymai atsilieka. Jie skirti 10-15 metų duomenų ir operacijų apimtims. Ir patikros punktas nėra išimtis.
Ši informacija yra iš mūsų ataskaitos su Postgres patikrinimu, t. y. automatiniu sveikatos patikrinimu. O štai keletas terabaitų duomenų bazė. Ir aišku, kad patikros punktai yra priverstiniai beveik 90% atvejų.
Ką tai reiškia? Ten yra du nustatymai. Patikrinimo taškas gali būti pasibaigęs, pavyzdžiui, 10 minučių. Arba tai gali ateiti tada, kai buvo užpildyta gana daug duomenų.
Ir pagal numatytuosius nustatymus max_wal_saze nustatytas 1 gigabaitas. Tiesą sakant, tai tikrai atsitinka „Postgres“ po 300–400 megabaitų. Jūs pakeitėte tiek daug duomenų ir jūsų patikros taškas įvyksta.
Ir jei niekas jo netiuningo, o paslauga išaugo, o įmonė uždirba daug pinigų, turi daug operacijų, tai patikros punktas ateina kartą per minutę, kartais kas 30 sekundžių, o kartais net persidengia. Tai gana blogai.
Ir turime pasirūpinti, kad tai būtų rečiau. Tai yra, galime padidinti max_wal_size. Ir ateis rečiau.
Bet mes sukūrėme visą metodiką, kaip tai padaryti teisingiau, tai yra, kaip priimti sprendimą dėl nustatymų pasirinkimo, aiškiai remiantis konkrečiais duomenimis.
Atitinkamai, mes atliekame dvi duomenų bazių eksperimentų serijas.
Pirmoji serija – keičiame max_wal_size. Ir mes atliekame didžiulę operaciją. Pirmiausia tai darome pagal numatytąjį 1 gigabaito nustatymą. Ir mes atliekame didžiulį daugelio milijonų eilučių trynimą.
Matote, kaip mums sunku. Matome, kad disko IO yra labai blogas. Žiūrime, kiek WAL sugeneravome, nes tai labai svarbu. Pažiūrėkime, kiek kartų patikros punktas įvyko. Ir matome, kad tai nėra gerai.
Toliau padidiname max_wal_size. Mes kartojame. Didiname, kartojame. Ir tiek daug kartų. Iš principo 10 taškų yra gerai, kur 1, 2, 4, 8 gigabaitai. Ir mes žiūrime į konkrečios sistemos elgesį. Aišku, kad čia įranga turėtų būti kaip ant prod. Turite turėti tuos pačius diskus, tiek pat atminties ir tuos pačius Postgres nustatymus.
Ir tokiu būdu mes apsikeisime savo sistema, ir žinome, kaip DBVS elgsis blogos masės DELETE atveju, kaip patikrins.
Patikrinimo punktas rusų kalba yra kontroliniai punktai.
Pavyzdys: IŠTRINKITE kelis milijonus eilučių pagal indeksą, eilutės yra „išsklaidytos“ puslapiuose.
Štai pavyzdys. Tai tam tikra bazė. O nustačius 1 gigabaito max_wal_size nustatymą, labai aišku, kad mūsų diskai patenka į lentyną įrašymui. Ši nuotrauka yra tipiškas labai sergančio paciento simptomas, tai yra, jis tikrai blogai jautėsi. Ir buvo viena operacija, buvo tik kelių milijonų eilučių DELETE.
Jei tokia operacija bus leidžiama prod, tai mes tiesiog gulėsime, nes aišku, kad vienas DELETE užmuša mus pulke.
Toliau, kur 16 gigabaitų, aišku, kad dantys jau išėjo. Dantys jau geriau, tai yra beldžiamės į lubas, bet ne taip jau blogai. Ten buvo šiek tiek laisvės. Dešinėje yra įrašas. O operacijų skaičius – antras grafikas. Ir aišku, kad jau šiek tiek lengviau kvėpuojame, kai 16 gigabaitų.
O kur 64 gigabaitai matosi, kad tapo visiškai geresnis. Jau dantys išryškėję, daugiau galimybių išgyventi kitas operacijas ir ką nors nuveikti su disku.
Kodėl taip yra?
Šiek tiek pasinersiu į smulkmenas, tačiau ši tema, kaip atlikti kontrolinių punktų derinimą, gali baigtis visa ataskaita, todėl daug neįkelsiu, bet šiek tiek apibūdinsiu, kokie sunkumai yra.
Jei patikros taškas vyksta per dažnai, o eilutes atnaujiname ne nuosekliai, o randame pagal indeksą, o tai yra gerai, nes neištriname visos lentelės, tada gali atsitikti taip, kad iš pradžių palietėme pirmą puslapį, paskui tūkstantį, o paskui grįžo į pirmąjį . Ir jei tarp šių apsilankymų pirmame puslapyje patikros punktas jį jau išsaugojo diske, tai išsaugos dar kartą, nes susitepėme antrą kartą.
Ir mes daug kartų priversime patikros tašką jį išsaugoti. Kaip jam būtų perteklinės operacijos.
Bet tai dar ne viskas. Puslapiai yra 8 kilobaitai „Postgres“ ir 4 kilobaitai „Linux“. Ir yra full_page_writes nustatymas. Jis įjungtas pagal numatytuosius nustatymus. Ir tai yra teisinga, nes jei jį išjungsime, kyla pavojus, kad jam sugedus bus išsaugota tik pusė puslapio.
Rašymas į persiuntimo žurnalą WAL yra toks, kad kai turime kontrolinį tašką ir pirmą kartą pakeičiame puslapį, visas puslapis, t.y. visi 8 kilobaitai, patenka į persiuntimo žurnalą, nors mes pakeitėme tik eilutė, kuri sveria 100 baitų . Ir mes turime užsirašyti visą puslapį.
Vėlesniuose pakeitimuose bus tik konkreti eilutė, bet pirmą kartą viską užrašome.
Ir atitinkamai, jei patikros taškas pasikartojo, turime vėl pradėti viską nuo nulio ir stumti visą puslapį. Kai tikriname dažnai, kai einame per tuos pačius puslapius, full_page_writes = on bus daugiau nei galėtų būti, t. y. generuojame daugiau WAL. Daugiau siunčiama į kopijas, į archyvą, į diską.
Ir atitinkamai turime du atleidimus.
Jei padidinsime max_wal_size, paaiškės, kad tai palengvinsime ir patikros taškui, ir wal rašytojui. Ir tai puiku.
Įdėkime terabaitą ir gyvenkime su juo. kas cia blogo? Tai blogai, nes gedimo atveju lipsime valandų valandas, nes patikros punktas buvo seniai ir jau daug kas pasikeitė. Ir mes turime padaryti visa tai REDO. Taigi mes atliekame antrąją eksperimentų seriją.
Atliekame operaciją ir matome, kada baigsis patikros punktas, tyčia nužudome -9 Postgres.
Ir po to vėl paleidžiame ir žiūrime, kiek laiko jis kils ant šios įrangos, t.y. kiek perdarys šioje blogoje situacijoje.
Du kartus pažymėsiu, kad padėtis bloga. Pirma, susidūrėme prieš pat kontrolinį tašką, todėl turime daug ką prarasti. Antra, mums buvo atlikta didžiulė operacija. Ir jei kontroliniai punktai būtų pasibaigę, greičiausiai nuo paskutinio patikros taško būtų sukurta mažiau WAL. Tai yra, tai yra dvigubas pralaimėtojas.
Matuojame tokią situaciją skirtingiems max_wal_size dydžiams ir suprantame, kad jei max_wal_size yra 64 gigabaitai, tai dvigubu blogiausiu atveju lipsime 10 minučių. Ir mes galvojame, ar tai mums tinka, ar ne. Tai verslo klausimas. Turime parodyti šį paveikslą tiems, kurie atsakingi už verslo sprendimus, ir paklausti: „Kiek daugiausiai galime gulėti iškilus problemai? Ar galime pagulėti blogiausioje situacijoje 3-5 minutes? Ir tu priimi sprendimą.
Ir čia yra įdomus momentas. Konferencijoje turime keletą pranešimų apie Patronį. Ir galbūt jūs juo naudojatės. Tai yra „Postgres“ automatinis failų perkėlimas. GitLab ir Data Egret kalbėjo apie tai.
O jei turite automatinį failoverį, kuris ateina per 30 sekundžių, tai gal galime pagulėti 10 minučių? Nes iki šio momento pereisime prie replikos ir viskas bus gerai. Tai ginčytinas klausimas. Nežinau aiškaus atsakymo. Tiesiog jaučiu, kad ši tema yra ne tik apie atkūrimą po avarijos.
Jei po nesėkmės atsigauname ilgai, tada ir daugelyje kitų situacijų jausimės nepatogiai. Pavyzdžiui, tuose pačiuose eksperimentuose, kai kažką darome ir kartais tenka laukti 10 minučių.
Vis tiek nenueičiau per toli, net jei turime automatinį failų perjungimą. Paprastai tokios vertės kaip 64, 100 gigabaitų yra geros vertės. Kartais net verta rinktis mažiau. Apskritai tai yra subtilus mokslas.
Norėdami atlikti iteracijas, pavyzdžiui, max_wal_size =1, 8, masės operaciją turite pakartoti daug kartų. Tau pavyko. Ir toje pačioje bazėje norite tai padaryti dar kartą, bet jau viską ištrynėte. Ką daryti?
Vėliau pakalbėsiu apie mūsų sprendimą, ką darome, kad kartotume tokias situacijas. Ir tai yra teisingiausias požiūris.
Tačiau šiuo atveju mums pasisekė. Jei, kaip čia sakoma, "PRADEDA, IŠTRINTI, ATGALIME", galime pakartoti IŠTRINTI. Tai yra, jei mes patys tai atšaukėme, galime tai pakartoti. Ir fiziškai pas jus duomenys gulės toje pačioje vietoje. Jūs net nesipučiate. Galite kartoti tokius DELETE.
Šis DELETE su ROLLBACK yra idealus patikros taško derinimui, net jei neturite tinkamai įdiegtos duomenų bazės laboratorijos.
Padarėme lėkštę su vienu stulpeliu „i“. Postgres turi naudingumo stulpelius. Jie yra nematomi, nebent būtų specialiai prašoma. Tai yra: ctid, xmid, xmax.
Ctid yra fizinis adresas. Nulis puslapio, pirmoji eilutė puslapyje.
Matyti, kad po ROOLBACK kortelės liko toje pačioje vietoje. Tai yra, galime bandyti dar kartą, elgsis taip pat. Tai yra pagrindinis dalykas.
Xmax yra kortelės mirties laikas. Jis buvo pažymėtas, bet „Postgres“ žino, kad sandoris buvo atšauktas, todėl nesvarbu, ar tai 0, ar atšaukta operacija. Tai rodo, kad galima kartoti per DELETE ir patikrinti masines sistemos elgsenos operacijas. Galite sukurti duomenų bazių laboratorijas vargšams.
Čia kalbama apie programuotojus. Apie DBA taip pat visada priekaištauja programuotojams: „Kodėl jūs darote tokias ilgas ir sudėtingas operacijas? Tai visiškai kita statmena tema. Anksčiau buvo administracija, o dabar bus plėtra.
Akivaizdu, kad mes nesame suskaidyti į gabalus. Tai aišku. Neįmanoma nesuskaidyti tokio DELETE milijonų eilučių į dalis. Tai bus daroma 20 minučių, ir viskas atsiguls. Bet, deja, net patyrę kūrėjai daro klaidų, net ir labai didelėse įmonėse.
Kodėl svarbu sulaužyti?
-
Jei matome, kad diskas kietas, tai sulėtinkime. O jei esame sugedę, galime pridėti pauzes, galime sulėtinti droselį.
-
Ir kitų ilgai neužblokuosime. Kai kuriais atvejais nesvarbu, jei ištrinate tikras šiukšles, prie kurių niekas nedirba, greičiausiai niekam neužblokuosite, išskyrus automatinį vakuuminį darbą, nes jis lauks, kol bus baigta operacija. Bet jei pašalinsite ką nors, ko gali prašyti kažkas kitas, tada jis bus užblokuotas, bus tam tikra grandininė reakcija. Svetainėse ir mobiliosiose programose reikėtų vengti ilgų operacijų.
Tai įdomu. Dažnai matau, kad kūrėjai klausia: „Kokio dydžio pakuotės turėčiau pasirinkti?“.
Akivaizdu, kad kuo didesnis paketo dydis, tuo mažesnės operacijos pridėtinės išlaidos, t. y. papildomos operacijų pridėtinės išlaidos. Tačiau kartu ilgėja ir šios operacijos laikas.
Turiu labai paprastą taisyklę: vartokite tiek, kiek galite, bet neviršykite vykdomųjų failų per sekundę.
Kodėl sekundę? Paaiškinimas labai paprastas ir suprantamas visiems, net ir netechniniams žmonėms. Matome reakciją. Paimkime 50 milisekundžių. Jei kas nors pasikeitė, mūsų akis sureaguos. Jei mažiau, tai sunkiau. Jei kas nors reaguoja po 100 milisekundžių, pavyzdžiui, spustelėjote pelę, o ji jums atsakė po 100 milisekundžių, jau jaučiate šį nedidelį delsą. Sekundė jau suvokiama kaip stabdys.
Atitinkamai, jei suskaidysime savo masines operacijas į 10 sekundžių serijas, rizikuojame ką nors užblokuoti. Ir tai veiks kelias sekundes, ir žmonės tai jau pastebės. Todėl man labiau patinka nedaryti daugiau nei sekundės. Tačiau tuo pat metu nesuskaidykite jo labai smulkiai, nes operacijos pridėtinės išlaidos bus pastebimos. Pagrindas bus kietesnis, gali kilti kitų įvairių problemų.
Mes pasirenkame pakuotės dydį. Kiekvienu atveju galime tai padaryti skirtingai. Gali būti automatizuotas. Ir mes esame įsitikinę vienos pakuotės apdorojimo efektyvumu. Tai yra, mes ištriname vieną pakuotę arba atnaujiname.
Beje, viskas, apie ką aš kalbu, yra ne tik DELETE. Kaip atspėjote, tai yra bet kokios masinės operacijos su duomenimis.
Ir matome, kad planas puikus. Galite matyti rodyklės nuskaitymą, tik indekso nuskaitymas yra dar geresnis. Ir mes turime nedidelį kiekį duomenų. Ir išsipildo mažiau nei sekundė. Super.
Ir vis tiek turime įsitikinti, kad nėra degradacijos. Būna, kad pirmosios pakuotės greitai pasiteisina, o paskui vis blogėja ir blogėja. Procesas toks, kad reikia daug išbandyti. Būtent tam skirtos duomenų bazių laboratorijos.
Ir dar turime ką nors paruošti, kad tai leistų teisingai to laikytis gamyboje. Pavyzdžiui, žurnale galime įrašyti laiką, galime parašyti, kur dabar esame ir ką dabar ištrynėme. Ir tai leis mums suprasti, kas vyksta vėliau. Ir jei kas nors negerai, greitai suraskite problemą.
Jei mums reikia patikrinti užklausų efektyvumą ir reikia kartoti daug kartų, tada yra toks dalykas kaip kolega robotas. Jis jau pasiruošęs. Jį kasdien naudoja dešimtys kūrėjų. Ir jis žino, kaip paprašius per 30 sekundžių pateikti didžiulę terabaitų duomenų bazę, savo kopiją. Ten galite ką nors ištrinti, pasakyti RESET ir ištrinti dar kartą. Galite eksperimentuoti su juo tokiu būdu. Aš matau šio dalyko ateitį. Ir mes tai jau darome.
Kas yra skaidymo strategijos? Matau 3 skirtingas skaidymo strategijas, kurias naudoja pakuotės kūrėjai.
Pirmasis yra labai paprastas. Turime skaitmeninį ID. Suskirstykime jį į skirtingus intervalus ir dirbkime su tuo. Minusas aiškus. Pirmajame segmente galime turėti 100 eilučių tikrų šiukšlių, antrame 5 eilučių arba visai ne, arba visos 1 eilučių bus šiukšlės. Labai netolygus darbas, bet lengvai sulaužomas. Jie paėmė maksimalų ID ir jį sudaužė. Tai naivus požiūris.
Antroji strategija yra subalansuotas požiūris. Jis naudojamas Gitlab. Jie paėmė ir nuskaitė stalą. Mes nustatėme ID paketų ribas, kad kiekvienoje pakuotėje būtų tiksliai 10 000 įrašų. Ir sudėti juos į eilę. Ir tada apdorojame. Tai galite padaryti keliose gijose.
Beje, pirmoje strategijoje taip pat galite tai padaryti keliomis gijomis. Tai nėra sunku.
Tačiau yra šaunesnis ir geresnis požiūris. Tai trečioji strategija. Ir kai įmanoma, geriau jį pasirinkti. Tai darome pagal specialų indeksą. Šiuo atveju tai greičiausiai bus indeksas pagal mūsų šiukšlių būklę ir ID. Įtrauksime ID, kad tai būtų tik indeksinis nuskaitymas, kad nepatektume į krūvą.
Paprastai nuskaitymas tik indeksu yra greitesnis nei indekso nuskaitymas.
Ir greitai randame savo ID, kuriuos norime pašalinti. BATCH_SIZE pasirenkame iš anksto. Ir mes juos ne tik gauname, bet ir gauname ypatingu būdu ir iškart nulaužiame. Bet rakiname, kad jei jau užrakinti, tai ne rakiname, o judame toliau ir imame kitus. Tai skirta naujinimų praleidimui užrakinta. Ši puiki „Postgres“ funkcija leidžia mums dirbti keliomis gijomis, jei norime. Galima vienu srautu. Ir čia yra CTE - tai vienas prašymas. O antrame šio CTE aukšte vyksta tikras ištrynimas – returning *. Galite grąžinti ID, bet geriau *jei neturite daug duomenų apie kiekvieną eilutę.
Kodėl mums to reikia? Apie tai turime pranešti. Dabar ištrynėme tiek daug eilučių. Ir mes turime tokias ribas pagal ID arba Create_at. Galite padaryti min, max. Galima dar ką nors padaryti. Čia galite daug ką prikimšti. Ir tai labai patogu stebėti.
Yra dar viena pastaba apie indeksą. Jei nusprendžiame, kad šiai užduočiai mums reikia specialaus indekso, turime įsitikinti, kad jis nesugadins tik kortelių atnaujinimų. Tai yra, „Postgres“ turi tokią statistiką. Tai galima pamatyti jūsų lentelės pg_stat_user_tables. Galite pamatyti, ar naudojami karštieji naujinimai, ar ne.
Yra situacijų, kai naujasis indeksas gali juos tiesiog nutraukti. Ir jūs turite visus kitus atnaujinimus, kurie jau veikia, sulėtinkite. Ne tik todėl, kad atsirado indeksas (kiekvienas indeksas šiek tiek sulėtina atnaujinimus, bet šiek tiek), bet čia jis vis tiek jį sugadina. Ir neįmanoma atlikti specialaus šios lentelės optimizavimo. Taip kartais nutinka. Tai tokia subtilybė, kurią mažai kas prisimena. Ir ant šio grėblio lengva užlipti. Kartais nutinka taip, kad reikia rasti požiūrį iš kitos pusės ir vis tiek apsieiti be šio naujo indekso arba pasidaryti kitą indeksą, arba kaip nors kitaip, pavyzdžiui, galima panaudoti antrąjį metodą.
Bet tai yra pati optimaliausia strategija, kaip suskirstyti į partijas ir šaudyti į partijas su vienu prašymu, šiek tiek ištrinti ir pan.
Ilgi sandoriai
Užblokuotas automatinis vakuumas -
blokavimo problema -
Klaida Nr. 5 yra didelė. Nikolajus iš Okmeter kalbėjo apie Postgres stebėjimą. Idealaus Postgres stebėjimo, deja, nėra. Vieni arčiau, kiti toliau. Okmeter yra pakankamai arti tobulumo, bet daug ko trūksta ir reikia pridėti. Turite būti tam pasiruošę.
Pavyzdžiui, negyvas korteles geriausia stebėti. Jei lentelėje yra daug negyvų daiktų, vadinasi, kažkas negerai. Geriau reaguoti dabar, kitaip gali prasidėti degradacija, ir mes galime atsigulti. Taip atsitinka.
Jei yra didelis IO, aišku, kad tai nėra gerai.
Taip pat ilgalaikiai sandoriai. Ilgos operacijos neturėtų būti leidžiamos naudojant OLTP. Ir čia yra nuoroda į fragmentą, leidžiantį paimti šį fragmentą ir jau atlikti tam tikrą ilgų operacijų stebėjimą.
Kodėl ilgalaikiai sandoriai yra blogi? Nes visos spynos bus atlaisvintos tik pabaigoje. Ir mes visus apsukame. Be to, blokuojame autovakuumą visiems stalams. Tai visai neblogai. Net jei kopijoje įjungtas karštasis budėjimo režimas, jis vis tiek blogas. Apskritai niekur nėra geriau vengti ilgų sandorių.
Jei turime daug lentelių, kurios nėra siurbiamos, tuomet turime turėti įspėjimą. Čia tokia situacija galima. Mes galime netiesiogiai paveikti autovakuumo veikimą. Tai yra Avito fragmentas, kurį šiek tiek patobulinau. Ir pasirodė, kad tai yra įdomus įrankis pamatyti, ką turime su autovakuumu. Pavyzdžiui, kai kurie stalai ten laukia ir nelauks savo eilės. Taip pat turite jį stebėti ir turėti įspėjimą.
Ir išduoda blokus. Blokuojančių medžių miškas. Man patinka ką nors iš ko nors perimti ir patobulinti. Čia paėmiau šaunų rekursyvų CTE iš Data Egret, kuriame rodomas užrakinamų medžių miškas. Tai geras dalykas diagnostikai. Jo pagrindu taip pat galima sukurti stebėjimą. Bet tai turi būti padaryta atsargiai. Turite pateikti nedidelį pareiškimą_laikas. Ir lock_timeout pageidautina.
Kartais visos šios klaidos atsiranda kartu.
Mano nuomone, čia pagrindinė klaida yra organizacinė. Tai organizacinis, nes technika netraukia. Tai numeris 2 – jie patikrino netinkamoje vietoje.
Patikrinome netinkamoje vietoje, nes neturėjome gamybos klono, kurį lengva patikrinti. Kūrėjas gali iš viso neturėti prieigos prie gamybos.
Ir patikrinome ne ten. Jei būtume ten patikrinę, patys būtume pamatę. Kūrėjas viską matė net be DBA, jei patikrino jį geroje aplinkoje, kur yra toks pat duomenų kiekis ir identiška vieta. Jis būtų matęs visą šį degradavimą ir jam būtų gėda.
Daugiau apie autovakuumą. Po to, kai atlikome didžiulį kelių milijonų eilučių nuvalymą, vis tiek turime atlikti REPACK. Tai ypač svarbu indeksams. Jie jausis blogai, kai mes ten viską išvalėme.
O jei norisi sugrąžinti kasdieninius valymo darbus, tuomet siūlyčiau juos atlikti dažniau, bet mažiau. Tai gali būti kartą per minutę arba net dažniau po truputį. Ir reikia stebėti du dalykus: kad šiame dalyke nebūtų klaidų ir kad jis neatsiliktų. Triukas, kurį parodžiau, kaip tik tai išspręs.
Tai, ką mes darome, yra atviras šaltinis. Jis paskelbtas GitLab. Ir mes tai darome taip, kad žmonės galėtų patikrinti net neturėdami DBA. Mes atliekame duomenų bazės laboratoriją, tai yra, vadiname bazinį komponentą, su kuriuo šiuo metu dirba Joe. Ir jūs galite paimti produkcijos kopiją. Dabar yra „Joe for slack“ diegimas, ten galite pasakyti: „paaiškinkite tokį ir tokį prašymą“ ir iškart gaukite savo duomenų bazės kopijos rezultatą. Ten netgi galite IŠTRINTI, ir niekas to nepastebės.
Tarkime, kad turite 10 terabaitų, duomenų bazės laboratoriją taip pat padarome 10 terabaitų. Vienu metu turint 10 terabaitų duomenų bazes, vienu metu gali dirbti 10 kūrėjų. Kiekvienas gali daryti ką nori. Gali ištrinti, numesti ir tt Tai tokia fantazija. Apie tai pakalbėsime rytoj.
Tai vadinama plonu aprūpinimu. Tai yra subtilus aprūpinimas. Tai yra tam tikra fantazija, kuri labai sumažina kūrimo ir bandymų vėlavimą ir daro pasaulį geresne vieta šiuo atžvilgiu. Tai yra, tai tiesiog leidžia išvengti problemų, susijusių su masinėmis operacijomis.
Pavyzdys: 5 terabaitų duomenų bazė, kopija gaunama greičiau nei per 30 sekundžių. Ir tai net nepriklauso nuo dydžio, tai yra, nesvarbu, kiek terabaitų.
Šiandien galite eiti į ir pasinerti į mūsų įrankius. Galite užsiregistruoti, kad pamatytumėte, kas ten yra. Galite įdiegti šį robotą. Tai nemokama. Rašyti.
Klausimai
Labai dažnai realiose situacijose paaiškėja, kad duomenų, kurie turėtų likti lentelėje, yra daug mažiau, nei reikia ištrinti. Tai yra, tokioje situacijoje dažnai lengviau įgyvendinti šį metodą, kai lengviau sukurti naują objektą, nukopijuoti ten tik reikiamus duomenis ir perrašyti seną lentelę. Akivaizdu, kad šiuo metu jums reikia programinės įrangos metodo, kai keičiate. Kaip toks požiūris?
Tai labai geras požiūris ir labai gera užduotis. Tai labai panašu į tai, ką daro pg_repack, tai labai panašu į tai, ką turite padaryti, kai sukuriate 4 baitų ID. Daugelis karkasų tai padarė prieš keletą metų, o tik plokštės išaugo ir jas reikia konvertuoti į 8 baitus.
Ši užduotis yra gana sunki. Mes tai padarėme. Ir jūs turite būti labai atsargūs. Yra spynos ir pan. Bet tai daroma. Tai reiškia, kad standartinis metodas yra pg_repack. Jūs deklaruojate tokią etiketę. Ir prieš pradėdami į jį įkelti momentinius duomenis, taip pat deklaruojate vieną plokštelę, kuri seka visus pakeitimus. Yra gudrybė, kad kai kurių pakeitimų galite net nesekti. Yra subtilybių. Tada perjungiate atlikdami pakeitimus. Kai visi uždarysime, bus trumpa pauzė, bet apskritai tai daroma.
Jei pažvelgsite į pg_repack GitHub, tada, kai buvo užduotis konvertuoti ID iš int 4 į int 8, tada kilo mintis naudoti patį pg_repack. Tai taip pat įmanoma, bet tai šiek tiek nulaužta, bet tai taip pat veiks. Galite įsikišti į trigerį, kurį naudoja pg_repack, ir pasakyti: „Mums nereikia šių duomenų“, t. y. perkeliame tik tai, ko mums reikia. Ir tada jis tiesiog persijungia ir viskas.
Taikydami šį metodą gauname ir antrą lentelės kopiją, kurioje duomenys jau yra indeksuoti ir labai sklandžiai išdėstyti gražiais indeksais.
Išpūtimo nėra, tai geras būdas. Bet žinau, kad tam yra bandoma sukurti automatiką, t.y., sukurti universalų sprendimą. Galiu susisiekti su šia automatika. Tai parašyta Python kalba, o tai yra geras dalykas.
Aš tik šiek tiek esu iš MySQL pasaulio, todėl atėjau pasiklausyti. Ir mes naudojame šį metodą.
Bet tai tik tuo atveju, jei turime 90 proc. Jeigu turime 5 proc., tai nelabai gerai jį naudoti.
Ačiū už pranešimą! Jei nėra išteklių, kad būtų galima padaryti visą gaminio kopiją, ar yra koks nors algoritmas ar formulė apkrovai arba dydžiui apskaičiuoti?
Geras klausimas. Kol kas galime rasti kelių terabaitų duomenų bazes. Net jei ten aparatinė įranga nėra ta pati, pavyzdžiui, mažiau atminties, mažiau procesoriaus ir diskai nėra visiškai vienodi, bet vis tiek tai darome. Jei visiškai niekur nėra, tada reikia galvoti. Leisk man pagalvoti iki rytojaus, tu atėjai, pasikalbėsime, tai geras klausimas.
Ačiū už pranešimą! Pirmiausia pradėjote apie tai, kad yra šaunus „Postgres“, kuris turi tokius ir tokius apribojimus, bet jis vystosi. Ir visa tai iš esmės yra ramentas. Ar visa tai neprieštarauja pačiam Postgres vystymuisi, kuriame atsiras koks nors DELETE deferentas ar dar kažkas, kas turėtų išlaikyti žemą lygį tai, ką mes čia bandome sutepti kažkokiomis savo keistomis priemonėmis?
Jei SQL sakėme, kad per vieną operaciją reikia ištrinti arba atnaujinti daug įrašų, kaip Postgres gali juos ten platinti? Esame fiziškai apriboti operacijose. Dar ilgai tai darysime. Ir šiuo metu užrakinsime ir pan.
Atlikta su indeksais.
Galiu daryti prielaidą, kad tas pats kontrolinio taško derinimas gali būti automatizuotas. Kada nors gali būti. Bet tada aš nelabai suprantu klausimo.
Kyla klausimas, ar yra toks vystymosi vektorius, kuris eina čia ir ten, o čia jūsų – lygiagrečiai? Tie. Ar jie dar apie tai nepagalvojo?
Aš kalbėjau apie principus, kuriuos galima naudoti dabar. Yra dar vienas botas , su tuo galite atlikti automatinį kontrolinių taškų derinimą. Ar tai kada nors bus Postgrese? Nežinau, dar net nekalbėta. Mums dar toli iki to. Tačiau yra mokslininkų, kurie kuria naujas sistemas. Ir jie įstumia mus į automatinius indeksus. Vystymosi yra. Pavyzdžiui, galite pažvelgti į automatinį derinimą. Jis automatiškai parenka parametrus. Bet jis dar neatliks patikros punkto derinimo už jus. Tai reiškia, kad jis pasieks našumą, apvalkalo buferį ir kt.
O patikros taško derinimui galite tai padaryti: jei debesyje turite tūkstantį grupių ir skirtingą aparatinę įrangą, skirtingas virtualias mašinas, galite naudoti mūsų robotą padaryti automatizavimą. Ir max_wal_size bus parinktas automatiškai pagal jūsų tikslinius nustatymus. Deja, kol kas tai nė iš tolo neprilygsta branduoliui.
Laba diena Kalbėjote apie ilgų sandorių pavojus. Sakėte, kad ištrynus automatinis vakuumas blokuojamas. Kaip dar tai mums kenkia? Nes mes daugiau kalbame apie vietos atlaisvinimą ir galimybę ja naudotis. Ko dar mums trūksta?
Autovakuumas čia gal ir nėra didžiausia problema. O tai, kad ilgas sandoris gali užblokuoti kitus sandorius, tokia galimybė yra pavojingesnė. Ji gali susitikti arba ne. Jei ji susitiko, gali būti labai blogai. O su autovakuumu – tai irgi problema. Yra dvi problemos, susijusios su ilgais sandoriais OLTP: užraktai ir automatinis vakuumas. Ir jei kopijoje įjungtas karštojo budėjimo režimo grįžtamasis ryšys, vis tiek gausite pagrindinio įrenginio automatinį vakuuminį užraktą, jis bus gautas iš kopijos. Bet bent jau spynų nebus. Ir bus loks. Kalbame apie duomenų pasikeitimus, todėl spynos čia yra svarbus dalykas. Ir jei visa tai vyksta ilgai, ilgai, tada vis daugiau sandorių užrakinama. Jie gali pavogti kitus. Ir atsiranda lok medžiai. Pateikiau nuorodą į fragmentą. Ir ši problema tampa labiau pastebima greičiau nei problema su autovakuumu, kuris gali tik kauptis.
Ačiū už pranešimą! Savo ataskaitą pradėjote sakydami, kad išbandėte neteisingai. Tęsėme mintį, kad reikia imti tą pačią įrangą, su baze taip pat. Tarkime, kūrėjui suteikėme pagrindą. Ir jis prašymą įvykdė. Ir atrodo, kad jam viskas gerai. Bet jis tikrina ne gyvai, o gyvai, pavyzdžiui, pas mus apkrova 60-70 proc. Ir net jei naudosime šį derinimą, jis neveikia labai gerai.
Svarbu, kad komandoje būtų ekspertas ir DBA ekspertai, galintys numatyti, kas nutiks esant realiam foniniam krūviui. Kai ką tik atlikome švarius pakeitimus, matome vaizdą. Bet pažangesnis požiūris, kai dar kartą padarėme tą patį, bet su apkrova, imituota gamyba. Tai gana kietas. Iki tol reikia suaugti. Tai kaip suaugęs žmogus. Tiesiog žiūrėjome, ką turime, taip pat žiūrėjome, ar turime pakankamai išteklių. Tai geras klausimas.
Kai jau atliekame šiukšlių pasirinkimą ir turime, pavyzdžiui, ištrintą vėliavėlę
Tai yra tai, ką automatinis vakuumas daro automatiškai „Postgres“.
O, ar jis tai daro?
Autovakuumas yra šiukšlių surinkėjas.
Dėkojame!
Ačiū už pranešimą! Ar yra galimybė iš karto suprojektuoti duomenų bazę su skaidymu taip, kad visos šiukšlės iš pagrindinės lentelės išsipurvintų kažkur į šoną?
Žinoma turi.
Ar tada galima apsisaugoti, jei užrakinome stalą, kurio nereikėtų naudoti?
Žinoma turi. Bet tai tarsi vištienos ir kiaušinio klausimas. Jei visi žinosime, kas bus ateityje, tada, žinoma, viską darysime šauniai. Tačiau verslas keičiasi, atsiranda naujų stulpelių, naujų prašymų. Ir tada – oi, norime jį pašalinti. Tačiau tokia ideali situacija gyvenime pasitaiko, bet ne visada. Bet apskritai tai gera idėja. Tiesiog sutrumpink ir viskas.
Šaltinis: www.habr.com