Zurückgewinnen von Speicherplatz durch Bereinigung - Amazon Aurora

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Zurückgewinnen von Speicherplatz durch Bereinigung

PostgreSQL Multiversion Concurrency Control (MVCC) trägt zur Wahrung der Datenintegrität bei, indem es eine interne Kopie aktualisierter oder gelöschter Zeilen speichert, bis eine Transaktion entweder festgeschrieben oder zurückgesetzt wird. Diese Kopien, auch Tupel genannt, können zu einer Überlastung der Tabelle führen, wenn sie nicht regelmäßig bereinigt werden. PostgreSQL-Instances ordnen Transaktionen nach ihren Transaktions-IDs, und PostgreSQL verwendet MVCC, das auf Transaktions-IDs basiert, um die Sichtbarkeit von Tupeln zu kontrollieren und die Transaktionsisolierung zu gewährleisten. Jede Transaktion erstellt einen Daten-Snapshot, und jedes Tupel hat eine Version. Sowohl der Snapshot als auch die Version basieren auf der Transaktions-ID.

Um Daten zu bereinigen, führt das Dienstprogramm VACUUM vier wichtige Funktionen in PostgreSQL aus:

  • VACUUM – Entfernt abgelaufene Zeilenversionen, wodurch Speicherplatz für die Wiederverwendung verfügbar wird.

  • VACUUM FULL – Ermöglicht eine vollständige Defragmentierung, indem veraltete Versionen entfernt und die Tabellen komprimiert werden, wodurch die Größe reduziert und die Effizienz gesteigert wird.

  • VACUUM FREEZE – Schützt vor Wraparound-Problemen bei Transaktions-IDs, indem ältere Zeilenversionen als gesperrt markiert werden.

  • VACUUM ANALYZE – Entfernt veraltete Zeilenversionen und aktualisiert die Abfrageplanungsstatistiken der Datenbank. Es ist eine Kombination aus VACUUM- und ANALYZE-Funktionen. Weitere Informationen zur Funktionsweise von ANALYZE in Aurora PostgreSQL Limitless Database finden Sie unter ANALYZE.

Wie bei MVCC basiert die Bereinigung in Aurora PostgreSQL auf der Transaktions-ID. Wenn zu Beginn der Bereinigung eine Transaktion läuft, werden Zeilen, die für diese Transaktion noch sichtbar sind, nicht entfernt.

Weitere Informationen zum Dienstprogramm VACUUM finden Sie unter VACUUM in der PostgreSQL-Dokumentation. Weitere Informationen zur Unterstützung von VACUUM in Aurora PostgreSQL Limitless Database finden Sie unter VACUUM.

AUTOVACUUM

Aurora PostgreSQL verwendet die Dienstprogramme VACUUM und AUTOVACUUM, um nicht benötigte Tupel zu entfernen. Der zugrundeliegende Mechanismus für AUTOVACUUM und manuelles VACUUM ist derselbe, der einzige Unterschied besteht in der Automatisierung.

AUTOVACUUM in Aurora PostgreSQL und Aurora PostgreSQL Limitless Database ist eine Kombination der Dienstprogramme VACUUM und ANALYZE. AUTOVACUUM legt gemäß einer vordefinierten Regel fest, welche Datenbanken und Tabellen bereinigt werden sollen, z. B. anhand des Prozentsatzes inaktiver Tupel und der Anzahl der Einfügungen.

AUTOVACUUM wird beispielsweise regelmäßig aktiviert, um eine Bereinigung durchzuführen. Das Intervall wird durch den Parameter autovacuum_naptime gesteuert. Der Standardwert beträgt 1 Minute. Die Standardwerte für die Konfigurationsparameter AUTOVACUUM und VACUUM sind für Aurora PostgreSQL Limitless Database dieselben wie für Aurora PostgreSQL.

Wenn der Daemon für AUTOVACUUM aktiviert ist, gibt er automatisch ANALYZE-Befehle aus, wenn sich der Inhalt einer Tabelle ausreichend geändert hat. In Aurora PostgreSQL Limitless Database gibt AUTOVACUUM ANALYZE auf Routern und auf Shards aus.

Weitere Informationen zum Daemon für AUTOVACUUM und zu den mit AUTOVACUUM verbundenen Tabellenspeicherparametern finden Sie unter Der Bereinigungsdaemon und die Speicherparameter in der PostgreSQL-Dokumentation.

Zeitbasiertes Bereinigen in Aurora PostgreSQL Limitless Database

Aurora PostgreSQL Limitless Database ist ein verteiltes System, was bedeutet, dass mehrere Instances an einer Transaktion beteiligt sein können. Daher gilt die auf der Transaktions-ID basierende Transparenz nicht. Stattdessen verwendet Aurora PostgreSQL Limitless Database zeitbasierte Sichtbarkeit, da Transaktions-IDs nicht Instance-übergreifend „vereinheitlicht“ werden, die Zeit hingegen schon. Jeder Transaktions-Snapshot und jede Tupel-Version folgen der Zeit und nicht der Transaktions-ID. Genauer gesagt hat ein Transaktions-Snapshot eine Snapshot-Startzeit, und ein Tupel hat eine Erstellungszeit (bei einem INSERT- oder UPDATE-Vorgang) und eine Löschzeit (bei einem DELETE-Vorgang).

