« AWS Black Belt Online Seminar「AWS上でのリアルタイムデータ分析入門」の資料およびQA公開 | メイン | Amazon EC2 Container Serviceより、Bloxをご紹介 »

Amazon Redshift テーブル設計詳細ガイド:Part 5 テーブルデータの永続性

著者 Zach Christopherson は Amazon Redshift チームのシニアデータベースエンジニアです。


Part 1: Preamble, Prerequisites, and Prioritization(序文、事前準備、優先順位付け)
Part 2: Distribution Styles and Distribution Keys(分散スタイルと分散キー)
Part 3: Compound and Interleaved Sort Keys (Compound と Interleaved ソートキー)
Part 4: Compression Encodings(圧縮エンコーディング)
Part 5: Table Data Durability(テーブルデータの永続性)[本稿]


「Amazon Redshift テーブル設計詳細ガイド」の最終回となるPart 5では、Amazon Redshift環境のパフォーマンスを更に引き出すための2つのシンプルなテーブルデータの永続性に関するプロパティの使い方について説明します。

自動バックアップ対象の限定

自動バックアップでは、Amazon Redshiftは増分の変更ブロックを高頻度でAmazon S3にプッシュします。これらの自動バックアップは時間の閾値または変更されたブロックによりトリガーされます。このアプローチによりスナップショットやテーブルレベルのリストア操作などのリカバリ機能が可能となっています。

一般的に自動バックアップの実際の処理コストは大きなものではありません。しかし、データブロックをS3に転送するため、継続的に大規模なCOPYやUNLOADを実行するワークロードに関するS3へのスループットに影響を与える可能性があります。このような自動バックアップの処理コストを抑制するために、S3に格納し耐久性を高めたいデータを含まないテーブルに対しては「BACKUP NO」テーブルプロパティを使用することができます。このプロパティを使用できるのは下記のようなテーブルです:

  1. 簡単に再構成可能なデータが挿入されたテーブル
  2. 一時的なデータや頻繁に変更される性質を持つデータを含むテーブル
  3. 重要度が低いデータや実験データが挿入されたテーブル

我々は下記の2点を実現するためにこのプロパティを使用します:

  1. 重要でないブロックの変更により高頻度で自動バックアップがトリガーされることを防止する
  2. バックアップ時にS3に転送されるブロックの量を減らし、バックアップ時間を短縮する

注: TEMPORARYとして定義されたテーブル(一時テーブル)は、それらが作成されたセッションの終了時にクリーンアップされるため、デフォルトでこのプロパティを継承しています。

同期データレプリケーションの抑制

デフォルトでは、マルチノード構成のAmazon Redshiftは自動的にクラスタ内の別ノードが持つテーブルデータの冗長コピーを保持するため、複数のディスクやノードの障害に耐性を持ちます。全ての同期データレプリケーションと同様に、このプロセスにはオーバーヘッドがあります。一時テーブルに関しては、システムがそれらのテーブル内のデータは一時的なものであると見なしているため、レプリケーションは実行されません。更に、一時テーブル内のブロックは自動バックアップをトリガーする閾値にはカウントされません。従って、一時的なデータに対して一時テーブルを使用することで、BACKUP NOオプションを使用した場合と同様に、バックアッププロセスの起動を回避し自動バックアップが完了するまでの速度を向上することができます。

一時テーブルのデータはレプリケートされていないので、一時テーブルデータをコミットするトランザクションは永続テーブルに対して実行するよりも処理コストが低くなります。つまり、適切な場面で一時テーブルを活用することで、クラスタのオーバーヘッドを大幅に抑制することができると言えます。例として、テーブルデータが単一のセッション内でのみアクセス可能であればよい場合や、本質的に一時的なデータである場合が挙げられます。

下記のクエリを使用して、クラスタ内でこれらのテーブルプロパティのいずれかが適用されているテーブルを特定することができます。

SELECT DISTINCT id, name, temp, backup 
FROM stv_tbl_perm 
WHERE backup=0 ORDER BY 1;

次のステップ

あなたの環境のデータの永続性や保存の要件次第では、これらのオプションを使用することは適切ではないかもしれませんが、それでも問題ありません。このブログシリーズを通して説明してきた内容の中では、今回のような細部の最適化はクラスタ全体のパフォーマンス向上への貢献度は小さいかもしれません。しかし、上から下まで最適化されている環境においては、これがパフォーマンス向上のために紹介できる最後のテーブルデザインコンセプトとなります。


Part 1: Preamble, Prerequisites, and Prioritization(序文、事前準備、優先順位付け)
Part 2: Distribution Styles and Distribution Keys(分散スタイルと分散キー)
Part 3: Compound and Interleaved Sort Keys (Compound と Interleaved ソートキー)
Part 4: Compression Encodings(圧縮エンコーディング)
Part 5: Table Data Durability(テーブルデータの永続性)[本稿]


著者について

christopherson

Zach Christopherson はパロアルトを拠点とするAWSのシニアデータベースエンジニアです

彼は、全ての業界において、Amazon Redshiftのユーザーが最適なパフォーマンスを得るためのワークロードをチューニングすることを支援しています。 Amazon Redshiftサービスチームの一員として、彼は新しいサービスや既存のサービスの開発にも影響を与えており、貢献しています。休暇の際は妻のメアリーと一緒に新しいレストランにトライし、生まれたばかりの娘ソフィアの世話を楽しんでいます。

 


※日本語訳はSA岡本が担当しました。原文は Amazon Redshift Engineering’s Advanced Table Design Playbook: Table Data Durability

コメント

Twitter, Facebook

このブログの最新情報はTwitterFacebookでもお知らせしています。お気軽にフォローください。

2018年4 月

1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30