Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Récupérer de l'espace de rangement en passant l'aspirateur
Postgre SQL Multiversion Concurrency Control (MVCC) permet de préserver l'intégrité des données en enregistrant une copie interne des lignes mises à jour ou supprimées jusqu'à ce qu'une transaction soit validée ou annulée. Ces copies, également appelées tuples, peuvent provoquer un gonflement de la table si elles ne sont pas nettoyées régulièrement. Les SQL instances Postgre classent les transactions en fonction de leur transactionIDs, et Postgre SQL utilise des identifiants de transaction MVCC pour contrôler la visibilité des tuples et isoler les transactions. Chaque transaction établit un instantané des données, et chaque tuple possède une version. L'instantané et la version sont tous deux basés sur l'identifiant de transaction.
Pour nettoyer les données, l'VACUUM
utilitaire exécute quatre fonctions clés dans Postgre SQL :
-
VACUUM
— Supprime les versions de ligne expirées, rendant ainsi l'espace disponible pour une réutilisation. -
VACUUM FULL
— Permet une défragmentation complète en supprimant les lignes mortes et en compactant les tables, en réduisant la taille et en augmentant l'efficacité. -
VACUUM FREEZE
— Protège contre les problèmes d'encapsulation des identifiants de transaction en marquant les anciennes versions de lignes comme étant gelées. -
VACUUM ANALYZE
— Supprime les versions des lignes mortes et met à jour les statistiques de planification des requêtes de la base de données. C'est une combinaison desANALYZE
fonctionsVACUUM
et. Pour plus d'informations sur leANALYZE
fonctionnement de la base de données Aurora Postgre SQL Limitless, consultez. ANALYZE
Comme dans le cas d'Aurora PostgreMVCC, l'aspiration SQL est basée sur un identifiant de transaction. Si une transaction est en cours lorsque le nettoyage commence, les lignes qui sont toujours visibles pour cette transaction ne sont pas supprimées.
Pour plus d'informations sur VACUUM
cet utilitaire, consultez VACUUMVACUUM
prise en charge de la base de données Aurora Postgre SQL Limitless, consultez. VACUUM
Rubriques
AUTOVACUUM
Aurora Postgre SQL utilise les AUTOVACUUM
utilitaires VACUUM
and pour supprimer les tuples inutiles. Le mécanisme sous-jacent AUTOVACUUM
et le manuel VACUUM
sont les mêmes ; la seule différence réside dans l'automatisation.
AUTOVACUUM
dans Aurora Postgre SQL et Aurora Postgre SQL Limitless Database est une combinaison des utilitaires et. VACUUM
ANALYZE
AUTOVACUUM
détermine les bases de données et les tables à nettoyer, selon une règle prédéfinie, telle que le pourcentage de tuples morts et le nombre d'insertions.
Par exemple, AUTOVACUUM
« se réveille » périodiquement pour effectuer un nettoyage. L'intervalle est contrôlé par le autovacuum_naptime
paramètre. La valeur par défaut est de 1 minute. Les valeurs par défaut AUTOVACUUM
et les paramètres VACUUM
de configuration sont les mêmes pour la base de données Aurora Postgre SQL Limitless et pour Aurora Postgre. SQL
Le AUTOVACUUM
daemon, s'il est activé, émet automatiquement des ANALYZE
commandes chaque fois que le contenu d'une table a suffisamment changé. Dans la base de données Aurora Postgre SQL Limitless, AUTOVACUUM
problèmes à la fois ANALYZE
sur les routeurs et les partitions.
Pour plus d'informations sur le AUTOVACUUM
démon et les paramètres de stockage des tables associésAUTOVACUUM
, consultez le démon autovacuum
L'aspiration basée sur le temps dans la base de données Aurora Postgre Limitless SQL
La base de données Aurora Postgre SQL Limitless est un système distribué, ce qui signifie que plusieurs instances peuvent être impliquées dans une transaction. Par conséquent, la visibilité basée sur l'identifiant de transaction ne s'applique pas. La base de données Aurora Postgre SQL Limitless utilise plutôt une visibilité basée sur le temps, car les transactions IDs ne sont pas « unifiées » entre les instances, mais le temps peut être « unifié » entre les instances. Chaque instantané de transaction et chaque version de tuple obéissent à l'heure plutôt qu'à l'identifiant de transaction. Pour être plus précis, un instantané de transaction possède une heure de début d'instantané, et un tuple a une heure de création (lorsqu'un INSERT
ou UPDATE
se produit) et une heure de suppression (lorsqu'un événement DELETE
se produit).
Pour maintenir la cohérence des données entre les instances du groupe de partitions de base de données, la base de données Aurora Postgre SQL Limitless doit s'assurer que le vacuuming ne supprime aucun tuple encore visible pour les transactions actives du groupe de partitions de base de données. Par conséquent, l'aspiration dans la base de données Aurora Postgre SQL Limitless est également basée sur le temps. D'autres aspects VACUUM
restent inchangés, notamment le fait que pour exécuter VACUUM
sur une table particulière, un utilisateur doit avoir accès à cette table.
Note
Nous vous recommandons vivement de ne pas laisser les transactions ouvertes pendant de longues périodes.
L'aspiration basée sur le temps consomme plus de mémoire que l'aspiration basée sur l'identifiant de transaction.
L'exemple suivant illustre le fonctionnement de l'aspirateur basé sur le temps.
-
Une table client est répartie sur quatre partitions.
-
La transaction 1 commence par une lecture répétable et ne cible qu'une seule partition (partition 1). Cette transaction reste ouverte.
La transaction 1 est plus ancienne que toute autre transaction entamée après elle.
-
La transaction 2 démarre plus tard et supprime tous les tuples d'une table, puis les valide.
-
Si
AUTOVACUUM
notre manuelVACUUM
essaie de nettoyer les tuples morts (morts à cause de la transaction 2), cela ne supprime rien.Cela est vrai non seulement pour la partition 1, mais également pour les partitions 2 à 4, car la transaction 1 peut toujours avoir besoin d'accéder à ces tuples. Ils sont toujours visibles pour la transaction 1 en raison deMVCC.
La dernière étape est réalisée par le biais de la synchronisation, afin que toutes les partitions soient informées de la transaction 1, même si la transaction 1 ne les touche pas toutes.
Utilisation des statistiques de base de données pour l'aspiration
Pour obtenir des informations sur les tuples que vous pourriez avoir besoin de nettoyer, utilisez la vue limitless_stat_all_tables, qui fonctionne de la même manière que pg_stat_all_tables.
SELECT * FROM rds_aurora.limitless_stat_all_tables WHERE relname LIKE '%customer%';
Pour vérifier l'utilisation du disque de la table, utilisez la fonction limitless_stat_relation_sizes, qui fonctionne de la même manière que pg_relation_size.
SELECT * FROM rds_aurora.limitless_stat_relation_sizes('public','customer');
Pour suivre la progression d'une VACUUM
opération sur la base de données Aurora Postgre SQL Limitless, utilisez la vue limitless_stat_progress_vacuum au lieu de pg_stat_progress_vacuum.
SELECT * FROM rds_aurora.limitless_stat_progress_vacuum;
Pour plus d’informations, consultez Vues de base de données Aurora PostgreSQL Limitless et Fonctions de base de données Aurora Postgre SQL Limitless.
Différences dans le comportement d'aspiration entre Aurora Postgre et SQL Aurora Postgre Limitless Database SQL
Voici d'autres différences entre Aurora Postgre SQL et Aurora Postgre SQL Limitless Database en ce qui concerne le fonctionnement de l'aspirateur :
-
Aurora Postgre SQL effectue
VACUUM
des opérations sur les transactions IDs jusqu'à la plus ancienne transaction en cours. S'il n'y a aucune transaction en cours dans la base de données,VACUUM
exécute l'opération jusqu'à la dernière transaction. -
La base de données Aurora Postgre SQL Limitless synchronise le plus ancien instantané toutes les 10 secondes. Par conséquent,
VACUUM
il est possible que l'opération ne soit pas effectuée sur les transactions exécutées au cours des 10 dernières secondes.
Pour plus d'informations sur la prise VACUUM
en charge de la base de données Aurora Postgre SQL Limitless, consultez VACUUM le. Référence de base de données Aurora Postgre SQL Limitless