Amazon Redshiftについて色々と聞く機会があった。その時聞いたことメモ。
Amazon EMRとAmazon Redshiftの違い
まずは、よく比較されることになるEMRとRedshiftの違いから。
Amazon EMR
HadoopクラスタとHiveを簡単に使うためのサービス。自由な台数のクラスタを自由なタイミングで起動したり破棄したりできる。
Hadoopクラスタ運用(初期設定、チューニング、等)の手間が完全に不要なのはものすごいメリット。
クエリの速さは、ログの量によりますが、数分～数十分くらいかかる。(ログの行数が数百万～数千万ある時)
Amazon Redshift
利用者から見た基本的な用途・できることはEMRとほとんど同じ。ただ、仕組みが全く違う。
RedshiftはRDBのような(Postgresベースらしい)テーブル設計を持つ。例えば、VARCHAR(255)みたいなカラムを持つ。EMR(Hive)では全部のカラムをSTRINGにしたりしても(パフォーマンス的に)全然OK。
RDBのようなややこしいテーブル設計が必要な代わりに、クエリの実行速度はHiveよりも断然早い。(最大で10倍、通常は2～3倍くらい？)
いわゆる普通のSQLが使えるので、fromの後にテーブル名を2つ書いたりできて便利。HiveQLだとそういう省略記法が書けないのでJOINを丁寧に書いていく必要がある。
EMRとRedshiftのどちらを選ぶべきか
ざっくり言うと、EMRはシンプルだけど遅い、Redshiftは複雑だけど早い、という違いがある。値段は、EMRの方が比較的安いっぽい。
ログの行数が数百万～数億くらいならEMRを選んだ方がよいと思う。
早い遅いと言っても、EMRもRedshiftも、通常のDBのようにクエリの結果をミリ秒オーダーで返すDBではない。あくまでもバッチ集計用と割り切った方がよい。
EMRはシンプルでRedshiftは複雑と書いたのは、主にテーブルのカラムの部分。とは言っても、EMR(Hive)は自分で圧縮コーデックやファイルフォーマットを指定する必要があるし、どっちがシンプルかは一概には言えない。
テーブルに対してDISTKEYとSORTKEYを指定する必要がある
ここからはRedshiftの特徴について書いていきます。
DISTKEYはカーディナリティが良い(データが最もばらついている)であろうカラムに指定する。
SORTKEYは範囲指定をすることが多いカラムに指定する。例えばDateTime型とか。
DISTKEYとSORTKEYは一見、RDBにおけるインデックスっぽいけど、インデックスとはけっこう違うものらしい。あと、カラムナー指向のDBではDISTKEYとSORTKEYの考え方は割と一般的らしい。
同時実行クエリ数は最大15
並列に実行できるクエリは最大15個らしい。FIFOのキューとして実装されている。
それだけだと遅いクエリがきたときに早いクエリも含めて全部ストップしてしまうので、早いクエリ用のキューと遅いクエリ用のキューを分けることができる。
遅いクエリ用のキューと早いクエリ用のキューはユーザーグループごとに使い分けるっぽい。
同時接続セッション数は最大95
通常のWebアプリケーションからがんがん接続するような用途には使いづらい。そもそもクエリが遅いってのもありますが。
クエリの実行に最低でも数分くらいはかかるので、どうしてもWebアプリケーションからクエリを実行したいなら、結果をキャッシュしておくとか、一旦別のDBを介すとか工夫する必要がある。
ストレージ容量はすごくでかい
細かくは忘れたけどテラ単位だったような。
Redshiftのストレージとは別にS3を介すことになるので、S3に保存しっぱなしにしておくなら実質的には容量無限です。
バックアップにはスナップショットを利用する
AWSを使う人にはお馴染みのスナップショットの仕組みを使って障害に備えることになる。デフォルトでは半日に1回くらい自動でスナップショットが取られるっぽい。
任意のタイミングでスナップショットを取ることもできる。
Redshiftのストレージとは別にS3もあるのでまぁ普通に安心できると思う。
インスタンスタイプはh1.xlarge、h1.8xlargeから選べる
それぞれのインスタンスを使いたい台数分指定してRedshiftを起動することになる。シングルインスタンス構成も可能。
間違いのご指摘やご意見は@ts_3156まで
よろしくお願いします(^^)
