Qualchì volta in u futuru distante, a rimuzione automatica di dati innecessarii serà unu di i travaglii impurtanti di u DBMS [1]. Intantu, avemu bisognu di piglià cura di sguassà o di trasfurmà e dati innecessarii in sistemi di almacenamentu menu caru. Diciamu chì decide di sguassà uni pochi milioni di file. Un compitu abbastanza simplice, soprattuttu se a cundizione hè cunnisciuta è ci hè un indice adattatu. "DELETE FROM table1 WHERE col1 =:value" - chì puderia esse più simplice, nò?
Video:
-
Sò in u cumitatu di u prugramma Highload da u primu annu, vale à dì da u 2007.
-
È aghju statu cù Postgres da u 2005. Adupratu in parechji prughjetti.
-
Gruppu cù RuPostges ancu da u 2007.
-
Avemu cresce à 2100+ participanti à Meetup. Hè a seconda in u mondu dopu à New York, superatu da San Francisco per un bellu pezzu.
-
Aghju campatu in California per parechji anni. Trattu più cù cumpagnie americane, cumprese i grandi. Sò utilizatori attivi di Postgres. È ci sò ogni tipu di cose interessanti.
hè a mo cumpagnia. Semu in l'affari di l'automatizazione di e attività chì eliminanu i rallentamenti di u sviluppu.
Sè vo fate qualcosa, allora qualchì volta ci sò qualchì tipu di plugs intornu à Postgres. Diciamu chì avete bisognu à aspittà chì l'amministratore per stabilisce un stand di prova per voi, o avete bisognu à aspittà chì u DBA vi risponda. E truvamu tali colli di bottiglia in u prucessu di sviluppu, di prova è di amministrazione è pruvate d'eliminà cù l'aiutu di l'automatizazione è di novi approcci.
Eru pocu tempu in VLDB in Los Angeles. Questa hè a più grande cunferenza di basa di dati. E ci hè statu un rapportu chì in u futuru DBMS ùn solu micca almacenà, ma ancu sguassate automaticamente e dati. Questu hè un novu tema.
Ci hè più è più dati in u mondu di zettabytes - questu hè 1 petabyte. È avà hè digià stimatu chì avemu più di 000 zettabytes di dati almacenati in u mondu. È ci sò più è più di elli.
È chì fà cun ellu? Ovviamente deve esse eliminata. Eccu un ligame à stu rapportu interessante. Ma finu à quì ùn hè micca statu implementatu in u DBMS.
Quelli chì ponu cuntà soldi volenu duie cose. Ci volenu sguassate, cusì tecnicamente duvemu esse capace di fà.
Ciò chì diceraghju dopu hè una situazione astratta chì include una mansa di situazioni reali, vale à dì un tipu di compilazione di ciò chì hè accadutu veramente à mè è à e basa di dati circundante parechje volte, parechji anni. Rakes sò in ogni locu è tutti li pisanu sempre.
Diciamu chì avemu una basa o parechje basi chì crescenu. È certi dischi sò ovviamente spazzatura. Per esempiu, l'utilizatore hà cuminciatu à fà qualcosa quì, ma ùn hà micca finitu. È dopu qualchì tempu sapemu chì questu unfinished ùn pò più esse guardatu. Vale à dì, vulemu pulizziari qualchi cose di basura per risparmià spaziu, migliurà u rendiment, etc.
In generale, u compitu hè di automatizà l'eliminazione di cose specifiche, linee specifiche in qualchì tavula.
È avemu una tale dumanda, chì avemu da parlà oghje, vale à dì, a rimozione di a basura.
Avemu dumandatu à un sviluppatore espertu per fà. Pigliò sta dumanda, hà verificatu per ellu stessu - tuttu funziona. Pruvatu in scena - tuttu hè bè. Rolled out - tuttu funziona. Una volta à ghjornu l'avemu eseguitu - tuttu hè bè.
A basa di dati cresce è cresce. Daily DELETE cumencia à travaglià un pocu più lentamente.
Allora avemu capitu chì avemu avà una cumpagnia di marketing è u trafficu serà parechje volte più grande, cusì decidemu di pause temporaneamente e cose innecessarii. È scurdate di vultà.
Qualchi mesi dopu si ricurdavanu. È quellu sviluppatore abbandunò o hè occupatu cù qualcosa altru, hà urdinatu à un altru per rinvià.
Hà verificatu in dev, in staging - tuttu hè bè. Naturalmente, avete sempre bisognu di pulizziari ciò chì hà accumulatu. Hà verificatu chì tuttu funziona.
Chì succede dopu ? Allora tuttu cade per noi. Scade cusì chì à un certu puntu tuttu cascà. Tutti sò in scossa, nimu capisce ciò chì succede. E poi si trova chì a materia era in questu DELETE.
Qualcosa hè andatu male? Eccu una lista di ciò chì puderia esse sbagliatu. Quale di questi hè u più impurtante?
-
Per esempiu, ùn ci era micca rivisione, vale à dì chì l'espertu DBA ùn hà micca vistu. Truvarà immediatamente u prublema cù un ochju espertu, è, in più, hà accessu à prod, induve parechji milioni di linii anu accumulatu.
-
Forse anu verificatu qualcosa di sbagliatu.
-
Forsi u hardware hè obsoletu è avete bisognu di aghjurnà sta basa.
-
O qualcosa hè sbagliatu cù a basa di dati stessu, è avemu bisognu di passà da Postgres à MySQL.
-
O forse ci hè qualcosa di sbagliatu cù l'operazione.
-
Forsi ci sò qualchì sbagliu in l'urganizazione di u travagliu è avete bisognu di sparisce à qualchissia è impiegà e persone megliu?
Ùn ci era micca cuntrollu DBA. S'ellu ci era un DBA, vi vede sti parechji milioni di linii è ancu senza esperimenti diceria: "Ùn facenu micca cusì". Suppone chì questu codice era in GitLab, GitHub è ci saria un prucessu di rivisione di codice è ùn era micca cusì chì senza l'appruvazioni di u DBA, sta operazione avissi da esse realizatu nantu à prod, allora ovviamente u DBA diceria: "Questu ùn pò micca esse fattu. "
E ellu dicia chì averete prublemi cù u discu IO è tutti i prucessi andaranu pazzi, pò esse chjusi, è ancu bluccà l'autovacuum per un munzeddu di minuti, cusì ùn hè micca bonu.
U secondu sbagliu - anu verificatu in u locu sbagliatu. Avemu vistu dopu à u fattu chì una quantità di dati junk accumulate nantu à prod, ma u sviluppatore ùn hà micca accumulatu dati in questa basa di dati, è nimu hà creatu sta junk durante staging. In cunsiquenza, ci sò stati 1 000 linee chì travagliavanu rapidamente.
Avemu capitu chì i nostri testi sò debuli, vale à dì u prucessu chì hè custruitu ùn catturà prublemi. Un esperimentu DB adattatu ùn hè statu realizatu.
Un esperimentu ideale hè preferibile realizatu nantu à u stessu equipamentu. Ùn hè micca sempre pussibule di fà questu nantu à u stessu equipamentu, ma hè assai impurtante chì sia una copia di a basa di dati à grandezza. Questu hè ciò chì aghju pridicatu dapoi parechji anni. È un annu fà aghju parlatu di questu, pudete vede tuttu nantu à YouTube.
Forse u nostru equipamentu hè male? Se guardate, allora a latenza hà saltatu. Avemu vistu chì l'utilizazione hè 100%. Di sicuru, s'ellu si trattava di unità NVMe muderne, allora probabilmente seria assai più faciule per noi. È forse ùn ci ne stendemu micca.
Sè vo avete nuvole, allura l 'aghjurnamentu hè facirmenti faciuli là. Rilevate novi repliche nantu à u novu hardware. cunversione. È tuttu hè bè. Piuttostu faciule.
Hè pussibule di tuccà in qualchì modu i dischi più chjuchi? È quì, solu cù l'aiutu di DBA, immersi in un certu tema chjamatu checkpoint tuning. Ci hè chì ùn avemu micca sintonizatu u puntu di cuntrollu.
Chì ghjè u checkpoint? Hè in ogni DBMS. Quandu avete dati in memoria chì cambia, ùn hè micca scrittu immediatamente à u discu. L'infurmazioni chì i dati anu cambiatu hè scrittu prima in u logu di scrittura. È in un certu puntu, u DBMS decide chì hè u tempu di dump pagine veri à u discu, perchè se avemu un fallimentu, pudemu fà menu REDO. Hè cum'è un ghjoculu. Sè simu ammazzati, avemu da principià u ghjocu da l'ultimu puntu di cuntrollu. È tutti i DBMS l'implementanu.
I paràmetri in Postgres sò in ritardu. Sò pensati per volumi di dati è transazzioni di 10-15 anni. È u checkpoint ùn hè micca eccezzioni.
Eccu l'infurmazioni da u nostru rapportu di verificazione Postgres, vale à dì un cuntrollu di salute automaticu. È quì hè una basa di dati di parechji terabytes. È si pò vede bè chì i punti di cuntrollu furzati in quasi 90% di i casi.
Cosa significa? Ci sò dui paràmetri quì. Checkpoint pò vene da timeout, per esempiu, in 10 minuti. O pò vene quandu una quantità di dati hè stata piena.
È per difettu max_wal_saze hè stabilitu à 1 gigabyte. In fatti, questu succede veramente in Postgres dopu à 300-400 megabytes. Avete cambiatu tanti dati è u vostru puntu di cuntrollu passa.
È s'ellu nimu hà sintonizatu, è u serviziu hà crisciutu, è a cumpagnia guadagna assai soldi, hà assai transazzione, allura u puntu di cuntrollu vene una volta per minutu, à volte ogni 30 seconde, è à volte ancu si superponu. Questu hè abbastanza male.
È avemu bisognu di assicurà chì vene menu spessu. Questu hè, pudemu elevà max_wal_size. È venerà menu spessu.
Ma avemu sviluppatu una metodulugia sana per cumu fà più currettamente, vale à dì, cumu fà una decisione nantu à a scelta di i paràmetri, chjaramente basatu nantu à dati specifichi.
Dunque, facemu duie serie di esperimenti nantu à basa di dati.
A prima serie - cambiamu max_wal_size. È facemu una operazione massiva. Prima, facemu nantu à u paràmetru predeterminatu di 1 gigabyte. È facemu un DELETE massivu di parechji milioni di linii.
Pudete vede quantu hè difficiule per noi. Avemu vistu chì u discu IO hè assai male. Fighjemu quanti WAL avemu generatu, perchè questu hè assai impurtante. Videmu quante volte u checkpoint hè accadutu. È vedemu chì ùn hè micca bè.
Dopu aumentemu max_wal_size. Ripitemu. Aumentemu, ripetemu. È tante volte. In principiu, 10 punti hè bonu, induve 1, 2, 4, 8 gigabytes. E fighjemu u cumpurtamentu di un sistema particulari. Hè chjaru chì quì l'equipaggiu deve esse cum'è in prod. Duvete avè i stessi dischi, a stessa quantità di memoria, è i stessi paràmetri di Postgres.
È in questu modu avemu da scambià u nostru sistema, è sapemu cumu si cumportanu u DBMS in casu di una mala massa DELETE, cumu si verificarà.
Checkpoint in russo sò checkpoints.
Esempiu: DELETE parechji milioni di fila per indice, e fila sò "dispersi" in e pagine.
Eccu un esempiu. Questu hè qualchì basa. È cù u paràmetru predeterminatu di 1 gigabyte per max_wal_size, hè assai chjaru chì i nostri dischi vanu à u scaffale per a registrazione. Questa stampa hè un sintumu tipicu di un paziente assai malatu, vale à dì, si sentia veramente male. È ci era una sola operazione, ci era solu un DELETE di parechji milioni di linii.
Sè un tali funziunamentu hè permessu in pruduzzione, allura avemu sulu mentiri, perchè hè chjaru chì unu DELETE ci ammazza in u scaffale.
In più, induve 16 gigabytes, hè chjaru chì i denti sò digià andatu. I denti sò digià megliu, vale à dì, chjamemu à u tettu, ma micca cusì male. Ci era una certa libertà. À a diritta hè u record. È u numeru di operazioni - u sicondu gràficu. È hè chjaru chì avemu digià respira un pocu più faciule quandu 16 gigabyte.
È induve 64 gigabyte pò esse vistu chì hè diventatu cumplettamente megliu. Dighjà i denti sò pronunzianu, ci sò più opportunità per sopravvive à altre operazioni è fà qualcosa cù u discu.
Perchè hè cusì?
Immergeraghju in i dettagli un pocu, ma questu tema, cumu fà a sintonizazione di u puntu di cuntrollu, pò esse risultatu in un rapportu tutale, per quessa ùn aghju micca carricà assai, ma descriveraghju un pocu ciò chì e difficultà ci sò.
Se u puntu di cuntrollu passa troppu spessu, è aghjurnà e nostre linee micca sequentially, ma truvamu per indice, chì hè bonu, perchè ùn sguassate micca tutta a tavola, allora pò accade chì prima avemu toccu a prima pagina, dopu a millesima, e poi vultò à u primu. È s'ellu trà queste visite à a prima pagina, u checkpoint hà digià salvatu à u discu, allora u salvarà di novu, perchè l'avemu bruttu una seconda volta.
È vi furzà u checkpoint à salvà parechje volte. Cumu ci saria l'operazione redundante per ellu.
Ma questu hè micca tuttu. E pagine sò 8 kilobytes in Postgres è 4 kilobytes in Linux. È ci hè un paràmetru full_page_writes. Hè attivatu per difettu. È questu hè currettu, perchè se l'avemu spentu, allora ci hè un periculu chì solu a mità di a pagina serà salvata s'ellu crash.
U cumpurtamentu di scrive à u WAL di u logu avanti hè cusì chì quandu avemu un puntu di cuntrollu è cambiamu a pagina per a prima volta, tutta a pagina, vale à dì, tutti i 8 kilobytes, entra in u logu avanti, ancu s'è avemu cambiatu solu u linea, chì pesa 100 bytes. È avemu da scrive tutta a pagina.
In i cambiamenti successivi, ci sarà solu un tuple specificu, ma per a prima volta scrivemu tuttu.
È, per quessa, se u puntu di cuntrollu hè accadutu di novu, allora avemu da principià tuttu da zero è spinghja tutta a pagina. Cù punti di cuntrollu frequenti, quandu andemu attraversu e stesse pagine, full_page_writes = on serà più di ciò chì puderia esse, vale à dì chì generà più WAL. Più hè mandatu à repliche, à l'archiviu, à u discu.
È, dunque, avemu dui licenzii.
Se aumentemu max_wal_size, risulta chì facemu più faciule per u checkpoint è u scrittore wal. È questu hè grande.
Mettimu un terabyte è campemu cun ellu. Chì ci hè male? Questu hè male, perchè in casu di fallimentu, cullà per ore, perchè u puntu di cuntrollu era assai tempu fà è assai hà digià cambiatu. È avemu bisognu di fà tuttu questu REDO. È cusì facemu a seconda seria di esperimenti.
Facemu una operazione è vedemu quandu u puntu di cuntrollu hè per compie, uccidemu -9 Postgres apposta.
E dopu chì avemu principiatu di novu, è vede quantu tempu risurrerà nantu à questu equipamentu, vale à dì quantu REDO in questa mala situazione.
Dui volte aghju nutatu chì a situazione hè male. Prima, avemu crashed right before the checkpoint era finitu, cusì avemu assai da perde. E siconda, avemu avutu una operazione massiva. È se i punti di cuntrollu eranu in timeout, allora, assai prubabilmente, menu WAL seria generatu da l'ultimu puntu di cuntrollu. Vale à dì, hè un doppiu perdente.
Misuremu una tale situazione per e diverse dimensioni max_wal_size è capiscenu chì se max_wal_size hè 64 gigabyte, allora in un casu duppiu peghju, cullà per 10 minuti. E pensemu s'ellu ci cunvene o micca. Questa hè una quistione di cummerciale. Avemu bisognu di mustrà sta stampa à i rispunsevuli di e decisioni di l'affari è dumandà: "Quantu tempu pudemu stende à u più in casu di prublema? Pudemu chjappà in a peor situazione per 3-5 minuti? È pigliate una decisione.
È quì hè un puntu interessante. Avemu un paru di rapporti nantu à Patroni à a cunferenza. E forsi l'avete aduprà. Questu hè un autofailover per Postgres. GitLab è Data Egret anu parlatu di questu.
È s'è vo avete un autofailover chì vene in 30 seconde, allora forse pudemu stende per 10 minuti? Perchè avemu da passà à a replica da questu puntu, è tuttu sarà bè. Questu hè un puntu discutibile. Ùn sò micca una risposta chjara. Sentu solu chì stu tema ùn hè micca solu intornu à a ricuperazione di crash.
Se avemu una longa ricuperazione dopu un fallimentu, allora seremu scomodi in parechje altre situazioni. Per esempiu, in i stessi esperimenti, quandu facemu qualcosa è qualchì volta deve aspittà per 10 minuti.
Ùn andaraghju micca troppu luntanu, ancu s'è avemu un autofailover. In regula, i valori cum'è 64, 100 gigabytes sò boni valori. Calchì volta vale ancu a pena di sceglie menu. In generale, questu hè una scienza sottile.
Per fà iterazioni, per esempiu, max_wal_size = 1, 8, avete bisognu di ripetiri l'operazione di massa parechje volte. Avete fattu. È nantu à a stessa basa chì vulete fà di novu, ma avete digià sguassatu tuttu. Chì fà ?
Parlaraghju più tardi di a nostra suluzione, ciò chì facemu per iterà in tali situazioni. È questu hè l'approcciu più currettu.
Ma in questu casu, avemu avutu furtunatu. Se, cum'è dice quì "BEGIN, DELETE, ROLLBACK", allora pudemu ripetiri DELETE. Vale à dì, se l'avemu annullatu noi stessi, pudemu ripetiri. E fisicamenti à voi i dati si trovanu in u stessu locu. Ùn avete mancu un gonfiore. Pudete iterate nantu à tali DELETE.
Questu DELETE cù ROLLBACK hè ideale per a sintonizazione di i punti di cuntrollu, ancu s'ellu ùn avete micca un laboratori di basa di dati implementati bè.
Avemu fattu un platu cù una colonna "i". Postgres hà colonne di utilità. Sò invisibili, salvu micca specificamente dumandatu. Questi sò: ctid, xmid, xmax.
Ctid hè un indirizzu fisicu. Pagina Zero, a prima tupla in a pagina.
Pò esse vistu chì dopu à ROOLBACK a tupla ferma in u stessu locu. Vale à dì, pudemu pruvà di novu, si cumportarà u listessu modu. Questu hè u principale.
Xmax hè u tempu di a morte di a tupla. Hè statu stampatu, ma Postgres sà chì a transazzione hè stata rinviata, per quessa ùn importa micca s'ellu hè 0 o hè una transazzione rolled back. Questu suggerisce chì hè pussibule iterà sopra DELETE è verificate l'operazioni in massa di u cumpurtamentu di u sistema. Pudete fà laboratori di basa di dati per i poveri.
Questu hè nantu à i programatori. Riguardu à DBA, ancu, anu sempre rimproverà i programatori per questu: "Perchè fate operazioni cusì longu è difficili?". Questu hè un tema perpendicular completamente diversu. Prima ci era l'amministrazione, è avà ci sarà u sviluppu.
Ovviamente, ùn avemu micca rottu in pezzi. Hè chjaru. Hè impussibile micca di rompe tali DELETE per un munzeddu di milioni di linii in parti. Serà fattu per 20 minuti, è tuttu si stende. Ma, sfurtunatamenti, ancu i sviluppatori sperimentati facenu sbagli, ancu in cumpagnie assai grande.
Perchè hè impurtante di rompe?
-
Se vedemu chì u discu hè duru, allora rallentemu. È se simu rotti, allora pudemu aghjunghje pause, pudemu rallentà u throttling.
-
È ùn avemu micca bluccà altri per un bellu pezzu. In certi casi ùn importa micca, s'è vo sguassate veri basura chì nimu hè travagliatu, allura più prubabile ùn bluccà nimu, salvu u travagliu autovacuum, perchè aspittà chì a transazzione finisci. Ma s'è vo sguassate qualcosa chì qualcunu altru pò dumandà, allura sarà bluccatu, ci sarà un tipu di reazzione in catena. E transazzione longu deve esse evitata in siti web è applicazioni mobili.
Questu hè interessante. Spessu vecu chì i sviluppatori dumandanu: "Quale dimensione di u pacchettu deve sceglie?".
Hè chjaru chì u più grande u grandezza di u fasciu, più chjuca hè a transazzione overhead, vale à dì, u overhead supplementu da e transacciones. Ma à u stessu tempu, u tempu aumenta per questa transazzione.
Aghju una regula assai simplice: pigliate quant'è pudete, ma ùn andate micca nantu à eseguibili per seconda.
Perchè un secondu? A spiegazione hè assai sèmplice è comprensibile per tutti, ancu e persone micca tecniche. Avemu vistu una reazione. Pigliemu 50 millisecondi. Se qualcosa hè cambiatu, allora u nostru ochju reagisce. Se menu, allora più difficiule. Se qualcosa risponde dopu à 100 millisecondi, per esempiu, avete clicatu u mouse, è vi hà rispostu dopu à 100 millisecondi, avete digià sentitu stu ligeru ritardu. Un secondu hè digià percepitu cum'è freni.
In cunsiquenza, s'ellu si rompe e nostre operazioni di massa in 10 secondi, allora avemu u risicu di bluccà qualcunu. È hà da travaglià per uni pochi seconde, è a ghjente hà digià nutatu. Per quessa, preferimu micca fà più di una seconda. Ma à u stessu tempu, ùn si rompe micca assai finamente, perchè a transazzione overhead serà notevule. A basa serà più dura, è altri prublemi diffirenti ponu esse.
Scegliemu a dimensione di u pacchettu. In ogni casu, pudemu fà in modu diversu. Pò esse automatizatu. È simu cunvinti di l'efficienza di a trasfurmazioni di un pacchettu. Vale à dì, facemu DELETE di un pacchettu o UPDATE.
Per via, tuttu ciò chì parlu ùn hè micca solu di DELETE. Cum'è l'avete capitu, queste sò qualsiasi operazioni in massa nantu à e dati.
È vedemu chì u pianu hè eccellente. Pudete vede l'indici di scansione, l'indici solu di scansione hè ancu megliu. È avemu una piccula quantità di dati implicati. È menu di un secondu cumpleta. Super.
È avemu sempre bisognu di assicurà chì ùn ci hè micca degradazione. Succede chì i primi pacchetti sò prestu prestu, è poi si peggiu, peghju è peghju. U prucessu hè tali chì avete bisognu di pruvà assai. Questu hè esattamente ciò chì serve i laboratori di basa di dati.
È avemu sempre à preparà qualcosa in modu chì ci permetterà di seguità questu currettamente in a produzzione. Per esempiu, pudemu scrive u tempu in u logu, pudemu scrive induve simu avà è quale avemu avà sguassatu. È questu ci permetterà di capisce ciò chì succede dopu. È in casu chì qualcosa va male, truvate rapidamente u prublema.
Se avemu bisognu di verificà l'efficienza di e dumande è avemu bisognu di iterate parechje volte, allora ci hè una cosa cum'è un cumpagnu bot. Hè digià prontu. Hè adupratu da decine di sviluppatori ogni ghjornu. È sà cumu dà una basa di dati di terabyte enormi nantu à dumanda in 30 seconde, a vostra propria copia. È pudete sguassà qualcosa quì è dì RESET, è sguassà di novu. Pudete sperimentà cun questu modu. Vecu un futuru per questa cosa. È a facemu digià.
Chì sò e strategie di spartizione? Vecu 3 diverse strategie di partizionamentu chì i sviluppatori nantu à u pacchettu utilizanu.
U primu hè assai simplice. Avemu un ID numericu. È spartemu in diversi intervalli è travaglià cun questu. U svantaghju hè chjaru. In u primu segmentu, pudemu avè 100 linee di veri basura, in a seconda linea 5 o micca in tuttu, o tutte e 1 linee saranu basura. U travagliu assai irregulare, ma hè faciule da rompe. Piglionu u massimu ID è smashed lu. Questu hè un approcciu ingenu.
A seconda strategia hè un approcciu equilibratu. Hè usatu in Gitlab. Piglionu è scannò u tavulinu. Avemu trovu i cunfini di i pacchetti d'identità in modu chì ogni pacchettu avia esattamente 10 000 records. E mette in una fila. È dopu avemu prucessu. Pudete fà questu in parechje fili.
In a prima strategia, ancu, per via, pudete fà questu in parechji fili. Ùn hè micca difficiule.
Ma ci hè un approcciu più frescu è megliu. Questa hè a terza strategia. È quandu hè pussibule, hè megliu di sceglie. Facemu questu nantu à a basa di un indice speciale. In questu casu, serà più prubabile un indice secondu a nostra cundizione di basura è ID. Avemu da include l'ID in modu chì hè un indexu solu scansione per ùn andà micca in u munzeddu.
In generale, a scansione di l'indexu solu hè più veloce di a scansione di l'indice.
È truvamu rapidamente i nostri ID chì vulemu caccià. BATCH_SIZE avemu sceltu in anticipu. È ùn l'avemu micca solu, l'avemu in modu speciale è l'hack immediatamente. Ma chjudemu cusì chì s'elli sò digià chjusi, ùn li chjudemu micca, ma andemu avanti è pigliate i prossimi. Questu hè per l'aghjurnamentu salta chjusu. Questa super funzione di Postgres ci permette di travaglià in parechji fili se vulemu. Hè pussibule in un flussu. E quì ci hè un CTE - questu hè una dumanda. È avemu una vera cancellazione in u sicondu pianu di stu CTE - returning *. Pudete rinvià id, ma hè megliu *se ùn avete micca assai dati nantu à ogni linea.
Perchè avemu bisognu? Questu hè ciò chì avemu bisognu di riportà. Avemu avà sguassatu tante linee in fattu. È avemu cunfini per ID o da created_at cum'è questu. Pudete fà min, max. Qualcosa altru pò esse fattu. Pudete cose assai quì. È hè assai còmuda per u monitoraghju.
Ci hè una nota più nantu à l'indici. Se decidemu chì avemu bisognu di un indice speciale per questu compitu, allora avemu bisognu di assicurà chì ùn sguassate micca solu l'aghjurnamenti di tuples. Questu hè, Postgres hà tali statistiche. Questu pò esse vistu in pg_stat_user_tables per a vostra tavula. Pudete vede se l'aghjurnamenti caldi sò usati o micca.
Ci sò situazioni quandu u vostru novu indice pò solu tagliate. È avete tutte l'altri aghjurnamenti chì sò digià travagliatu, rallentate. Micca solu perchè l'indici apparsu (ogni indice rallenta l'aghjurnamenti un pocu, ma un pocu), ma quì ancu arruvina. È hè impussibile di fà ottimisazione speciale per questa tavola. Questu succede qualchì volta. Questa hè una sutilezza cusì chì pocu persone si ricordanu. È questu rake hè faciule per passà. A volte succede chì avete bisognu di truvà un accostu da l'altra parte è ancu fà senza stu novu indice, o fà un altru indice, o in qualchì altru modu, per esempiu, pudete aduprà u sicondu metudu.
Ma questu hè a strategia più ottima, cumu si divide in batch è sparà in batch cù una dumanda, sguassate un pocu, etc.
Transazzione longa
Autovacuum bloccatu -
prublema di bloccu -
L'errore #5 hè un grande. Nikolai da Okmeter hà parlatu di u monitoraghju di Postgres. U monitoraghju Ideal Postgres, sfurtunatamenti, ùn esiste micca. Certi sò più vicini, certi sò più luntanu. Okmeter hè abbastanza vicinu à esse perfettu, ma assai manca è deve esse aghjuntu. Avete bisognu à esse prontu per questu.
Per esempiu, i tuppi morti sò megliu monitorati. Sì avete parechje cose morte in a tavula, allora qualcosa hè sbagliatu. Hè megliu per reagisce avà, altrimenti ci pò esse degradazione, è pudemu chjappà. Si passa.
Se ci hè un grande IO, allora hè chjaru chì questu ùn hè micca bonu.
E transazzioni longu ancu. E transazzione longa ùn deve esse permessa nantu à OLTP. È quì hè un ligame à un snippet chì permette di piglià stu snippet è digià fà un pocu di seguimentu di transazzioni longu.
Perchè e transazzioni longu sò cattivi? Perchè tutti i chjusi seranu liberati solu à a fine. È sguassemu tutti. In più, blocchemu l'autovacuum per tutti i tavulini. Ùn hè micca bè in tuttu. Ancu s'è vo avete attivatu hot standby nantu à a replica, hè sempre male. In generale, ùn hè micca megliu per evità transazzioni longu.
Se avemu parechje tavule chì ùn sò micca vacuumed, allora avemu bisognu di avè una alerta. Quì una tale situazione hè pussibule. Pudemu affettà indirettamente l'operazione di l'autovacuum. Questu hè un snippet da Avito, chì aghju ligeramente migliuratu. È hè diventatu un strumentu interessante per vede ciò chì avemu cù l'autovacuum. Per esempiu, certi tavule sò aspittendu quì è ùn aspittàranu micca u so turnu. Avete ancu bisognu di mette in surviglianza è avè una alerta.
È emette blocchi. Foresta d'arburi di blocchi. Mi piace à piglià qualcosa da qualchissia è migliurà. Quì aghju pigliatu un CTE recursive cool da Data Egret chì mostra una furesta di arburi di serratura. Questu hè un bonu strumentu di diagnosticu. È nantu à a so basa, pudete ancu custruisce un monitoraghju. Ma questu deve esse fattu cù cura. Avete bisognu di fà un picculu statement_timeout per sè stessu. È lock_timeout hè desideratu.
Calchì volta tutti sti errori accadenu in summa.
In my opinion, u principale sbagliu quì hè l'urganizazione. Hè urganisazione, perchè a tecnica ùn tira micca. Questu hè u numeru 2 - anu verificatu in u locu sbagliatu.
Avemu verificatu in u locu sbagliatu, perchè ùn avemu micca un clone di produzzione, chì hè faciule da verificà. Un sviluppatore pò micca avè accessu à a produzzione in tuttu.
È avemu verificatu micca quì. S'è no aviamu verificatu quì, l'avemu vistu noi stessi. U sviluppatore hà vistu tuttu ancu senza un DBA s'ellu hà verificatu in un bonu ambiente, induve ci hè a stessa quantità di dati è un locu identicu. Avaria vistu tutta sta degradazione è si vergogna.
Più nantu à l'autovacuum. Dopu avè fattu una spazzata massiva di parechji milioni di linii, avemu sempre bisognu di fà REPACK. Questu hè particularmente impurtante per l'indici. Sentiranu male dopu avè pulitu tuttu quì.
È se vulete ritruvà u travagliu di pulizia di ogni ghjornu, allora suggerissi di fà più spessu, ma più chjucu. Pò esse una volta per minutu o ancu più spessu un pocu. È avete bisognu di monitorà duie cose: chì sta cosa ùn hà micca errori è chì ùn resta micca in daretu. U truccu chì aghju dimustratu solu risolverà questu.
Ciò chì facemu hè open source. Hè publicatu nantu à GitLab. È facemu cusì chì a ghjente pò verificà ancu senza un DBA. Facemu un laboratoriu di basa di dati, vale à dì, chjamemu u cumpunente di basa nantu à quale Joe travaglia attualmente. È pudete piglià una copia di pruduzzione. Avà ci hè una implementazione di Joe per slack, pudete dì quì: "spiegà una tale dumanda" è immediatamente ottene u risultatu per a vostra copia di a basa di dati. Puderete ancu DELETE quì, è nimu l'avvisarà.
Diciamu chì avete 10 terabytes, facemu u laboratoriu di basa di dati ancu 10 terabytes. È cù basa di dati simultanea di 10 terabyte, 10 sviluppatori ponu travaglià simultaneamente. Ognunu pò fà ciò chì vulete. Pò sguassà, goccia, etc. Chì hè una tale fantasia. Ne parleremu dumani.
Questu hè chjamatu thin provisioning. Questu hè un pruvisione sottile. Questu hè un tipu di fantasia chì elimina assai ritardu in u sviluppu, in a prova è face u mondu un postu megliu in questu sensu. Questu hè, solu permette di evità prublemi cù operazioni in massa.
Esempiu: basa di dati 5 terabyte, ottene una copia in menu di 30 seconde. È ùn dipende ancu di a dimensione, vale à dì, ùn importa micca quantu terabytes.
Oghje pudete andà è scavà in i nostri arnesi. Pudete registrà per vede ciò chì ci hè. Pudete installà stu bot. Hè gratis. Scrivite.
I vostri dumanni
Assai spessu in situazione reale si trova chì i dati chì deve esse in a tavula hè assai menu di ciò chì deve esse sguassatu. Questu hè, in una tale situazione, hè spessu più faciule per implementà un tali approcciu, quandu hè più faciule per creà un novu ughjettu, copià solu i dati necessarii quì, è trunk the vech table. Hè chjaru chì un approcciu programmaticu hè necessariu per questu mumentu, mentre chì sarete cambiatu. Cumu hè questu approcciu?
Questu hè un approcciu assai bonu è un compitu assai bonu. Hè assai simili à ciò chì pg_repack faci, hè assai simili à ciò chì duvete fà quandu fate ID 4 bytes. Parechje frameworks anu fattu questu uni pochi anni fà, è solu i platti sò cresciuti, è anu da esse cunvertiti in 8 bytes.
Stu compitu hè abbastanza difficiule. Avemu fattu. È duvete esse assai attenti. Ci sò chjusi, etc. Ma hè fattu. Questu hè, l'approcciu standard hè di andà cun pg_repack. Dichjarà una tale etichetta. È prima di inizià a carica di dati di snapshot in questu, ancu dichjarà una piastra chì traccia tutti i cambiamenti. Ci hè un truccu chì pudete ancu micca seguità qualchi cambiamenti. Ci sò suttilità. E poi cambiate cù cambiamenti rotulanti. Ci sarà una breve pausa quandu chjudemu tutti, ma in generale questu hè fattu.
Se guardate pg_repack in GitHub, allora, quandu ci era un compitu per cunvertisce un ID da int 4 à int 8, allora ci era una idea di utilizà pg_repack stessu. Questu hè ancu pussibule, ma hè un pocu di pirate, ma hà da travaglià ancu per questu. Pudete intervene in u trigger chì pg_repack usa è dì quì: "Ùn avemu micca bisognu di sti dati", vale à dì chì trasfiremu solu ciò chì avemu bisognu. E poi cambia solu è basta.
Cù questu approcciu, avemu sempre una seconda copia di a tavula, in quale i dati sò digià indiziati è stacked assai uniformi cù belli indici.
Bloat ùn hè micca presente, hè un bonu approcciu. Ma sò chì ci sò tentativi di sviluppà una automatizazione per questu, vale à dì per fà una suluzione universale. Vi possu mette in cuntattu cù questa automatizazione. Hè scrittu in Python, chì hè una bona cosa.
Sò solu un pocu di u mondu di MySQL, cusì sò venutu à sente. È avemu aduprà stu approcciu.
Ma hè solu s'ellu avemu u 90%. Se avemu 5%, allora ùn hè micca assai bonu per aduprà.
Grazie per u rapportu! Se ùn ci sò micca risorse per fà una copia cumpleta di prod, ci hè un algoritmu o una formula per calculà a carica o a dimensione?
Bona dumanda. Finu a ora, simu capaci di truvà basa di dati multi-terabyte. Ancu s'è u hardware ùn hè micca u listessu, per esempiu, menu memoria, menu prucessori è dischi ùn sò micca esattamente u listessu, ma ancu facemu. Se ùn ci hè assolutamente nulla, allora avete bisognu di pensà. Lasciami pinsà finu à dumane, site ghjuntu, parlemu, questa hè una bona dumanda.
Grazie per u rapportu! Prima avete principiatu nantu à u fattu chì ci hè un Postgres cool, chì hà tali limitazioni, ma si sviluppa. È questu hè tuttu una crutch in generale. Ùn hè micca tuttu in cunflittu cù u sviluppu di Postgres stessu, in quale alcuni DELETE deferente appariscerà o qualcosa d'altru chì duverebbe mantene à un livellu bassu ciò chì pruvemu à smear cù alcuni di i nostri strani mezi quì?
Se avemu dettu in SQL per sguassà o aghjurnà parechji registri in una transazzione, allora cumu pò Postgres distribuisce quì? Semu fisicamente limitati in operazioni. A faremu sempre per un bellu pezzu. È chjuderemu à questu tempu, etc.
Fattu cù l'indici.
Puderaghju assume chì u stessu puntu di cuntrollu pò esse automatizatu. Qualchì ghjornu puderia esse. Ma allora ùn capiscu micca veramente a quistione.
A quistione hè, ci hè un tali vettore di sviluppu chì và quì è quì, è quì u vostru vai parallella ? Quelli. Ùn ci anu ancu pensatu ?
Aghju parlatu di i principii chì ponu esse usatu avà. Ci hè un altru bot , cù questu pudete fà un tuning automaticu di u puntu di cuntrollu. Serà un ghjornu in Postgres ? Ùn sò micca, ùn hè ancu statu discutitu. Semu sempre luntanu da questu. Ma ci sò scientisti chì facenu novi sistemi. È ci mettenu in indici automatichi. Ci sò sviluppi. Per esempiu, pudete vede l'autotuning. Selezziunà i paràmetri automaticamente. Ma ùn hà micca da fà l'accordu di u checkpoint per voi. Vale à dì, ripiglià per prestazioni, buffer di shell, etc.
È per a sintonizazione di u puntu di cuntrollu, pudete fà questu: se avete mille clusters è hardware diffirenti, diverse macchine virtuali in u nuvulu, pudete aduprà u nostru bot. fà l'automatizazione. È max_wal_size serà sceltu automaticamente sicondu i vostri paràmetri di destinazione. Ma finu à quì ùn hè ancu vicinu in u core, sfurtunatamenti.
Bonghjornu Avete parlatu di i periculi di transazzioni longu. Avete dettu chì l'autovacuum hè bluccatu in casu di eliminazione. Cumu altrimenti ci fa male? Perchè parlemu più di liberà u spaziu è di pudè usà. Chì altru ci manca ?
L'autovacuum hè forse micca u prublema più grande quì. È u fattu chì una transazzione longa pò chjude altre transazzione, sta pussibilità hè più periculosa. Puderà o micca scuntrà. S'ellu hà scontru, pò esse assai male. È cù autovacuum - questu hè ancu un prublema. Ci sò dui prublemi cù transazzione longu in OLTP: chjusi è autovacuum. È s'è vo avete un feedback di standby caldu attivatu nantu à a replica, allora riceverete sempre un serratura autovacuum nantu à u maestru, ghjunghjerà da a replica. Ma almenu ùn ci sarà micca serratura. È ci sarà loks. Parlemu di cambiamenti di dati, cusì i chjusi sò un puntu impurtante quì. È s'ellu hè tuttu per un bellu pezzu, allora più è più transazzioni sò chjusi. Puderanu arrubbari altri. È l'arburi di lok appariscenu. Aghju furnitu un ligame à u snippet. E stu prublema diventa più notu più veloce chì u prublema cù l'autovacuum, chì pò solu accumulà.
Grazie per u rapportu! Avete principiatu u vostru rapportu dicendu chì avete pruvatu incorrectamente. Avemu cuntinuatu a nostra idea chì avemu bisognu di piglià u stessu equipamentu, cù a basa in u listessu modu. Diciamu chì avemu datu u sviluppatore una basa. È hà cumpresu a dumanda. È pare ch'ellu sia bè. Ma ùn cuntrolla micca per vive, ma per vive, per esempiu, avemu una carica di 60-70%. E ancu s'è avemu aduprà sta sintonizazione, ùn viaghja micca bè.
Avè un espertu in a squadra è aduprà esperti DBA chì ponu prediche ciò chì succederà cù una carica di fondo reale hè impurtante. Quandu avemu ghjustu guidatu i nostri cambiamenti puliti, vedemu a stampa. Ma un accostu più avanzatu, quandu avemu fattu a stessa cosa di novu, ma cù una carica simulata cù a pruduzzione. Hè abbastanza cool. Finu à quì, avete da cresce. Hè cum'è un adultu. Avemu vistu solu ciò chì avemu è ancu guardatu s'ellu avemu abbastanza risorse. Hè una bona dumanda.
Quandu avemu digià fattu una selezzione di basura è avemu, per esempiu, una bandiera sguassata
Questu hè ciò chì l'autovacuum faci automaticamente in Postgres.
Oh, u face ?
L'autovacuum hè u cullettore di basura.
Grazie!
Grazie per u rapportu! Ci hè una opzione per disignà immediatamente una basa di dati cù partizioni in tale manera chì tutta a basura si sporca da a tavola principale in un locu à u latu?
Di sicuru avè.
Hè pussibili tandu à prutege si avemu chjusu un tavulinu chì ùn deve esse usatu ?
Di sicuru avè. Ma hè cum'è una quistione di pollo è ovu. Sè tutti sapemu ciò chì succede in u futuru, allora, sicuru, faremu tuttu cool. Ma l'affari cambia, ci sò novi culonni, novi dumande. E poi - oops, vulemu caccià. Ma sta situazione ideale, in a vita si trova, ma micca sempre. Ma in generale hè una bona idea. Truncate solu è basta.
Source: www.habr.com