Amazon Redshiftの開発者がこれだけは知っておきたい10のTIPS / 第18回 AWS User Group - Japan
Upcoming SlideShare
Loading in...5
×
 

Amazon Redshiftの開発者がこれだけは知っておきたい10のTIPS / 第18回 AWS User Group - Japan

on

  • 6,870 views

 

Statistics

Views

Total Views
6,870
Views on SlideShare
4,944
Embed Views
1,926

Actions

Likes
20
Downloads
53
Comments
0

8 Embeds 1,926

http://dev.classmethod.jp 1432
http://toatoshi.hatenablog.com 404
https://twitter.com 83
http://www.google.co.jp 2
https://www.chatwork.com 2
http://plus.url.google.com 1
http://translate.googleusercontent.com 1
https://kcw.kddi.ne.jp 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Amazon Redshiftの開発者がこれだけは知っておきたい10のTIPS / 第18回 AWS User Group - Japan Amazon Redshiftの開発者がこれだけは知っておきたい10のTIPS / 第18回 AWS User Group - Japan Presentation Transcript

  • Amazon Redshiftの開発者が これだけは知っておきたい10のTIPS 第18回 AWS User Group – Japan 東京勉強会 Hapyrus Inc. 藤川幸一 @fujibee
  • まずは初級
  • 1. Redshift (Data Warehouse) は通常の RDB (MySQL, Oracleなど)と違う! »データの持ち方がカラム毎に独立 »1行取ってくるのも数秒かかる »その代わり大規模データの join / group by / sort が異常に早い • Hadoop/Hiveはこの辺りがかなり苦手(つ まり遅い・難しい)
  • 2. Table設計はパフォーマンスに大きな 影響がある »distkeyはjoin時のキー (1個だけしか設定 できない) »sortkeyはwhere句の条件カラム (400個設 定できる) • timestampが第一候補 • distkey, sortkey, は後から変更できない »変更にはテーブル/カラム作り直しが必 要
  • 3. カラムナーデータの圧縮は大事 »適切な圧縮エンコードによってクエリ スピードが大きく変わる • 圧縮エンコーディングを自動的に適用する にはテーブル作成直後に10万行程度ロード する • 以後は“ANALYZE COMPRESSION” コマンドで 適切なエンコーディングがわかる »圧縮エンコーディングは後から変更で きない
  • 4. データロードとクエリ実行はどうする の? » データロード • insert文はとても遅い • copyコマンドによるバルクロード • S3かdynamodbにデータをアップロードしてcopyコ マンドで投入 » クエリ実行は PostgreSQL と同等! • psqlやpg gemなど既存ツールがそのまま使える • JDBC/ODBCアクセスも可能 » unloadというコマンドでデータをS3にexport できる
  • 中級のちょっとしたネタ
  • 5. RedshiftでのSQL的制約 »primary keyやunique制約は文法的には存 在するが、実際には制約として機能し ない • クエリオプティマイズに内部的に使われる のみ »not null制約は実際に機能する
  • 6. UTF-8の一部マルチバイト文字コー ドが利用できない »以前は4バイト文字がNGだった • 多国語環境では頻繁にエラーが起きた » 現在は5バイト以上がNG »最近(8月末あたり)copyコマンドで ACCEPTINVCHARSというオプションを指 定すると利用できない文字を置換でき るようになった
  • 上級・実際に使っている人向け
  • 7. リサイズあれこれ » 操作はAWS consoleから数クリック • XLの数を増やすことも、8XLクラスタにすること も可能 » 最初にread onlyになり、数時間後、数分read も不可になって利用可能に » 内部的には別クラスタを立ち上げてデータを マイグレート、DNSを切り替えている » データ量が多い、複雑なテーブル構造等があ るとリサイズは時間がかかる事が多い • snapshotからの復元のほうが早いこともある
  • 8. Redshiftの主要な制限 » PostgreSQLベースだが関数は半分くらいしか使えな い • 主にパフォーマンスに影響する関数がNG » データタイプもプリミティブなもののみ • INT系、FLOAT系、Boolean、Char、Varchar、Date、Timestamp » 1テーブルにつきバルクロード系操作は同時に1つ しかできない • copyやselect insertクエリはテーブルごとに2個め以降キュー イングされる » 最大コネクション数は95 = 複数サーバからのcopy コマンドがキューイングされるとすぐいっぱいに なる » TimestampはTimezoneをサポートしていない。UTC で格納し、アプリ側でハンドルした方が良い » 8XLインスタンスは最低2インスタンスから
  • 9. copyコマンドのオプティマイズ » 一度に処理するデータ量が多ければ多い ほどスループットは大きい • 1 copyコマンドで処理されるファイルは分割す るべし • 1インスタンスのクラスタ(XLノード)でも効果 あり – 1インスタンスは複数のスライスで構成されてい るので • 少なくともインスタンス数分は分割したほう が良い » クラスタのインスタンスが多ければ多い ほどパフォーマンスが向上 » クラスタサイズによってデータ量・分割 数をチューニングするとよい
  • 10. FlyDataを使おう! » 今までの内容が全て考慮されたRedshift向 け全自動データインテグレーション(ETL) サービス » 大量データ(200GB/day)でもロードパフォーマン ス最適化 » エラーハンドリングもバッチリ=開発・ 運用コスト削減 » apache logや JSONフォーマットも対応
  • See Also: 技術評論社サイトgihyo.jpにて技術連載
  • Hapyrusでは「カスタマーサクセス」エンジ ニアを 募集しています!Wantedlyにて!
  • ありがとうございました! Hapyrus は Amazon Redshift のデータインテグレーションパートナーです。