En un futur llunyà, l'eliminació automàtica de dades innecessàries serà una de les tasques importants del SGBD [1]. Mentrestant, nosaltres mateixos ens hem d'encarregar d'esborrar o traslladar dades innecessàries a sistemes d'emmagatzematge menys costosos. Suposem que decidiu suprimir uns quants milions de files. Una tasca bastant senzilla, sobretot si es coneix la condició i hi ha un índex adequat. "ELIMINAR DE LA taula1 WHERE col1 = :valor" - què podria ser més senzill, oi?
Vídeo:
-
Formo part del comitè del programa Highload des del primer any, és a dir, des del 2007.
-
I estic amb Postgres des del 2005. S'ha utilitzat en molts projectes.
-
Grup amb RuPostges també des del 2007.
-
Hem crescut a més de 2100 participants a Meetup. És el segon del món després de Nova York, superat per San Francisco durant molt de temps.
-
Fa diversos anys que visc a Califòrnia. Tracto més amb empreses nord-americanes, incloses les grans. Són usuaris actius de Postgres. I hi ha tot tipus de coses interessants.
és la meva empresa. Estem en el negoci d'automatitzar tasques que eliminen les alentiments del desenvolupament.
Si esteu fent alguna cosa, de vegades hi ha algun tipus de connectors al voltant de Postgres. Suposem que heu d'esperar que l'administrador us instal·li un banc de proves o bé que us respongui el DBA. I trobem aquests colls d'ampolla en el procés de desenvolupament, proves i administració i intentem eliminar-los amb l'ajuda de l'automatització i nous enfocaments.
Vaig estar recentment a VLDB a Los Angeles. Aquesta és la conferència més gran sobre bases de dades. I hi va haver un informe que en el futur DBMS no només emmagatzemarà, sinó que també esborrarà automàticament les dades. Aquest és un tema nou.
Cada cop hi ha més dades al món dels zettabytes, això són 1 de petabytes. I ara ja es calcula que tenim més de 000 zettabytes de dades emmagatzemats al món. I cada cop n'hi ha més.
I què fer-hi? Evidentment s'ha de treure. Aquí teniu un enllaç a aquest interessant reportatge. Però fins ara això no s'ha implementat al SGBD.
Els que saben comptar diners volen dues coses. Volen que suprimim, així que tècnicament hauríem de ser capaços de fer-ho.
El que explicaré a continuació és una situació abstracta que inclou un munt de situacions reals, és a dir, una mena de recopilació del que realment em va passar a mi i a les bases de dades del voltant moltes vegades, molts anys. Els rasclets estan a tot arreu i tothom els trepitja tot el temps.
Diguem que tenim una base o diverses bases que creixen. I alguns discos són, evidentment, escombraries. Per exemple, l'usuari va començar a fer alguna cosa allà, però no ho va acabar. I al cap d'un temps sabem que aquest inacabat ja no es pot emmagatzemar. És a dir, ens agradaria netejar algunes escombraries per tal d'estalviar espai, millorar el rendiment, etc.
En general, la tasca és automatitzar l'eliminació de coses específiques, línies específiques en alguna taula.
I tenim una petició així, de la qual parlarem avui, és a dir, de la retirada d'escombraries.
Hem demanat a un desenvolupador experimentat que ho faci. Va acceptar aquesta sol·licitud, la va comprovar per si mateix: tot funciona. Provat a la posada en escena: tot està bé. Desplegat: tot funciona. Un cop al dia l'executem, tot està bé.
La base de dades creix i creix. Daily DELETE comença a funcionar una mica més lentament.
Aleshores entenem que ara tenim una empresa de màrqueting i el trànsit serà diverses vegades més gran, així que decidim aturar temporalment les coses innecessàries. I oblida't de tornar.
Uns mesos després se'n van recordar. I aquest desenvolupador va sortir o està ocupat amb una altra cosa, va dir a un altre que la retornés.
Va comprovar el desenvolupament, la posada en escena: tot està bé. Naturalment, encara heu de netejar el que s'ha acumulat. Va comprovar que tot funcionava.
Què passa després? Llavors tot s'ensorra per nosaltres. Baixa de manera que en algun moment tot cau. Tothom està en xoc, ningú entén què està passant. I aleshores resulta que l'assumpte estava en aquest ELIMINAR.
Alguna cosa ha anat malament? Aquí teniu una llista del que podria haver anat malament. Quina d'aquestes és la més important?
-
Per exemple, no hi va haver cap revisió, és a dir, l'expert DBA no ho va mirar. Trobaria immediatament el problema amb un ull experimentat i, a més, té accés al producte, on s'han acumulat diversos milions de línies.
-
Potser han comprovat alguna cosa malament.
-
Potser el maquinari està obsolet i necessiteu actualitzar aquesta base.
-
O alguna cosa no funciona amb la base de dades i hem de passar de Postgres a MySQL.
-
O potser hi ha alguna cosa malament amb l'operació.
-
Potser hi ha alguns errors en l'organització del treball i cal acomiadar algú i contractar la millor gent?
No hi va haver cap control DBA. Si hi hagués un DBA, veuria aquests milions de línies i fins i tot sense cap experiment diria: "No ho fan". Suposem que si aquest codi estigués a GitLab, GitHub i hi hauria un procés de revisió de codi i no hi hagués tal cosa que sense l'aprovació del DBA aquesta operació tingués lloc en prod, llavors òbviament el DBA diria: "Això no es pot fer. .”
I diria que tindreu problemes amb l'E/S del disc i tots els processos es tornaran bojos, pot haver-hi bloquejos, i també bloquejareu l'autoaspiració durant un munt de minuts, així que això no és bo.
El segon error: van comprovar al lloc equivocat. Després del fet, vam veure que s'acumulava moltes dades no desitjades al producte, però el desenvolupador no tenia dades acumulades en aquesta base de dades i ningú va crear aquesta brossa durant la posada en escena. En conseqüència, hi va haver 1 línies que van funcionar ràpidament.
Entenem que les nostres proves són febles, és a dir, el procés que es construeix no capta problemes. No es va realitzar un experiment de DB adequat.
Un experiment ideal es realitza preferentment amb el mateix equip. No sempre és possible fer-ho en el mateix equip, però és molt important que sigui una còpia a mida completa de la base de dades. Això és el que estic predicant des de fa uns quants anys. I fa un any vaig parlar d'això, ho podeu veure tot a YouTube.
Potser el nostre equipament és dolent? Si mireu, la latència va saltar. Hem vist que la utilització és del 100%. Per descomptat, si aquestes fossin unitats NVMe modernes, probablement ens seria molt més fàcil. I potser no ens acostaríem.
Si teniu núvols, l'actualització es fa fàcilment allà. S'han creat noves rèpliques al nou maquinari. commutar. I tot va bé. Bastant fàcil.
És possible tocar d'alguna manera els discs més petits? I aquí, només amb l'ajuda de DBA, ens submergim en un tema determinat anomenat sintonització del punt de control. Resulta que no teníem sintonització de punts de control.
Què és el punt de control? Està en qualsevol SGBD. Quan teniu dades a la memòria que canvien, no s'escriuen immediatament al disc. La informació que han canviat les dades s'escriu primer al registre d'escriptura anticipada. I en algun moment, el SGBD decideix que és hora d'abocar pàgines reals al disc, de manera que si tenim un error, podem fer menys REDO. És com una joguina. Si ens maten, començarem el joc des de l'últim punt de control. I tots els DBMS ho implementen.
La configuració de Postgres està endarrerida. Estan dissenyats per a volums de dades i transaccions d'entre 10 i 15 anys. I el control no és una excepció.
Aquí teniu la informació del nostre informe de control de Postgres, és a dir, la comprovació de salut automàtica. I aquí teniu una base de dades de diversos terabytes. I es veu bé que els punts de control forçats en gairebé el 90% dels casos.
Què vol dir? Hi ha dues configuracions. El punt de control pot arribar amb el temps d'espera, per exemple, als 10 minuts. O pot arribar quan s'han omplert moltes dades.
I, per defecte, max_wal_saze s'estableix en 1 gigabyte. De fet, això passa realment a Postgres després de 300-400 megabytes. Heu canviat tantes dades i el vostre punt de control passa.
I si ningú el va ajustar, i el servei va créixer, i l'empresa guanya molts diners, té moltes transaccions, llavors el punt de control arriba una vegada per minut, de vegades cada 30 segons, i de vegades fins i tot es solapa. Això és bastant dolent.
I hem d'assegurar-nos que vingui amb menys freqüència. És a dir, podem augmentar max_wal_size. I vindrà amb menys freqüència.
Però hem desenvolupat tota una metodologia sobre com fer-ho de manera més correcta, és a dir, com prendre una decisió sobre l'elecció de la configuració, clarament basada en dades concretes.
En conseqüència, estem fent dues sèries d'experiments sobre bases de dades.
La primera sèrie: canviem max_wal_size. I estem fent una operació massiva. Primer, ho fem amb la configuració predeterminada d'1 gigabyte. I fem una SUPRIMACIÓ massiva de molts milions de línies.
Podeu veure com ens costa. Veiem que l'IO del disc és molt dolent. Mirem quants WAL hem generat, perquè això és molt important. A veure quantes vegades ha passat el control. I veiem que no és bo.
A continuació, augmentem max_wal_size. Repetim. Augmentem, repetim. I tantes vegades. En principi, 10 punts és bo, on 1, 2, 4, 8 gigabytes. I mirem el comportament d'un sistema determinat. Està clar que aquí l'equip hauria de ser com en producte. Heu de tenir els mateixos discs, la mateixa quantitat de memòria i la mateixa configuració de Postgres.
I d'aquesta manera intercanviarem el nostre sistema, i sabem com es comportarà el SGBD en cas d'una mala massa DELETE, com es farà el punt de control.
Els punts de control en rus són els punts de control.
Exemple: ELIMINEU diversos milions de files per índex, les files estan "escampades" per pàgines.
Aquí teniu un exemple. Això és una base. I amb la configuració predeterminada d'1 gigabyte per a max_wal_size, és molt clar que els nostres discs van a la prestatgeria per gravar-los. Aquesta imatge és un símptoma típic d'un pacient molt malalt, és a dir, es va sentir molt malament. I hi va haver una única operació, només hi va haver una SUPRESIÓ de diversos milions de línies.
Si aquesta operació està permesa en prod, només ens estirem, perquè està clar que un DELETE ens mata a la prestatgeria.
A més, on 16 gigabytes, està clar que les dents ja han anat. Les dents ja estan millors, és a dir, estem tocant el sostre, però no tan malament. Allà hi havia una mica de llibertat. A la dreta hi ha el registre. I el nombre d'operacions - el segon gràfic. I és evident que ja estem respirant una mica més fàcil quan tenim 16 gigabytes.
I on 64 gigabytes es pot veure que ha millorat completament. Ja les dents estan pronunciades, hi ha més oportunitats per sobreviure a altres operacions i fer alguna cosa amb el disc.
Per què?
Aprofundiré una mica en els detalls, però aquest tema, com s'ajusta el punt de control, pot donar lloc a un informe complet, de manera que no carregaré gaire, però descriuré una mica quines dificultats hi ha.
Si el punt de control passa massa sovint, i actualitzem les nostres línies no de manera seqüencial, però trobem per índex, que és bo, perquè no suprimim tota la taula, llavors pot passar que al principi toquem la primera pàgina, després la mil·lèsima, i després va tornar a la primera. I si entre aquestes visites a la primera pàgina, checkpoint ja l'ha desat al disc, llavors el desarà de nou, perquè l'hem embrutat una segona vegada.
I forçarem el punt de control per salvar-lo moltes vegades. Com hi hauria operacions redundants per a ell.
Però això no és tot. Les pàgines tenen 8 kilobytes a Postgres i 4 kilobytes a Linux. I hi ha una configuració full_page_writes. Està habilitat per defecte. I això és correcte, perquè si l'apagam, hi ha el perill que només es desi la meitat de la pàgina si es bloqueja.
El comportament d'escriure al WAL del registre d'enviament és tal que quan tenim un punt de control i canviem la pàgina per primera vegada, tota la pàgina, és a dir, els 8 kilobytes, entra al registre d'enviament, tot i que només hem canviat la pàgina. línia, que pesa 100 bytes. I hem d'anotar tota la pàgina.
En canvis posteriors, només hi haurà una tupla concreta, però per primera vegada ho anotem tot.
I, en conseqüència, si el punt de control tornava a passar, haurem de tornar a començar tot des de zero i empènyer tota la pàgina. Amb punts de control freqüents, quan passem per les mateixes pàgines, full_page_writes = on serà més del que podria ser, és a dir, generem més WAL. S'envia més a les rèpliques, a l'arxiu, al disc.
I, en conseqüència, tenim dos acomiadaments.
Si augmentem max_wal_size, resulta que ho facilitem tant per al checkpoint com per al wal writer. I això és genial.
Posem un terabyte i vivim amb ell. Què hi ha de dolent? Això és dolent, perquè en cas de fallada, pujarem hores, perquè el control era fa molt de temps i ja han canviat moltes coses. I hem de fer tot això REDO. I així fem la segona sèrie d'experiments.
Fem una operació i veiem quan el punt de control està a punt de completar-se, matem -9 Postgres a propòsit.
I després d'això, tornem a començar, i veiem quant de temps pujarà en aquest equip, és a dir, quant tornarà a REFER en aquesta mala situació.
Dos cops notaré que la situació és dolenta. Primer, ens vam estavellar just abans que s'acabés el control, així que tenim molt a perdre. I en segon lloc, vam tenir una operació massiva. I si els punts de control estiguessin en temps d'espera, llavors, molt probablement, es generaria menys WAL des de l'últim punt de control. És a dir, és un doble perdedor.
Mesurem aquesta situació per a diferents mides max_wal_size i entenem que si max_wal_size és de 64 gigabytes, aleshores, en el pitjor dels casos, pujarem durant 10 minuts. I pensem si ens convé o no. Aquesta és una pregunta empresarial. Hem de mostrar aquesta imatge als responsables de les decisions empresarials i preguntar-nos: “Quant de temps ens podem estirar com a màxim en cas d'un problema? Podem estirar-nos en la pitjor situació durant 3-5 minuts? I tu prens una decisió.
I aquí hi ha un punt interessant. Tenim un parell d'informes sobre Patroni a la conferència. I potser l'estàs utilitzant. Aquest és un error automàtic per a Postgres. GitLab i Data Egret en van parlar.
I si teniu una fallada automàtica que arriba en 30 segons, potser podrem estirar-nos durant 10 minuts? Perquè en aquest moment canviarem a la rèplica i tot anirà bé. Aquest és un punt discutible. No sé una resposta clara. Crec que aquest tema no només tracta de la recuperació d'un accident.
Si tenim una llarga recuperació després d'un fracàs, ens sentirem incòmodes en moltes altres situacions. Per exemple, en els mateixos experiments, quan fem alguna cosa i de vegades hem d'esperar 10 minuts.
Encara no aniria massa lluny, encara que tinguem un autofailover. Per regla general, valors com 64, 100 gigabytes són bons valors. De vegades, fins i tot val la pena escollir-ne menys. En general, aquesta és una ciència subtil.
Per fer iteracions, per exemple, max_wal_size =1, 8, heu de repetir l'operació massiva moltes vegades. Ho has fet. I sobre la mateixa base voleu tornar a fer-ho, però ja ho heu esborrat tot. Què fer?
Més endavant parlaré de la nostra solució, què fem per repetir en aquestes situacions. I aquest és l'enfocament més correcte.
Però en aquest cas, vam tenir sort. Si, com diu aquí "BEGIN, DELETE, ROLLBACK", llavors podem repetir DELETE. És a dir, si ho cancel·lem nosaltres mateixos, podem repetir-ho. I físicament, les dades estaran al mateix lloc. Ni tan sols tens cap inflor. Podeu iterar sobre aquests SUPRIMIES.
Aquesta DELETE amb ROLLBACK és ideal per ajustar el punt de control, fins i tot si no teniu un laboratori de base de dades desplegat correctament.
Hem fet un plat amb una columna "i". Postgres té columnes d'utilitat. Són invisibles tret que se'ls demani específicament. Aquests són: ctid, xmid, xmax.
Ctid és una adreça física. Pàgina zero, la primera tupla de la pàgina.
Es pot veure que després de ROOLBACK la tupla es va quedar al mateix lloc. És a dir, ho podem tornar a provar, es comportarà de la mateixa manera. Això és el principal.
Xmax és el moment de la mort de la tupla. Es va estampar, però Postgres sap que la transacció es va revertir, així que no importa si és 0 o es tracta d'una transacció revertida. Això suggereix que és possible iterar sobre DELETE i comprovar les operacions massives del comportament del sistema. Podeu fer laboratoris de bases de dades per als pobres.
Això és sobre programadors. Sobre DBA, també, sempre renyen als programadors per això: "Per què feu operacions tan llargues i difícils?". Aquest és un tema perpendicular completament diferent. Abans hi havia administració, i ara hi haurà desenvolupament.
Evidentment, no ens hem trencat a trossos. Està clar. És impossible no trencar aquest DELETE per un munt de milions de línies en parts. Es farà durant 20 minuts, i tot s'estirarà. Però, malauradament, fins i tot els desenvolupadors experimentats cometen errors, fins i tot en empreses molt grans.
Per què és important trencar?
-
Si veiem que el disc és dur, alentirem-lo. I si estem trencats, podem afegir pauses, podem frenar l'acceleració.
-
I no bloquejarem els altres durant molt de temps. En alguns casos, no importa, si esteu suprimint escombraries reals en què ningú està treballant, el més probable és que no bloquegeu ningú, excepte el treball d'aspiració automàtica, perquè esperarà que es completi la transacció. Però si elimineu alguna cosa que algú altre pugui sol·licitar, es bloquejarà, hi haurà algun tipus de reacció en cadena. S'han d'evitar transaccions llargues en llocs web i aplicacions mòbils.
Això és interessant. Sovint veig que els desenvolupadors es pregunten: "Quina mida de paquet he de triar?".
És evident que com més gran sigui la mida del paquet, més petita serà la sobrecàrrega de transacció, és a dir, la sobrecàrrega addicional de les transaccions. Però al mateix temps, el temps per a aquesta transacció augmenta.
Tinc una regla molt senzilla: agafa tant com puguis, però no revisis els executables per segon.
Per què un segon? L'explicació és molt senzilla i comprensible per a tothom, fins i tot per a persones no tècniques. Veiem una reacció. Prenem 50 mil·lisegons. Si alguna cosa ha canviat, el nostre ull reaccionarà. Si és menys, més difícil. Si alguna cosa respon després de 100 mil·lisegons, per exemple, heu fet clic amb el ratolí i us ha contestat després de 100 mil·lisegons, ja sentiu aquest lleuger retard. Un segon ja es percep com a frens.
En conseqüència, si dividim les nostres operacions massives en ràfegues de 10 segons, correm el risc de bloquejar algú. I funcionarà durant uns segons, i la gent ja ho notarà. Per tant, prefereixo no fer més d'un segon. Però, al mateix temps, no el trenqueu molt finament, perquè la sobrecàrrega de la transacció es notarà. La base serà més dura i poden sorgir altres problemes diferents.
Triem la mida del paquet. En cada cas, ho podem fer de manera diferent. Es pot automatitzar. I estem convençuts de l'eficiència del processament d'un paquet. És a dir, fem SUPRIMIR un paquet o ACTUALITZAR.
Per cert, tot el que estic parlant no és només de SUPRIMIR. Com heu endevinat, aquestes són operacions massives sobre dades.
I veiem que el pla és excel·lent. Podeu veure l'anàlisi d'índex, l'exploració només d'índex és encara millor. I tenim una petita quantitat de dades implicades. I menys d'un segon compleix. Súper.
I encara hem d'assegurar-nos que no hi hagi degradació. Passa que els primers paquets funcionen ràpidament, i després cada cop empitjora. El procés és tal que cal provar molt. Això és exactament per al que serveixen els laboratoris de bases de dades.
I encara hem de preparar alguna cosa perquè ens permeti seguir-ho correctament en la producció. Per exemple, podem escriure l'hora al registre, podem escriure on som ara i qui hem esborrat ara. I això ens permetrà entendre què està passant més endavant. I en cas que alguna cosa surti malament, trobeu ràpidament el problema.
Si hem de comprovar l'eficiència de les sol·licituds i hem de repetir moltes vegades, aleshores hi ha un bot. Ell ja està preparat. Desenes de desenvolupadors l'utilitzen diàriament. I sap com donar una gran base de dades de terabytes a petició en 30 segons, la teva pròpia còpia. I podeu suprimir alguna cosa allà i dir RESTAURAR i suprimir-lo de nou. Podeu experimentar-ho d'aquesta manera. Hi veig un futur per a aquesta cosa. I ja ho estem fent.
Quines són les estratègies de partició? Veig 3 estratègies de partició diferents que estan utilitzant els desenvolupadors del paquet.
El primer és molt senzill. Tenim un identificador numèric. I desglossem-ho en diferents intervals i treballem amb això. L'inconvenient és clar. En el primer segment, podem tenir 100 línies d'escombraries reals, en el segon 5 línies o no, o les 1 línies resultaran ser escombraries. Treball molt irregular, però fàcil de trencar. Van agafar la màxima identificació i la van trencar. Aquest és un enfocament ingenu.
La segona estratègia és un enfocament equilibrat. S'utilitza a Gitlab. Van agafar i escanejar la taula. Hem trobat els límits dels paquets d'identificació de manera que cada paquet tingués exactament 10 registres. I posar-los a la cua. I després processem. Podeu fer-ho en diversos fils.
A la primera estratègia, també, per cert, podeu fer-ho en diversos fils. No és difícil.
Però hi ha un enfocament més fresc i millor. Aquesta és la tercera estratègia. I quan sigui possible, és millor triar-lo. Ho fem a partir d'un índex especial. En aquest cas, probablement serà un índex d'acord amb la nostra condició d'escombraries i identificació. Inclourem l'ID perquè sigui només un escaneig d'índex perquè no anem a l'heap.
En general, l'exploració només d'índex és més ràpida que l'exploració d'índex.
I ràpidament trobem els nostres identificadors que volem eliminar. BATCH_SIZE seleccionem per endavant. I no només els aconseguim, els aconseguim d'una manera especial i immediatament els pirategem. Però estem tancant perquè si ja estan tancats, no els tanquem, sinó que seguim i agafem els següents. Això és per a l'actualització bloquejada. Aquesta súper característica de Postgres ens permet treballar en diversos fils si volem. És possible en un sol flux. I aquí hi ha un CTE: aquesta és una sol·licitud. I tenim una supressió real al segon pis d'aquest CTE - returning *. Podeu tornar l'identificador, però és millor *si no teniu moltes dades a cada línia.
Per què ho necessitem? Això és el que hem d'informar. De fet, ara hem suprimit tantes línies. I tenim vores per ID o per create_at com aquesta. Podeu fer min, max. Es pot fer una altra cosa. Aquí podeu omplir moltes coses. I és molt convenient per al seguiment.
Hi ha una nota més sobre l'índex. Si decidim que necessitem un índex especial per a aquesta tasca, hem d'assegurar-nos que no fa malbé les actualitzacions de tuples només. És a dir, Postgres té aquestes estadístiques. Això es pot veure a pg_stat_user_tables per a la vostra taula. Podeu veure si s'estan utilitzant actualitzacions en calent o no.
Hi ha situacions en què el vostre nou índex simplement pot tallar-los. I teniu totes les altres actualitzacions que ja funcionen, alentiu-vos. No només perquè va aparèixer l'índex (cada índex frena una mica les actualitzacions, però una mica), sinó que aquí encara l'arruïna. I és impossible fer una optimització especial per a aquesta taula. Això passa de vegades. Aquesta és una subtilesa que poca gent recorda. I aquest rastell és fàcil de trepitjar. De vegades passa que necessiteu trobar un enfocament des de l'altre costat i encara prescindir d'aquest nou índex, o fer un altre índex, o d'alguna altra manera, per exemple, podeu utilitzar el segon mètode.
Però aquesta és l'estratègia més òptima, com dividir-se en lots i disparar a lots amb una sol·licitud, eliminar una mica, etc.
Transaccions llargues
Autobuit bloquejat -
problema de bloqueig -
L'error número 5 és gran. Nikolai d'Okmeter va parlar del seguiment de Postgres. El seguiment ideal de Postgres, malauradament, no existeix. Alguns estan més a prop, altres més lluny. Okmeter està prou a prop de ser perfecte, però falta molt i cal afegir-hi. Has d'estar preparat per a això.
Per exemple, les tuples mortes es controlen millor. Si tens moltes coses mortes a la taula, llavors alguna cosa no funciona. És millor reaccionar ara, sinó pot haver-hi degradació, i ens podem estirar. Això passa.
Si hi ha una IO gran, està clar que això no és bo.
Transaccions llargues també. Les transaccions llargues no s'han de permetre a OLTP. I aquí teniu un enllaç a un fragment que us permet agafar aquest fragment i ja fer un seguiment de transaccions llargues.
Per què les transaccions llargues són dolentes? Perquè tots els panys s'alliberaran només al final. I fotem a tothom. A més, bloquegem l'autoaspiració per a totes les taules. No és gens bo. Fins i tot si teniu activat el mode d'espera en calent a la rèplica, encara és dolent. En general, enlloc és millor evitar transaccions llargues.
Si tenim moltes taules que no s'aspiren, hem de tenir una alerta. Aquí una situació així és possible. Podem afectar indirectament el funcionament de l'autobuit. Aquest és un fragment d'Avito, que vaig millorar lleugerament. I va resultar ser una eina interessant per veure què tenim amb l'autoaspirador. Per exemple, algunes taules hi estan esperant i no esperaran el seu torn. També cal posar-lo en seguiment i tenir una alerta.
I emet blocs. Bosc d'arbres de bloc. M'agrada agafar alguna cosa d'algú i millorar-la. Aquí vaig prendre un CTE recursiu genial de Data Egret que mostra un bosc d'arbres de pany. Aquesta és una bona eina de diagnòstic. I sobre la seva base, també podeu crear un seguiment. Però això s'ha de fer amb cura. Heu de fer un petit statement_timeout per vosaltres mateixos. I lock_timeout és desitjable.
De vegades, tots aquests errors es produeixen en suma.
Al meu entendre, el principal error aquí és organitzatiu. És organitzatiu, perquè la tècnica no tira. Aquest és el número 2: han comprovat al lloc equivocat.
Hem comprovat al lloc equivocat, perquè no teníem un clon de producció, cosa que és fàcil de comprovar. És possible que un desenvolupador no tingui accés a la producció.
I no vam comprovar allà. Si haguéssim comprovat allà, ho hauríem vist nosaltres mateixos. El desenvolupador ho va veure tot fins i tot sense DBA si ho va comprovar en un bon entorn, on hi ha la mateixa quantitat de dades i una ubicació idèntica. Ell hauria vist tota aquesta degradació i li faria vergonya.
Més informació sobre l'autoaspiració. Després d'haver fet una escombrada massiva de diversos milions de línies, encara hem de fer REPACK. Això és especialment important per als índexs. Es sentiran malament després que hàgim netejat tot allà.
I si voleu recuperar el treball de neteja diari, us suggeriria que ho feu més sovint, però més petit. Pot ser una vegada per minut o fins i tot més sovint una mica. I cal vigilar dues coses: que aquesta cosa no tingui errors i que no es quedi enrere. El truc que vaig mostrar només solucionarà això.
El que fem és de codi obert. Està publicat a GitLab. I ho fem perquè la gent pugui comprovar fins i tot sense un DBA. Estem fent un laboratori de bases de dades, és a dir, anomenem el component base en què treballa actualment en Joe. I podeu agafar una còpia de la producció. Ara hi ha una implementació de Joe per slack, podeu dir allà: "explicar tal o tal sol·licitud" i obtenir immediatament el resultat de la vostra còpia de la base de dades. Fins i tot pots ELIMINAR allà, i ningú ho notarà.
Suposem que teniu 10 terabytes, fem que el laboratori de bases de dades també sigui de 10 terabytes. I amb bases de dades simultànies de 10 terabytes, 10 desenvolupadors poden treballar simultàniament. Cadascú pot fer el que vulgui. Pot suprimir, deixar anar, etc. Això és una fantasia. D'això en parlarem demà.
Això s'anomena thin provisioning. Això és un aprovisionament subtil. Aquesta és una mena de fantasia que elimina en gran mesura els retards en el desenvolupament, en les proves i fa que el món sigui un lloc millor en aquest sentit. És a dir, només us permet evitar problemes amb operacions massives.
Exemple: base de dades de 5 terabytes, obtenint una còpia en menys de 30 segons. I ni tan sols depèn de la mida, és a dir, no importa quants terabytes.
Avui pots anar-hi i aprofundir en les nostres eines. Podeu registrar-vos per veure què hi ha. Podeu instal·lar aquest bot. És gratis. Escriu.
Les vostres preguntes
Molt sovint en situacions reals resulta que les dades que haurien de romandre a la taula són molt inferiors a les que s'han d'esborrar. És a dir, en aquesta situació, sovint és més fàcil implementar aquest enfocament, quan és més fàcil crear un objecte nou, copiar-hi només les dades necessàries i connectar la taula antiga. És clar que cal un enfocament programàtic per a aquest moment, mentre canviaràs. Com és aquest plantejament?
Aquest és un molt bon enfocament i una molt bona tasca. És molt semblant al que fa pg_repack, és molt semblant al que has de fer quan fas ID de 4 bytes. Molts marcs ho van fer fa uns anys, i només les plaques han crescut i s'han de convertir a 8 bytes.
Aquesta tasca és força difícil. Ho hem fet. I cal anar molt en compte. Hi ha panys, etc. Però s'està fent. És a dir, l'enfocament estàndard és anar amb pg_repack. Vostè declara aquesta etiqueta. I abans de començar a penjar-hi dades de la instantània, també declareu una placa que fa un seguiment de tots els canvis. Hi ha un truc que pot ser que ni tan sols feu un seguiment d'alguns canvis. Hi ha subtileses. I després canvieu fent canvis. Hi haurà una breu pausa quan tanquem tothom, però en general això s'està fent.
Si mireu pg_repack a GitHub, aleshores, quan hi havia una tasca per convertir un ID d'int 4 a int 8, hi havia una idea d'utilitzar pg_repack. Això també és possible, però és una mica un pirateig, però també funcionarà per a això. Podeu intervenir en el disparador que fa servir pg_repack i dir allà: "No necessitem aquestes dades", és a dir, només transferim el que necessitem. I després només canvia i ja està.
Amb aquest enfocament, encara obtenim una segona còpia de la taula, en la qual les dades ja estan indexades i apilades de manera molt uniforme amb índexs bonics.
La inflor no és present, és un bon enfocament. Però sé que hi ha intents de desenvolupar una automatització per a això, és a dir, fer una solució universal. Et puc posar en contacte amb aquesta automatització. Està escrit en Python, que és una bona cosa.
Sóc una mica del món de MySQL, així que vaig venir a escoltar. I fem servir aquest enfocament.
Però és només si tenim el 90%. Si tenim un 5%, no és molt bo utilitzar-lo.
Gràcies pel reportatge! Si no hi ha recursos per fer una còpia completa de prod, hi ha algun algorisme o fórmula per calcular la càrrega o la mida?
Bona pregunta. Fins ara, som capaços de trobar bases de dades de diversos terabytes. Encara que el maquinari no sigui el mateix, per exemple, menys memòria, menys processador i discs no són exactament iguals, però així i tot ho fem. Si no hi ha enlloc, cal pensar. Deixa'm pensar fins demà, has vingut, en parlarem, aquesta és una bona pregunta.
Gràcies pel reportatge! Primer vas començar amb el fet que hi ha un Postgres genial, que té tals i tals limitacions, però s'està desenvolupant. I tot això és una crossa en general. No està tot això en conflicte amb el desenvolupament del mateix Postgres, en el qual apareixerà algun deferent DELETE o alguna cosa més que hauria de mantenir a un nivell baix el que estem intentant untar amb alguns dels nostres estranys mitjans aquí?
Si vam dir a SQL que esborram o actualitzem molts registres en una transacció, com pot distribuir-lo Postgres allà? Estem físicament limitats en les operacions. Encara ho farem durant molt de temps. I tancarem en aquest moment, etc.
Fet amb índexs.
Puc suposar que la mateixa sintonització del punt de control es podria automatitzar. Algun dia podria ser. Però aleshores no entenc realment la pregunta.
La pregunta és, hi ha aquest vector de desenvolupament que va aquí i allà, i aquí el teu va paral·lel? Aquells. Encara no s'ho han pensat?
Vaig parlar dels principis que es poden utilitzar ara. Hi ha un altre bot , amb això podeu fer una sintonització automatitzada del punt de control. Algun dia serà a Postgres? No ho sé, encara no s'ha parlat. Encara estem lluny d'això. Però hi ha científics que fan nous sistemes. I ens introdueixen als índexs automàtics. Hi ha novetats. Per exemple, podeu mirar l'ajust automàtic. Selecciona els paràmetres automàticament. Però encara no farà la sintonització del punt de control per a tu. És a dir, augmentarà el rendiment, la memòria intermèdia, etc.
I per ajustar el punt de control, podeu fer això: si teniu mil clústers i maquinari diferent, diferents màquines virtuals al núvol, podeu utilitzar el nostre bot fer automatització. I max_wal_size es seleccionarà automàticament segons la configuració de l'objectiu. Però fins ara això ni tan sols està a prop del nucli, malauradament.
Bona tarda Vostè va parlar dels perills de les transaccions llargues. Vostè va dir que l'autobuit està bloquejat en cas d'eliminació. Com més ens perjudica? Perquè estem parlant més d'alliberar espai i poder-lo utilitzar. Què més ens perdem?
L'aspirat automàtic potser no és el problema més gran aquí. I el fet que una transacció llarga pugui bloquejar altres transaccions, aquesta possibilitat és més perillosa. Es pot trobar o no. Si es coneix, pot ser molt dolent. I amb el buit automàtic, això també és un problema. Hi ha dos problemes amb les transaccions llargues a OLTP: bloquejos i buit automàtic. I si teniu activada la retroalimentació d'espera activa a la rèplica, encara rebreu un bloqueig de buit automàtic al mestre, que arribarà de la rèplica. Però almenys no hi haurà panys. I hi haurà loks. Estem parlant de canvis de dades, així que els bloquejos són un punt important aquí. I si tot això és durant molt, molt de temps, cada cop hi ha més transaccions bloquejades. Poden robar altres. I apareixen els arbres de lok. He proporcionat un enllaç al fragment. I aquest problema es fa més notable més ràpidament que el problema amb l'autobuit, que només es pot acumular.
Gràcies pel reportatge! Heu començat el vostre informe dient que heu fet la prova incorrectament. Vam continuar amb la nostra idea que hem de portar el mateix equipament, amb la base de la mateixa manera. Suposem que hem donat una base al desenvolupador. I va complir la petició. I sembla que està bé. Però no comprova en directe, sinó en directe, per exemple, tenim una càrrega del 60-70%. I encara que utilitzem aquesta sintonia, no funciona gaire bé.
És important tenir un expert a l'equip i utilitzar experts DBA que puguin predir què passarà amb una càrrega de fons real. Quan acabem de fer els nostres canvis nets, veiem la imatge. Però un enfocament més avançat, quan vam tornar a fer el mateix, però amb una càrrega simulada amb la producció. És força xulo. Fins aleshores, has de créixer. És com un adult. Només hem mirat el que tenim i també hem mirat si tenim prou recursos. Aquesta és una bona pregunta.
Quan ja estem fent una selecció d'escombraries i tenim, per exemple, una bandera esborrada
Això és el que fa automàticament l'autovacuum a Postgres.
Ah, ho fa?
Autovacuum és el col·lector d'escombraries.
Gràcies!
Gràcies pel reportatge! Hi ha una opció per dissenyar immediatament una base de dades amb particions de tal manera que totes les escombraries s'embrutin de la taula principal en algun lloc cap al costat?
Per descomptat tenir.
És possible, doncs, protegir-nos si hem tancat una taula que no s'hauria d'utilitzar?
Per descomptat tenir. Però és com una pregunta d'ou i gallina. Si tots sabem què passarà en el futur, llavors, per descomptat, ho farem tot genial. Però el negoci està canviant, hi ha noves columnes, noves peticions. I després, vaja, volem eliminar-lo. Però aquesta situació ideal, a la vida es produeix, però no sempre. Però en general és una bona idea. Només trunqueu i ja està.
Font: www.habr.com