ふつうのRedshiftパフォーマンスチューニング @ AWS Casual 02, 2014-04-18

1. ふつうのRedshift
パフォーマンスチューニング
青木峰郎

2. Redshiftについて

3. 並列RDBMS

4. Redshiftのアーキテクチャ
compute node 0
compute node 1
leader node
compute node 2
compute node 3

5. 並列単位はNode Slice
Node 0 Node 1 Node 2
Slice 0 Slice 1 Slice 2 Slice 3 Slice 4 Slice 5

6. 行は分散キーのハッシュ値で決定する
node slice 0 node slice 1 node slice 2 node slice 3
time user_id item_id
1398579843 289750 19375

7. 本題

8. なんかシステムもいろいろ
あるじゃないですか

9. 典型的なシステム
ウェブとか
アプリとか
Redshift
BIツール
Txn,
ログ
マスター
マスター
Hadoop
直SQL
（人間）
バッチ

10. 処理の種類
• オンライン（OLTP）マイクロ秒、更新あり
• オンライン（OLAP / tactical）0.1∼数秒
• オンライン（OLAP / strategic）数秒∼数分
• バッチ 数分∼数時間

11. OLTP
無理

12. 具体的に言うと…
• リクエストの並列度が高いのは無理
• 秒間2桁以上はやめとけ
• 高頻度・細粒度で更新するのは無理
• 5分間隔の追加くらいがギリ

13. Tactical Query
• sortkeyに当てろ
• テーブルサイズを実測して一番小さくしろ
• 事前ジョインはあんま効かない（集計はOK）

14. Strategic, Batch
ここからが本番

15. 問題外の頻出パターン
Redshift
全行selectしてきてRedshiftの外で非並列処理している
Rubyとか
Perlとか

16. やめて！

17. データを移動したら負け

18. データの規模感
行数 サイズ 雰囲気 設計時の態度
100億∼ 1TB∼ マジヤバイ 細心の注意
∼100億 ∼1TB 大きい 真面目にやれ
∼10億 ∼100GB 普通 考える
∼1億 ∼10GB 小さい 適当
∼1千万 ∼1GB ゴミ 無視

19. ネットワークが最重要
slice 0
CPU
Disk
slice 1
CPU
Disk
slice 2
CPU
Disk

20. dw1.xlargeの場合
最近の速度 速度比
CPU
メモリより
だいぶ速い
x10
メモリ
20GB/s
※DDR3
x100
ディスク 300MB/s x10
ネットワーク
30MB/s
※実測
1

21. チューニングすべき順
# リソース 手段
1 ネットワーク distkey
2 I/O
encode, sortkey,
正規化, 事前集計
3 CPU
sortkey,
正規化, 事前集計

22. 再分散を避ける
データ データ データ データ
データ データ データ データ

23. ジョインキーがdistkeyなら
再分散は起こらない
user_id time action
1
1
3
5
user_id name org
1
3
5
7
user_id time action
2
4
4
4
user_id name org
2
4
6
8
ログテーブル
ユーザー
マスター

24. ログテーブル
GROUP BYキーがdistkeyなら
再分散は起こらない
user_id time action
1
1
3
5
5
5
7
9
9
user_id time action
2
4
4
4
6
6
8
10
10

25. 目印は DS_DIST_NONE

26. データを移動したら負け
（再）

27. 詳しくは
WEB+DB
pressの
記事をごら
んください

28. カジュアルなまとめ
• 並列RDBではネットワークが最も貴重
• ネットワークの負荷を減らすには再分散を回避
• 再分散を回避するには分散キーを熟慮する