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

Like this? Share it with your network

Share

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

  • 7,544 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
7,544
On Slideshare
5,577
From Embeds
1,967
Number of Embeds
8

Actions

Shares
Downloads
56
Comments
0
Likes
22

Embeds 1,967

http://dev.classmethod.jp 1,468
http://toatoshi.hatenablog.com 408
https://twitter.com 84
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

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

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