Recupero dello spazio di archiviazione tramite il processo di vacuum - Amazon Aurora
AUTOVACUUMProcesso di vacuum basato sul tempo in Aurora PostgreSQL Limitless DatabaseUtilizzo delle statistiche del database per il processo di vacuumDifferenze di funzionamento del processo di vacuum

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Recupero dello spazio di archiviazione tramite il processo di vacuum

PostgreSQL Multiversion Concurrency Control (MVCC) aiuta a preservare l’integrità dei dati salvando una copia interna delle righe aggiornate o eliminate fino al commit o al rollback di una transazione. Queste copie, chiamate anche tuple, possono causare l’aumento delle dimensioni della tabella se non vengono pulite regolarmente. Le istanze PostgreSQL ordinano le transazioni in base ai relativi ID di transazione e PostgreSQL utilizza l’MVCC basato su ID di transazione per controllare la visibilità delle tuple e fornire l’isolamento delle transazioni. Ogni transazione stabilisce uno snapshot dei dati e ogni tupla possiede una versione. Sia lo snapshot che la versione sono basati sull’ID della transazione.

Per pulire i dati, l’utility VACUUM esegue in PostgreSQL quattro funzioni chiave:

  • VACUUM: rimuove le versioni di riga scadute, rendendo lo spazio disponibile per il riutilizzo.

  • VACUUM FULL: fornisce una deframmentazione completa rimuovendo le versioni delle tuple morte e compattando le tabelle, in modo da ridurre le dimensioni e aumentare l’efficienza.

  • VACUUM FREEZE: protegge dai problemi di wraparound degli ID delle transazioni contrassegnando le versioni di riga precedenti come bloccate.

  • VACUUM ANALYZE rimuove le versioni delle tuple morte e aggiorna le statistiche di pianificazione delle query del database. Si tratta di una combinazione delle funzioni VACUUM e ANALYZE. Per ulteriori informazioni sul funzionamento di ANALYZE in Aurora PostgreSQL Limitless Database, consulta ANALYZE.

Come in MVCC, anche in Aurora PostgreSQL il processo di vacuum è basato sull’ID delle transazioni. Se al momento dell’avvio del processo di vacuum è in corso una transazione, le righe ancora visibili in quella transazione non vengono rimosse.

Per ulteriori informazioni sull’utility VACUUM, consulta VACUUM nella documentazione di PostgreSQL. Per ulteriori informazioni sul supporto di VACUUM in Aurora PostgreSQL Limitless Database, consulta VACUUM.

AUTOVACUUM

Per rimuovere le tuple non necessarie, Aurora PostgreSQL ricorre alle utility VACUUM e AUTOVACUUM. Il meccanismo di base di AUTOVACUUM e del VACUUM manuale è lo stesso, l’unica differenza è l’automazione.

In Aurora PostgreSQL e Aurora PostgreSQL Limitless Database, AUTOVACUUM è una combinazione delle utility VACUUM e ANALYZE. AUTOVACUUM determina quali database e tabelle pulire in base a una regola predefinita, come la percentuale di tuple morte e il numero di inserti.

Ad esempio, AUTOVACUUM “si riattiva” periodicamente per eseguire la pulizia. L’intervallo è controllato dal parametro autovacuum_naptime. Il valore predefinito è di 1 minuto. I valori predefiniti per i parametri di configurazione AUTOVACUUM e VACUUM sono gli stessi sia per Aurora PostgreSQL Limitless Database che per Aurora PostgreSQL.

Se abilitato, il daemon AUTOVACUUM invia automaticamente i comandi ANALYZE ogni volta che il contenuto di una tabella risulta sufficientemente modificato. In Aurora PostgreSQL Limitless Database, AUTOVACUUM invia ANALYZE sia sui router che sugli shard.

Per ulteriori informazioni sul daemon AUTOVACUUM e sui parametri di archiviazione della tabella associati ad AUTOVACUUM, consulta The autovacuum daemon e Storage parameters nella documentazione di PostgreSQL.

Processo di vacuum basato sul tempo in Aurora PostgreSQL Limitless Database

Aurora PostgreSQL Limitless Database è un sistema distribuito. Questo significa che in una transazione possono essere coinvolte più istanze. Pertanto, la visibilità basata sull’ID della transazione non si applica. Aurora PostgreSQL Limitless Database utilizza la visibilità basata sul tempo, poiché se gli ID delle transazioni non sono “unificati” tra le istanze, è invece possibile “unificare” il tempo. Ogni snapshot delle transazioni e ogni versione delle tuple rispondono al tempo anziché all’ID delle transazioni. Più specificamente, agli snapshot delle transazioni è associata un’ora di inizio e alle tuple è associata un’ora di creazione (in presenza di una richiesta INSERT o un UPDATE) e un’ora di eliminazione (in presenza di una richiesta DELETE).

