メニュー
Amazon Redshift
データベース開発者ガイド (API Version 2012-12-01)

テーブルのバキューム処理

一括削除、ロード、一連の増分更新の後にテーブルをクリーンアップするには、データベース全体または個々のテーブルに対して VACUUM コマンドを実行する必要があります。

注記

実質的に、テーブルの所有者またはスーパーユーザーのみがテーブルにバキューム処理を実行できます。そのテーブルの所有者権限またはスーパーユーザー権限を持っていない場合は、1 つのテーブルに対する VACUUM は失敗します。テーブル名を指定せずにデータベース全体の VACUUM を実行すると、操作は正常に完了しますが、所有者権限またはスーパーユーザー権限を持っていないテーブルには効果がありません。さらに、データベース全体のバキューム処理が潜在的に高コストの操作であることから、個々のテーブルのバキューム処理は必要に応じて行うことをお勧めします。

行の削除や更新で解放された領域を、Amazon Redshift が自動的に再利用することはありません。更新を実行するために、Amazon Redshift は元の行を削除し、更新された行を追加します。そのため、すべての更新では実質的に削除の後で挿入が行われることになります。削除を実行する場合、行には削除のマークが付けられますが、削除されません。クエリプロセッサは、削除された行と削除されていない行をスキャンする必要があるため、削除された行の数が多すぎると不必要な処理が発生します。大規模な削除や更新の後でバキューム処理を実行することで、領域を再利用してクエリのパフォーマンスを向上させる必要があります。

ソートキーを含むテーブルの場合は、VACUUM コマンドを使用して、テーブル内の新しいデータをディスク上で完全にソートします。ソートキーを含むテーブルにデータが最初にロードされたとき、データは CREATE TABLE ステートメントの SORTKEY 仕様に従ってソートされます。ただし、COPY、INSERT、UPDATE ステートメントを使用してテーブルを更新するとき、新しい文はディスク上の個別の未ソート領域に格納され、その後、クエリの要求に基づき、必要に応じてソートされます。大量の行がディスク上で未ソートのまま残っている場合、範囲限定スキャンやマージ結合など、ソートされたデータに依存する操作でクエリパフォーマンスが低下する可能性があります。VACUUM コマンドは新しい行と既存のソート済み行をマージするため、範囲限定スキャンがより効率的であり、実行エンジンはクエリ実行中にオンデマンドで行をソートする必要がありません。

インターリーブソートキーを使用してテーブルをソートするとき、Amazon Redshift はソートキー列の値の分散を分析して、最適なソート方法を決定します。時間の経過とともに、それらの値の分散が変わる、つまりスキューが発生することがあり、パフォーマンス低下につながる場合があります。VACUUM REINDEX を実行して、ソートキーの分散を再分析し、パフォーマンスを回復します。詳細については、「インターリーブソートキー」を参照してください。

VACUUM の頻度

一貫性のあるクエリパフォーマンスを維持するために、必要な頻度でバキューム処理を行います。VACUUM コマンドの実行頻度を決めるときは、これらの要因を考慮します。

  • VACUUM は、夜間や指定されたデータベース管理期間など、クラスターのアクティビティが最小限になると予想される期間に実行します。

  • 大きなリージョンが未ソートの状態であれば、バキューム処理の時間が長くなります。バキューム処理を遅らせる場合、再整理しなければならないデータが増えるのでバキューム処理にかかる時間が長くなります。

  • VACUUM は I/O 集約型な操作です。そのため、バキューム処理の完了にかかる時間が長ければ、同時クエリとクラスターで実行されている他のデータベース操作に与える影響が大きくなります。

  • VACUUM は、インターリーブソートを使用するテーブルに対しては時間がかかります。インターリーブテーブルを復元する必要があるかどうかを評価するには、SVV_INTERLEAVED_COLUMNS ビューのクエリを実行します。

ソートステージとマージステージ

