クラウド工房 Powered by Amazon Web Services

  • 03-3342-9620
  • 受付時間 9:00~18:00 定休日:土日祝

クラウド工房 Powered by Amazon Web Services

menu
9:00~18:00(平日)

Redshiftテーブル設計前必見!!押さえておくべきRedshiftの分散処理の仕組みしくみ!

blog_14_01

 

みなさん。こんにちは。または、こんばんは。STSの山口です。今回もRedshift関連の記事を記載します。さて、Redshiftと言いますと、一般的な特徴としてよく以下の事柄があげられます。

①数百GB~数PBまで容量を拡張可能
 データの容量が増えても容易に拡張が可能。
②カラムナ型と超並列分散処理(MPP)
 カラムナ型と超並列分散処理で非常にDWHに向いたアーキテクチャを搭載している。反面、OLTP系のような小さくて大量のトランザクションをこなす事は苦手。
③インスタンスの従量課金(初期費用、ライセンス不要)
 世の中に販売されている、オンプレミスのDWHアプライアンス製品は初期費用に数千万円~数億円投じなければならなかったが、Redshiftは他のAWSサービス同様、使った分だけ料金がかかる従量課金制で、最も小さい構成で1時間当たり、わずか0.3ドルから利用可能。
 
 以上、3点がRedshiftの特徴として一般的によく言われており、私も、お客様への提案書などでは上記を記述して、Redshiftを紹介する事が多いです。

 さて、今回はそのRedshiftの特徴の1つでもある、「並列分散処理の仕組み」について、ご紹介したいと思います。テーブル設計時にも考慮に入れておくべき点なので、是非、押さえておいてください。

 

ノードスライス

Redshiftの並列分散処理の仕組みを説明する時、重要な要素となるのがノードスライスです。Redshiftでは、1つのノードの中で処理を行うプロセスが複数稼働しています。実はこの複数で稼働しているプロセスはノードスライスと言う単位で稼働しています。ですので、Redshiftでは並列分散で処理を行う単位は、ノードではなくノードスライスと言う単位になります。
 ノードスライスはCPUコア数と同じ数だけ存在します。たとえば、dw1.8xlargeは16コアなので、1ノードにつき、16のノードスライスを持つと言う事になります。dw2.8xlargeでは32コアなので、32のノードスライスと言うようなイメージです。dw1.8xlargeのインスタンスタイプで2ノードのクラスターを構成した場合、16コア×2台=32ノードスライスがこのクラスターには存在する事になり、このクラスターは処理を32並列で実行する事になります。1つのクエリに対して、32並列で処理するわけですから、理論上は非並列処理にくらべると32倍高速に処理できることとなります。
 Redshiftはシェアードナッシング型のデータベースです。各ノードスライスは、専用のCPUコア、メモリ、ディスクを持っており、各ノードスライス間で基本的にはデータを共有するような事は行いません。それぞれのノードスライスは独立して動作します。

 

データ分散の方法

 さて、先ほどまでノードスライスについて説明してきました。各ノードスライスは専用のディスクを有しています。複数のノードスライスに対して、Redshiftはどのようにデータを格納するのでしょうか。Resfhiftにデータを格納する場合、Redshiftでは格納するデータを各ノードスライスに分散して格納します。データの分散方式はいくつかありますが、これはユーザが指定する必要があります。データの分散方式を指定するタイミングはテーブルを作成するタイミングです。この分散方式は現在3つ存在していますので紹介します。

①均等分散
デフォルトのデータ分散方式です。分散方式の指定が無い場合などはこの方式となります。これはすべてのノードスライスに対して、ラウンドロビン方式で均等にデータを分散し格納する方式です。

②KEY分散
このデータの分散方式では、「分散キー」と言うものを使って、各ノードスライスへの配分を決めます。テーブルを作る際にある1つのカラムを「分散キー」として指定します。分散キーに指定できるのは1つのテーブルにつき1つです。分散キーに指定されたカラムの値の「ハッシュ値」によって、配分されるノードスライスが決定されます。なので、同じ値のデータは同じノードスライスへ配分されると言う事になります。

