Amazon Redshift は、パッチ 198 以降、新しい Python UDF の作成をサポートしなくなります。既存の Python UDF は、2026 年 6 月 30 日まで引き続き機能します。詳細については、[ブログ記事](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)を参照してください。
# テーブルのバキューム処理
Amazon Redshift は、バックグラウンドでテーブルを自動でソートし、VACUUM DELETE オペレーションを実行できます。ロードまたは一連の増分更新の後にテーブルをクリーンアップするには、データベース全体または個々のテーブルに対して [VACUUM](r_VACUUM_command.md) コマンドを実行することもできます。
**注記**
必要なテーブルのアクセス許可を持つユーザーのみが、テーブルのバキューム処理を効果的に行うことができます。必要なテーブルアクセス許可なしで VACUUM が実行された場合、オペレーションは完了しますが、効果はありません。バキューム処理を効果的に実行するための有効なテーブルのアクセス許可のリストについては、「[VACUUM](r_VACUUM_command.md)」を参照してください。
このため、必要に応じて、テーブルを個別にバキューム処理することをお勧めします。この方法をお勧めするもう 1 つの理由は、データベース全体をバキューム処理すると、コストのかかるオペレーションになる場合があるからです。
## 自動テーブルソート
Amazon Redshift は、データをバックグラウンドで自動的にソートし、テーブルデータをソートキー順に維持します。Amazon Redshift は、スキャンクエリを追跡し、テーブルのどのセクションがソートする利点あるかを判断します。Amazon Redshift は、同時実行スケーリングクラスターからのスキャンクエリも追跡します。Amazon Redshift データ共有を使用するマルチクラスターアーキテクチャの場合、Amazon Redshift は、異なるリージョンのクラスター/ワークグループを含む、データメッシュ内のコンシューマークラスター/ワークグループから発生するスキャンクエリも追跡します。メインクラスター、同時実行スケーリングクラスター、コンシューマークラスターからのスキャン統計が集約され、テーブルのどのセクションがソートの恩恵を受けるかが決まります。
システムの負荷に応じて、Amazon Redshift は自動でソートを開始します。この自動ソートにより、データをソートキー順に維持するために VACUUM コマンドを実行する必要が少なくなります。例えば、大きなデータをロードした後に、ソートキー順でデータを完全にソートする必要がある場合でも、VACUUM コマンドを手動で実行することができます。VACUUM SORT コマンドの実行が有効的かどうかを判断するには、`vacuum_sort_benefit`の[SVV\_TABLE\_INFO](r_SVV_TABLE_INFO.md)をモニタします。
Amazon Redshift は、各テーブルのソートキーを使用するスキャンクエリを追跡します。Amazon Redshift は、テーブルが完全にソートされている場合、各テーブルのデータのスキャンやフィルターの最大改善率を見積ります。この見積もりは、`vacuum_sort_benefit`の[SVV\_TABLE\_INFO](r_SVV_TABLE_INFO.md)列で表示されます。この列は、`unsorted`列と一緒に使用することができ、クエリの際、いつテーブルで VACUUM SORT を手動で実行したら効率的かを判断します。`unsorted`列は、テーブルの物理的なソート順を反映しています。`vacuum_sort_benefit` 列は、VACUUM SORT を手動で実行することでソートによるテーブルへの影響を特定します。
例えば、次のクエリを考えてみます。
```
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
```
「sales」というテーブルの場合、86% が物理的にソートされていなくても、86% ソートされていないテーブルからのクエリ実行の影響は、5% だけとなります。理由としては、クエリがテーブルの一部にしかアクセスしていないか、ごく少数のクエリがテーブルにアクセスしたかのどちらかとなります。「event」というテーブルの場合、テーブルは、45% が物理的にソートされていません。ですが、67% のクエリ実行の影響は、クエリがテーブルの大部分にアクセスしたか、テーブルにアクセスしたクエリが多かったことを表しています。「event」というテーブルには、VACUUM SORT の実行が潜在的に有効となります。
## 自動バキューム削除
削除を実行すると、行は削除対象としてマークされますが、削除されません。Amazon Redshift は、データベーステーブルの削除された行数に基づいて、バックグラウンドで VACUUM DELETE オペレーションを自動的に実行します。Amazon Redshift では、負荷が軽減されているときに VACUUM DELETE を実行するようにスケジュールし、負荷が高いときにはオペレーションを一時停止します。
**Topics**
+ [自動テーブルソート](#automatic-table-sort)
+ [自動バキューム削除](#automatic-table-delete)
+ [VACUUM の頻度](#vacuum-frequency)
+ [ソートステージとマージステージ](#vacuum-stages)
+ [バキュームのしきい値](#vacuum-sort-threshold)
+ [バキュームの種類](#vacuum-types)
+ [バキューム処理時間の最小化](vacuum-managing-vacuum-times.md)
## VACUUM の頻度
一貫性のあるクエリパフォーマンスを維持するために、必要な頻度でバキューム処理を実行する必要があります。VACUUM コマンドの実行頻度を決めるときは、これらの要因を考慮します。
+ VACUUM は、夜間や指定されたデータベース管理期間など、クラスターのアクティビティが最小限になると予想される期間に実行します。
+ メンテナンスウィンドウ以外で VACUUM コマンドを実行します。詳細については、「[保守時間の時間枠を回避したスケジュール計画](https://docs.aws.amazon.com/redshift/latest/dg/c_best-practices-avoid-maintenance.html)」を参照してください。
+ 大きなリージョンが未ソートの状態であれば、バキューム処理の時間が長くなります。バキューム処理を遅らせる場合、再整理しなければならないデータが増えるのでバキューム処理にかかる時間が長くなります。
+ VACUUM は I/O 集約型な操作です。そのため、バキューム処理の完了にかかる時間が長ければ、同時クエリとクラスターで実行されている他のデータベース操作に与える影響が大きくなります。
+ VACUUM は、インターリーブソートを使用するテーブルに対しては時間がかかります。インターリーブテーブルを再ソートする必要があるかどうかを評価するには、[SVV\_INTERLEAVED\_COLUMNS](r_SVV_INTERLEAVED_COLUMNS.md) ビューのクエリを実行します。
## ソートステージとマージステージ
Amazon Redshift では、2 つのステージでバキュームオペレーションを実行します。最初に未ソートのリージョン内の行をソートし、続いて必要に応じて、テーブルの最後の新しくソートされた行に既存の行をマージします。大きなテーブルでバキュームを実行すると、バキューム操作は一連の差分ソートから成るステップを実行した後で、マージを実行します。オペレーションが失敗した場合、または Amazon Redshift がバキュームの間にオフラインになった場合は、部分的にバキュームが実行されたテーブルまたはデータベースは一貫性のある状態が保たれますが、バキュームオペレーションを手動で再開する必要があります。差分ソートは失われますが、操作が失敗する前にコミットされたマージ済みの行に再度バキューム処理を実行する必要はありません。未ソートのリージョンが大きい場合は、無駄になる時間が大きくなる可能性があります。ソートとマージのステージの詳細については、「[マージ済みの行のボリューム管理](vacuum-managing-vacuum-times.md#vacuum-managing-volume-of-unmerged-rows)」を参照してください。
ユーザーは、バキューム処理中のテーブルにアクセスできます。バキューム処理中のテーブルにクエリおよび書き込み操作を実行できますが、DML およびバキュームを同時に実行すると両方の処理時間が長くなる可能性があります。バキューム処理中に UPDATE および DELETE ステートメントを実行する場合は、システムのパフォーマンスが低減する場合があります。差分マージにより UPDATE と DELETE の同時操作が一時的にブロックされ、UPDATE と DELETE により操作で影響のあるテーブルでのマージのステップが一時的にブロックされます。ALTER TABLE などの DDL 操作は、テーブルでバキューム操作が終了するまでブロックされます。
**注記**
VACUUM の様々な修飾子により、その動作方法が制御されます。それらを使用して、現在のニーズに合わせてバキュームオペレーションを調整することができます。例えば、VACUUM RECLUSTER を使用すると、完全なマージ操作が実行されないので、バキューム操作が短縮されます。詳細については、「[VACUUM](r_VACUUM_command.md)」を参照してください。
## バキュームのしきい値
デフォルトではVACUUM コマンドで、テーブルの行の 95 パーセント以上がすでにソートされているテーブルのソートフェーズをスキップします。ソートフェーズをスキップすることにより、VACUUM のパフォーマンスが大幅に向上します。VACUUM コマンドを実行するとき、テーブル名および TO *threshold* PERCENT パラメータを含む 1 つのテーブルの、デフォルトのソートしきい値を変更する。
## バキュームの種類
バキュームのタイプ別の詳細については、「[VACUUM](r_VACUUM_command.md)」を参照してください。