AWS Casual 02: ふつうのRedshiftパフォーマンスチューニング
•
36 likes•8,518 views
ふつうのRedshiftパフォーマンスチューニング @ AWS Casual 02, 2014-04-18
Recommended
More Related Content
What's hot
What's hot (20)
Similar to AWS Casual 02: ふつうのRedshiftパフォーマンスチューニング
Similar to AWS Casual 02: ふつうのRedshiftパフォーマンスチューニング (20)
Recently uploaded
Recently uploaded (8)
AWS Casual 02: ふつうの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. 本題
- 10. 処理の種類 • オンライン（OLTP）マイクロ秒、更新あり • オンライン（OLAP / tactical）0.1∼数秒 • オンライン（OLAP / strategic）数秒∼数分 • バッチ 数分∼数時間
- 11. OLTP 無理
- 12. 具体的に言うと… • リクエストの並列度が高いのは無理 • 秒間2桁以上はやめとけ • 高頻度・細粒度で更新するのは無理 • 5分間隔の追加くらいがギリ
- 13. Tactical Query • sortkeyに当てろ • テーブルサイズを実測して一番小さくしろ • 事前ジョインはあんま効かない（集計はOK）
- 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. データを移動したら負け （再）
- 28. カジュアルなまとめ • 並列RDBではネットワークが最も貴重 • ネットワークの負荷を減らすには再分散を回避 • 再分散を回避するには分散キーを熟慮する