③ALL分散
この分散方式ではテーブル全体のコピーがすべてのノードに分散されます。後述しますが、Redshiftでは「データの再分散」という動作が、非常に重たい処理となり、全てのノードに全てのデータをコピーする事でこのデータの再分散の発生を抑止できます。

 

データの再分散

 データの分散方式の「ALL分散」の中にも少し出てきましたが、Redshiftには「データの再分散」と言う内部的な処理が存在します。この「データの再分散」とは何でしょうか。
均等分散にしてもKEY分散にしても、いずれかのノードスライスにデータは格納されます。また、ほかのノードスライスのデータを基本的には触る事はできません。この時、他のノードスライスのデータが必要になった場合、Redshiftではどのように対処するのでしょうか。その答えが「データの再分散」です。再分散とは、分散キーを変更した一時テーブルを内部的に作成し、この一時テーブルへデータを入れ直す処理の事です。この処理によって、各ノードスライスで必要なデータが集められ、結合などが可能な状態となります。再分散はテーブルに格納されている全てのデータをネットワーク経由で転送する処理となる為、非常に重たい処理です。

例えば以下の例を確認してみてください。

blog_14_02
図1:データの再配分

商品マスタテーブル(item_master)は商品IDに分散キーを指定しているKEY分散とします。一方で売上テーブル(sales)には分散キーは指定していない為、均等分散で作成されたとします。
この時に以下のようなSQLを実行する事を想定してください。

このSQLでは売上テーブルと商品マスタテーブルを商品ID(item_id)カラムで結合していますが、この場合、売上テーブルと商品マスタテーブルのitem_idが同じであったとしても、売上テーブルは均等分散でデータが均等にすべてのノードスライスへ分散されています。商品マスタテーブルは分散キーに指定された商品IDカラムの値の「ハッシュ値」によって、配分されるノードスライスが決定されている為、2つのテーブルの商品IDが等しい行でも、まったく違うノードスライスにデータがある可能性があります。
 このような場合は、内部的にデータの再分散が発生します。具体的には、再分散して「商品IDの同じ行が必ず同じノードスライス上にある」ようにしなければ結合できない為、売上テーブルに対して、商品IDを分散キーにして再分散処理が行われます。※必ずしも売上テーブルが再分散の対象となるとは限りません。

 ここで、ALL分散方式について考えてみましょう。ALL分散でテーブルを作成した場合にはすべてのノードに全データが格納されます。今回の商品マスタテーブルをKEY分散ではなく、ALL分散にした場合は、全てのノードに商品マスタテーブルの全データが存在する様な形でデータが格納されます。この為、同様のSQLによる、売上テーブルと商品マスタテーブルの結合は、再分散処理なしに行う事が可能になります(すべてのノードスライスで商品マスタテーブルの全データを参照可能となる為)。なので、件数が比較的小さく、あまり更新がかからないようなマスタテーブルのようなテーブルについては、再分散を行わせない為にALL分散が有効な分散方式となりえます。

 

ノードスライスとデータの分散方式が、Redshiftの分散処理の仕組みで大事

 上述しましたが、Redshiftはシェアードナッシング型のDBです。メモリとディスクをCPUコアと同数に分割したノードスライスと言う単位で並列処理します。このノードスライス間ではデータの共有が基本的に不可の為、データをどのようにノードスライスに格納するかと言う点は、再分散を考慮に入れるとRedshiftの性能を左右する非常に重要なポイントです。Redshiftでテーブル設計を行う前に是非、押さえておきたいポイントになりますので、是非押さえておきましょう!!それでは、また!!

  • このエントリーをはてなブックマークに追加
山口正寛(1984年生まれ おうし座/2013年入社)

山口正寛(1984年生まれ おうし座/2013年入社)

株式会社システムサポート 東京支社 クラウドコンサルティング事業部所属。
AWSソリューションアーキテクト。
社内では主に、データベース(特にOracle、Redshift)を担当。DBA、コンサルタントなどを経験。最近減量中。

株式会社システムサポート 東京支社 クラウドコンサルティング事業部所属。
AWSソリューションアーキテクト。
社内では主に、データベース(特にOracle、Redshift)を担当。DBA、コンサルタントなどを経験。最近減量中。


ニュース&ブログ

トピックス

∧