Redshiftで、クラスターのノード数により、テーブルのデータサイズが増減するという話

題名の通りなのですが、増減します。詳しい解説は、以下のナレッジページにあります。

Redshift クラスターのストレージスペースについて理解する


Redshiftのテーブルサイズを決定する要員として下記があります。

  • The number of populated slices on each Amazon Redshift cluster
  • The number of table segments used by each table

Redshiftは利用されるスライスに対して、1つ以上のブロックが作成されます。ここで重要な点がRedshiftは列志向型データベースであるので、ブロックには列のデータ単位で記録がされるということです。

一般的なRDBですと、ブロックには行単位でデータが埋められていきますよね。列志向データベースの場合、カラム単位でデータが埋められていくという話で、つまり、テーブル定義している列の数だけ、各スライスにブロックが最低限作成されることになります。

尚、Redshiftのブロックサイズは1MBとなり、一般的なRDBのブロックサイズより大きいため(4KBとか8KBとかのはず)、1ブロックあたりのデータ充填効率が、一般的なRDBと比較すると悪くなる傾向があると言えます。

また、上で記載されている The number of table segments とは、一般的なRDBで言われる セグメント/エクステント/ブロックセグメント とは違い、Redshift特有の部分があるように感じます。ナレッジのページですと、以下のように紹介されています。

変数 number_of_table_segments は、Amazon Redshift テーブルに割り当てるためのテーブルセグメントの数を表わす、以下の 3 つの値のうち、いずれか 1 つを返します。

0: テーブルはロードされたことはありません。ディスクスペースはゼロテーブルセグメントに割り当てます。

1: ソートキーのないテーブルが 1 回以上ロードされました。

2: ソートキーのあるテーブルが 1 回以上ロードされました。


では、クラスターノード数(スライス数)により、実際どの程度テーブルサイズが変動するのか、その点は試してみないとわかりません。ただし、極めて小さいデータソースを投入した場合の、最小テーブルサイズの計算式を記載してくれているため、その傾向を掴むことはできます。

  • For tables created using the KEY or EVEN distribution style:
    • block_size (1 MB) * (number_of_user_columns + 3 system columns) * number_of_populated_slices * number_of_table_segments.
  • For tables created using the ALL distribution style:
    • block_size (1 MB) * (number_of_user_columns + 3 system columns) * number_of_cluster_nodes * number_of_table_segments.

たとえば、ds2.xlarge(2スライス)の3ノード構成と、ds2.8xlarge(16スライス)の1ノード構成で、ソートキーを利用した7列ある分散スタイルEVENのテーブル定義のテーブルに、1レコード分の小さいデータソースを投入すると、以下のようなテーブルサイズの違いが発生する可能性があります。

クラスター構成 最小テーブルサイズの計算式 テーブルサイズ
ds2.xlarge ✕ 3 1MB * ( 7 + 3 ) * 6 * 2 120MB
ds2.8xlarge ✕ 1 1MB * ( 7 + 3 ) * 16 * 2 320MB

この値は最小テーブルサイズの値となるので、実際のデータですとブロックあたりのデータ充填率がもっと良くなるため、ここまで極端な違いにはならないとは思います。

クラスターのノード数により、テーブルサイズが変わるよって話でした。