Usahay sa layo nga umaabot, ang awtomatik nga pagtangtang sa wala kinahanglana nga datos mahimong usa sa hinungdanon nga buluhaton sa DBMS [1]. Sa kasamtangan, kita mismo kinahanglan nga mag-amping sa pagtangtang o pagbalhin sa wala kinahanglana nga datos sa dili kaayo mahal nga mga sistema sa pagtipig. Ingnon ta nga nakahukom ka sa pagtangtang sa pipila ka milyon nga mga linya. Usa ka yano nga buluhaton, labi na kung nahibal-an ang kahimtang ug adunay usa ka angay nga indeks. "DELETE FROM table1 WHERE col1 = : value" - unsa may mas simple, di ba?
Video:
-
Naa ko sa Highload program committee sukad sa unang tuig, ie sukad sa 2007.
-
Ug kauban nako ang Postgres sukad 2005. Gigamit kini sa daghang mga proyekto.
-
Grupo uban sa RuPostges usab sukad sa 2007.
-
Mitubo kami ngadto sa 2100+ ka mga partisipante sa Meetup. Ikaduha kini sa kalibutan sunod sa New York, nga naapsan sa San Francisco sa dugay nga panahon.
-
Nagpuyo ko sa California sa daghang tuig. Mas daghan ang akong giatubang sa mga kompanya sa Amerika, lakip ang mga dagko. Sila mga aktibong tiggamit sa Postgres. Ug adunay tanan nga mga matang sa makapaikag nga mga butang.
mao ang akong kompanya. Anaa kami sa negosyo sa pag-automate sa mga buluhaton nga nagwagtang sa mga paghinay sa pag-uswag.
Kung adunay imong gibuhat, unya usahay adunay usa ka matang sa mga plug sa palibot sa Postgres. Ingnon ta nga kinahanglan nimong hulaton ang admin nga magbutang ug test stand para nimo, o kinahanglan nimong hulaton ang DBA nga motubag kanimo. Ug nakit-an namon ang ingon nga mga bottleneck sa proseso sa pag-uswag, pagsulay ug pagdumala ug pagsulay sa pagwagtang niini sa tabang sa automation ug bag-ong mga pamaagi.
Bag-o lang ko sa VLDB sa Los Angeles. Kini ang pinakadako nga komperensya sa mga database. Ug adunay usa ka taho nga sa umaabot ang DBMS dili lamang magtipig, apan awtomatiko usab nga mapapas ang datos. Kini usa ka bag-ong hilisgutan.
Nagkadaghan ang datos sa kalibutan sa mga zettabytes - kana ang 1 petabytes. Ug karon gibanabana na nga kita adunay labaw pa sa 000 ka zettabytes nga datos nga gitipigan sa kalibutan. Ug nagkadaghan sila.
Ug unsay buhaton niini? Dayag nga kini kinahanglan nga tangtangon. Ania ang usa ka link sa kini nga makapaikag nga taho. Apan hangtod karon wala pa kini mapatuman sa DBMS.
Kadtong makaihap sa kuwarta gusto ug duha ka butang. Gusto nila nga atong tangtangon, mao nga sa teknikal nga paagi mahimo naton kini.
Ang sunod nakong isulti mao ang pipila ka abstract nga sitwasyon nga naglakip sa usa ka hugpong sa tinuod nga mga sitwasyon, i.e. usa ka matang sa paghugpong sa aktuwal nga nahitabo kanako ug sa naglibot nga mga database sa daghang mga higayon, daghang mga tuig. Ang mga rake bisan asa ug ang tanan nagtunob niini sa tanang panahon.
Ingnon ta nga kita adunay usa ka base o daghang mga base nga nagtubo. Ug ang pipila ka mga rekord klaro nga basura. Pananglitan, ang tiggamit nagsugod sa pagbuhat sa usa ka butang didto, apan wala kini nahuman. Ug pagkahuman sa pila ka panahon nahibal-an namon nga kini nga wala mahuman dili na matipigan. Sa ato pa, gusto namong limpyohan ang pipila ka mga butang nga basura aron makadaginot sa lugar, mapaayo ang performance, ug uban pa.
Sa kinatibuk-an, ang tahas mao ang pag-automate sa pagtangtang sa piho nga mga butang, piho nga mga linya sa pipila ka lamesa.
Ug kami adunay ingon nga hangyo, nga atong hisgutan karon, nga mao, mahitungod sa pagtangtang sa basura.
Gihangyo namo ang usa ka eksperyensiyadong developer sa pagbuhat niini. Gikuha niya kini nga hangyo, gisusi kini sa iyang kaugalingon - ang tanan nagtrabaho. Gisulayan sa dula - maayo ang tanan. Gilunsad - ang tanan nagtrabaho. Kausa sa usa ka adlaw among gipadagan kini - maayo ang tanan.
Ang database motubo ug motubo. Ang adlaw-adlaw nga DELETE nagsugod sa pagtrabaho nga mas hinay.
Unya nahibal-an namon nga kami karon adunay usa ka kompanya sa pamaligya ug ang trapiko mahimong daghang beses nga labi ka dako, mao nga nakahukom kami nga temporaryo nga ihunong ang wala kinahanglana nga mga butang. Ug makalimot sa pagbalik.
Paglabay sa pipila ka bulan nakahinumdom sila. Ug kana nga developer mihunong o busy sa laing butang, misugo sa lain nga ibalik kini.
Gisusi niya ang dev, sa dula - OK ra ang tanan. Siyempre, kinahanglan nimo nga limpyohan ang natipon. Gisusi niya ang tanan nga nagtrabaho.
Unsay sunod nga mahitabo? Unya ang tanan nahulog alang kanato. Nagtulo kini aron sa usa ka punto ang tanan mahulog. Nakurat ang tanan, walay nakasabot sa nahitabo. Ug unya kini nahimo nga ang butang naa sa kini nga DELETE.
Naay nahitabo? Ania ang usa ka lista kung unsa ang mahimo nga sayup. Hain niini ang labing importante?
-
Pananglitan, wala'y pagrepaso, i.e. ang eksperto sa DBA wala magtan-aw niini. Makit-an dayon niya ang problema sa usa ka eksperyensiyado nga mata, ug labut pa, siya adunay access sa prod, diin daghang milyon nga linya ang natipon.
-
Tingali ilang gisusi ang usa ka sayup.
-
Tingali ang hardware wala na sa panahon ug kinahanglan nimo nga i-upgrade kini nga base.
-
O adunay sayup sa database mismo, ug kinahanglan naton nga mobalhin gikan sa Postgres ngadto sa MySQL.
-
O tingali adunay sayup sa operasyon.
-
Tingali adunay pipila ka mga sayup sa organisasyon sa trabaho ug kinahanglan nimo nga sunugon ang usa ka tawo ug mag-hire sa labing kaayo nga mga tawo?
Walay DBA check. Kung adunay DBA, makita niya kini nga daghang milyon nga mga linya ug bisan kung wala’y bisan unsang mga eksperimento moingon: "Wala nila kana buhaton." Pananglit kung kini nga code naa sa GitLab, GitHub ug adunay proseso sa pagrepaso sa code ug dili ingon nga kung wala ang pagtugot sa DBA kini nga operasyon mahitabo sa prod, nan klaro nga ang DBA moingon: "Dili kini mahimo. ”
Ug siya moingon nga ikaw adunay mga problema sa disk IO ug ang tanan nga mga proseso mabuang, mahimo nga adunay mga kandado, ug usab imong babagan ang autovacuum sulod sa usa ka hugpong sa mga minuto, mao nga kini dili maayo.
Ang ikaduha nga sayop - ilang gisusi sa sayop nga dapit. Nakita namon pagkahuman sa kamatuoran nga daghang junk data ang natipon sa prod, apan ang developer wala’y natipon nga datos sa kini nga database, ug wala’y usa nga naghimo niini nga basura sa panahon sa dula. Tungod niini, adunay 1 ka linya nga dali nga nagtrabaho.
Nakasabut kami nga ang among mga pagsulay huyang, kana, ang proseso nga gitukod wala makakuha mga problema. Usa ka igong eksperimento sa DB wala gihimo.
Ang usa ka sulundon nga eksperimento mas maayo nga himuon sa parehas nga kagamitan. Dili kanunay posible nga buhaton kini sa parehas nga kagamitan, apan hinungdanon kaayo nga kini usa ka tibuuk nga kopya sa database. Kini ang akong gisangyaw sa daghang tuig na karon. Ug usa ka tuig na ang milabay ako naghisgot bahin niini, mahimo nimong tan-awon ang tanan sa YouTube.
Basin dili maayo ang atong kagamitan? Kung imong tan-awon, unya ang latency milukso. Nakita namon nga 100% ang paggamit. Siyempre, kung kini mga modernong NVMe drive, nan kini tingali labi ka dali alang kanamo. Ug tingali dili kita mohunong gikan niini.
Kung ikaw adunay mga panganod, nan ang pag-upgrade dali nga mahimo didto. Gipataas ang bag-ong mga replika sa bag-ong hardware. pagbalhin. Ug maayo ang tanan. Sayon ra.
Posible ba nga mahikap ang gagmay nga mga disk? Ug dinhi, sa tabang lang sa DBA, nag-dive kami sa usa ka hilisgutan nga gitawag nga checkpoint tuning. Mogawas nga wala miy checkpoint tuning.
Unsa ang checkpoint? Anaa kini sa bisan unsang DBMS. Kung adunay ka data sa memorya nga nagbag-o, dili dayon kini isulat sa disk. Ang impormasyon nga giusab sa datos unang gisulat sa write-ahead log. Ug sa pipila ka mga punto, ang DBMS nakahukom nga panahon na sa paglabay sa tinuod nga mga panid ngadto sa disk, aron nga kon kita adunay kapakyasan, kita makahimo sa dili kaayo REDO. Murag dulaan. Kung mapatay mi, sugdan namo ang duwa gikan sa kataposang checkpoint. Ug ang tanan nga DBMS nagpatuman niini.
Ang mga setting sa Postgres naatras. Gidisenyo kini alang sa 10-15 ka tuig nga gidaghanon sa datos ug mga transaksyon. Ug ang checkpoint dili eksepsiyon.
Ania ang impormasyon gikan sa among Postgres check-up report, i.e. automatic health check. Ug ania ang pipila ka database sa daghang terabytes. Ug makita nga maayo nga gipugos ang mga checkpoint sa hapit 90% sa mga kaso.
Unsay buot ipasabot niini? Adunay duha ka mga setting didto. Ang checkpoint mahimong moabot pinaagi sa timeout, pananglitan, sa 10 minutos. O mahimong moabut kung daghang datos ang napuno.
Ug pinaagi sa default max_wal_saze gibutang sa 1 gigabyte. Sa tinuud, kini mahitabo gyud sa Postgres pagkahuman sa 300-400 megabytes. Daghan kaayong datos ang imong nausab ug mahitabo ang imong checkpoint.
Ug kung wala’y nag-tune niini, ug ang serbisyo mitubo, ug ang kompanya nakakuha og daghang salapi, kini adunay daghang mga transaksyon, unya ang checkpoint moabut kausa sa usa ka minuto, usahay matag 30 segundos, ug usahay magsapaw pa. Kini dili maayo.
Ug kinahanglan natong sigurohon nga dili kaayo kanunay kini moabut. Sa ato pa, mahimo natong ipataas ang max_wal_size. Ug kini moabut dili kaayo kanunay.
Apan nakahimo kami usa ka tibuuk nga pamaagi kung giunsa kini buhaton nga mas husto, nga mao, kung giunsa paghimo ang usa ka desisyon bahin sa pagpili sa mga setting, tin-aw nga gibase sa piho nga datos.
Tungod niini, naghimo kami og duha ka serye sa mga eksperimento sa mga database.
Ang unang serye - giusab namo ang max_wal_size. Ug naghimo kami usa ka dako nga operasyon. Una, buhaton nato kini sa default setting nga 1 gigabyte. Ug naghimo kami usa ka dako nga DELETE sa daghang milyon nga linya.
Makita nimo kung unsa ka lisud alang kanamo. Nakita namon nga ang disk IO daotan kaayo. Atong tan-awon kon pila ka mga WAL ang atong namugna, tungod kay kini importante kaayo. Tan-awon nato kung kapila nahitabo ang checkpoint. Ug atong nakita nga kini dili maayo.
Sunod among dugangan ang max_wal_size. Atong balikon. Kami nagdugang, among gisubli. Ug sa daghang mga higayon. Sa prinsipyo, maayo ang 10 puntos, diin 1, 2, 4, 8 gigabytes. Ug atong tan-awon ang kinaiya sa usa ka partikular nga sistema. Klaro nga dinhi ang kagamitan kinahanglan nga sama sa prod. Kinahanglan nga adunay parehas nga mga disk, parehas nga kantidad sa memorya, ug parehas nga mga setting sa Postgres.
Ug niining paagiha atong ibaylo ang atong sistema, ug nahibal-an nato kung unsaon paggawi sa DBMS kung adunay dili maayo nga mass DELETE, kung unsaon kini pag-checkpoint.
Ang checkpoint sa Russian kay mga checkpoint.
Panig-ingnan: DELETE ang pipila ka milyon nga mga laray pinaagi sa indeks, ang mga laray "pagkatag" sa mga panid.
Ania ang usa ka pananglitan. Kini usa ka sukaranan. Ug sa default setting nga 1 gigabyte para sa max_wal_size, klaro kaayo nga ang among mga disk moadto sa estante para sa pagrekord. Kini nga hulagway maoy usa ka tipikal nga simtoma sa usa ka masakiton kaayo nga pasyente, sa ato pa, dili maayo ang iyang gibati. Ug adunay usa ka operasyon, adunay usa ka DELETE sa daghang milyon nga linya.
Kung tugotan ang maong operasyon sa prod, mohigda na lang ta, kay klaro man nga usa ka DELETE ang mopatay nato sa estante.
Dugang pa, diin ang 16 gigabytes, klaro nga nawala na ang mga ngipon. Maayo na ang ngipon, sa ato pa, nanuktok kami sa kisame, apan dili kaayo daotan. Adunay pipila ka kagawasan didto. Sa tuo mao ang rekord. Ug ang gidaghanon sa mga operasyon - ang ikaduha nga graph. Ug klaro nga nakaginhawa na kita og gamay kung 16 gigabytes.
Ug diin ang 64 gigabytes makita nga kini nahimong hingpit nga mas maayo. Gipahayag na ang mga ngipon, adunay daghang mga oportunidad nga mabuhi sa ubang mga operasyon ug maghimo usa ka butang sa disk.
Ngano?
Mag-dive ko og gamay sa mga detalye, apan kini nga hilisgutan, kung unsaon pagpahigayon sa checkpoint tuning, mahimong moresulta sa usa ka tibuok nga report, mao nga dili ako mag-load og daghan, apan akong i-outline og gamay kung unsa ang mga kalisdanan.
Kung ang checkpoint kanunay nga mahitabo, ug among gi-update ang among mga linya nga dili sunud-sunod, apan pangitaon pinaagi sa indeks, nga maayo, tungod kay dili namon mapapas ang tibuuk nga lamesa, mahimo’g mahitabo nga sa una among gihikap ang una nga panid, dayon ang ika-libo, ug unya mibalik sa una. Ug kung tali sa kini nga mga pagbisita sa una nga panid, gitipigan na kini sa checkpoint sa disk, nan kini i-save kini pag-usab, tungod kay nahugawan namon kini sa ikaduha nga higayon.
Ug pugson namo ang checkpoint aron maluwas kini sa makadaghang higayon. Naunsa man nga adunay mga redundant nga operasyon alang kaniya.
Apan dili lang kana. Ang mga panid 8 kilobytes sa Postgres ug 4 kilobytes sa Linux. Ug adunay full_page_writes setting. Gipaandar kini pinaagi sa default. Ug kini husto, tungod kay kung atong i-off kini, adunay peligro nga katunga ra sa panid ang maluwas kung kini maguba.
Ang kinaiya sa pagsulat ngadto sa WAL sa forward log mao nga kung aduna kitay checkpoint ug usbon nato ang panid sa unang higayon, ang tibuok panid, i.e., tanan nga 8 ka kilobytes, makasulod sa forward log, bisan tuod giusab lang nato ang linya, nga may gibug-aton nga 100 bytes . Ug kinahanglan natong isulat ang tibuok panid.
Sa sunod nga mga pagbag-o, adunay usa lamang ka piho nga tuple, apan sa unang higayon atong isulat ang tanan.
Ug, sumala niana, kung ang checkpoint nahitabo pag-usab, nan kinahanglan natong sugdan pag-usab ang tanan gikan sa sinugdan ug iduso ang tibuok panid. Uban sa kanunay nga mga checkpoint, kung maglakaw kami sa parehas nga mga panid, ang full_page_writes = on mahimong labaw pa sa mahimo, i.e. makamugna kami og daghang WAL. Daghan pa ang gipadala sa mga replika, sa archive, sa disk.
Ug, sumala niana, kami adunay duha ka redundancies.
Kung atong dugangan ang max_wal_size, mogawas nga gipasayon nato ang checkpoint ug wal writer. Ug maayo kana.
Atong ibutang sa usa ka terabyte ug mabuhi uban niini. Unsa ang daotan niini? Grabe ni, kay in case mapakyas, musaka ta ug mga oras, kay dugay na ang checkpoint ug daghan na ang nausab. Ug kinahanglan natong buhaton kining tanan nga REDO. Ug mao nga gihimo namon ang ikaduha nga serye sa mga eksperimento.
Naghimo kami usa ka operasyon ug tan-awon kung hapit na makompleto ang checkpoint, gipatay namon ang -9 nga mga Postgres nga tinuyo.
Ug pagkahuman ato sugdan kini pag-usab, ug tan-awon kung unsa kadugay kini mobangon sa kini nga kagamitan, i.e. kung unsa kadaghan ang PAG-REDO sa kini nga dili maayo nga kahimtang.
Kaduha nako mamatikdan nga dili maayo ang sitwasyon. Una, nahagsa mi sa wala pa mahuman ang checkpoint, mao nga daghan ang mawala kanamo. Ug ang ikaduha, kami adunay usa ka dako nga operasyon. Ug kung ang mga checkpoint anaa sa timeout, nan, lagmit, mas gamay nga WAL ang mamugna sukad sa katapusang checkpoint. Sa ato pa, double loser kini.
Gisukod namo ang ingon nga sitwasyon alang sa lain-laing mga gidak-on sa max_wal_size ug nasabtan nga kung ang max_wal_size 64 gigabytes, nan sa doble nga pinakagrabe nga kaso kami mosaka sulod sa 10 minutos. Ug atong gihunahuna kung kini angay ba kanato o dili. Kini usa ka pangutana sa negosyo. Kinahanglan natong ipakita kini nga hulagway ngadto sa mga responsable sa mga desisyon sa negosyo ug mangutana, “Hangtod kanus-a kita makahigda kon adunay problema? Makahigda ba ta sa pinakagrabe nga sitwasyon sulod sa 3-5 ka minuto? Ug maghimo ka usa ka desisyon.
Ug ania ang usa ka makapaikag nga punto. Kami adunay usa ka magtiayon nga mga taho bahin sa Patroni sa komperensya. Ug tingali gigamit nimo kini. Kini usa ka autofailover alang sa mga Postgres. GitLab ug Data Egret naghisgot bahin niini.
Ug kung ikaw adunay usa ka autofailover nga moabut sa 30 segundos, unya mahimo ba kita makahigda sulod sa 10 ka minuto? Tungod kay kita mobalhin ngadto sa replika niining puntoha, ug ang tanan mamaayo ra. Kini usa ka moot point. Wala ko kabalo ug klarong tubag. Gibati ko lang nga kini nga hilisgutan dili lamang sa pag-ayo sa pag-crash.
Kon kita adunay dugay nga pagkaayo human sa usa ka kapakyasan, nan kita dili komportable sa daghang uban pang mga sitwasyon. Pananglitan, sa parehas nga mga eksperimento, kung buhaton naton ang usa ka butang ug usahay kinahanglan maghulat sa 10 minuto.
Dili gihapon ko mopalayo, bisag naa mi autofailover. Ingon sa usa ka lagda, ang mga kantidad sama sa 64, 100 gigabytes maayo nga mga kantidad. Usahay angayan pa gani nga mopili og gamay. Sa kinatibuk-an, kini usa ka maliputon nga siyensya.
Aron mahimo ang mga pag-uli, pananglitan, max_wal_size =1, 8, kinahanglan nimo nga balikon ang operasyon sa masa sa daghang mga higayon. Gihimo nimo kini. Ug sa parehas nga sukaranan gusto nimo nga buhaton kini pag-usab, apan gitangtang na nimo ang tanan. Unsay buhaton?
Maghisgot ko unya bahin sa among solusyon, kung unsa ang among buhaton aron mabag-o ang ingon nga mga sitwasyon. Ug kini ang labing husto nga pamaagi.
Apan sa kini nga kaso, kami swerte. Kung, ingon sa giingon dinhi "SUGOD, DELETE, ROLLBACK", nan mahimo natong balikon ang DELETE. Sa ato pa, kung kita mismo ang nagkansela niini, mahimo naton kini balikon. Ug sa pisikal kanimo ang datos ibutang sa parehas nga lugar. Wala ka man gani makakuha og bisan unsang bloat. Mahimo nimong balikon ang ingon nga mga DELETE.
Kini nga DELETE nga adunay ROLLBACK maayo alang sa pag-tune sa checkpoint, bisan kung wala kay husto nga gipakaylap nga database lab.
Naghimo kami usa ka plato nga adunay usa ka kolum nga "i". Ang mga postgres adunay mga kolum sa utility. Sila dili makita gawas kon espesipikong gipangayo. Kini mao ang: ctid, xmid, xmax.
Ang Ctid kay pisikal nga adres. Zero nga panid, ang unang tuple sa panid.
Makita nga pagkahuman sa ROOLBACK ang tuple nagpabilin sa parehas nga lugar. Kana mao, mahimo natong sulayan pag-usab, kini molihok sa samang paagi. Kini ang nag-unang butang.
Ang Xmax mao ang panahon sa pagkamatay sa tuple. Naselyohan kini, apan nahibal-an sa Postgres nga ang transaksyon gi-roll back, busa dili igsapayan kung kini 0 o kini usa ka rolled back nga transaksyon. Gisugyot niini nga posible nga mag-uli sa DELETE ug susihon ang kadaghanan nga mga operasyon sa pamatasan sa sistema. Makahimo ka ug database labs para sa mga kabus.
Kini mahitungod sa mga programmer. Mahitungod sa DBA, usab, kanunay nilang sawayon ang mga programmer tungod niini: "Nganong nagbuhat ka og dugay ug lisud nga mga operasyon?". Kini usa ka hingpit nga lahi nga perpendikular nga hilisgutan. Kaniadto adunay administrasyon, ug karon adunay kalamboan.
Dayag nga wala kami nabungkag. Klaro na. Imposible nga dili maputol ang ingon nga DELETE alang sa usa ka tapok sa minilyon nga linya sa mga bahin. Buhaton kini sulod sa 20 minutos, ug ang tanan mahiluna. Apan, sa kasubo, bisan ang mga eksperyensiyado nga mga developer masayop, bisan sa dagkong mga kompanya.
Nganong importante nga magbuwag?
-
Kung makita nato nga gahi ang disk, hinayhinayon nato kini. Ug kung nabuak kita, mahimo naton idugang ang mga paghunong, mahimo naton mapahinay ang pag-throttling.
-
Ug dili ta mu block sa uban ug dugay. Sa pipila ka mga kaso dili igsapayan, kung imong gitangtang ang tinuod nga basura nga wala’y nagtrabaho, nan lagmit nga dili nimo babagan ang bisan kinsa gawas sa trabaho sa autovacuum, tungod kay maghulat kini nga makompleto ang transaksyon. Apan kung imong tangtangon ang usa ka butang nga mahimo’g hangyoon sa uban, unya ma-block sila, adunay usa ka klase nga reaksyon sa kadena. Ang taas nga mga transaksyon kinahanglan nga likayan sa mga website ug mga mobile application.
Makapainteres kini. Kanunay nakong makita nga ang mga nag-develop nangutana: "Unsa nga gidak-on sa pakete ang akong pilion?".
Klaro nga kon mas dako ang gidak-on sa bundle, mas gamay ang overhead sa transaksyon, i.e., ang dugang nga overhead gikan sa mga transaksyon. Apan sa samang higayon, ang panahon nagdugang alang niini nga transaksyon.
Ako adunay usa ka yano nga lagda: pagkuha kutob sa imong mahimo, apan ayaw pag-adto sa mga executable matag segundo.
Ngano sa usa ka segundo? Ang pagpatin-aw kay yano kaayo ug masabtan sa tanan, bisan sa dili teknikal nga mga tawo. Nakita namon ang reaksyon. Atong kuhaon ang 50 milliseconds. Kung adunay nausab, nan ang atong mata mag-react. Kung gamay ra, mas lisud. Kung adunay motubag pagkahuman sa 100 millisecond, pananglitan, imong gi-klik ang mouse, ug gitubag ka pagkahuman sa 100 millisecond, gibati nimo kini nga gamay nga paglangan. Ang usa ka segundo giisip na nga preno.
Subay niini, kung atong bungkagon ang atong mga mass operations ngadto sa 10-segundos nga pagbuto, nan aduna kitay risgo nga atong babagan ang usa ka tawo. Ug kini molihok sulod sa pipila ka segundo, ug ang mga tawo makamatikod na niini. Busa, gipalabi nako nga dili mobuhat og labaw sa usa ka segundo. Apan sa samang higayon, ayaw kini pagbungkaga pag-ayo, tungod kay ang overhead sa transaksyon mamatikdan. Ang sukaranan mahimong labi ka lisud, ug ang uban pang lainlaing mga problema mahimong motungha.
Gipili namo ang gidak-on sa pakete. Sa matag kaso, mahimo naton kini nga lahi. Mahimong awtomatiko. Ug kami kombinsido sa kaepektibo sa pagproseso sa usa ka pakete. Sa ato pa, atong DELETE ang usa ka pack o UPDATE.
By the way, ang tanan nga akong gihisgutan dili lang mahitungod sa DELETE. Sama sa imong nahibal-an, kini bisan unsang daghang mga operasyon sa datos.
Ug among nakita nga ang plano maayo kaayo. Makita nimo ang index scan, mas maayo pa ang index scan. Ug kami adunay gamay nga kantidad sa datos nga nahilambigit. Ug wala pay usa ka segundo natuman. Super.
Ug kinahanglan pa natong siguroon nga walay degradasyon. Nahitabo nga ang una nga mga pakete dali nga molihok, ug unya kini labi ka grabe, labi ka grabe. Ang proseso mao nga kinahanglan nimo nga sulayan ang daghang. Kini gyud ang para sa database labs.
Ug kinahanglan pa nga mag-andam kita og usa ka butang aron kini magtugot kanato sa pagsunod niini sa husto sa produksyon. Pananglitan, mahimo natong isulat ang oras sa log, mahimo natong isulat kung asa kita karon ug kinsa ang atong gipapas. Ug kini magtugot kanato nga masabtan kung unsa ang mahitabo sa ulahi. Ug kung adunay mahitabo nga sayup, pangitaa dayon ang problema.
Kung kinahanglan naton susihon ang kaepektibo sa mga hangyo ug kinahanglan naton nga mag-uli sa daghang mga higayon, nan adunay usa ka butang sama sa usa ka kauban nga bot. Andam na siya. Gigamit kini sa daghang mga developer kada adlaw. Ug nahibal-an niya kung giunsa paghatag ang usa ka dako nga database sa terabyte kung gihangyo sa 30 segundos, ang imong kaugalingon nga kopya. Ug mahimo nimong tangtangon ang usa ka butang didto ug isulti ang RESET, ug tangtangon kini pag-usab. Mahimo nimong sulayan kini niining paagiha. Nakita nako ang umaabot alang niini nga butang. Ug ginabuhat na namo kini.
Unsa ang mga estratehiya sa pagbahin? Nakita nako ang 3 nga lainlaing mga estratehiya sa pagbahin nga gigamit sa mga nag-develop sa pakete.
Ang una yano ra kaayo. Naa miy numeric ID. Ug atong bungkagon kini ngadto sa lain-laing mga agwat ug pagtrabaho uban niana. Ang downside klaro. Sa una nga bahin, mahimo nga adunay 100 ka linya sa tinuod nga basura, sa ikaduha nga 5 ka linya o wala, o ang tanan nga 1 nga linya mahimong basura. Dili patas nga trabaho, apan dali kini maguba. Ilang gikuha ang maximum ID ug gidugmok kini. Kini usa ka walay pulos nga paagi.
Ang ikaduha nga estratehiya mao ang balanse nga pamaagi. Gigamit kini sa Gitlab. Ilang gikuha ug gi-scan ang lamesa. Among nakit-an ang mga utlanan sa mga ID packs aron ang matag pakete adunay eksaktong 10 ka mga rekord. Ug ibutang sila sa usa ka pila. Ug unya among giproseso. Mahimo nimo kini sa daghang mga hilo.
Sa una nga estratehiya, usab, sa paagi, mahimo nimo kini sa daghang mga hilo. Dili kini lisud.
Apan adunay mas bugnaw ug mas maayo nga pamaagi. Kini ang ikatulo nga estratehiya. Ug kung mahimo, mas maayo nga pilion kini. Gihimo namo kini base sa usa ka espesyal nga indeks. Sa kini nga kaso, lagmit kini usa ka indeks sumala sa kahimtang sa atong basura ug ID. Among iapil ang ID para index lang ang scan para dili ta mangadto sa heap.
Sa kinatibuk-an, ang index lamang nga pag-scan mas paspas kaysa index scan.
Ug dali namong nakit-an ang among mga ID nga gusto namong i-delete. BATCH_SIZE among pilion daan. Ug dili lang nato sila makuha, makuha nato sila sa espesyal nga paagi ug gi-hack dayon sila. Pero gi lock namo para kung na lock na sila, dili namo i lock, but move on nalang ug kuha sa sunod. Kini alang sa update skip locked. Kini nga super bahin sa Postgres nagtugot kanamo sa pagtrabaho sa daghang mga hilo kung gusto namon. Mahimo kini sa usa ka sapa. Ug dinhi adunay usa ka CTE - kini usa ka hangyo. Ug kami adunay tinuod nga pagtangtang nga nagpadayon sa ikaduhang andana niining CTE - returning *. Mahimo nimong ibalik ang id, apan mas maayo *kung wala ka daghang datos sa matag linya.
Nganong gikinahanglan nato kini? Kini ang kinahanglan natong i-report balik. Daghan na kaayo mig mga linya nga gipapas na sa tinuod. Ug kami adunay mga utlanan pinaagi sa ID o pinaagi sa gibuhat_sa ingon niini. Mahimo nimo ang min, max. Adunay laing mahimo. Daghan ka og butang dinhi. Ug kini sayon kaayo alang sa pag-monitor.
Adunay usa pa ka nota bahin sa indeks. Kung magdesisyon kami nga kinahanglan namon ang usa ka espesyal nga indeks alang sa kini nga buluhaton, nan kinahanglan namon nga sigurohon nga dili kini makadaot sa mga pag-update sa tuples. Sa ato pa, ang Postgres adunay ingon nga mga istatistika. Kini makita sa pg_stat_user_tables para sa imong lamesa. Makita nimo kung gigamit ang mainit nga mga update o wala.
Adunay mga sitwasyon kung ang imong bag-ong index mahimo ra nga putlon kini. Ug naa nimo ang tanan nga uban pang mga update nga nagtrabaho na, hinayhinay. Dili lang tungod kay nagpakita ang indeks (ang matag indeks nagpahinay og gamay sa mga update, apan gamay), apan dinhi kini nagdaot gihapon niini. Ug imposible nga maghimo espesyal nga pag-optimize alang sa kini nga lamesa. Kini mahitabo usahay. Kini usa ka maliputon nga pipila ka mga tawo ang nakahinumdom. Ug kini nga rake dali nga matunob. Usahay mahitabo nga kinahanglan nimo pangitaon ang usa ka pamaagi gikan sa pikas nga bahin ug buhaton gihapon kung wala kini nga bag-ong indeks, o paghimo og lain nga indeks, o sa ubang paagi, pananglitan, mahimo nimong gamiton ang ikaduha nga pamaagi.
Apan kini ang labing kamalaumon nga estratehiya, kung giunsa ang pagbahin sa mga batch ug pag-shoot sa mga batch nga adunay usa ka hangyo, pagtangtang gamay, ug uban pa.
Taas nga mga transaksyon
Gibabagan ang autovacuum -
isyu sa pagpugong -
Ang sayop #5 usa ka dako. Si Nikolai gikan sa Okmeter naghisgot bahin sa pagmonitor sa Postgres. Ang maayo nga pag-monitor sa Postgres, sa kasubo, wala. Ang uban mas duol, ang uban mas layo. Ang Okmeter hapit na mahimong perpekto, apan daghan ang kulang ug kinahanglan idugang. Kinahanglang andam ka niini.
Pananglitan, ang mga patay nga tuple labing maayo nga bantayan. Kung ikaw adunay daghang mga patay nga butang sa lamesa, nan adunay sayup. Mas maayo nga mag-react karon, kung dili, mahimo’g adunay pagkadaot, ug kita makahigda. Kini mahitabo.
Kung adunay usa ka dako nga IO, nan klaro nga kini dili maayo.
Taas usab ang mga transaksyon. Ang taas nga mga transaksyon kinahanglan dili tugutan sa OLTP. Ug ania ang usa ka link sa usa ka snippet nga nagtugot kanimo sa pagkuha niini nga snippet ug makahimo na sa pipila nga pagsubay sa taas nga mga transaksyon.
Ngano nga ang dugay nga mga transaksyon dili maayo? Tungod kay ang tanan nga mga kandado ipagawas ra sa katapusan. Ug gibalibaran namo ang tanan. Dugang pa, gibabagan namon ang autovacuum alang sa tanan nga mga lamesa. Dili gyud maayo. Bisan kung gipaandar nimo ang init nga standby sa replika, daotan gihapon kini. Sa kinatibuk-an, wala'y mas maayo nga likayan ang taas nga mga transaksyon.
Kung kita adunay daghang mga lamesa nga wala ma-vacuum, nan kinahanglan nga adunay alerto. Dinhi posible ang ingon nga kahimtang. Mahimo natong dili direkta nga makaapekto sa operasyon sa autovacuum. Kini usa ka snippet gikan sa Avito, nga akong gipauswag gamay. Ug kini nahimo nga usa ka makapaikag nga himan aron makita kung unsa ang naa sa autovacuum. Pananglitan, ang pipila ka mga lamesa naghulat didto ug dili maghulat sa ilang turno. Kinahanglan usab nimo nga ibutang kini sa pagmonitor ug adunay alerto.
Ug nag-isyu sa mga bloke. Lasang sa block nga mga kahoy. Ganahan kong mokuha ug usa ka butang gikan sa usa ka tawo ug pauswagon kini. Dinhi, gikuha sa Data Egret ang usa ka cool recursive CTE nga nagpakita sa usa ka lasang sa mga punoan sa kandado. Kini usa ka maayo nga himan sa pagdayagnos. Ug sa basehan niini, mahimo ka usab nga magtukod og pag-monitor. Apan kini kinahanglan nga buhaton pag-ayo. Kinahanglan ka maghimo ug gamay nga statement_timeout para sa imong kaugalingon. Ug gusto ang lock_timeout.
Usahay kining tanan nga mga sayup mahitabo sa sumada.
Sa akong opinyon, ang nag-unang sayop dinhi mao ang organisasyonal. Kini usa ka organisasyonal, tungod kay ang teknik wala magbira. Kini ang numero 2 - gisusi nila sa sayup nga lugar.
Gisusi namon ang sayup nga lugar, tungod kay wala kami usa ka clone sa produksiyon, nga dali nga susihon. Ang usa ka developer mahimong walay access sa produksyon sa tanan.
Ug among gisusi nga wala didto. Kung gisusi pa namo didto, kami ra unta ang nakakita niini. Nakita sa developer ang tanan bisan kung wala’y DBA kung gisusi niya kini sa usa ka maayo nga palibot, diin adunay parehas nga kantidad sa datos ug parehas nga lokasyon. Nakita unta niya kining tanan nga pagkadaotan ug maulaw siya.
Dugang pa bahin sa autovacuum. Human nato mabuhat ang usa ka dako nga sweep sa pipila ka milyon nga mga linya, kinahanglan pa naton buhaton ang REPACK. Kini labi ka hinungdanon alang sa mga indeks. Masakitan sila paghuman namong limpyohan ang tanan didto.
Ug kung gusto nimo nga ibalik ang adlaw-adlaw nga paglimpyo, nan isugyot nako nga buhaton kini kanunay, apan mas gamay. Mahimo kini kausa sa usa ka minuto o mas kanunay usa ka gamay. Ug kinahanglan nimo nga bantayan ang duha ka mga butang: nga kini nga butang wala’y mga sayup ug nga kini dili malangan. Ang lansis nga akong gipakita makasulbad ra niini.
Ang among gibuhat mao ang open source. Gi-post kini sa GitLab. Ug gihimo namo kini aron ang mga tawo makasusi bisan walay DBA. Naghimo kami usa ka database lab, nga mao, gitawag namon ang base nga sangkap diin karon nagtrabaho si Joe. Ug mahimo nimong makuha ang usa ka kopya sa produksiyon. Karon adunay usa ka pagpatuman sa Joe alang sa slack, mahimo nimong isulti didto: "ipasabut ang ingon ug ingon nga usa ka hangyo" ug makuha dayon ang resulta alang sa imong kopya sa database. Mahimo pa gani nimo nga DELETE didto, ug walay makamatikod niini.
Ingnon ta nga ikaw adunay 10 terabytes, naghimo kami og database lab nga 10 usab ka terabytes. Ug sa dungan nga 10 ka terabyte nga mga database, 10 ka mga developer ang mahimong dungan nga magtrabaho. Ang tanan makahimo sa ilang gusto. Mahimong tangtangon, ihulog, ug uban pa. Kini usa ka pantasya. Ato kining hisgotan ugma.
Gitawag kini nga thin provisioning. Kini usa ka maliputon nga paghatag. Kini usa ka matang sa pantasya nga nagtangtang pag-ayo sa mga paglangan sa pag-uswag, sa pagsulay ug naghimo sa kalibutan nga usa ka mas maayo nga lugar niining bahina. Sa ato pa, gitugotan ka lang nga malikayan ang mga problema sa daghang mga operasyon.
Pananglitan: 5 terabyte database, pagkuha og kopya sa ubos sa 30 segundos. Ug wala gani kini magdepende sa gidak-on, nga mao, dili igsapayan kung pila ka terabytes.
Karon makaadto ka sa ug pagkalot sa atong mga himan. Mahimo kang magparehistro aron makita kung unsa ang anaa. Mahimo nimong i-install kini nga bot. Libre kini. Isulat.
Ang imong mga pangutana
Kasagaran sa tinuud nga mga sitwasyon nahimo nga ang datos nga kinahanglan magpabilin sa lamesa labi ka gamay kaysa kung unsa ang kinahanglan nga tangtangon. Kana mao, sa ingon nga sitwasyon, kasagaran mas sayon ang pagpatuman sa ingon nga pamaagi, kung mas sayon ang paghimo og bag-ong butang, kopyaha lamang ang gikinahanglan nga datos didto, ug ibutang ang daang lamesa. Klaro nga ang usa ka programmatic nga pamaagi gikinahanglan alang niining higayona, samtang ikaw magbalhinbalhin. Giunsa kini nga pamaagi?
Kini usa ka maayo kaayo nga pamaagi ug usa ka maayo kaayo nga buluhaton. Parehas kaayo kini sa gibuhat sa pg_repack, parehas kini sa kinahanglan nimong buhaton kung maghimo ka mga ID nga 4 bytes. Daghang mga gambalay ang nagbuhat niini pipila ka tuig na ang milabay, ug ang mga palid lang ang mitubo, ug sila kinahanglan nga makabig ngadto sa 8 bytes.
Kini nga buluhaton medyo lisud. Among gibuhat. Ug kinahanglang magmatngon ka. Adunay mga kandado, ug uban pa. Apan kini gibuhat. Kana mao, ang sumbanan nga pamaagi mao ang pag-adto sa pg_repack. Gipahayag nimo ang ingon nga label. Ug sa dili ka pa magsugod sa pag-upload sa snapshot data ngadto niini, ipahayag usab nimo ang usa ka plato nga nagsubay sa tanang kausaban. Adunay usa ka limbong nga dili nimo masubay ang pipila ka mga pagbag-o. Adunay mga subtleties. Ug unya mobalhin ka pinaagi sa mga pagbag-o. Adunay usa ka mubo nga paghunong kung gisirhan namon ang tanan, apan sa kinatibuk-an kini gihimo.
Kung tan-awon nimo ang pg_repack sa GitHub, unya didto, kung adunay usa ka buluhaton sa pag-convert sa usa ka ID gikan sa int 4 hangtod sa int 8, unya adunay ideya nga gamiton ang pg_repack mismo. Posible usab kini, apan kini usa ka gamay nga hack, apan kini molihok usab alang niini. Mahimo kang mangilabot sa gatilyo nga gigamit sa pg_repack ug moingon didto: "Dili namo kinahanglan kini nga datos", i.e. gibalhin lang namo ang among gikinahanglan. And then nag switch nalang siya ug mao na.
Uban niini nga pamaagi, nakakuha gihapon kami usa ka ikaduha nga kopya sa lamesa, diin ang mga datos na-index na ug na-stack kaayo nga parehas sa matahum nga mga indeks.
Ang bloat wala, kini usa ka maayong pamaagi. Apan nahibal-an ko nga adunay mga pagsulay sa paghimo sa usa ka automation alang niini, i.e. paghimo usa ka unibersal nga solusyon. Mahimo ko ikaw makontak niini nga automation. Gisulat kini sa Python, nga usa ka maayong butang.
Gamay ra ko sa kalibutan sa MySQL, mao nga mianhi ko aron maminaw. Ug gigamit namon kini nga pamaagi.
Apan kini mao lamang kung kita adunay 90%. Kung kita adunay 5%, nan dili kaayo maayo nga gamiton kini.
Salamat sa report! Kung walay kahinguhaan sa paghimo og kompletong kopya sa prod, aduna bay algorithm o pormula aron makalkulo ang load o gidak-on?
Maayong pangutana. Hangtod karon, nakit-an namon ang mga database nga multi-terabyte. Bisan kung ang hardware didto dili parehas, pananglitan, gamay nga memorya, gamay nga processor ug mga disk dili parehas nga parehas, apan gibuhat gihapon namon kini. Kung wala'y bisan asa, nan kinahanglan ka maghunahuna. Huna-hunaon nako hangtod ugma, niabot ka, magstorya ta, maayo ni nga pangutana.
Salamat sa report! Una nimong gisugdan ang kamatuoran nga adunay usa ka cool nga Postgres, nga adunay ingon ug ingon nga mga limitasyon, apan kini nag-uswag. Ug kining tanan usa ka saklay sa kadaghanan. Dili ba kini tanan supak sa pag-uswag sa Postgres mismo, diin ang pipila nga DELETE deferent motungha o usa pa nga kinahanglan nga magpabilin sa usa ka ubos nga lebel kung unsa ang atong gipaningkamutan nga pahiran sa pipila sa atong mga katingad-an nga paagi dinhi?
Kung giingon namon sa SQL nga tangtangon o i-update ang daghang mga rekord sa usa ka transaksyon, nan unsaon pag-apod-apod kini sa Postgres didto? Kami sa pisikal limitado sa mga operasyon. Buhaton pa nato kini sa dugay nga panahon. Ug atong i-lock kini nga panahon, ug uban pa.
Nahuman sa mga indeks.
Makahunahuna ko nga ang parehas nga pag-tune sa checkpoint mahimong awtomatiko. Sa umaabot nga adlaw mahimo kini. Pero wala gyud ko kasabot sa pangutana.
Ang pangutana mao, aduna bay ingon nga vector sa kalamboan nga moadto dinhi ug didto, ug dinhi ang imoha magkaparehas? Mga. Wala pa ba sila makahunahuna niini?
Naghisgot ko bahin sa mga prinsipyo nga magamit karon. Adunay laing bot , pinaagi niini makahimo ka og automated checkpoint tuning. Maanaa ba kini sa Postgres? I don't know, wala pa gani nahisgotan. Layo pa ta niana. Apan adunay mga siyentipiko nga naghimo ug bag-ong mga sistema. Ug ila mi nga giduso ngadto sa awtomatikong mga indeks. Adunay mga kalamboan. Pananglitan, mahimo nimong tan-awon ang auto tuning. Gipili niini ang mga parameter nga awtomatiko. Apan dili pa siya mohimo og checkpoint tuning para nimo. Kana mao, kini mokuha alang sa performance, shell buffer, ug uban pa.
Ug alang sa pag-tune sa checkpoint, mahimo nimo kini: kung ikaw adunay usa ka libo nga mga kumpol ug lainlaing hardware, lainlaing mga virtual machine sa panganod, mahimo nimong gamiton ang among bot paghimo sa automation. Ug ang max_wal_size mapilian sumala sa imong target setting awtomatik. Apan sa pagkakaron dili pa kini duol sa kinauyokan, sa kasubo.
Maayong hapon Naghisgot ka bahin sa mga kapeligrohan sa taas nga mga transaksyon. Giingon nimo nga ang autovacuum gibabagan kung adunay mga pagtangtang. Sa unsang paagi pa kini makadaot kanato? Tungod kay naghisgut pa kami mahitungod sa pagpalingkawas sa luna ug sa paggamit niini. Unsa pa may kulang nato?
Ang Autovacuum tingali dili ang pinakadako nga problema dinhi. Ug ang kamatuoran nga ang usa ka taas nga transaksyon maka-lock sa ubang mga transaksyon, kini nga posibilidad mas peligro. Mahimong makigkita siya o dili. Kung magkita siya, mahimo’g daotan kaayo. Ug sa autovacuum - kini usab usa ka problema. Adunay duha ka mga problema sa taas nga mga transaksyon sa OLTP: mga kandado ug autovacuum. Ug kung ikaw adunay init nga standby nga feedback nga gipagana sa replika, nan makadawat ka gihapon og autovacuum lock sa master, kini moabut gikan sa replika. Apan labing menos walay mga kandado. Ug adunay mga lok. Naghisgot kami bahin sa mga pagbag-o sa datos, busa ang mga kandado usa ka hinungdanon nga punto dinhi. Ug kung kini tanan sa dugay, dugay nga panahon, labi pa nga daghang mga transaksyon ang na-lock. Mahimo silang mangawat sa uban. Ug mitungha ang mga kahoy nga lok. Naghatag ko og link sa snippet. Ug kini nga problema mahimong mas mamatikdan nga mas paspas kay sa problema sa autovacuum, nga mahimo lamang nga matipon.
Salamat sa report! Gisugdan nimo ang imong report pinaagi sa pag-ingon nga sayop ang imong pagsulay. Gipadayon namon ang among ideya nga kinahanglan nimo nga kuhaon ang parehas nga kagamitan, nga adunay base sa parehas nga paagi. Ingnon ta nga gihatagan namo og base ang developer. Ug gituman niya ang hangyo. Ug murag okay ra siya. Apan wala siya magsusi alang sa live, apan alang sa live, pananglitan, kami adunay karga nga 60-70%. Ug bisan kung gamiton namon kini nga pag-tune, dili kaayo kini molihok.
Importante ang pagbaton ug eksperto sa team ug paggamit sa mga eksperto sa DBA nga makatagna unsay mahitabo sa tinuod nga background load. Sa diha nga kami nagmaneho sa among limpyo nga mga pagbag-o, among nakita ang litrato. Apan ang usa ka mas abante nga pamaagi, sa diha nga gibuhat namo ang sama nga butang pag-usab, apan sa usa ka load simulated uban sa produksyon. Nindot kaayo. Hangtud niana, kinahanglan ka magdako. Morag hamtong na. Gitan-aw ra namo kung unsa ang naa namo ug gitan-aw usab kung kami adunay igo nga mga kapanguhaan. Maayo kana nga pangutana.
Kung naghimo na kita og usa ka pagpili sa basura ug kita adunay, pananglitan, usa ka natangtang nga bandila
Mao kini ang awtomatikong gibuhat sa autovacuum sa Postgres.
Oh, gibuhat ba niya kini?
Ang Autovacuum mao ang tigkolekta sa basura.
Спасибо!
Salamat sa report! Aduna bay kapilian sa pagdesinyo dayon sa usa ka database nga adunay partitioning sa paagi nga ang tanang basura mahugaw gikan sa main table sa usa ka dapit ngadto sa kilid?
Siyempre adunay.
Posible ba unya nga mapanalipdan ang atong kaugalingon kung naka-lock ang usa ka lamesa nga dili angay gamiton?
Siyempre adunay. Pero murag manok ug itlog nga pangutana. Kung nahibal-an naton tanan kung unsa ang mahitabo sa umaabot, nan, siyempre, buhaton naton ang tanan nga cool. Apan ang negosyo nagbag-o, adunay bag-ong mga kolum, bag-ong mga hangyo. Ug unya - oops, gusto namong tangtangon kini. Apan kini nga sulundon nga kahimtang, sa kinabuhi kini mahitabo, apan dili kanunay. Apan sa kinatibuk-an kini usa ka maayong ideya. Putol lang ug mao na.
Source: www.habr.com