Amazon Redshift では、2 つのステージでバキューム操作を実行します。最初に未ソートのリージョン内の行をソートし、続いて必要に応じて、テーブルの最後の新しくソートされた行に既存の行をマージします。大きなテーブルでバキュームを実行すると、バキューム操作は一連の差分ソートから成るステップを実行した後で、マージを実行します。操作が失敗した場合、または Amazon Redshift がバキュームの間にオフラインになった場合は、部分的にバキュームが実行されたテーブルまたはデータベースは一貫性のある状態が保たれますが、バキューム操作を手動で再開する必要があります。差分ソートは失われますが、操作が失敗する前にコミットされたマージ済みの行に再度バキューム処理を実行する必要はありません。未ソートのリージョンが大きい場合は、無駄になる時間が大きくなる可能性があります。ソートとマージのステージの詳細については、「マージ済みの行のボリューム管理」を参照してください。

ユーザーは、バキューム処理中のテーブルにアクセスできます。バキューム処理中のテーブルにクエリおよび書き込み操作を実行できますが、DML およびバキュームを同時に実行すると両方の処理時間が長くなる可能性があります。バキューム処理中に UPDATE および DELETE ステートメントを実行する場合は、システムのパフォーマンスが低減する場合があります。差分マージにより UPDATE と DELETE の同時操作が一時的にブロックされ、UPDATE と DELETE により操作で影響のあるテーブルでのマージのステップが一時的にブロックされます。ALTER TABLE などの DDL 操作は、テーブルでバキューム操作が終了するまでブロックされます。

バキュームのしきい値

デフォルトではVACUUM コマンドで、テーブルの行の 95 パーセント以上がすでにソートされているテーブルのソートフェーズをスキップします。ソートフェーズをスキップすることにより、VACUUM のパフォーマンスが大幅に向上します。 また、削除フェーズの VACUUM では、残りの行の少なくとも 95 パーセントが削除対象としてマークされていない領域を再利用します。VACUUM では、削除対象としてマークされた数行のみを含む多数のブロックの書き換えをスキップできるため、通常削除された行の 100 パーセントを再利用することに比べて削除フェーズの時間が少なくて済みます。VACUUM コマンドを実行する時、テーブル名および TO threshold PERCENT パラメーターを含む 1 つのテーブルの、デフォルトのソートしきい値を変更する。

バキュームの種類

完全バキューム、削除のみのバキューム、ソートのみのバキューム、またはインデックス再生成ありの完全バキュームを実行できます。

  • VACUUM FULL

    領域の再利用と行の再ソートが同じくらい重要な場合、ほとんどのアプリケーションに完全バキュームをお勧めします。DELETE ONLY と SORT ONLY のバキューム操作を連続して実行するより、完全バキュームを実行するほうが効率的です。VACUUM FULL は VACUUM と同じです。完全バキュームはデフォルトのバキューム操作です。

  • VACUUM DELETE ONLY

    DELETE ONLY バキュームは、ソートを省略することを除いて、完全バキュームと同じです。ディスク領域の再利用は重要であるが、新しい行の再ソートは重要でない場合は、DELETE ONLY バキュームを実行することで時間を短縮できます。例えば、行を再ソートしてクエリパフォーマンスを最適化する必要がない場合、DELETE ONLY バキューム操作を実行します。

  • VACUUM SORT ONLY

    SORT ONLY バキュームではディスク領域を再利用しないため、ある程度時間を節約できますが、ほとんどの場合は完全バキュームに比べて利点があまりありません。

  • VACUUM REINDEX

    VACUUM REINDEX は、インターリーブソートキーを使用するテーブルに使用します。REINDEX はテーブルのソートキー列の値の分散を再分析してから、完全 VACUUM オペレーションを実行します。VACUUM REINDEX は VACUUM FULL よりも大幅に時間がかかります。これは、データ全体に余分な分析パスが必要になるだけでなく、インターリーブされたデータのマージにすべてのデータブロックへのタッチが含まれるためです。

    VACUUM REINDEX オペレーションがその完了前に終了した場合、次の VACUUM はバキュームの実行前に REINDEX オペレーションを再開します。