1. Amazon Redshiftの開発者が
これだけは知っておきたい10のTIPS
第18回 AWS User Group – Japan 東京勉強会
Hapyrus Inc. 藤川幸一 @fujibee

3. まずは初級

4. 1. Redshift (Data Warehouse) は通常の
RDB (MySQL, Oracleなど)と違う！
»データの持ち方がカラム毎に独立
»１行取ってくるのも数秒かかる
»その代わり大規模データの join / group
by / sort が異常に早い
• Hadoop/Hiveはこの辺りがかなり苦手（つ
まり遅い・難しい)

5. 2. Table設計はパフォーマンスに大きな
影響がある
»distkeyはjoin時のキー (1個だけしか設定
できない)
»sortkeyはwhere句の条件カラム (400個設
定できる)
• timestampが第一候補
• distkey, sortkey, は後から変更できない
»変更にはテーブル/カラム作り直しが必
要

6. 3. カラムナーデータの圧縮は大事
»適切な圧縮エンコードによってクエリ
スピードが大きく変わる
• 圧縮エンコーディングを自動的に適用する
にはテーブル作成直後に10万行程度ロード
する
• 以後は“ANALYZE COMPRESSION” コマンドで
適切なエンコーディングがわかる
»圧縮エンコーディングは後から変更で
きない

7. 4. データロードとクエリ実行はどうする
の？
» データロード
• insert文はとても遅い
• copyコマンドによるバルクロード
• S3かdynamodbにデータをアップロードしてcopyコ
マンドで投入
» クエリ実行は PostgreSQL と同等！
• psqlやpg gemなど既存ツールがそのまま使える
• JDBC/ODBCアクセスも可能
» unloadというコマンドでデータをS3にexport
できる

8. 中級のちょっとしたネタ

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

10. ６. UTF-8の一部マルチバイト文字コー
ドが利用できない
»以前は4バイト文字がNGだった
• 多国語環境では頻繁にエラーが起きた
» 現在は5バイト以上がNG
»最近(８月末あたり)copyコマンドで
ACCEPTINVCHARSというオプションを指
定すると利用できない文字を置換でき
るようになった

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

12. 7. リサイズあれこれ
» 操作はAWS consoleから数クリック
• XLの数を増やすことも、8XLクラスタにすること
も可能
» 最初にread onlyになり、数時間後、数分read
も不可になって利用可能に
» 内部的には別クラスタを立ち上げてデータを
マイグレート、DNSを切り替えている
» データ量が多い、複雑なテーブル構造等があ
るとリサイズは時間がかかる事が多い
• snapshotからの復元のほうが早いこともある

13. 8. Redshiftの主要な制限
» PostgreSQLベースだが関数は半分くらいしか使えな
い
• 主にパフォーマンスに影響する関数がNG
» データタイプもプリミティブなもののみ
• INT系、FLOAT系、Boolean、Char、Varchar、Date、Timestamp
» 1テーブルにつきバルクロード系操作は同時に１つ
しかできない
• copyやselect insertクエリはテーブルごとに２個め以降キュー
イングされる
» 最大コネクション数は95 = 複数サーバからのcopy
コマンドがキューイングされるとすぐいっぱいに
なる
» TimestampはTimezoneをサポートしていない。UTC
で格納し、アプリ側でハンドルした方が良い
» 8XLインスタンスは最低２インスタンスから

14. 9. copyコマンドのオプティマイズ
» 一度に処理するデータ量が多ければ多い
ほどスループットは大きい
• 1 copyコマンドで処理されるファイルは分割す
るべし
• 1インスタンスのクラスタ(XLノード)でも効果
あり
– １インスタンスは複数のスライスで構成されてい
るので
• 少なくともインスタンス数分は分割したほう
が良い
» クラスタのインスタンスが多ければ多い
ほどパフォーマンスが向上
» クラスタサイズによってデータ量・分割
数をチューニングするとよい

15. 10. FlyDataを使おう！
» 今までの内容が全て考慮されたRedshift向
け全自動データインテグレーション(ETL)
サービス
» 大量データ(200GB/day)でもロードパフォーマン
ス最適化
» エラーハンドリングもバッチリ＝開発・
運用コスト削減
» apache logや
JSONフォーマットも対応

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

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

18. ありがとうございました！
Hapyrus は Amazon Redshift のデータインテグレーションパートナーです。