Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

AWS Casual 02: ふつうのRedshiftパフォーマンスチューニング

8.091 visualizaciones

Publicado el

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

Publicado en: Tecnología
  • Inicia sesión para ver los comentarios

AWS Casual 02: ふつうのRedshiftパフォーマンスチューニング

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

×