Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

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

8.127 Aufrufe

Veröffentlicht am

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

Veröffentlicht in: Technologie
  • Loggen Sie sich ein, um Kommentare anzuzeigen.

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ではネットワークが最も貴重 • ネットワークの負荷を減らすには再分散を回避 • 再分散を回避するには分散キーを熟慮する

×