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 derANALYZE
FunktionenVACUUM
und. Weitere Informationen zurANALYZE
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 VACUUMVACUUM
Unterstützung in Aurora Postgre SQL Limitless Database finden Sie unter. VACUUM
Themen
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.
AUTOVACUUM
In Aurora Postgre SQL und Aurora Postgre ist SQL Limitless Database eine Kombination der VACUUM
Hilfsprogramme und. ANALYZE
AUTOVACUUM
bestimmt 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 dieAUTOVACUUM
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.
-
Eine Kundentabelle ist auf vier Shards verteilt.
-
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.
-
Transaktion 2 beginnt später und löscht alle Tupel aus einer Tabelle. Anschließend wird ein Commit ausgeführt.
-
Wenn
AUTOVACUUM
oder manuellVACUUM
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.
SELECT * FROM rds_aurora.limitless_stat_all_tables WHERE relname LIKE '%customer%';
Um die Festplattennutzung von Tabellen zu überprüfen, verwenden Sie die Funktion limitless_stat_relation_sizes, die ähnlich wie pg_relation_size funktioniert
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.
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, wirdVACUUM
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