Amazon Redshift ne prendra plus en charge la création de nouveaux Python à UDFs partir du patch 198. UDFs Le Python existant continuera de fonctionner jusqu'au 30 juin 2026. Pour plus d’informations, consultez le [ billet de blog ](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/). 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. # Exécution de l’opération VACUUM sur les tables Amazon Redshift peut trier et effectuer automatiquement une opération VACUUM DELETE sur les tables en arrière-plan. Pour nettoyer les tables après un chargement ou une série de mises à jour incrémentielles, vous pouvez également exécuter la commande [VACUUM](r_VACUUM_command.md), sur toute la base de données ou sur chaque table individuelle. **Note** Seuls les utilisateurs disposant des autorisations nécessaires peuvent efficacement vider une table. Si VACUUM est exécutée sans les autorisations de table nécessaires, l’opération se termine correctement, mais n’a aucun effet. Pour obtenir la liste des autorisations de table valides permettant d’exécuter VACUUM efficacement, consultez [VACUUM](r_VACUUM_command.md). C’est pourquoi nous vous recommandons de nettoyer les tables individuellement en fonction des besoins. Nous vous recommandons également cette approche, car le nettoyage de toute la base de données peut être une opération coûteuse. ## Tri automatique des tables Amazon Redshift trie automatiquement les données en arrière-plan pour gérer les données de la table selon l’ordre de la clé de tri. Amazon Redshift assure le suivi de vos requêtes d’analyse afin de déterminer à quelles sections de la table le tri sera appliqué. Amazon Redshift assure également le suivi des requêtes de scan provenant de clusters de dimensionnement simultané. Pour les architectures multi-clusters utilisant le partage de données Amazon Redshift, Amazon Redshift suit également les requêtes de scan provenant des clusters/workgroups consommateurs de votre maillage de données, clusters/workgroups y compris dans différentes régions. Les statistiques d'analyse du cluster principal, des clusters de dimensionnement simultané et des clusters de consommateurs sont agrégées afin de déterminer les sections du tableau qui bénéficieront du tri. Selon la charge du système, Amazon Redshift lance le tri automatiquement. Ce tri automatique réduit la nécessité d’exécuter la commande VACUUM pour que les données restent dans l’ordre de la clé de tri. Si vous souhaitez que les données soient triées dans l’ordre de la clé de tri, par exemple après un chargement de données volumineux, vous pouvez toujours exécuter la commande VACUUM manuellement. Afin de déterminer s’il sera utile pour votre table d’exécuter une commande VACUUM SORT, surveillez la colonne `vacuum_sort_benefit` dans [SVV\$1TABLE\$1INFO](r_SVV_TABLE_INFO.md). Amazon Redshift suit les requêtes d’analyse qui utilisent la clé de tri de chaque table. Amazon Redshift estime le pourcentage maximum d’amélioration en analysant et filtrant les données de chaque table (si la table a été complètement triée). L’estimation est visible dans la colonne `vacuum_sort_benefit` de [SVV\$1TABLE\$1INFO](r_SVV_TABLE_INFO.md). Vous pouvez utiliser cette colonne avec la colonne `unsorted` afin de déterminer à quel moment il est utile pour les requêtes d’exécuter une opération VACUUM SORT sur une table. La colonne `unsorted` reflète l’ordre de tri physique d’une table. La colonne `vacuum_sort_benefit` spécifie l’impact du tri d’une table en exécutant manuellement une opération VACUUM SORT. Par exemple, réfléchissez à la requête suivante : ``` select "table", unsorted,vacuum_sort_benefit from svv_table_info order by 1; ``` ``` table | unsorted | vacuum_sort_benefit -------+----------+--------------------- sales | 85.71 | 5.00 event | 45.24 | 67.00 ``` Pour la table « sales », même si la table n’est pas triée à \$186 %, l’impact de la requête sur la performance pour la table est de 5 % seulement. Cela peut être parce qu’une petite partie de la table a été utilisée par les requêtes ou parce qu’un petit nombre de requêtes ont eu accès à la table. Pour la table « event », elle n’est pas triée physiquement à \$145 %. Mais l’impact de la requête sur la performance est de 67 %, ce qui indique qu’une partie plus importante de la table a été utilisée pour les requêtes ou qu’un grand nombre de requêtes ont eu accès à la table. L’exécution de l’opération VACUUM SORT peut potentiellement être utile pour la table « event ». ## Suppression de vide automatique Lorsque vous effectuez une suppression, les lignes sont marquées pour suppression, mais ne sont pas supprimées. Amazon Redshift exécute automatiquement une opération VACUUM DELETE en arrière-plan en fonction du nombre de lignes supprimées dans les tables de base de données. Amazon Redshift planifie l’exécution de VACUUM DELETE au cours des périodes à charge réduite et suspend l’opération au cours des périodes à charge élevée. **Topics** + [Tri automatique des tables](#automatic-table-sort) + [Suppression de vide automatique](#automatic-table-delete) + [Fréquence de VACUUM](#vacuum-frequency) + [Phase de tri et phase de fusion](#vacuum-stages) + [Seuil de VACUUM](#vacuum-sort-threshold) + [Types d’opération VACUUM](#vacuum-types) + [Réduire la durée des opérations vacuum](vacuum-managing-vacuum-times.md) ## Fréquence de VACUUM Vous devez exécuter la commande VACUUM aussi souvent que nécessaire pour assurer des performances de requêtes constantes. Prenez en compte ces facteurs au moment de déterminer la fréquence d’exécution de votre commande VACUUM : + Exécutez la commande VACUUM pendant les périodes où vous prévoyez une activité minimale sur le cluster, telles que le soir ou les fenêtres dédiées d’administration de la base de données. + Exécutez les commandes VACUUM en dehors des fenêtres de maintenance. Pour plus d’informations, consultez [Planifier la maintenance Windows](https://docs.aws.amazon.com/redshift/latest/dg/c_best-practices-avoid-maintenance.html). + Une grande région non triée se traduit par des temps d’exécution de la commande VACUUM plus longs. Si vous différez la commande, son exécution prendra plus de temps, car un plus grand nombre de données doit être réorganisé. + VACUUM est une opération I/O intensive. Par conséquent, plus la réalisation de votre aspirateur est longue, plus elle aura d'impact sur les requêtes simultanées et les autres opérations de base de données exécutées sur votre cluster. + VACUUM prend plus de temps pour les tables qui utilisent le tri entrelacé. Pour déterminer si les tables entrelacées doivent être retriées, interrogez la vue [SVV\$1INTERLEAVED\$1COLUMNS](r_SVV_INTERLEAVED_COLUMNS.md). ## Phase de tri et phase de fusion Amazon Redshift effectue une opération VACUUM en deux étapes : tout d’abord, il trie les lignes de la région non triée, puis, si nécessaire, il fusionne les lignes nouvellement triées en fin de la table avec les lignes existantes. Lors de l’exécution de la commande VACUUM sur une grande table, l’opération procède par une série d’étapes consistant en tris incrémentiels suivis de fusions. Si l’opération échoue ou si Amazon Redshift passe hors connexion pendant l’opération, la table ou la base de données partiellement aspirées se trouvent dans un état cohérent, mais vous devez relancer manuellement l’opération VACUUM. Les tris incrémentiels sont perdus, mais les lignes fusionnées qui ont été validées avant la défaillance n’ont pas besoin d’être aspirées à nouveau. Si la région non triée est grande, le temps perdu peut être important. Pour plus d’informations sur les étapes de tri et de fusion, consultez [Réduction du volume des lignes fusionnées](vacuum-managing-vacuum-times.md#vacuum-managing-volume-of-unmerged-rows). Les utilisateurs peuvent accéder aux tables pendant qu’elles sont aspirées. Vous pouvez exécuter des requêtes et des opérations d’écriture pendant qu’une table est l’objet de la commande VACUUM, mais lorsque DML et une commande VACUUM s’exécutent en même temps, les deux peuvent prendre plus de temps. Si vous exécutez les instructions UPDATE et DELETE pendant une opération VACUUM, les performances du système peuvent être réduites. Les fusions incrémentielles bloquent temporairement les opérations UPDATE et DELETE simultanée, tandis que les opérations UPDATE et DELETE bloquent à leur tour temporairement les étapes de la fusion incrémentielle sur les tables concernées. Les opérations DDL, telles que ALTER TABLE, sont bloquées tant que l’opération VACUUM sur la table n’est pas finie. **Note** Divers modificateurs pour l’opération VACUUM contrôlent la façon dont elle fonctionne. Vous pouvez les utiliser pour adapter l’opération aux besoins actuels. Par exemple, l’utilisation de VACUUM RECLUSTER accélère l’opération VACUUM, car elle n’effectue pas d’opération de fusion complète. Pour plus d'informations, consultez [VACUUM](r_VACUUM_command.md). ## Seuil de VACUUM Par défaut, la commande VACUUM ignore la phase de tri pour toute table dans laquelle plus de 95 % des lignes sont déjà triées. L’omission de la phase de tri peut améliorer considérablement les performances de l’opération VACUUM. Pour modifier le seuil de tri par défaut d’une seule table, incluez le nom de la table et le paramètre TO *seuil* PERCENT lorsque vous exécutez la commande VACUUM. ## Types d’opération VACUUM Pour plus d’informations sur les différents types d’opérations VACUUM, consultez [VACUUM](r_VACUUM_command.md). # Réduire la durée des opérations vacuum Amazon Redshift trie automatiquement les données et exécute l’opération VACUUM DELETE en arrière-plan. Cela réduit la nécessité d’exécuter la commande VACUUM. L’exécution de l’opération vacuum est un processus qui peut prendre beaucoup de temps. Selon la nature de vos données, nous vous conseillons de suivre les pratiques suivantes afin de réduire la durée des opérations vacuum. **Topics** + [Choix de réindexation](#r_vacuum-decide-whether-to-reindex) + [Réduction de la taille de la région non triée](#r_vacuum_diskspacereqs) + [Réduction du volume des lignes fusionnées](#vacuum-managing-volume-of-unmerged-rows) + [Charger vos données dans l’ordre de la clé de tri](#vacuum-load-in-sort-key-order) + [Utilisez des tables de séries chronologiques pour réduire les données stockées](#vacuum-time-series-tables) ## Choix de réindexation Vous pouvez souvent améliorer de façon significative les performances des requêtes en utilisant un style de tri entrelacé, mais au fil du temps les performances peuvent se dégrader si la distribution des valeurs des colonnes de clé de tri change. Lorsque vous chargez initialement une table entrelacée vide à l’aide de COPY ou CREATE TABLE AS, Amazon Redshift crée automatiquement l’index entrelacé. Si vous chargez initialement une table entrelacée à l’aide d’INSERT, vous devez exécuter VACUUM REINDEX après pour initialiser l’index entrelacé. Au fil du temps, à mesure que vous ajoutez des lignes avec de nouvelles valeurs de clé de tri, les performances peuvent se dégrader si la distribution des valeurs dans les colonnes de clés change. Si vos nouvelles lignes se trouvent principalement dans la plage de valeurs des clés de tri existantes, vous n’avez pas besoin de réindexer. Exécutez VACUUM SORT ONLY ou VACUUM FULL pour rétablir l’ordre de tri. Le moteur de requête est en mesure d’utiliser l’ordre de tri pour sélectionner efficacement les blocs de données qui doivent être analysés pour traiter une requête. Pour un tri entrelacé, Amazon Redshift analyse les valeurs des colonnes de clé de tri pour déterminer l’ordre de tri optimal. Si la distribution des valeurs de clés change, ou est altérée, au fur et à mesure que les lignes sont ajoutées, la politique de tri n’est plus optimale et l’avantage des performances de tri se dégrade. Pour réanalyser la distribution des clés de tri, vous pouvez exécuter une opération VACUUM REINDEX. Comme l’opération de réindexation prend du temps, pour décider si une table peut bénéficier d’une réindexation, interrogez la vue [SVV\$1INTERLEAVED\$1COLUMNS](r_SVV_INTERLEAVED_COLUMNS.md). Par exemple, la requête suivante affiche les détails des tables qui utilisent les clés de tri entrelacé. ``` select tbl as tbl_id, stv_tbl_perm.name as table_name, col, interleaved_skew, last_reindex from svv_interleaved_columns, stv_tbl_perm where svv_interleaved_columns.tbl = stv_tbl_perm.id and interleaved_skew is not null; tbl_id | table_name | col | interleaved_skew | last_reindex --------+------------+-----+------------------+-------------------- 100048 | customer | 0 | 3.65 | 2015-04-22 22:05:45 100068 | lineorder | 1 | 2.65 | 2015-04-22 22:05:45 100072 | part | 0 | 1.65 | 2015-04-22 22:05:45 100077 | supplier | 1 | 1.00 | 2015-04-22 22:05:45 (4 rows) ``` La valeur de `interleaved_skew` est un rapport qui indique le degré de déformation. Une valeur égale à 1 signifie qu’il n’y a pas de déformation. Si la déformation est supérieure à 1,4, une opération VACUUM REINDEX améliore généralement les performances, sauf si la déformation est inhérente à l’ensemble jeu sous-jacent. Vous pouvez utiliser la valeur de date dans `last_reindex` pour déterminer le temps qui s’est écoulé depuis la dernière réindexation. ## Réduction de la taille de la région non triée La région non triée croît lors du chargement de grandes quantités de nouvelles données dans des tables qui contiennent déjà des données ou lorsque vous ne pas videz pas les tables dans le cadre de vos opérations régulières de maintenance. Pour éviter les longues opérations VACUUM, utilisez les pratiques suivantes : + Exécutez les opérations VACUUM sur une base régulière. Si vous chargez vos tables par petits incréments (mises à jour quotidiennes qui représentent un faible pourcentage du nombre total de lignes de la table, par exemple), l’exécution régulière de VACUUM aide à s’assurer que les opérations VACUUM individuelles se déroulent rapidement. + Exécutez d’abord le chargement le plus important. Si vous avez besoin de charger une nouvelle table avec plusieurs opérations COPY, exécutez d’abord le chargement le plus important. Lorsque vous exécutez un chargement initial dans une table nouvelle ou tronquée, toutes les données sont chargées directement dans la région triée et, par conséquent, aucune opération VACUUM n’est obligatoire. + Tronquez une table au lieu de supprimer toutes les lignes. La suppression des lignes d’une table ne récupère pas l’espace que les lignes occupaient jusqu’à ce que vous effectuiez une opération VACUUM ; cependant, la troncation d’une table vide la table et récupère l’espace, et, par conséquent, aucune opération VACUUM n’est obligatoire. Une autre solution consiste à supprimer la table et à la recréer. + Tronquez ou supprimez les tables de test. Si vous chargez un petit nombre de lignes dans une table à des fins de test, ne supprimez pas les lignes lorsque vous avez terminé. A la place, tronquez la table et rechargez les lignes dans le cadre de l’opération de chargement de production suivante. + Exécutez une copie complète. Si une table qui utilise une table de clé de tri composée possède une grande région non triée, une copie complète est beaucoup plus rapide qu’une opération VACUUM. Une copie complète recrée et remplit une table à l’aide d’une insertion en bloc, qui retrie automatiquement la table. Si une table possède une grande région non triée, une copie complète est beaucoup plus rapide qu’une opération VACUUM. Cependant, vous ne pouvez pas effectuer de mises à jour simultanées pendant une opération de copie complète, alors que cela est possible durant une opération VACUUM. Pour plus d’informations, consultez [Bonnes pratiques Amazon Redshift pour la conception de requêtes](c_designing-queries-best-practices.md). ## Réduction du volume des lignes fusionnées Si une opération VACUUM doit fusionner de nouvelles lignes dans la région triée d’une table, le temps nécessaire pour l’opération augmente au fur et à mesure que la table se développe. Vous pouvez améliorer les performances de l’opération VACUUM en réduisant le nombre de lignes à fusionner. Avant une opération VACUUM, une table se compose d’une région triée en tête de table, suivie d’une région non triée, qui croît chaque fois que des lignes sont ajoutées ou mises à jour. Lorsqu’un ensemble de lignes est ajouté par une opération COPY, le nouvel ensemble de lignes est trié sur la clé de tri tel qu’il est ajouté à la région non triée en fin de table. Les nouvelles lignes sont classées au sein de leur propre ensemble, mais pas au sein de la région non triée. Le schéma suivant illustre la région non triée après deux opérations COPY successives, où la clé de tri est CUSTID. Pour plus de simplicité, cet exemple montre une clé de tri composée, mais les mêmes principes s’appliquent aux clés de tri entrelacé, sauf que l’impact de la région non triée est une plus grande pour les tables entrelacées. ![\[Table non triée contenant les enregistrements de deux opérations COPY.\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/images/vacuum-unsorted-region.png) Une opération VACUUM restaure l’ordre de tri de la table en deux étapes : 1. Triez la région non triée dans une région nouvellement triée. La première étape est relativement bon marché, parce que seule la région non triée est réécrite. Si la plage des valeurs de clé de tri de la région nouvellement triée est supérieure à la plage existante, seules les nouvelles lignes doivent être réécrites, et l’opération VACUUM est terminée. Par exemple, si la région triée contient des valeurs d’ID comprises entre 1 et 500 et que les opérations de copie suivantes ajoutent des valeurs de clé supérieures à 500, seule la région non triée doit être réécrite. 1. Fusionnez la région nouvellement triée avec la région précédemment triée. Si les clés de la région nouvellement triée chevauchent les clés de la région triée, l’opération VACUUM doit fusionner les lignes. En commençant par le début de la région nouvellement triée (à la clé de tri la plus basse), l’opération VACUUM écrit les lignes fusionnées à partir de la région précédemment triée et de la région nouvellement triée dans un nouvel ensemble de blocs. L’étendue selon laquelle la nouvelle plage de clés de tri chevauche les clés de tri existantes détermine l’étendue selon laquelle la région précédemment triée doit être réécrite. Si les clés non triées sont dispersées à travers la plage de tri existante, une opération VACUUM peut avoir besoin de réécrire Des parties existantes de la table. Le schéma suivant montre comment une opération VACUUM trie et fusionne les lignes qui sont ajoutées à une table où CUSTID est la clé de tri. Comme chaque opération de copie ajoute un nouvel ensemble de lignes avec des valeurs de clé qui chevauchent les clés existantes, presque la totalité de la table doit être réécrite. Le schéma illustre une seule étape de tri et fusion, mais, en pratique, une grand opération VACUUM se compose d’une série d’étapes incrémentielles de tri et de fusion. ![\[Une opération VACUUM sur la table d’exemple en deux étapes. Les nouvelles lignes sont d’abord triées, puis fusionnées avec les lignes existantes.\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/images/vacuum-unsorted-region-sort-merge.png) Si la plage de clés de tri d’un ensemble de nouvelles lignes chevauche la plage des clés existantes, le coût de l’étape de fusion continue à croître proportionnellement à la taille de la table au fur et à mesure que la table augmente, tandis que le coût de l’étape de tri demeure proportionnel à la taille de la région non triée. Dans un tel cas, le coût de l’étape de fusion éclipse le coût de l’étape de tri, comme l’illustre le schéma suivant. ![\[Schéma montrant comment l’étape de fusion devient plus coûteuse lorsque les nouvelles lignes ont des clés de tri qui se chevauchent avec des lignes existantes.\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/images/vacuum-example-merge-region-grows.png) Pour déterminer quelle proportion d’une table a été refusionnée, interrogez SVV\$1VACUUM\$1SUMMARY après la fin de l’opération VACUUM. La requête suivante affiche les conséquences de six opérations VACUUM successives tandis que CUSTSALES croît au fil du temps. ``` select * from svv_vacuum_summary where table_name = 'custsales'; table_name | xid | sort_ | merge_ | elapsed_ | row_ | sortedrow_ | block_ | max_merge_ | | partitions | increments | time | delta | delta | delta | partitions -----------+------+------------+------------+------------+-------+------------+---------+--------------- custsales | 7072 | 3 | 2 | 143918314 | 0 | 88297472 | 1524 | 47 custsales | 7122 | 3 | 3 | 164157882 | 0 | 88297472 | 772 | 47 custsales | 7212 | 3 | 4 | 187433171 | 0 | 88297472 | 767 | 47 custsales | 7289 | 3 | 4 | 255482945 | 0 | 88297472 | 770 | 47 custsales | 7420 | 3 | 5 | 316583833 | 0 | 88297472 | 769 | 47 custsales | 9007 | 3 | 6 | 306685472 | 0 | 88297472 | 772 | 47 (6 rows) ``` La colonne merge\$1increments fournit une indication de la quantité de données qui a été fusionnée pour chaque opération VACUUM. Si le nombre d’incréments de fusion sur des opérations VACUUM consécutives augmente proportionnellement à la croissance de la taille de la table, cela indique que chaque opération VACUUM refusionne un nombre croissant de lignes de la table, car la région existante et la région nouvellement triée se chevauchent. ## Charger vos données dans l’ordre de la clé de tri Si vous chargez vos données dans l’ordre de la clé de tri avec une commande COPY, vous aurez peut-être moins (voire plus du tout) besoin d’avoir recours à l’opération VACUUM. La commande COPY ajoute automatiquement de nouvelles lignes à la région triée de la table lorsque toutes les conditions suivantes sont définies sur true : + La table utilise une clé de tri composée avec une seule colonne de tri. + La colonne de tri est NOT NULL. + La table est triée ou vide à 100 %. + Toutes les nouvelles lignes sont plus élevées dans l’ordre de tri que les lignes existantes, y compris les lignes marquées pour la suppression. Dans ce cas, Amazon Redshift utilise les huit premiers octets de la clé de tri pour déterminer l’ordre de tri. + La commande COPY ne déclenche pas certaines optimisations de charge. Lors du chargement de gros volumes de données, Amazon Redshift peut optimiser les performances en créant de nouvelles partitions triées plutôt qu'en ajoutant des lignes à la région triée de la table. Par exemple, supposons que vous ayez une table qui enregistre les événements clients à l’aide d’un ID client et de l’heure. Si vous triez sur l’ID client, il est probable que la plage des clés de tri des nouvelles lignes ajoutées par les chargements incrémentiels chevauchent la plage existante, comme illustré dans l’exemple précédent, ce qui conduit à une opération VACUUM coûteuse. Si vous définissez votre clé de tri sur une colonne d’horodatage, vos nouvelles lignes sont ajoutées dans l’ordre de tri à la fin de la table, comme l’illustre le schéma suivant, ce qui rend l’opération VACUUM moins (voire plus du tout) nécessaire. ![\[Table qui utilise une colonne d’horodatage comme clé de tri pour obtenir de nouveaux enregistrements qui n’ont pas besoin d’être triés.\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/images/vacuum-unsorted-region-date-sort.png) ## Utilisez des tables de séries chronologiques pour réduire les données stockées Si vous maintenez les données pendant une période aléatoire, utilisez une série de tables, comme l’illustre le schéma suivant. ![\[Cinq tables contenant des données provenant de cinq trimestres. La table la plus ancienne est supprimée pour conserver une année de continuité.\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/images/vacuum-example-unsorted-region-copy-time-series.png) Créez une table chaque fois que vous ajoutez un ensemble de données, puis supprimez la table la plus ancienne de la série. Vous bénéficiez d’un double avantage : + Vous évitez le coût supplémentaire de suppression des lignes, parce qu’une opération DROP TABLE est beaucoup plus efficace qu’une opération DELETE massive. + Si les tables sont triées par horodate, aucune opération VACUUM n’est nécessaire. Si chaque table contient les données pour un mois, une opération VACUUM devra au plus réécrire la valeur d’un mois de données, même si les tables ne sont pas triées par horodatage. Vous pouvez créer une vue UNION ALL à utiliser par les requêtes de création de rapports qui masque le fait que les données sont stockées en plusieurs tables. Si une requête filtre sur la clé de tri, le planificateur de requête peut efficacement ignorer toutes les tables qui ne sont pas utilisées. Comme une opération UNION ALL peut être moins efficace pour les autres types de requêtes, vous devez évaluer les performances de la requête dans le contexte de toutes les requêtes qui utilisent les tables.