Um die Datenkonsistenz zwischen den Instances in der DB-Shard-Gruppe aufrechtzuerhalten, muss Aurora PostgreSQL Limitless Database sicherstellen, dass beim Bereinigen keine Tupel entfernt werden, die für aktive Transaktionen in der DB-Shard-Gruppe noch sichtbar sind. Daher ist die Bereinigung in Aurora PostgreSQL Limitless Database auch zeitbasiert. Andere Aspekte von VACUUM bleiben gleich, einschließlich der Tatsache, dass ein Benutzer Zugriff auf diese Tabelle haben muss, um VACUUM auf einer bestimmten Tabelle auszuführen.

Anmerkung

Es wird dringend davon abgeraten, Transaktionen für längere Zeit offen zu lassen.

Die zeitbasierte Bereinigung verbraucht mehr Speicher als die auf der Transaktions-ID basierte Bereinigung.

Das folgende Beispiel veranschaulicht die Funktionsweise von zeitbasierter Bereinigung.

  1. Eine Kundentabelle ist auf vier Shards verteilt.

  2. Transaktion 1 beginnt mit einem wiederholbaren Lesevorgang und zielt nur auf einen Shard (Shard 1) ab. Diese Transaktion bleibt offen.

    Transaktion 1 ist älter als jede andere Transaktion, die danach gestartet wurde.

  3. Transaktion 2 beginnt später, löscht alle Tupel aus einer Tabelle und wird anschließend festgeschrieben.

  4. Wenn AUTOVACUUM oder manuelles VACUUM versucht, inaktive Tupel zu bereinigen (die aufgrund von Transaktion 2 inaktiv sind), wird nichts entfernt.

    Dies gilt nicht nur für Shard 1, sondern auch für die Shards 2 bis 4, da Transaktion 1 möglicherweise immer noch auf diese Tupel zugreifen muss. Sie sind aufgrund von MVCC immer noch für Transaktion 1 sichtbar.

Der letzte Schritt wird durch Synchronisierung erreicht, sodass alle Shards über Transaktion 1 informiert sind, auch wenn Transaktion 1 nicht alle Shards betrifft.

Verwenden von Datenbankstatistiken für die Bereinigung

Um Informationen über Tupel zu erhalten, die Sie möglicherweise bereinigen müssen, verwenden Sie die Ansicht limitless_stat_all_tables, die ähnlich wie pg_stat_all_tables funktioniert. Im folgenden Beispiel wird die Ansicht abgefragt.

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

Entsprechend verwenden Sie für Datenbankstatistiken limitless_stat_database anstelle von pg_stat_database und limitless_stat_activity anstelle von pg_stat_activity.

Um die Festplattennutzung zu überprüfen, verwenden Sie die Funktion limitless_stat_relation_sizes, die ähnlich wie pg_relation_size funktioniert. Im folgenden Beispiel wird die Funktion abgefragt.

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

Um den Fortschritt eines VACUUM-Vorgangs in der Aurora PostgreSQL Limitless Database zu verfolgen, verwenden Sie die Ansicht limitless_stat_progress_vacuum anstelle von pg_stat_progress_vacuum. Im folgenden Beispiel wird die Ansicht abgefragt.

SELECT * FROM rds_aurora.limitless_stat_progress_vacuum;

Weitere Informationen erhalten Sie unter Ansichten für Aurora PostgreSQL Limitless Database und Funktionen für Aurora PostgreSQL Limitless Database.

Unterschiede im Bereinigungsverhalten zwischen Aurora PostgreSQL und Aurora PostgreSQL Limitless Database

Einige weitere Unterschiede zwischen Aurora PostgreSQL und Aurora PostgreSQL Limitless Database in Bezug auf die Funktionsweise der Bereinigung sind die folgenden:

  • Aurora PostgreSQL führt VACUUM-Vorgänge mit Transaktions-IDs bis zur ältesten laufenden Transaktion durch. Wenn in der Datenbank keine laufende Transaktion vorhanden ist, führt VACUUM den Vorgang bis zur letzten Transaktion ausgeführt.

  • Aurora PostgreSQL Limitless Database synchronisiert den ältesten Zeit-Snapshot alle 10 Sekunden. Daher wird VACUUM den Vorgang möglicherweise nicht für Transaktionen durch, die innerhalb der letzten 10 Sekunden ausgeführt wurden.

Weitere Informationen zur Unterstützung für VACUUM in Aurora PostgreSQL Limitless Database finden Sie unter VACUUM in der Referenz zu Aurora PostgreSQL Limitless Database.