AWS Casual 02: ふつうのRedshiftパフォーマンスチューニング
-
Upload
minero-aoki -
Category
Technology
-
view
2.392 -
download
0
description
Transcript of AWS Casual 02: ふつうのRedshiftパフォーマンスチューニング
ふつうのRedshift パフォーマンスチューニング
青木峰郎
Redshiftについて
並列RDBMS
Redshiftのアーキテクチャcompute node 0
compute node 1
leader node
compute node 2
compute node 3
並列単位はNode SliceNode 0 Node 1 Node 2
Slice 0 Slice 1 Slice 2 Slice 3 Slice 4 Slice 5
行は分散キーのハッシュ値で決定する
node slice 0 node slice 1 node slice 2 node slice 3
time user_id item_id
1398579843 289750 19375
本題
なんかシステムもいろいろ あるじゃないですか
典型的なシステム
ウェブとか アプリとか
Redshift
BIツールTxn, ログ
マスター
マスター
Hadoop
直SQL (人間)
バッチ
処理の種類
• オンライン(OLTP)マイクロ秒、更新あり
• オンライン(OLAP / tactical)0.1~数秒
• オンライン(OLAP / strategic)数秒~数分
• バッチ 数分~数時間
OLTP
無理
具体的に言うと…• リクエストの並列度が高いのは無理
• 秒間2桁以上はやめとけ
• 高頻度・細粒度で更新するのは無理
• 5分間隔の追加くらいがギリ
Tactical Query
• sortkeyに当てろ
• テーブルサイズを実測して一番小さくしろ
• 事前ジョインはあんま効かない(集計はOK)
Strategic, Batch
ここからが本番
問題外の頻出パターン
Redshift
全行selectしてきてRedshiftの外で非並列処理している
Rubyとか Perlとか
やめて!
データを移動したら負け
データの規模感行数 サイズ 雰囲気 設計時の態度
100億~ 1TB~ マジヤバイ 細心の注意
~100億 ~1TB 大きい 真面目にやれ
~10億 ~100GB 普通 考える
~1億 ~10GB 小さい 適当
~1千万 ~1GB ゴミ 無視
ネットワークが最重要
slice 0
CPU
Disk
slice 1
CPU
Disk
slice 2
CPU
Disk
dw1.xlargeの場合最近の速度 速度比
CPU メモリより だいぶ速い x10
メモリ 20GB/s ※DDR3
x100
ディスク 300MB/s x10
ネットワーク 30MB/s ※実測
1
チューニングすべき順# リソース 手段
1 ネットワーク distkey
2 I/O encode, sortkey, 正規化, 事前集計
3 CPU sortkey, 正規化, 事前集計
再分散を避ける
データ データ データ データ
データ データ データ データ
ジョインキーがdistkeyなら 再分散は起こらないuser_id time action1135
user_id name org1357
user_id time action2444
user_id name org2468
ログテーブル
ユーザー マスター
ログテーブル
GROUP BYキーがdistkeyなら 再分散は起こらないuser_id time action113555799
user_id time action24446681010
目印は DS_DIST_NONE
データを移動したら負け (再)
詳しくはWEB+DB pressの 記事をごらんください
カジュアルなまとめ• 並列RDBではネットワークが最も貴重
• ネットワークの負荷を減らすには再分散を回避
• 再分散を回避するには分散キーを熟慮する