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

11,616
-1

Published on

Published in: Technology
0 Comments
35 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
11,616
On Slideshare
0
From Embeds
0
Number of Embeds
12
Actions
Shares
0
Downloads
99
Comments
0
Likes
35
Embeds 0
No embeds

No notes for slide

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

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

×