この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
ボリューム少な目なので に続いて間を置かずに連投します。こちらのエントリは『テーブルのバキューム処理(VACUUM)』についてです。
目次
テーブルのバキューム処理
削除や更新を数多く実行した後は、VACUUMコマンドを実行するようにしましょう。
注意：
唯一のテーブル所有者またはスーパーユーザが効果的にテーブルにVACUUM処理を実施することができます。
VACUUMが必要なテーブルの権限なしで実行された場合、操作は正常に完了しますが、効果はありません。
アップデートを実行するために、Amazon Redshiftは元の行を削除し、更新した行を追加します。全ての更新が追加削除を効果的に行っているのです。
Amazon Redshiftはテーブル内またはテーブル内の更新行を削除する時に解放されるスペースを自動的に取り戻し、再利用するといった事は行いません。あまりにも多くの行を削除した場合は、不要な処理を要する事になるかも知れません。VACUUMコマンドは削除を行い、利用可能なストレージを増やすだけで無く、パフォーマンスが向上する事になるスペースを取り戻します。 一括削除、ロード、または増分更新の後にテーブルをクリーンアップするには、データベースまたは個々のテーブルに対して、VACUUMコマンドを実行する必要があります。
未使用のディスク領域を再利用する事に加えて、VACUUMコマンドはテーブル内の新しいデータが完全にディスク上でソートされている事を保証します。データが最初にテーブルにロードされると、CREATE TABLE文内のSORTKEY仕様に従ってデータがソートされます。しかし、COPYやINSERT,UPDATE文を使いテーブルを更新すると、新しい行はディスク上のソートされていない別領域に格納されてしまい、クエリの需要によってはソート処理が必要になってしまいます。
VACUUMコマンドは、既存のソート済み行と一緒に新しい行をマージされるので、クエリ実行中に、必要に応じてソートする必要はありません。多数の行がディスク上で並べ替えられたままになっている場合は、ソート済みのデータに依存する操作の為にクエリのパフォーマンスが低下する可能性があります。大きな未ソート状態の領域は、結果として長時間のVACUUM処理が必要となってしまいます。
一貫したクエリ性能を維持する為に、出来るだけ頻繁にVACUUM処理を行いましょう。VACUUMコマンドを実行する頻度を決定する際は、以下の要因を考慮してください。
- もしVACUUM処理を遅らせてしまうと、より多くのデータを再編成する必要が出てくるため、よりVACUUM処理に時間が掛かってしまうようになります。
- VACUUM処理はI/O集中型の操作なので、VACUUM処理が完了するまで時間が掛かり、同じタイミングで行われているクエリ問い合わせやクラスタ上で実行されている他のデータベース操作に対し多くの影響を与えてしまう可能性があります。
- クラスタ上で最小限の時間でVACUUM処理を済ませたい場合は、メンテナンスウインドウ、またはその期間中(？)にVACUUM処理を実行します。
VACUUM操作の進行中に、クエリを実行し、書き込み操作をする事も出来ます。ユーザーはVACUUM操作されているテーブルを含むデータベース内の全てのテーブルにアクセスする事が出来ます。例えば、VACUUM処理を行っているテーブルの名前を変更しようとした場合、ALTER TABLEコマンドは失敗します。
VACUUM操作は、段階的に進んで行きます。操作が何らかの理由で失敗した場合、またAmazon RedshiftがVACUUM処理中にオフラインになった場合、部分的にVACUUMされたテーブルまたはデータベースが一貫性のある状態になります。手動でVACUUM操作を再起動する必要がありますが、大半の場合、VACUUM操作を完全に繰り返す必要はありません。障害が発生する前にコミットされたマージ行も、再びVACUUMを行う必要はありません。
あなたはVACUUM処理について、Full VACUUM、DELETE ONLY、SORT ONLYを行う事が出来ます。
- Full vacuum
- スペース及び行を取り戻します。我々としてはスペースを取り戻すのと行を再ソートは等しく重要であると考えているので、殆どのアプリケーションに於いて完全なVACUUM処理をお勧めします。完全なVACUUM処理を実行する必要が有る場合、以下のDELETE ONLY,SORT ONLYを個別に行うよりも、1回の操作で全てを行う方が効率的です。
- DELETE ONLY
- スペースのみを取り戻します。DELETE ONLYでのVACUUM処理は処理に掛かる時間を減らしますが、ディスクスペースの再利用が重要である時に新しい行をソートする事は出来ません。例えばクエリのパフォーマンスを最適化する為に行をソートする必要がない場合、この操作を実行する可能性があります。
- SORT ONLY
- 行のみソートします。ディスクスペースを取り戻す事が重要で無い局面で、ソートを行う必要が有る場合、ソートに掛かるVACUUM操作の時間を減らします。例えば、アプリケーションがディスクスペースの制約を持っていない場合はSORT ONLYでVACUUM操作を実行するかも知れませんが、テーブル行のソートを保つクエリの最適化には依存しません。
ソートされていない領域のサイズを管理する
空のテーブル(作り立て、若しくはtruncate直後)に初期ロードを実行すると、全てのデータがソート領域に直接ロードされているので、VACUUM操作は全く必要ありません。既にデータを含むテーブルに新しいデータを大量にロードした時、また日々の保守業務の一環としてVACUUM操作を行っていない場合は、ソートされていない領域は大きくなります。長時間掛かるようなVACUUM操作を回避するには、以下の方法を用います。
- 定期的にVACUUM操作を実行します。少しずつテーブルをロードする際に定期的にVACUUMを実行すると、個々のVACUUM操作は短く済みます。
- 復数のCOPY操作と同じテーブルをロードする必要が有る場合、最初に一番大きいロードを実行します。
- テスト目的の為にテーブルに対して少数の行をロードする場合、作業終了後にテーブルを切り捨て、その後本番ロード操作の一部として、これらの行をリロードします。また代替として、テーブルを削除し再生成するのもありです。
- 全ての行を削除する代わりに、テーブル自体を切り捨て(truncate)ます。VACUUM操作を行うまで、テーブルから行を削除する事＝スペースを取り返す、と言うことにはなりません。しかしながら、テーブルを切り捨てる事はテーブルを空にし、ディスク領域を再利用する事になります。なので、VACUUM操作は必要ありません。
- ディープコピーを実行します。ディープコピーは、自動的にテーブルを再ソートするバルクインサートを使い、自動的にテーブルを再生成・再移入を行います。テーブルがソートされていない大規模な領域を有する場合は、ディープコピーはVACUUM操作よりも遥かに高速です。トレードオフは、VACUUM操作中には出来た同時更新が、ディープコピー中には行えないという事です。詳細については、Performing a deep copy to avoid long vacuumsをご参照ください。
3
