• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Amazon Redshiftの開発者がこれだけは知っておきたい10のTIPS / 第18回 AWS User Group - Japan
 

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

on

  • 6,255 views

 

Statistics

Views

Total Views
6,255
Views on SlideShare
4,388
Embed Views
1,867

Actions

Likes
18
Downloads
49
Comments
0

6 Embeds 1,867

http://dev.classmethod.jp 1382
http://toatoshi.hatenablog.com 404
https://twitter.com 77
http://www.google.co.jp 2
http://plus.url.google.com 1
http://translate.googleusercontent.com 1

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 のデータインテグレーションパートナーです。