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ではネットワークが最も貴重

• ネットワークの負荷を減らすには再分散を回避

• 再分散を回避するには分散キーを熟慮する