Per mantenere la coerenza dei dati tra le istanze del gruppo di shard di database, Aurora PostgreSQL Limitless Database deve assicurarsi che il processo di vacuum non rimuova le tuple ancora visibili su qualsiasi transazione attiva nel gruppo di shard di database. Pertanto, anche in Aurora PostgreSQL Limitless Database il processo di vacuum è basato sul tempo. Altri aspetti di VACUUM rimangono invariati, incluso il fatto che per eseguire VACUUM su una particolare tabella, un utente deve avere accesso a tale tabella.

Nota

È fortemente consigliato non lasciare le transazioni aperte per lunghi periodi di tempo.

Il processo di vacuum basato sul tempo consuma più memoria rispetto al vacuum basato sull’ID delle transazioni.

Nell’esempio seguente viene illustrato come funziona il processo di vacuum basato sul tempo.

  1. Una tabella dei clienti viene distribuita su quattro shard.

  2. La transazione 1 inizia con un livello di isolamento Repeatable Read e riguarda un solo shard (shard 1). Questa transazione rimane aperta.

    La transazione 1 è più datata di qualsiasi altra transazione iniziata dopo di essa.

  3. La transazione 2 inizia successivamente e, dopo aver eliminato tutte le tuple da una tabella, esegue il commit.

  4. Se AUTOVACUUM o il VACUUM manuale tenta di pulire le tuple morte (morte a causa della transazione 2), non rimuove nulla.

    Questo vale non solo per gli shard 1, ma anche per gli shard da 2 a 4, perché la transazione 1 potrebbe avere ancora bisogno di accedere a tali tuple. Sono ancora visibili nella transazione 1 grazie a MVCC.

L’ultimo passaggio viene eseguito tramite la sincronizzazione, in modo che tutti gli shard siano consapevoli della transazione 1, anche se questa non li riguarda tutti.

Utilizzo delle statistiche del database per il processo di vacuum

Per ottenere informazioni sulle tuple che potresti dover pulire, utilizza la vista limitless_stat_all_tables, che funziona in modo analogo a pg_stat_all_tables. Nell’esempio seguente viene eseguita una query sulla vista. 

SELECT * FROM rds_aurora.limitless_stat_all_tables WHERE relname LIKE '%customer%';

Allo stesso modo, per le statistiche del database utilizza limitless_stat_database anziché pg_stat_database e limitless_stat_activity anziché pg_stat_activity.

Per controllare l’utilizzo del disco della tabella, ricorri alla funzione limitless_stat_relation_sizes, che funziona in modo analogo a pg_relation_size. Negli esempi seguenti vengono inviate query alla funzione.

SELECT * FROM rds_aurora.limitless_stat_relation_sizes('public','customer');

Per tracciare l’avanzamento di un’operazione VACUUM su Aurora PostgreSQL Limitless Database, utilizza la vista limitless_stat_progress_vacuum anziché pg_stat_progress_vacuum. Nell’esempio seguente viene eseguita una query sulla vista. 

SELECT * FROM rds_aurora.limitless_stat_progress_vacuum;

Per ulteriori informazioni, consulta Visualizzazioni di Aurora PostgreSQL Limitless Database e Funzioni di Aurora PostgreSQL Limitless Database.

Differenze nel comportamento di vacuum tra Aurora PostgreSQL e Aurora PostgreSQL Limitless Database

Il funzionamento del processo di vacuum in Aurora PostgreSQL e in Aurora PostgreSQL Limitless Database presenta altre differenze, tra cui:

  • Aurora PostgreSQL esegue operazioni VACUUM sugli ID delle transazioni fino alla transazione in corso più datata. Se nel database non è presente alcuna transazione in corso, VACUUM esegue l’operazione fino all’ultima transazione.

  • Aurora PostgreSQL Limitless Database esegue la sincronizzazione dello snapshot più datato ogni 10 secondi. Pertanto, VACUUM potrebbe non eseguire l’operazione su alcuna transazione eseguita negli ultimi 10 secondi.

Per informazioni sul supporto per VACUUM in Aurora PostgreSQL Limitless Database, consulta VACUUM in Riferimento ad Aurora PostgreSQL Limitless Database.