pgcompactor
Cred că mulți oameni cunosc caracteristica PostgreSQL, ceea ce duce la efectul umflării tabelelor sau al balonului de masă. Se știe că se manifestă în cazuri de actualizare intensivă a datelor, atât cu operații UPDATE frecvente, cât și cu operații INSERT / DELETE. Ca rezultat al acestei inflații, productivitatea este redusă. De fapt, întrebarea este cum să comprimați masa în postgres? Mai jos este răspunsul și, în același timp, vom analiza de ce se întâmplă acest lucru și cum să facem acest lucru.
Tabelele din PostgreSQL prezentate sub formă de pagini, dimensiune 8kb, care are intrări. Atunci când o pagină este complet umplut cu înregistrări, se adaugă un tabel la noua pagină. Atunci când înregistrările udalaleni folosind DELETE sau modifica prin intermediul UPDATE, locul în care au fost de înregistrare vechi nu pot fi refolosite imediat. Pentru acest proces de curățare autovacuum, sau comanda VACUUM, ruleaza pe modificate paginile și marcați un loc ca liber, după care noi intrări pot fi ușor înregistrate în acest loc. În cazul în care autovacuum nu face, de exemplu, ca urmare a modificărilor în mai multe date active sau pur și simplu din cauza setărilor proaste, atunci un tabel va fi necesară pentru a adăuga noi pagini ca noi recorduri. Și chiar și după curățare va ajunge la înregistrările noastre la distanță, noi pagini vor rămâne. Se pare că tabelul devine mai sărăcită în ceea ce privește densitatea de înregistrare. Aceasta se numește efectul de umflare a tabelelor, tabelul bloat.
Procedeul de curățare, autovacuum sau VACUUM, poate reduce dimensiunea tabelei de pagini goale îndepărtarea completă, dar numai cu condiția ca acestea să fie în partea de jos a tabelului. Pentru a minimiza tabelul din PostgreSQL are o VID FULL sau clusterului, dar ambele metode necesită instalarea de încuietori grele și lungi la o masă care nu este întotdeauna cel mai bun.
Să luăm în considerare una dintre soluții. Când actualizați o intrare utilizând UPDATE, dacă există un spațiu liber în tabel, noua versiune va merge în spațiul liber, fără a selecta pagini noi. Preferința este dată spațiului liber mai aproape de începutul mesei. Dacă actualizați tabelul utilizând așa-numitul. false actualizări, cum ar fi some_column = some_column din ultima pagină, la un moment dat, toate intrările de pe ultima pagină vor ajunge la spațiul liber din paginile anterioare ale tabelului. Astfel, după mai multe astfel de operații, ultimele pagini vor fi goale, iar VACUUM-ul obișnuit care nu blochează le poate tăia de pe masă, reducând dimensiunea.
Ca urmare, cu ajutorul acestei tehnici este posibilă comprimarea maximă a mesei, fără a provoca blocări critice și astfel fără a împiedica alte sesiuni și funcționarea normală a bazei de date.
Și acum cel mai important)))) Pentru automatizarea acestei proceduri există un utilitar pgcompactor.
Principalele sale caracteristici:
- Nu necesită alte dependențe decât Perl> = 5.8.8, adică puteți să copiați pur și simplu pgcompactor pe server și să lucrați cu acesta;
- funcționează prin adaptoare DBD :: Pg, DBD :: PgPP sau chiar prin utilitarul standard psql, dacă primele două nu sunt pe server;
- prelucrarea ambelor tabele individuale și a tuturor tabelelor dintr-o schemă, bază sau un întreg grup;
- posibilitatea excluderii bazelor, schemelor sau tabelelor de la prelucrare;
- analiza efectului de suflare și prelucrarea numai a tabelelor în care este prezent, pentru calcule mai precise se recomandă instalarea extensiei pgstattuple;
- analiza și refacerea indicilor cu efectul inflației;
- analiza și reconstruirea constrângerilor unice și a cheilor primare cu efectul inflației;
- utilizarea incrementală, adică Puteți opri procesul de comprimare fără a afecta nimic;
- ajustarea dinamică a încărcării curente a bazei de date, astfel încât să nu afecteze performanța solicitărilor utilizatorilor (cu capacitatea de a se adapta la pornire);
- recomandări către administratori, urmate de un DDL gata, pentru reconstruirea obiectelor bazei de date care nu pot fi reconstruite în modul automat.
Câteva exemple de utilizare:
executați pe întregul cluster cu reconstrucția necesară a indexurilor:
# pgcompactor - tot - redevență
executați pe o masă separată (cu indexări de reconstrucție):
# pgcompactor --reindex --dbname geodata - orașe disponibile --verbose info> pgcompactor.log 2> 1
Dimensiunea tabelului a scăzut de la 9.2GB la 5.6GB. Dimensiunea cumulativă a tuturor indiciilor a scăzut de la 7,5 GB la 2,8 GB
Trimiteți-le prietenilor: