Rückgewinnung von Speicherplatz durch Staubsaugen - 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.

Rückgewinnung von Speicherplatz durch Staubsaugen

Postgre SQL Multiversion Concurrency Control (MVCC) trägt zur Wahrung der Datenintegrität bei, indem eine interne Kopie aktualisierter oder gelöschter Zeilen gespeichert wird, bis eine Transaktion entweder festgeschrieben oder rückgängig gemacht wird. Diese Kopien, auch Tupel genannt, können zu einer Überlastung der Tabelle führen, wenn sie nicht regelmäßig bereinigt werden. SQLPostgre-Instanzen ordnen Transaktionen nach ihrer Transaktion anIDs, und Postgre SQL verwendet Transaktions-IDs, um die Sichtbarkeit von Tupeln MVCC zu kontrollieren und Transaktionen zu isolieren. Jede Transaktion erstellt eine Momentaufnahme der Daten, 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 VACUUM Hilfsprogramm in Postgre vier Hauptfunktionen aus: SQL

  • VACUUM— Entfernt abgelaufene Zeilenversionen und macht den Speicherplatz für die Wiederverwendung verfügbar.

  • 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 Transaktions-ID-Wraparound-Problemen, indem ältere Zeilenversionen als eingefroren markiert werden.

  • VACUUM ANALYZE— Entfernt tote Zeilenversionen und aktualisiert die Abfrageplanungsstatistiken der Datenbank. Es ist eine Kombination der ANALYZE Funktionen VACUUM und. Weitere Informationen zur ANALYZE Funktionsweise von Aurora Postgre SQL Limitless Database finden Sie unter. ANALYZE

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

Weitere Informationen zum VACUUM Hilfsprogramm finden Sie VACUUMin der Postgre-Dokumentation. SQL Weitere Informationen zur VACUUM Unterstützung in Aurora Postgre SQL Limitless Database finden Sie unter. VACUUM

AUTOVACUUM

Aurora Postgre SQL verwendet die AUTOVACUUM Hilfsprogramme VACUUM und, um nicht benötigte Tupel zu entfernen. Der zugrundeliegende Mechanismus für AUTOVACUUM und das Handbuch VACUUM ist derselbe; der einzige Unterschied ist die Automatisierung.

AUTOVACUUMIn Aurora Postgre SQL und Aurora Postgre ist SQL Limitless Database eine Kombination der VACUUM Hilfsprogramme und. ANALYZE AUTOVACUUMbestimmt anhand einer vordefinierten Regel, wie z. B. den Prozentsatz toter Tupel und die Anzahl der Einfügungen, welche Datenbanken und Tabellen bereinigt werden sollen.

Beispielsweise AUTOVACUUM „wacht“ regelmäßig auf, um eine Bereinigung durchzuführen. Das Intervall wird durch den autovacuum_naptime Parameter gesteuert. Der Standardwert ist 1 Minute. Die Standardwerte AUTOVACUUM und VACUUM Konfigurationsparameter sind für Aurora Postgre SQL Limitless Database dieselben wie für Aurora Postgre. SQL

Wenn der AUTOVACUUM Daemon aktiviert ist, gibt er automatisch ANALYZE Befehle aus, wenn sich der Inhalt einer Tabelle ausreichend geändert hat. In Aurora Postgre SQL Limitless Database treten AUTOVACUUM Probleme sowohl ANALYZE auf Routern als auch auf Shards auf.

Weitere Informationen zu den zugehörigen Speicherparametern für AUTOVACUUM Daemon und Tabellen finden Sie unter Der Autovacuum-Daemon und die Speicherparameter in der Postgre-Dokumentation. AUTOVACUUM SQL

Zeitbasiertes Staubsaugen in der Aurora Postgre Limitless Database SQL

