Dimensione del database ridotta dopo il backup su PostgreSQL 8.3 e ripristino in PostgreSQL 9.4


8

Ho fatto un pg_dumpdatabase JIRA che ospitavo in un server PostgreSQL 8.3. La dimensione del database dopo vacuum fullera 217132652(circa 207 MB).

Quindi ho ripristinato quel database JIRA su un server PostgreSQL 9.4 con il seguente comando:

$ psql -X -v ON_ERROR_STOP=1 -d jira2 -U jira -h localhost < jiradb2017_03_12.sql

Presumo che il ripristino sarebbe ON_ERROR_STOP=1terminato su qualsiasi errore da quando l'ho usato , ma lo script SQL è stato completato correttamente (nonostante alcuni avvisi non correlati al ripristino dei dati).

Ho finito con un database con una dimensione di 158019348(circa 151 MB).

Allora, qual è la storia qui? Posso solo supporre che il database sia stato ripristinato correttamente e PostgreSQL abbia ottimizzato il motore di archiviazione (da qualche parte tra le versioni 8.3 e 9.4) e utilizzi lo spazio in modo più efficiente?


3
Pablo, hai provato a ripristinare la versione 8.3 e controllare le dimensioni? Lo confermerebbe o eliminerebbe qualsiasi effetto della versione cahnge
Jack dice di provare topanswers.xyz il

Risposte:


10

Quando ripristini un database hai tutte le informazioni in esso contenute , senza spazio vuoto tra le righe (o negli indici), a meno che non siano presenti alcune impostazioni specifiche (in pratica: FILLFACTORper le tabelle e FILLFACTORper gli indici ).

D'altra parte, quando il database è in uso da un po 'di tempo e hai avuto la tua quota di inserimenti, aggiornamenti ed eliminazioni, apparirà spazio libero inutilizzato . Ciò è dovuto al modo in cui PostgreSQL e Multiversion Concurrency Control, ovvero MVCC, funzionano. MVCC consente meno blocchi, il che significa sostanzialmente che risparmi tempo . Ma paghi un prezzo in termini di spazio :

  1. Ognuno UPDATEequivale a un INSERTinsieme a a DELETE, con il sovraccarico (almeno in termini di spazio utilizzato) associato ad entrambi.
  2. Quando si dispone di più operazioni in esecuzione, e ognuno è INSERTing, UPDATEing o DELETEing, si ha contemporaneamente più copie di ogni riga coinvolti.
  3. Lo spazio assegnato a queste versioni di riga non verrà liberato immediatamente dopo il commit e per un po 'sarà spazio inutilizzato all'interno dei file in cui sono archiviati i dati della tabella (e gli indici).

Autovacuum si occupa di rendere questo spazio riutilizzabile di default, oppure potresti avere una procedura specifica per l' aspirazione di routine .

Questo fatto può già spiegare il cambiamento di dimensione.

Probabilmente si sono verificate anche ottimizzazioni tra le versioni; e può spiegare ulteriori miglioramenti. Potrebbero anche essere state apportate ottimizzazioni per la velocità e non per le dimensioni, e le dimensioni effettive potrebbero effettivamente aumentare da una versione all'altra. Davvero non conosco i dettagli per poterlo dire; sebbene il commento di @Erwin affermi che entrambe le modifiche che fanno restringere le tue tabelle e quelle che fanno gonfiare (crescere) le tue tabelle sono avvenute dalla versione 8.3.

Per distinguere tra i due effetti, se sei curioso, potresti semplicemente, come suggerisce @ Jack Douglas, ripristinare il tuo database su 8.3. Molto probabilmente si ridurrà di dimensioni. Se si riduce a meno di 151 MB (una dimensione inferiore a quella ottenuta con la versione 9.4), la rimozione dello spazio inutilizzato ha ridotto il tuo DB e la modifica della versione ha effettivamente fatto crescere il tuo DB.


Per una migliore comprensione di MVCC, guarda la presentazione di Bruce Momjian .


1
Questo è molto al punto. E sì, da Postgres 8.3 sono state apportate modifiche sia alla riduzione delle dimensioni della tabella di base che alla riduzione.
Erwin Brandstetter,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.