すのふら

日々の備忘録

Redshiftのデータロード方法についてメモ

Redshiftのデータロード方法について、初めて触れるところがあるのでメモする。
データのロード - Amazon Redshift


Insert

COPYコマンドが推奨される。

COPY コマンドは Amazon Redshift の超並列処理 (MPP) アーキテクチャを活用し、Amazon S3 のファイル、DynamoDB テーブル、リモートホストから出力されたテキストのいずれかから並列でデータをロードします。
大量のデータをロードする場合、COPY コマンドを使うことをお勧めします。個々に INSERT ステートメントを使ってテーブルにデータを入力すると著しく時間がかかる場合があります。
または、データがすでに他の Amazon Redshift データベーステーブルに存在する場合、INSERT INTO ... SELECT または CREATE TABLE AS を使用するとパフォーマンスが改善します。
http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/t_Loading_tables_with_the_COPY_command.html

普通にInsertすると並列で処理されるから遅いってことかな?
具体的にどのくらい変わるのかっていう点は、計測していないから折見てやってみるか。


Bulk insertを使って、データを一気にインポートする。

その際、テーブルのkey重複等は見ないので、実行すればするほど同じデータが蓄積される。
なので2回実行されないようにするか、実行されたときの設計はしっかり考えなければいけない。


またCOPYコマンドを実行する際、インポート元のS3のcredentials情報を明示的に指定しなければならない?*1ので、
config等に情報を保持するか、CLIで登録されている情報を取得してあげる必要がある。


テーブル生成するときにSORT KEYを定義しておけば、COPYコマンドを実行時初回のみソートが実行される。


Update/Delete

通常通りSQLのupdate/delete文で対応。

ここまではプロジェクトで触ったことでなんとなく知ってる。


insert/update/delete後のデータソートについて

ここからがお初事項。

COPYコマンドで随時コピーすると、2回目以降のCOPYコマンドはソートされないままテーブルに蓄積される。 また、update・deleteを行った後は、テーブルをクリーンアップしないと未ソート領域にデータが蓄積されてクエリ実行時の処理速度が低下する。

データ総数が数百件ならいいけど、数万~億件だとするとこれが致命傷になりかねない。

じゃあどうするかって、クリーンアップするんだが、redshiftだとどうするかというと、VACUUM コマンドを使用する。

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

ただ、テーブル上での未ソート件数が多い場合はVACUUMコマンドよりもディープコピーがいいよう。

テーブルにソートされていない大規模なリージョンがある場合、ディープコピーの方がバキューム処理より高速です。
欠点としては、ディープコピー処理中は同時更新を実行できません。バキューム処理では実行できます。
ディープコピーを実行する - Amazon Redshift



まだ実際に触ってみたわけではないので、実際に触って癖が分かったらまたメモする。

以下備忘録としてメモ
Redshift設計での個人的知見のまとめ その3 | トロこんぶ
Amazon Redshift DB開発者ガイド – データのロード処理(5).テーブルのバキューム処理 | DevelopersIO
これからAmazon Redshiftを始める技術者が注意すべき22つのポイント | DevelopersIO

*1:調べたかぎりはそうだったので