ニュース＆ブログ
Redshiftテーブル設計前必見！！押さえておくべきRedshiftの分散処理の仕組みしくみ！
投稿日：2014/9/1
みなさん。こんにちは。または、こんばんは。STSの山口です。今回もRedshift関連の記事を記載します。さて、Redshiftと言いますと、一般的な特徴としてよく以下の事柄があげられます。
①数百ＧＢ～数ＰＢまで容量を拡張可能
データの容量が増えても容易に拡張が可能。
②カラムナ型と超並列分散処理（ＭＰＰ）
カラムナ型と超並列分散処理で非常にＤＷＨに向いたアーキテクチャを搭載している。
反面、ＯＬＴＰ系のような小さくて大量のトランザクションをこなす事は苦手。
③インスタンスの従量課金（初期費用、ライセンス不要）
世の中に販売されている、オンプレミスのＤＷＨアプライアンス製品は初期費用に数千万円～数億円投じなければならなかったが、Redshiftは他のＡＷＳサービス同様、使った分だけ料金がかかる従量課金制で、最も小さい構成で1時間当たり、わずか0.3ドルから利用可能。
以上、３点がRedshiftの特徴として一般的によく言われており、私も、お客様への提案書などでは上記を記述して、Redshiftを紹介する事が多いです。
さて、今回はそのRedshiftの特徴の１つでもある、「並列分散処理の仕組み」について、ご紹介したいと思います。テーブル設計時にも考慮に入れておくべき点なので、是非、押さえておいてください。
ノードスライス
Redshiftの並列分散処理の仕組みを説明する時、重要な要素となるのがノードスライスです。Redshiftでは、１つのノードの中で処理を行うプロセスが複数稼働しています。実はこの複数で稼働しているプロセスはノードスライスと言う単位で稼働しています。ですので、Redshiftでは並列分散で処理を行う単位は、ノードではなくノードスライスと言う単位になります。
ノードスライスはCPUコア数と同じ数だけ存在します。たとえば、dw1.8xlargeは16コアなので、1ノードにつき、16のノードスライスを持つと言う事になります。dw2.8xlargeでは32コアなので、32のノードスライスと言うようなイメージです。dw1.8xlargeのインスタンスタイプで２ノードのクラスターを構成した場合、16コア×２台＝32ノードスライスがこのクラスターには存在する事になり、このクラスターは処理を32並列で実行する事になります。１つのクエリに対して、32並列で処理するわけですから、理論上は非並列処理にくらべると32倍高速に処理できることとなります。
Redshiftはシェアードナッシング型のデータベースです。各ノードスライスは、専用のCPUコア、メモリ、ディスクを持っており、各ノードスライス間で基本的にはデータを共有するような事は行いません。それぞれのノードスライスは独立して動作します。
データ分散の方法
さて、先ほどまでノードスライスについて説明してきました。各ノードスライスは専用のディスクを有しています。複数のノードスライスに対して、Redshiftはどのようにデータを格納するのでしょうか。Resfhiftにデータを格納する場合、Redshiftでは格納するデータを各ノードスライスに分散して格納します。データの分散方式はいくつかありますが、これはユーザが指定する必要があります。データの分散方式を指定するタイミングはテーブルを作成するタイミングです。この分散方式は現在３つ存在していますので紹介します。
①均等分散
デフォルトのデータ分散方式です。分散方式の指定が無い場合などはこの方式となります。これはすべてのノードスライスに対して、ラウンドロビン方式で均等にデータを分散し格納する方式です。
②KEY分散
このデータの分散方式では、「分散キー」と言うものを使って、各ノードスライスへの配分を決めます。テーブルを作る際にある１つのカラムを「分散キー」として指定します。分散キーに指定できるのは１つのテーブルにつき１つです。分散キーに指定されたカラムの値の「ハッシュ値」によって、配分されるノードスライスが決定されます。なので、同じ値のデータは同じノードスライスへ配分されると言う事になります。
③ALL分散
この分散方式ではテーブル全体のコピーがすべてのノードに分散されます。後述しますが、Redshiftでは「データの再分散」という動作が、非常に重たい処理となり、全てのノードに全てのデータをコピーする事でこのデータの再分散の発生を抑止できます。
データの再分散
データの分散方式の「ALL分散」の中にも少し出てきましたが、Redshiftには「データの再分散」と言う内部的な処理が存在します。この「データの再分散」とは何でしょうか。
均等分散にしてもKEY分散にしても、いずれかのノードスライスにデータは格納されます。また、ほかのノードスライスのデータを基本的には触る事はできません。この時、他のノードスライスのデータが必要になった場合、Redshiftではどのように対処するのでしょうか。その答えが「データの再分散」です。再分散とは、分散キーを変更した一時テーブルを内部的に作成し、この一時テーブルへデータを入れ直す処理の事です。この処理によって、各ノードスライスで必要なデータが集められ、結合などが可能な状態となります。再分散はテーブルに格納されている全てのデータをネットワーク経由で転送する処理となる為、非常に重たい処理です。
図1：データの再配分
商品マスタテーブル（item_master）は商品IDに分散キーを指定しているKEY分散とします。一方で売上テーブル（sales）には分散キーは指定していない為、均等分散で作成されたとします。
この時に以下のようなSQLを実行する事を想定してください。
select * from sales s inner join item_master i on s.item_id=i.item_id;このような場合は、内部的にデータの再分散が発生します。具体的には、再分散して「商品IDの同じ行が必ず同じノードスライス上にある」ようにしなければ結合できない為、売上テーブルに対して、商品ＩＤを分散キーにして再分散処理が行われます。※必ずしも売上テーブルが再分散の対象となるとは限りません。
ここで、ALL分散方式について考えてみましょう。ALL分散でテーブルを作成した場合にはすべてのノードに全データが格納されます。今回の商品マスタテーブルをKEY分散ではなく、ALL分散にした場合は、全てのノードに商品マスタテーブルの全データが存在する様な形でデータが格納されます。この為、同様のSQLによる、売上テーブルと商品マスタテーブルの結合は、再分散処理なしに行う事が可能になります（すべてのノードスライスで商品マスタテーブルの全データを参照可能となる為）。なので、件数が比較的小さく、あまり更新がかからないようなマスタテーブルのようなテーブルについては、再分散を行わせない為にALL分散が有効な分散方式となりえます。
ノードスライスとデータの分散方式が、Redshiftの分散処理の仕組みで大事
上述しましたが、Redshiftはシェアードナッシング型のDBです。メモリとディスクをCPUコアと同数に分割したノードスライスと言う単位で並列処理します。このノードスライス間ではデータの共有が基本的に不可の為、データをどのようにノードスライスに格納するかと言う点は、再分散を考慮に入れるとRedshiftの性能を左右する非常に重要なポイントです。Redshiftでテーブル設計を行う前に是非、押さえておきたいポイントになりますので、是非押さえておきましょう！！それでは、また！！
山口正寛（1984年生まれ おうし座/2013年入社）
株式会社システムサポート 東京支社 クラウドコンサルティング事業部所属。
AWSソリューションアーキテクト。
社内では主に、データベース（特にOracle、Redshift）を担当。DBA、コンサルタントなどを経験。最近減量中。