テーブルのバキューム処理 - Amazon Redshift

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

Amazon Redshift は、バックグラウンドでテーブルを自動でソートし、VACUUM DELETE オペレーションを実行できます。ロードまたは一連の増分更新の後にテーブルをクリーンアップするには、データベース全体または個々のテーブルに対して VACUUM コマンドを実行することもできます。

注記

実質的に、テーブルの所有者またはスーパーユーザーのみがテーブルにバキューム処理を実行できます。そのテーブルの所有者権限またはスーパーユーザー権限を持っていない場合は、1 つのテーブルに対する VACUUM オペレーションは失敗します。テーブル名を指定せずに、データベース全体に VACUUM を実行した場合、オペレーションは正常に完了します。ただし、このオペレーションは、所有者の権限またはスーパーユーザー権限がないテーブルには効果がありません。

このため、必要に応じて、テーブルを個別にバキューム処理することをお勧めします。この方法をお勧めするもう 1 つの理由は、データベース全体をバキューム処理すると、コストのかかるオペレーションになる場合があるからです。

自動テーブルソート

Amazon Redshift は、データをバックグラウンドで自動的にソートし、テーブルデータをソートキー順に維持します。Amazon Redshift は、スキャンクエリを追跡し、ソートするメリットのあるテーブルのセクションを判断します。

システムの負荷に応じて、Amazon Redshift は自動でソートを開始します。この自動ソートにより、データをソートキー順に維持するために VACUUM コマンドを実行する必要が少なくなります。たとえば、大きなデータをロードした後に、ソートキー順でデータを完全にソートする必要がある場合でも、VACUUM コマンドを手動で実行することができます。VACUUM SORT コマンドの実行が有効的かどうかを判断するには、SVV_TABLE_INFOvacuum_sort_benefitをモニタします。

Amazon Redshiftは、各テーブルのソートキーを使用するスキャンクエリを追跡します。Amazon Redshiftは、テーブルが完全にソートされている場合、各テーブルのデータのスキャンやフィルターの最大改善率を見積ります。この見積もりは、SVV_TABLE_INFOvacuum_sort_benefit列で表示されます。この列は、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 を実行するようスケジュールし、高負荷のときには操作を中断します。

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 コマンドを実行するとき、テーブル名および TO threshold PERCENT パラメータを含む 1 つのテーブルの、デフォルトのソートしきい値を変更する。

バキュームの種類

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

  • VACUUM FULL

    VACUUM FULL は行を再ソートし削除された行からスペースを再利用します。Amazon Redshift は自動的に VACUUM DELETE ONLY のオペレーションをバックグラウンドで実行するため、多くのアプリケーションでは、VACUUM FULL および VACUUM SORT ONLY は同等です。VACUUM FULL は VACUUM と同じです。完全バキュームはデフォルトのバキューム操作です。

  • VACUUM DELETE ONLY

    DELETE ONLY バキュームは、ソートを省略することを除いて、完全バキュームと同じです。Amazon Redshift では、自動的に DELETE ONLY バキュームをバックグラウンドで事項するため、DELETE ONLY バキュームを実行する必要は、まずありません。

  • VACUUM SORT ONLY

    A SORT ONLY はディスクスペースを再利用しません。多くの場合、フルバキュームに比べてメリットはほとんどありません。

  • VACUUM REINDEX

    VACUUM REINDEX は、インターリーブソートキーを使用するテーブルに使用します。インターリーブソートキーの詳細については、「インターリーブソートキー」を参照してください。

    最初に COPY または CREATE TABLE AS を使用して空のインターリーブテーブルをロードすると、Amazon Redshift は自動的にインターリーブインデックスを作成します。最初に INSERT を使用してインターリーブテーブルをロードする場合は、その後に VACUUM REINDEX を実行して、インターリーブインデックスを初期化する必要があります。

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

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