Aurora Postgre SQL Limitless Database ist ein verteiltes System, was bedeutet, dass mehrere Instanzen an einer Transaktion beteiligt sein können. Daher gilt die Transparenz, die auf Transaktions-IDs basiert, nicht. Stattdessen verwendet Aurora Postgre SQL Limitless Database zeitbasierte Transparenz, da Transaktionen IDs nicht instanzübergreifend „vereinheitlicht“ werden, sondern die Zeit kann instanzübergreifend „vereinheitlicht“ werden. Jeder Transaktions-Snapshot und jede Tupelversion folgen der Uhrzeit statt der Transaktions-ID. Genauer gesagt hat ein Transaktions-Snapshot eine Snapshot-Startzeit, und ein Tupel hat eine Erstellungszeit (wenn ein INSERT oder UPDATE passiert) und eine Löschzeit (wenn ein DELETE Ereignis passiert).

Um die Datenkonsistenz zwischen den Instances in der DB-Shard-Gruppe aufrechtzuerhalten, muss Aurora Postgre SQL Limitless Database sicherstellen, dass beim Vakuumieren keine Tupel entfernt werden, die für aktive Transaktionen in der DB-Shard-Gruppe noch sichtbar sind. Daher ist das Staubsaugen in der Aurora Postgre SQL Limitless Database auch zeitbasiert. Andere Aspekte von VACUUM bleiben gleich, einschließlich der Tatsache, dass ein Benutzer Zugriff VACUUM auf diese Tabelle haben muss, um auf einer bestimmten Tabelle arbeiten zu können.

Anmerkung

Wir empfehlen dringend, Transaktionen nicht über einen längeren Zeitraum offen zu lassen.

Zeitbasiertes Staubsaugen verbraucht mehr Speicher als Transaktions-ID-basiertes Staubsaugen.

Das folgende Beispiel zeigt, wie zeitbasiertes Staubsaugen funktioniert.

  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 und löscht alle Tupel aus einer Tabelle. Anschließend wird ein Commit ausgeführt.

  4. Wenn AUTOVACUUM oder manuell VACUUM versucht, tote Tupel zu bereinigen (die aufgrund von Transaktion 2 tot sind), wird nichts entfernt.

    Dies gilt nicht nur für Shard 1, sondern auch für die Shards 2—4, da Transaktion 1 möglicherweise immer noch auf diese Tupel zugreifen muss. Aus diesem Grund sind sie für Transaktion 1 immer noch sichtbar. MVCC

Der letzte Schritt wird durch Synchronisation erreicht, sodass alle Shards Transaktion 1 kennen, obwohl Transaktion 1 nicht alle davon berührt.

Verwenden von Datenbankstatistiken zum Staubsaugen

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. Das folgende Beispiel fragt die Ansicht ab.

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

In ähnlicher Weise 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 von Tabellen zu überprüfen, verwenden Sie die Funktion limitless_stat_relation_sizes, die ähnlich wie pg_relation_size funktioniert. Das folgende Beispiel fragt die Funktion ab.

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

Um den Fortschritt einer VACUUM Operation in Aurora Postgre SQL 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 Aurora Postgre SQL Unbegrenzte Datenbankansichten und Aurora Postgre SQL Unbegrenzte Datenbankfunktionen.

Unterschiede im Saugverhalten zwischen Aurora Postgre SQL und Aurora Postgre Limitless Database SQL

Einige weitere Unterschiede zwischen Aurora Postgre SQL und Aurora Postgre SQL Limitless Database in Bezug auf die Funktionsweise des Staubsaugens sind die folgenden:

  • Aurora Postgre SQL führt VACUUM Transaktionen IDs bis zur ältesten laufenden Transaktion durch. Wenn in der Datenbank keine laufende Transaktion vorhanden ist, wird VACUUM der Vorgang bis zur letzten Transaktion ausgeführt.

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

Informationen zur Unterstützung von VACUUM in Aurora Postgre SQL Limitless Database finden Sie VACUUM in der. Referenz zur Aurora Postgre SQL Limitless Database