Amazon Redshift の開発者がこれだけは知っておきたい 10 の TIPS

第 18 回 AWS User Group – Japan 東京勉強会

Hapyrus Inc. 藤川幸一 @fujibee

まずは初級

1. [初級 ] Redshift (Data Warehouse) は通常の RDB (MySQL, Oracle など ) と違う！

»データの持ち方がカラム毎に独立»１行取ってくるのも数秒かかる»その代わり大規模データの join / group

by / sort が異常に早い• Hadoop/Hive はこの辺りがかなり苦手（つ

まり遅い・難しい )

2. [初級 ] Table 設計はパフォーマンスに大きな影響がある

»distkey は join 時のキー (1 個だけしか設定できない )

»sortkey は where 句の条件カラム (400 個設定できる )• timestamp が第一候補• distkey, sortkey, は後から変更できない

»変更にはテーブル / カラム作り直しが必要

3. [初級 ] カラムナーデータの圧縮は大事

»適切な圧縮エンコードによってクエリスピードが大きく変わる• 圧縮エンコーディングを自動的に適用するに

はテーブル作成直後に 10 万行程度ロードする• 以後は“ ANALYZE COMPRESSION” コマンドで適

切なエンコーディングがわかる»圧縮エンコーディングは後から変更できな

い

4. [初級 ] データロードとクエリ実行はどうするの？

» データロード• insert 文はとても遅い• copy コマンドによるバルクロード• S3 か dynamodb にデータをアップロードして copy

コマンドで投入» クエリ実行は PostgreSQL と同等！• psql や pg gem など既存ツールがそのまま使える• JDBC/ODBC アクセスも可能

» unload というコマンドでデータを S3 にexport できる

中級のちょっとしたネタ

5. [中級 ] Redshift での SQL 的制約

»primary key や unique 制約は文法的には存在するが、実際には制約として機能しない• クエリオプティマイズに内部的に使われる

のみ»not null 制約は実際に機能する

６ . [中級 ] UTF-8 の一部マルチバイト文字コードが利用できない

»以前は 4 バイト文字が NG だった• 多国語環境では頻繁にエラーが起きた

» 現在は 5 バイト以上が NG»最近 ( ８月末あたり )copy コマンドで

ACCEPTINVCHARS というオプションを指定すると利用できない文字を置換できるようになった

上級・実際に使っている人向け

7. [上級 ] リサイズあれこれ

» 操作は AWS console から数クリック• XL の数を増やすことも、 8XL クラスタにすること

も可能» 最初に read only になり、数時間後、数分 read

も不可になって利用可能に» 内部的には別クラスタを立ち上げてデータを

マイグレート、 DNS を切り替えている» データ量が多い、複雑なテーブル構造等があ

るとリサイズは時間がかかる事が多い• snapshot からの復元のほうが早いこともある

8. [上級 ] Redshift の主要な制限

» PostgreSQL ベースだが関数は半分くらいしか使えない• 主にパフォーマンスに影響する関数が NG

» データタイプもプリミティブなもののみ• INT 系、 FLOAT 系、 Boolean 、 Char 、 Varchar 、 Date 、 Timestamp

» 1 テーブルにつきバルクロード系操作は同時に１つしかできない• copy や select insert クエリはテーブルごとに２個め以降キュー

イングされる» 最大コネクション数は 95 = 複数サーバからの copy コ

マンドがキューイングされるとすぐいっぱいになる» Timestamp は Timezone をサポートしていない。 UTC で

格納し、アプリ側でハンドルした方が良い» 8XL インスタンスは最低２インスタンスから

9. [上級 ] copy コマンドのオプティマイズ

» 一度に処理するデータ量が多ければ多いほどスループットは大きい• 1 copy コマンドで処理されるファイルは分割するべ

し• 1 インスタンスのクラスタ (XL ノード ) でも効果あり

– １インスタンスは複数のスライスで構成されているので• 少なくともインスタンス数分は分割したほうが良い

» クラスタのインスタンスが多ければ多いほどパフォーマンスが向上

» クラスタサイズによってデータ量・分割数をチューニングするとよい

10. [宣伝 ] FlyData を使おう！

» 今までの内容が全て考慮された Redshift 向け全自動データインテグレーション (ETL)サービス

» 大量データ (200GB/day) でもロードパフォーマンス最適化

» エラーハンドリングもバッチリ＝開発・運用コスト削減

» apache log や JSON フォーマットも対応

See Also: 技術評論社サイト gihyo.jp にて技術連載

Hapyrus では「カスタマーサクセス」エンジニアを募集しています！ Wantedly にて！

ありがとうございました！

Hapyrus は Amazon Redshift のデータインテグレーションパートナーです。