題名の通りなのですが、増減します。詳しい解説は、以下のナレッジページにあります。
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 |
この値は最小テーブルサイズの値となるので、実際のデータですとブロックあたりのデータ充填率がもっと良くなるため、ここまで極端な違いにはならないとは思います。
クラスターのノード数により、テーブルサイズが変わるよって話でした。