Sa ibang araw sa malayong hinaharap, ang awtomatikong pag-alis ng hindi kinakailangang data ay magiging isa sa mga mahahalagang gawain ng isang DBMS [1]. Pansamantala, kailangan nating mag-ingat sa pagtanggal o paglipat ng hindi kinakailangang data sa mas murang mga storage system. Sabihin nating nagpasya kang magtanggal ng ilang milyong row. Isang medyo simpleng gawain, lalo na kung ang kundisyon ay kilala at mayroong isang angkop na index. "DELETE FROM table1 WHERE col1 = :value" - ano ang mas simple, tama?
Video:
-
Nasa Highload program committee ako mula noong unang taon, ibig sabihin, mula noong 2007.
-
At kasama ko ang Postgres mula noong 2005. Ginamit ito sa maraming proyekto.
-
Ang grupo ay kasama rin sa RuPostges mula noong 2007.
-
Umabot na kami sa 2100+ kalahok sa Meetup. Ito ang pangalawang lugar sa mundo pagkatapos ng New York, na naabutan ang San Francisco matagal na ang nakalipas.
-
Ilang taon na akong nakatira sa California. Madalas akong nagtatrabaho sa mga kumpanyang Amerikano, kabilang ang mga malalaking kumpanya. Sila ay mga aktibong gumagamit ng Postgres. At lahat ng uri ng mga kagiliw-giliw na bagay ay lumitaw doon.
β ito ang aking kumpanya. Kami ay nasa negosyo ng pag-automate ng mga gawain na nag-aalis ng mga paghina ng pag-unlad.
Kung may gagawin ka, minsan may mga aberya sa paligid ng Postgres. Sabihin nating kailangan mong maghintay hanggang sa bigyan ka ng admin ng test bench, o kailangan mong maghintay hanggang sa tumugon ang DBA sa iyo. At nakita namin ang gayong mga bottleneck sa proseso ng pagbuo, pagsubok at pangangasiwa at sinusubukan naming alisin ang mga ito gamit ang automation at mga bagong diskarte.
Kamakailan ay nasa VLDB ako sa Los Angeles. Ito ang pinakamalaking database conference. At mayroong isang ulat na sa hinaharap ang mga DBMS ay hindi lamang mag-iimbak, ngunit awtomatikong magtanggal ng data. Ito ay isang bagong paksa.
Parami nang parami ang data sa mundo. Ang mga zetabytes ay 1 petabytes. At ngayon ay tinatayang mayroon na tayong higit sa 000 zettabytes ng data na nakaimbak sa mundo. At parami nang parami ang mga ito.
At ano ang gagawin dito? Malinaw na kailangan itong tanggalin. Narito ang isang link sa kawili-wiling ulat na ito. Ngunit hanggang ngayon ay hindi pa ito naipapatupad sa DBMS.
Dalawang bagay ang gusto ng mga marunong magbilang ng pera. Gusto nilang tanggalin namin, kaya technically kailangan namin itong gawin.
Ang susunod kong sasabihin ay isang abstract na sitwasyon na kinabibilangan ng isang grupo ng mga tunay na sitwasyon, iyon ay, isang tiyak na compilation ng kung ano ang aktwal na nangyari sa akin at sa mga nakapalibot na database ng maraming beses, maraming taon. Ang mga rake ay nasa lahat ng dako at lahat ay tinatapakan sila sa lahat ng oras.
Sabihin nating mayroon tayong base o ilang base na lumalaki. At ang ilan sa mga tala ay halatang basura. Halimbawa, ang gumagamit ay nagsimulang gumawa ng isang bagay doon, ngunit hindi natapos. At pagkaraan ng ilang oras alam natin na ang hindi natapos na gawaing ito ay hindi na maiimbak. Ibig sabihin, gusto naming maglinis ng ilang basurang bagay para makatipid ng espasyo, mapabuti ang performance, atbp.
Sa pangkalahatan, ang gawain ay i-automate ang pagtanggal ng mga partikular na bagay, mga partikular na linya sa isang talahanayan.
At mayroon tayong kahilingan na pag-uusapan natin ngayon, iyon ay, tungkol sa pagtatanggal ng basura.
Hiniling namin sa isang makaranasang developer na gawin ito. Kinuha niya ang kahilingang ito, sinuri ito mismo - gumagana ang lahat. Sinubukan ko ito sa pagtatanghal - lahat ay maayos. Inilunsad ito - gumagana ang lahat. Minsan sa isang araw pinapatakbo namin ito - maayos ang lahat.
Ang database ay lumalaki at lumalaki. Ang pang-araw-araw na DELETE ay nagsisimula nang mas mabagal.
Pagkatapos ay napagtanto namin na isa na kaming kumpanya sa marketing at ang trapiko ay magiging ilang beses na mas malaki, kaya nagpasya kaming pansamantalang i-pause ang mga hindi kinakailangang bagay. At nakalimutan naming ibalik ito.
Makalipas ang ilang buwan naalala nila. At ang developer na iyon ay huminto o abala sa ibang bagay, nagtalaga sila ng isa pang ibalik ito.
Sinuri niya ang dev, sa pagtatanghal - lahat ay OK. Natural, kailangan mo pa ring linisin ang naipon. Sinuri niya, gumagana ang lahat.
Anong mangyayari sa susunod? Pagkatapos ang lahat ay nahuhulog para sa amin. Ito ay bumaba nang labis na sa isang punto ay bumagsak ang lahat. Gulat na gulat ang lahat, walang nakakaintindi sa nangyayari. At pagkatapos ay lumabas na ang DELETE na ito ang isyu.
May nangyaring mali? Narito ang isang listahan ng mga bagay na maaaring magkamali. Alin sa mga ito ang pinakamahalaga?
-
Halimbawa, walang pagsusuri, ibig sabihin, hindi tumingin ang eksperto sa DBA. Sa may karanasang mata, mahahanap niya kaagad ang problema, at bukod pa, mayroon siyang access sa prod, kung saan ilang milyong linya ang naipon.
-
Baka may na-check silang mali.
-
Marahil ay luma na ang hardware at kailangan mong i-upgrade ang database na ito.
-
O may mali sa database mismo, at kailangan nating lumipat mula sa Postgres patungo sa MySQL.
-
O baka may mali sa operasyon.
-
Marahil ay may ilang mga pagkakamali sa organisasyon ng trabaho at kailangan mong tanggalin ang isang tao at kumuha ng mas mahusay na mga tao?
Walang DBA check. Kung mayroong DBA, makikita niya ang ilang milyong linyang ito at kahit na walang anumang mga eksperimento ay sasabihin: "Hindi nila ginagawa iyon." Sabihin nating kung ang code na ito ay nasa GitLab, GitHub at nagkaroon ng proseso ng pagsusuri ng code at walang ganoong bagay na kung walang pag-apruba ng DBA ay magaganap ang operasyong ito sa prod, kung gayon malinaw na sasabihin ng DBA: "Hindi mo magagawa iyon. β
At sasabihin niya na magkakaroon ka ng mga problema sa disk IO at lahat ng mga proseso ay mababaliw, maaaring may mga kandado, at haharangan mo rin ang autovacuum sa loob ng ilang minuto, kaya hindi ito maganda.
Ang pangalawang pagkakamali ay na-check nila sa maling lugar. Nakita namin pagkatapos ng katotohanan na maraming data ng basura ang naipon sa prod, ngunit ang developer ay walang naipon na data sa database na ito, at walang sinuman ang talagang lumikha ng basurang ito sa pagtatanghal. Alinsunod dito, mayroong 1 linya, na mabilis na natapos.
Naiintindihan namin na ang aming mga pagsubok ay mahina, ibig sabihin, ang proseso na binuo ay hindi nakakakuha ng mga problema. Hindi naisagawa ang isang sapat na eksperimento sa DB.
Ang isang mainam na eksperimento ay dapat na maisagawa sa parehong kagamitan. Hindi laging posible na gawin ito sa parehong hardware, ngunit napakahalaga na ito ay isang buong laki ng kopya ng database. Ito ang ipinangangaral ko sa loob ng ilang taon. At isang taon na ang nakalipas napag-usapan ko ito, mapapanood mo lahat sa YouTube.
Baka sira ang gamit natin? Kung titingnan mo, tumalon ang latency. Nakita namin na ang pag-recycle ay 100%. Siyempre, kung ang mga ito ay mga modernong NVMe drive, malamang na magiging mas madali para sa amin. At marahil ay hindi kami mahiga dahil dito.
Kung mayroon kang mga ulap, kung gayon ang pag-upgrade ay madali. Naglunsad kami ng mga bagong replika sa bagong hardware. Lumipat sa. At lahat ay maayos. medyo madali.
Posible bang kahit papaano ay hawakan ang mas maliliit na disk? At dito, sa tulong ng DBA, sumisid kami sa isang partikular na paksa na tinatawag na checkpoint tuning. Hindi pala kami nagsagawa ng checkpoint tuning.
Ano ang checkpoint? Ito ay magagamit sa anumang DBMS. Kapag ang data sa iyong memorya ay nagbago, hindi ito agad na isinulat sa mga disk. Ang impormasyong binago ng data ay unang isinusulat sa forward log, sa write-ahead log. At sa ilang mga punto, ang DBMS ay nagpasya na oras na upang itapon ang mga tunay na pahina sa disk, upang kung tayo ay mabigo, mas mababa ang magagawa natin sa REDO. Parang laruan. Kung tayo ay mapatay, sisimulan natin ang laro mula sa huling checkpoint. At lahat ng DBMS ay nagpapatupad nito.
Ang mga setting sa Postgres ay nahuhuli. Idinisenyo ang mga ito para sa 10-15 taong gulang na dami ng data at operasyon. At ang checkpoint ay walang pagbubukod.
Ang impormasyong ito ay mula sa aming ulat sa Postgres check-up, ibig sabihin, awtomatikong pagsusuri sa kalusugan. At narito ang ilang database ng ilang terabytes. At malinaw na ang mga checkpoint ay pinipilit sa halos 90% ng mga kaso.
Ano ang ibig sabihin nito? Mayroong dalawang mga setting doon. Maaaring mangyari ang checkpoint sa timeout, halimbawa, sa loob ng 10 minuto. O maaaring mangyari ito kapag napakaraming data ang napunan.
At bilang default, ang max_wal_saze ay nakatakda sa 1 gigabyte. Sa katunayan, ito ay aktwal na nangyayari sa Postgres pagkatapos ng 300-400 megabytes. Napakaraming data ang nabago mo at mayroon kang checkpoint.
At kung walang nag-tune nito, ngunit ang serbisyo ay lumago, at ang kumpanya ay kumikita ng maraming pera, mayroon itong maraming mga transaksyon, pagkatapos ay ang checkpoint ay nangyayari isang beses sa isang minuto, minsan isang beses bawat 30 segundo, at kung minsan sila ay nagsasapawan sa isa't isa. . Ito ay talagang masama.
At kailangan nating tiyakin na mas madalas itong dumating. Ibig sabihin, maaari nating taasan ang max_wal_size. At hindi na siya madalas umatake.
Ngunit nakabuo kami ng isang buong pamamaraan kung paano ito gagawin nang mas tama, iyon ay, kung paano gumawa ng mga pagpapasya tungkol sa pagpili ng mga setting, malinaw na batay sa partikular na data.
Alinsunod dito, nagsasagawa kami ng dalawang serye ng mga eksperimento sa database.
Unang serye - binabago namin ang max_wal_size. At nagsasagawa kami ng isang napakalaking operasyon. Una naming gawin ito sa default na setting ng 1 gigabyte. At gumagawa kami ng napakalaking DELETE ng milyun-milyong linya.
Makikita mo kung gaano kami kahirap. Nakikita namin na ang disk IO ay napakasama. Tingnan natin kung gaano karaming WAL ang nabuo natin, dahil ito ay napakahalaga. Tingnan natin kung ilang beses nangyari ang checkpoint. At nakikita natin na hindi ito maganda.
Susunod, dinadagdagan namin ang max_wal_size. Ulitin namin. Dagdagan, ulitin. At napakaraming beses. Sa prinsipyo, 10 puntos ay mabuti, kung saan 1, 2, 4, 8 gigabytes. At tinitingnan natin ang pag-uugali ng isang partikular na sistema. Malinaw na ang mga kagamitan dito ay dapat na tulad ng sa prod. Dapat ay mayroon kang parehong mga disk, parehong dami ng memorya, at parehong mga setting ng Postgres.
At sa ganitong paraan, ipapalit namin ang aming system, at alam namin kung paano kikilos ang DBMS kung sakaling magkaroon ng masamang masa DELETE, kung paano ito mag-tsekpoint.
Ang checkpoint sa Russian ay nangangahulugan ng mga control point.
Halimbawa: I-DELETE ang ilang milyong row ayon sa index, ang mga row ay βscatteredβ sa mga page.
Narito ang isang halimbawa. Ito ay ilang batayan. At sa default na setting na 1 gigabyte para sa max_wal_size, napakalinaw na ang aming mga disk para sa pagre-record ay napupunta sa istante. Ang larawang ito ay tipikal na sintomas ng isang napakasakit na pasyente, ibig sabihin, masama talaga ang pakiramdam niya. At nagkaroon lamang ng isang operasyon, dito ay DELETE lamang ng ilang milyong linya.
Kung papayagan ang ganyang operasyon sa prod, matutumba lang tayo, dahil malinaw na may isang DELETE ang pumapatay sa atin sa istante.
Dagdag pa, kung saan mayroong 16 gigabytes, makikita mo na ang mga ngipin ay nagsimula nang lumitaw. Ang mga ngipin ay mas mahusay na, i.e. kami ay kumakatok sa kisame, ngunit hindi masyadong masama. Isang maliit na kalayaan ang lumitaw doon. Sa kanan ay ang recording. At ang bilang ng mga operasyon ay ang pangalawang graph. At malinaw na medyo nakahinga na tayo nang maluwag sa 16 gigabytes.
At kung saan makikita ang 64 gigabytes, ito ay naging ganap na mas mahusay. Ang mga ngipin ay malinaw na nakikita, mayroong higit pang mga pagkakataon upang makaligtas sa iba pang mga operasyon at gumawa ng isang bagay sa disc.
Bakit na?
Sumisid ako sa mga detalye nang kaunti, ngunit ang paksang ito kung paano isasagawa ang pag-tune ng checkpoint ay maaaring magresulta sa isang buong ulat, kaya hindi na ako magdetalye, ngunit ilalarawan ko nang kaunti kung anong mga paghihirap ang mayroon.
Kung masyadong madalas mangyari ang checkpoint, at hindi namin ina-update ang aming mga row nang sunud-sunod, ngunit hanapin ang mga ito sa pamamagitan ng index, na mabuti, dahil hindi namin tinatanggal ang buong talahanayan, maaaring mangyari na una naming hinawakan ang unang pahina, pagkatapos ay ang ika-libo, at pagkatapos ay bumalik sa una. At kung sa pagitan ng mga pagbisitang ito sa unang pahina ay nai-save na ito ng checkpoint sa disk, muli itong i-save, dahil nadungisan namin ito sa pangalawang pagkakataon.
At pipilitin natin ang checkpoint na i-save ito ng maraming beses. Para bang may mga redundant operations para dito.
Ngunit hindi lang iyon. Sa Postgres, ang mga pahina ay tumitimbang ng 8 kilobytes, at sa Linux ay 4 na kilobytes. At mayroong isang setting na full_page_writes. Ito ay pinagana bilang default. At ito ay tama, dahil kung i-off natin ito, may panganib na kung mayroong pagkabigo, kalahati lamang ng pahina ang mai-save.
Ang pag-uugali ng entry sa WAL ng forward log ay tulad na kapag mayroon tayong checkpoint at binago natin ang isang page sa unang pagkakataon, ang buong page, ibig sabihin, lahat ng 8 kilobytes, ay mapupunta sa forward log, bagama't tayo lamang binago ang isang linya na tumitimbang ng 100 bytes . At napipilitan kaming isulat ang buong pahina.
Sa kasunod na mga pagbabago magkakaroon lamang ng isang tiyak na tuple, ngunit sa unang pagkakataon ay isusulat namin ang lahat.
At, ayon dito, kung mangyari muli ang checkpoint, kailangan nating simulan muli ang lahat mula sa simula at isiksik ang buong pahina. Sa madalas na mga checkpoint, kapag dumaan tayo sa parehong mga pahina, ang full_page_writes = on ay magiging mas malaki kaysa sa maaaring mangyari, ibig sabihin, bumubuo tayo ng mas maraming WAL. Higit pa ang ipinapadala sa mga replika, sa archive, sa disk.
At, ayon dito, mayroon kaming dalawang redundancies.
Kung dinadagdagan natin ang max_wal_size, lumalabas na mas pinapadali natin ang gawain ng checkpoint at wal writer. At ang galing.
Mag-install tayo ng terabyte at mabuhay kasama nito. Anong masama dun? Ito ay masama, dahil kung sakaling mabigo tayo ay babangon ng maraming oras, dahil ang checkpoint ay matagal na ang nakalipas at marami na ang nagbago. At kailangan nating gawin ang REDO para sa lahat ng ito. At kaya nagsasagawa kami ng pangalawang serye ng mga eksperimento.
Ginagawa namin ang operasyon at tinitingnan kapag malapit nang makumpleto ang checkpoint, sinasadya namin ang pagpatay -9 Postgres.
At pagkatapos nito, sisimulan natin itong muli, at tingnan kung gaano katagal bago tumaas ang kagamitang ito, ibig sabihin, kung gaano karaming REDO ang gagawin nito sa masamang sitwasyong ito.
Dalawang beses kong papansinin na masama ang sitwasyon. Una, nahulog kami bago matapos ang checkpoint, kaya marami kaming mawawala. At pangalawa, nagkaroon kami ng malawakang operasyon. At kung ang mga checkpoint ay may timeout, malamang na mas kaunting WAL ang nabuo mula noong huling checkpoint. Ibig sabihin, twice-loser ito.
Sinusukat namin ang sitwasyong ito para sa iba't ibang max_wal_size at nauunawaan na kung ang max_wal_size ay 64 gigabytes, kung gayon sa isang dobleng pinakamasamang sitwasyon ay tataas kami sa loob ng 10 minuto. At iniisip namin kung nababagay ba ito sa amin o hindi. Ito ay isang isyu sa negosyo. Kailangan nating ipakita ang larawang ito sa mga responsable para sa mga desisyon sa negosyo at itanong: βAno ang maximum na oras na maaari nating hintayin kung sakaling magkaroon ng problema? Maaari ba tayong mahiga sa mas masamang sitwasyon sa loob ng 3-5 minuto?" At gumawa ka ng desisyon.
At dito mayroong isang kawili-wiling punto. Mayroon kaming ilang mga ulat tungkol kay Patroni sa kumperensya. At marahil ay ginagamit mo ito. Ito ay autofailover para sa Postgres. Pinag-usapan ito ng GitLab at Data Egret.
At kung mayroon kang autofailover na magaganap sa loob ng 30 segundo, kung gayon maaari tayong humiga ng 10 minuto? Dahil sa puntong ito ay lilipat tayo sa replika, at magiging maayos ang lahat. Ito ay isang kontrobersyal na isyu. Wala akong alam na malinaw na sagot. Nararamdaman ko lang na ang paksang ito ay hindi lamang tungkol sa pagbawi ng kalamidad.
Kung mayroon tayong matagal na paggaling mula sa isang kabiguan, kung gayon tayo ay magiging hindi komportable sa maraming iba pang mga sitwasyon. Halimbawa, sa parehong mga eksperimento, kapag gumawa tayo ng isang bagay at kung minsan ay kailangang maghintay ng 10 minuto.
Hindi pa rin ako lalayo, kahit na may autofailover kami. Bilang isang patakaran, ang mga halaga tulad ng 64, 100 gigabytes ay mahusay na mga halaga. Minsan ito ay nagkakahalaga ng pagpili ng mas kaunti. Sa pangkalahatan, ito ay isang banayad na agham.
Upang umulit, halimbawa, max_wal_size = 1, 8, kailangan mong ulitin ang mass operation nang maraming beses. Nagawa mo. At gusto mong gawin itong muli sa parehong base, ngunit tinanggal mo na ang lahat. Anong gagawin?
Sasabihin ko sa iyo sa ibang pagkakataon ang tungkol sa aming solusyon at kung ano ang ginagawa namin para umulit sa mga ganitong sitwasyon. At ito ang pinaka tamang diskarte.
Ngunit sa kasong ito kami ay masuwerte. Kung, gaya ng sinasabi dito na "BEGIN, DELETE, ROLLBACK", maaari nating ulitin ang DELETE. Ibig sabihin, kung tayo mismo ang nagkansela nito, maaari nating ulitin ito. At pisikal na naroroon ang iyong data. Ni hindi ka nagkakaroon ng bloat. Maaari kang umulit sa naturang DELETE.
Ang DELETE na ito na may ROLLBACK ay mainam para sa pag-tune ng checkpoint, kahit na wala kang maayos na naka-deploy na database lab.
Gumawa kami ng sign na may isang column na βiβ. May mga column ng serbisyo ang mga postgres. Ang mga ito ay hindi nakikita maliban kung partikular na hiniling. Ito ay: ctid, xmid, xmax.
Ang Ctid ay ang pisikal na address. Page zero, ang unang tuple sa page.
Ito ay makikita na pagkatapos ng ROOLBACK ang tuple ay nanatili sa parehong lugar. Ibig sabihin, maaari nating subukan muli, ito ay magiging pareho. Ito ang pangunahing bagay.
Ang Xmax ay ang oras ng pagkamatay ng tuple. Ito ay ipinasok, ngunit alam ng Postgres na ang transaksyong ito ay na-roll back, kaya hindi mahalaga kung ito ay 0 o isang rolled back na transaksyon. Iminumungkahi nito na ang DELETE ay maaaring gamitin upang umulit at subukan ang napakalaking operasyon ng pag-uugali ng system. Maaari kang gumawa ng mga database lab para sa mahihirap.
Ito ay tungkol sa mga programmer. Tungkol din sa DBA, palagi nilang pinapagalitan ang mga programmer dahil dito: "Bakit ka gumagawa ng mahaba at mahirap na operasyon?" Ito ay isang ganap na naiibang perpendikular na paksa. Dati ay may administrasyon, ngunit ngayon magkakaroon ng pag-unlad.
Malinaw na hindi namin ito pinaghiwa-hiwalay sa mga bahagi. Malinaw na. Imposibleng hatiin ang naturang DELETE para sa isang bungkos ng milyun-milyong linya sa mga bahagi. Aabutin ng 20 minuto upang gawin, at lahat ay mahiga. Ngunit, sa kasamaang-palad, kahit na ang mga nakaranasang developer ay nagkakamali, kahit na sa napakalaking kumpanya.
Bakit mahalaga ang breaking?
-
Kung nakikita natin na ang disc ay matigas, pagkatapos ay pabagalin natin ito. At kung tayo ay nasira, pagkatapos ay maaari tayong magdagdag ng mga pag-pause, maaari nating pabagalin ang throttling.
-
At hindi namin haharangin ang iba nang matagal. Sa ilang mga kaso, hindi mahalaga, kung nag-aalis ka ng mga totoong basura na walang gumagawa, malamang na hindi mo haharangin ang sinuman maliban sa trabaho ng autovacuum dahil maghihintay ito para makumpleto ang transaksyon. Ngunit kung tatanggalin mo ang isang bagay na maaaring hilingin ng ibang tao, pagkatapos ay mai-block sila, magkakaroon ng ilang uri ng chain reaction. Dapat na iwasan ang mahabang transaksyon sa mga website at mobile application.
Ito ay kawili-wili. Madalas kong nakikita ang mga developer na nagtatanong, "Anong laki ng pack ang dapat kong piliin?"
Malinaw na mas malaki ang laki ng batch, mas mababa ang overhead ng transaksyon, ibig sabihin, karagdagang overhead ng transaksyon. Ngunit sa parehong oras, ang oras para sa transaksyong ito ay tumataas.
Mayroon akong isang napaka-simpleng panuntunan: kumuha ng mas marami hangga't maaari, ngunit huwag lumampas sa execution bawat segundo.
Bakit isang segundo? Ang paliwanag ay napaka-simple at naiintindihan ng lahat, kahit na hindi teknikal na mga tao. Nakikita namin ang reaksyon. Maglaan tayo ng 50 milliseconds. Kung may nagbago, magre-react ang mata natin. Kung mas kaunti, mas mahirap. Kung may tumugon pagkatapos ng 100 millisecond, halimbawa, nag-click ka gamit ang mouse at tumugon ito sa iyo pagkatapos ng 100 milliseconds, nararamdaman mo na ang bahagyang pagkaantala na ito. Ang isang segundo ay itinuturing na bilang isang preno.
Alinsunod dito, kung hahatiin natin ang ating mga mass operations sa 10 segundong pagsabog, magkakaroon tayo ng panganib na maharangan natin ang isang tao. At gagana ito ng ilang segundo, at mapapansin na ito ng mga tao. Iyon ang dahilan kung bakit mas gusto kong huwag gawin ito nang higit sa isang segundo. Ngunit sa parehong oras, huwag sirain ito nang napakaliit, dahil ang overhead ng transaksyon ay mapapansin. Ito ay magiging mas mabigat para sa base, at iba't ibang mga problema ay maaaring lumitaw.
Pinipili namin ang laki ng pack. Sa bawat kaso, maaari nating gawin ito nang iba. Maaaring awtomatiko. At kami ay kumbinsido sa kahusayan ng pagproseso ng isang pakete. Ibig sabihin, I-DELETE namin ang isang pack o UPDATE.
Siyanga pala, lahat ng sinasabi ko sayo ay hindi lang tungkol sa DELETE. Gaya ng nahulaan mo, ito ay anumang maramihang pagpapatakbo sa data.
At nakita namin na ang plano ay mahusay. Maaari mong makita ang index scan, kahit na mas mahusay na index lamang scan. At mayroon kaming maliit na halaga ng data na kasangkot. At lahat ay gumagana sa mas mababa sa isang segundo. Super.
At kailangan pa rin nating siguraduhin na walang degradation. Ito ay nangyayari na ang mga unang batch ay mabilis na naisagawa, at pagkatapos ang lahat ay lumalala at mas masahol pa at mas masahol pa. Ang proseso ay tulad na kailangan mong subukan ng maraming. Ito ay eksakto kung ano ang database labs ay kailangan para sa.
At kailangan pa nating maghanda ng isang bagay upang ito ay magbibigay-daan sa atin na masubaybayan ito ng tama sa produksyon. Halimbawa, maaari nating isulat ang oras sa log, maaari nating isulat kung nasaan tayo ngayon at kung sino ang tinanggal natin ngayon. At ito ay magbibigay-daan sa amin upang maunawaan mamaya kung ano ang nangyayari. At kung may mali, mabilis na hanapin ang problema.
Kung kailangan nating suriin ang kahusayan ng mga query at kailangan nating umulit ng maraming beses, kung gayon mayroong isang bagay bilang isang kapwa bot. Nakahanda na siya. Ito ay ginagamit ng dose-dosenang mga developer araw-araw. At makakapagbigay siya ng malaking database ng terabyte kapag hiniling sa loob ng 30 segundo, ang iyong sariling kopya. At maaari kang magtanggal ng isang bagay doon at sabihin ang RESET, at tanggalin ito muli. Maaari kang mag-eksperimento dito sa ganitong paraan. Nakikita ko ang hinaharap sa bagay na ito. At ginagawa na namin ito.
Ano ang mga diskarte sa paghahati? Nakikita ko ang 3 iba't ibang diskarte sa paghati na ginagamit ng mga developer sa pack.
Ang una ay napaka-simple. Mayroon kaming numerical ID. At hatiin natin ito sa iba't ibang mga agwat at gawin iyon. Ang downside ay malinaw. Sa unang segment, maaari tayong magkaroon ng 100 linya ng totoong basura, sa pangalawang 5 linya o hindi man, o lahat ng 1 linya ay magiging basura. Napakalubak sa trabaho, ngunit madaling masira. Kinuha nila ang maximum ID at binasag ito. Ito ay isang walang muwang na diskarte.
Ang pangalawang diskarte ay isang balanseng diskarte. Ito ay ginagamit sa Gitlab. Kinuha namin at ini-scan ang table. Natagpuan namin ang mga hangganan ng mga ID pack upang ang bawat pakete ay naglalaman ng eksaktong 10 mga tala. At inipit nila ako sa ilang uri ng pila. At nagproseso pa kami. Magagawa mo ito sa ilang mga thread.
Sa unang diskarte, sa pamamagitan ng paraan, maaari mo ring gawin ito sa ilang mga thread. Ito ay hindi mahirap.
Ngunit mayroong isang mas cool at mas pinakamainam na diskarte. Ito ang ikatlong diskarte. At kung maaari, mas mahusay na piliin ito. Ginagawa namin ito batay sa isang espesyal na index. Sa kasong ito, malamang na ito ay isang index batay sa aming kondisyon ng basura at ID. Isasama natin ang ID para ito ay index only scan para hindi tayo mapunta sa heap.
Karaniwan, ang pag-scan ng index lamang ay mas mabilis kaysa sa pag-scan ng index.
At mabilis naming mahanap ang aming mga ID na gusto naming tanggalin. Pinipili namin ang BATCH_SIZE nang maaga. At hindi lamang namin natatanggap ang mga ito, tinatanggap namin ang mga ito sa isang espesyal na paraan at agad na ayusin ang mga ito. Ngunit ini-lock namin ang mga ito sa paraang kung naka-lock na sila, hindi namin sila iki-lock, ngunit magpatuloy at kunin ang mga susunod. Ito ay para sa update skip lock. Ang sobrang tampok na Postgres na ito ay nagpapahintulot sa amin na magtrabaho sa maraming mga thread kung gusto namin. Malamang sa isang thread. At pagkatapos ay mayroong CTE - ito ay isang kahilingan. At mayroon kaming totoong pagtatanggal na nangyayari sa ikalawang palapag ng CTE na ito - returning *. Maaari mong ibalik ang id, ngunit ito ay mas mahusay *, kung mayroon kang maliit na data sa bawat linya.
Bakit kailangan natin ang mga ito? Kailangan namin ito para makapag-ulat. Sa totoo lang, napakaraming linya ang tinanggal namin. At ang aming mga hangganan sa pamamagitan ng ID o nilikha_at ay ganito. Maaari mong gawin ang min, max. May magagawa pa. Marami kang pwedeng pagsiksikan dito. At ito ay napaka-maginhawa para sa pagsubaybay.
May isa pang tala tungkol sa index. Kung magpasya kami na kailangan namin ng isang espesyal na index para sa partikular na gawain, pagkatapos ay kailangan naming tiyakin na ito ay hindi palayawin heap lamang tuples update. Ibig sabihin, ang Postgres ay may mga ganoong istatistika. Maaari itong matingnan sa pg_stat_user_tables para sa iyong talahanayan. Makikita mo kung ginagamit ang mga mainit na update o hindi.
May mga sitwasyon kung kailan ang iyong bagong index ay maaaring putulin lamang ang mga ito. At lahat ng iba pang mga update na tumatakbo na ay bumagal. Hindi lamang dahil lumitaw ang index (bawat index ay nagpapabagal ng kaunti, ngunit kaunti lamang), ngunit dito ay magugulo pa rin ang mga bagay-bagay. At imposibleng gumawa ng espesyal na pag-optimize para sa talahanayang ito. Nangyayari ito minsan. Ito ay isang subtlety na natatandaan ng ilang tao. At madaling makatapak sa rake na ito. Minsan nangyayari na kailangan mong makahanap ng isang diskarte mula sa kabilang panig at gawin pa rin nang wala ang bagong index na ito, o gumawa ng isa pang index, o gumawa ng iba pa, halimbawa, maaari mong gamitin ang pangalawang paraan.
Ngunit ito ang pinakamainam na diskarte, kung paano hatiin ito sa mga batch at shoot sa mga batch na may isang kahilingan, tanggalin nang paunti-unti, atbp.
Mahabang transaksyon -
Na-block ang autovacuum
Isyu sa pagharang
Malaki ang pagkakamali #5. Si Nikolay mula sa Okmeter ay nagsalita tungkol sa pagsubaybay ng Postgres. Sa kasamaang palad, walang perpektong pagsubaybay sa Postgres. Ang iba ay mas malapit, ang iba ay mas malayo. Ang Okmeter ay malapit na para maging perpekto, ngunit maraming kulang at kailangang idagdag. Kailangan mong maging handa para dito.
Halimbawa, mas mahusay na subaybayan ang mga patay na tuple. Kung marami kang patay na bagay sa iyong mesa, may mali. Mas mabuting mag-react ngayon, kung hindi, maaaring magkaroon ng degradasyon doon, at maaari tayong mahiga. Nangyayari ito.
Kung mayroong isang malaking IO, pagkatapos ay malinaw na ito ay hindi mabuti.
Mahabang transaction din. Hindi dapat pahintulutan ang mahabang transaksyon sa OLTP. At narito ang isang link sa snippet, na nagbibigay-daan sa iyong kunin ang snippet na ito at gumawa na ng ilang pagsubaybay sa mahahabang transaksyon.
Bakit masama ang mahabang transaksyon? Dahil ang lahat ng mga kandado ay ilalabas lamang sa dulo. At ikinukulong namin ang lahat. Dagdag pa, hinaharangan namin ang autovacuum para sa lahat ng mga talahanayan. Ito ay hindi mabuti sa lahat. Kahit na naka-enable ang hot standby sa replica, masama pa rin ito. Sa pangkalahatan, mas mainam na iwasan ang mahabang transaksyon kahit saan.
Kung marami tayong table na hindi na-vacuum, kailangan nating magkaroon ng alerto. Posible ang ganitong sitwasyon dito. Maaari naming hindi direktang maapektuhan ang pagpapatakbo ng autovacuum. Ito ay isang snippet mula sa Avito, na medyo pinagbuti ko. At ito ay naging isang kawili-wiling tool upang makita kung ano ang mayroon kami sa autovacuum. Halimbawa, may ilang mesa na naghihintay doon at hindi sila maghihintay ng kanilang turn. Kailangan mo ring ilagay ito sa pagsubaybay at magkaroon ng alerto.
At naglalabas ng mga bloke. Kagubatan ng nakaharang na mga puno. Gusto kong kumuha ng isang bagay mula sa isang tao at pagbutihin ito. Dito ay kumuha ako ng isang cool na recursive CTE mula sa Data Egret, na nagpapakita ng kagubatan ng mga nakakulong na puno. Ito ay isang magandang bagay para sa mga diagnostic. At ang pagsubaybay ay maaari ding itayo sa batayan nito. Ngunit ito ay dapat gawin nang maingat. Kailangan mong gumawa ng isang maliit na statement_timeout para sa iyong sarili. At ang lock_timeout ay kanais-nais.
Minsan ang lahat ng mga error na ito ay nangyayari nang magkasama.
Sa aking palagay, ang pinakamahalagang pagkakamali dito ay ang organisasyon. Ito ay pang-organisasyon, dahil ang teknolohiya ay hindi gumagana. Ito ang numero 2 - nag-check sila sa maling lugar.
Hindi kami nag-check doon dahil wala kaming production clone na madaling i-check. Maaaring walang access ang developer sa produksyon.
At nag-check kami sa maling lugar. Kung doon sila nag-check, kami na mismo ang nakakita. Makikita ng developer ang lahat ng ito kahit na walang DBA, kung susuriin niya ito sa isang magandang kapaligiran, kung saan mayroong parehong dami ng data at magkaparehong kaayusan. Nakita niya sana ang lahat ng pagkasira na ito at mapapahiya siya.
Higit pa tungkol sa vacuum ng kotse. Pagkatapos naming gumawa ng malawakang paglilinis ng ilang milyong linya, kailangan pa rin naming gumawa ng REPACK. Ito ay lalong mahalaga para sa mga index. Masama ang pakiramdam nila pagkatapos naming linisin lahat doon.
At kung gusto mong ibalik ang pang-araw-araw na gawain ng paghuhubad, iminumungkahi kong gawin ito nang mas madalas, ngunit mas maliit. Maaari itong isang beses bawat minuto o mas madalas nang kaunti. At kailangan nating subaybayan ang dalawang bagay: na ang bagay na ito ay walang mga pagkakamali at hindi ito nahuhuli. Ang trick na ipinakita ko ay magbibigay-daan sa iyo upang malutas ito.
Ang ginagawa namin ay open source. Ito ay nai-post sa GitLab. At ginagawa namin ito para masuri ng mga tao kahit walang DBA. Gumagawa kami ng database lab, ibig sabihin, tinatawag namin ang base component kung saan kasalukuyang nagtatrabaho si Joe. At maaari kang kumuha ng kopya ng produksyon. Ngayon ay mayroong pagpapatupad ng Joe para sa slack, maaari mong sabihin doon: "ipaliwanag ang ganoon at ganoong kahilingan" at agad na makuha ang resulta para sa iyong kopya ng database. Maaari mo ring gawin ang DELETE doon, at walang makakapansin.
Sabihin nating mayroon kang 10 terabytes, gumagawa kami ng database lab na 10 terabytes din. At 10 developer ay maaaring gumana nang sabay-sabay sa sabay-sabay na 10 terabyte database. Magagawa ng lahat ang gusto nila. Maaaring tanggalin, i-drop, atbp. Ito ay hindi kapani-paniwala. Bukas na natin ito pag-usapan.
Ito ay tinatawag na thin provisioning. Ito ay banayad na paglalaan. Ito ay isang uri ng pantasya na lubos na nag-aalis ng mga pagkaantala sa pag-unlad at pagsubok at ginagawang mas magandang lugar ang mundo sa bagay na ito. Iyon ay, pinapayagan ka lamang nitong maiwasan ang mga problema sa mga operasyong masa.
Halimbawa: 5 terabyte database, nakakakuha ng kopya nang wala pang 30 segundo. At hindi rin ito nakadepende sa laki, ibig sabihin, hindi mahalaga kung gaano karaming terabytes.
Ngayon ay maaari kang pumunta sa at humukay sa aming mga gamit. Maaari kang magparehistro at makita kung ano ang naroroon. Maaari mong i-install ang bot na ito para sa iyong sarili. Ito'y LIBRE. Sumulat.
mga katanungan
Kadalasan, sa totoong mga sitwasyon, lumalabas na ang data na dapat manatili sa talahanayan ay mas mababa kaysa sa kung ano ang kailangang tanggalin. Iyon ay, sa ganitong sitwasyon ay madalas na mas madaling ipatupad ang diskarteng ito, kapag mas madaling lumikha ng isang bagong bagay, kopyahin lamang ang kinakailangang data doon at i-transcribe ang lumang talahanayan. Malinaw na kailangan mo ng diskarte sa software para sa sandaling ito habang lumilipat ka. Paano ito diskarte?
Ito ay isang napakahusay na diskarte at isang napakahusay na gawain. Ito ay halos kapareho sa kung ano ang ginagawa ng pg_repack, ito ay halos kapareho sa kung ano ang kailangan mong gawin kapag ginawa mo itong 4 bytes ng mga tao. Ginawa ito ng maraming mga framework ilang taon na ang nakalilipas, at ang mga plate ay lumaki na, at kailangan nilang i-convert sa 8 bytes.
Ang gawaing ito ay medyo mahirap. Nagawa natin. At kailangan mong maging maingat. May mga kandado, atbp. Ngunit tapos na. Iyon ay, ang karaniwang diskarte ay ang paggamit ng pg_repack. Ibinalita mo ang gayong tanda. At bago mo simulan ang pagpuno nito ng data ng snapshot, idedeklara mo rin ang isang talahanayan na sumusubaybay sa lahat ng mga pagbabago. Mayroong isang trick doon na maaaring hindi mo masubaybayan ang ilang mga pagbabago. May mga subtleties. At pagkatapos ay lumipat ka, inilunsad ang mga pagbabago. Magkakaroon ng maikling pag-pause kapag ikinulong namin ang lahat, ngunit sa pangkalahatan ito ay ginagawa.
Kung titingnan mo ang pg_repack sa GitHub, pagkatapos ay kapag nagkaroon ng gawain na i-convert ang ID mula int 4 hanggang int 8, pagkatapos ay nagkaroon ng ideya na gamitin ang pg_repack mismo. Posible rin ito, ngunit ito ay medyo isang paraan ng hacker, ngunit gagana rin ito para dito. Maaari kang makialam sa trigger na gumagamit ng pg_repack at sabihin doon: "Hindi namin kailangan ang data na ito," ibig sabihin, inililipat lang namin ang kailangan namin. At pagkatapos ay lumipat lang siya at iyon na.
Sa diskarteng ito, nakakakuha din kami ng pangalawang kopya ng talahanayan, kung saan ang data ay nai-index na at inilatag nang maayos na may magagandang mga index.
Bloat hindi, ito ay isang magandang diskarte. Ngunit alam ko na may mga pagtatangka na bumuo ng automation para dito, ibig sabihin, gumawa ng isang unibersal na solusyon. Maaari kong ipakilala sa iyo ang automation na ito. Nakasulat ito sa Python, magandang bagay.
Medyo malayo lang ako sa MySQL world, kaya naparito ako para makinig. At ginagamit namin ang diskarteng ito.
Ngunit ito ay kung mayroon tayong 90%. Kung mayroon tayong 5%, hindi masyadong magandang gamitin ito.
Salamat sa ulat! Kung walang mapagkukunan upang makagawa ng isang buong kopya ng prod, mayroon bang anumang algorithm o formula upang makalkula ang pagkarga o laki?
Magandang tanong. Sa ngayon ay nakakahanap kami ng mga multi-terabyte na database. Kahit na ang hardware doon ay hindi pareho, halimbawa, mas kaunting memorya, mas kaunting processor at ang mga disk ay hindi eksaktong pareho, ginagawa pa rin namin ito. Kung talagang wala kahit saan, kailangan mong isipin ito. Hayaan mong isipin ko ito hanggang bukas, dumating ka, mag-usap tayo, magandang tanong ito.
Salamat sa ulat! Una mong sinimulan ang pakikipag-usap tungkol sa katotohanan na mayroong isang cool na Postgres, na may ganoon at ganoong mga limitasyon, ngunit ito ay umuunlad. At lahat ito ay isang saklay sa pangkalahatan. Hindi ba't ang lahat ng ito ay sumasalungat sa pag-unlad ng Postgres mismo, kung saan lilitaw ang ilang uri ng DELETE deferent o iba pang bagay na dapat panatilihin sa mababang antas kung ano ang sinusubukan nating pagtakpan dito gamit ang ilan sa sarili nating kakaibang paraan?
Kung sa SQL sinabi namin na tanggalin o i-update ang maraming mga tala sa isang transaksyon, kung gayon paano ito maipamahagi ng Postgres? Kami ay pisikal na limitado sa mga operasyon. Gagawin pa natin ito sa mahabang panahon. At magla-lock kami sa oras na ito, atbp.
Ganun din ang ginawa nila sa mga index.
Maaari kong ipagpalagay na ang parehong pag-tune ng checkpoint ay maaaring awtomatiko. Balang araw maaring mangyari ito. Ngunit pagkatapos ay hindi ko talaga maintindihan ang tanong.
Ang tanong ay: mayroon bang development vector na papunta doon, at parallel sa iyo dito? Yung. Hindi pa ba nila ito iniisip?
Napag-usapan ko ang mga prinsipyo na magagamit ngayon. May isa pang bot , sa pamamagitan nito ay makakagawa ka ng automated checkpoint tuning. Mangyayari ba ito sa Postgres? Hindi ko alam, hindi pa ito napag-uusapan. Malayo pa tayo dito. Ngunit may mga siyentipiko na gumagawa ng mga bagong sistema. At itinulak nila tayo sa mga awtomatikong pag-index. May mga developments. Halimbawa, maaari mong tingnan ang auto tuning. Awtomatikong pinipili nito ang mga parameter. Ngunit hindi pa siya gagawa ng checkpoint tuning para sa iyo. Iyon ay, pipili ito para sa pagganap, shell buffer, atbp.
At para sa pag-tune ng checkpoint, magagawa mo ang sumusunod na bagay: kung mayroon kang isang libong kumpol at iba't ibang piraso ng hardware, iba't ibang virtual machine sa cloud, maaari mong gamitin ang aming bot gumawa ng automation. At ang max_wal_size ay awtomatikong pipiliin ayon sa iyong mga target na setting. Ngunit sa ngayon ay hindi pa ito malapit sa pagiging kernel, sa kasamaang-palad.
Magandang hapon Nagsalita ka tungkol sa mga panganib ng mahabang transaksyon. Sinabi mo na ang autovacuum ay naharang kung sakaling matanggal. Paano pa ito nakakasama sa atin? Dahil mas pinag-uusapan natin ang tungkol sa pagpapalaya ng espasyo at paggamit nito. Ano pa ba ang kailangan nating mawala?
Maaaring hindi ang Autovacuum ang pinakamalaking problema dito. At ang katotohanan na ang isang mahabang transaksyon ay maaaring harangan ang iba pang mga transaksyon ay isang mas mapanganib na posibilidad. Maaaring magkita siya o hindi. Kung magkakilala siya, kung gayon ang mga bagay ay maaaring maging napakasama. At sa autovacuum ito ay isang problema din. Mayroong dalawang problema sa mahabang transaksyon sa OLTP: lock at autovacuum. At kung mayroon kang mainit na standby na feedback na pinagana sa replica, pagkatapos ay darating din ang autovacuum blocking sa master, darating ito mula sa replica. Ngunit hindi bababa sa walang mga kandado doon. At dito magkakaroon ng mga kandado. Pinag-uusapan natin ang tungkol sa mga pagbabago sa data, kaya ang mga kandado ay isang mahalagang punto dito. At kung ito ay magpapatuloy sa loob ng mahabang panahon, parami nang parami ang mga transaksyon ang naharang. Maaari nilang bitag ang iba. At lumitaw ang mga puno ng kandado. Nagbigay ako ng link sa snippet. At ang problemang ito ay mabilis na nagiging mas kapansin-pansin kaysa sa problema sa autovacuum, na maaari lamang maipon.
Salamat sa ulat! Sinimulan mo ang iyong ulat sa pagsasabing mali ang iyong pagsubok. Ipinagpatuloy namin ang aming ideya na kailangan naming kunin ang parehong kagamitan, na ang base ay eksaktong pareho. Sabihin nating binigyan namin ng base ang developer. At sinunod niya ang hiling. At mukhang maayos naman ang lagay niya. Ngunit hindi ito sumusuri sa live, ngunit sa live, halimbawa, ang aming load ay 60-70%. At kahit na gamitin natin ang pag-tune na ito, hindi ito nagiging maganda
Ang pagkakaroon ng eksperto sa iyong team at paggamit ng mga eksperto sa DBA na maaaring mahulaan kung ano ang mangyayari sa ilalim ng totoong pag-load sa background ay mahalaga. Kapag kami ay nagmaneho sa pamamagitan ng aming mga purong pagbabago, nakikita namin ang larawan. Ngunit ang isang mas advanced na diskarte ay kapag ginawa namin ang parehong bagay muli, ngunit may isang kunwa pagkarga ng produksyon. Ito ay ganap na cool. Kailangan pa nating umunlad hanggang sa puntong ito. Mature na. Panay ang tingin namin sa kung ano ang meron kami at tiningnan din kung may sapat kaming resources. Iyan ay isang magandang katanungan.
Kapag gumagawa na tayo ng basura piliin at mayroon tayong, halimbawa, isang tinanggal na bandila
Ito ang awtomatikong ginagawa ng autovacuum sa Postgres.
Oh, ginagawa niya iyon?
Ang Autovacuum ay ang tagakolekta ng basura.
Salamat sa iyo!
Salamat sa ulat! Mayroon bang pagpipilian upang agad na magdisenyo ng isang database na may partitioning upang ang lahat ng basura ay maalis mula sa pangunahing talahanayan sa isang lugar sa gilid?
Syempre meron.
Maaari ba nating protektahan ang ating sarili kung nai-lock natin ang isang mesa na hindi dapat gamitin?
Syempre meron. Ngunit ito ay tanong ng manok at itlog. Kung alam nating lahat kung ano ang mangyayari sa hinaharap, kung gayon, siyempre, gagawin natin ang lahat ng mahusay. Ngunit nagbabago ang negosyo, lumalabas ang mga bagong column at bagong kahilingan. At pagkatapos - oops, gusto naming tanggalin ito. Ngunit ito ay isang perpektong sitwasyon; nangyayari ito sa buhay, ngunit hindi palaging. Ngunit sa pangkalahatan ito ay isang magandang ideya. Putulin lang at iyon na.
Pinagmulan: www.habr.com