■ はじめに
https://dk521123.hatenablog.com/entry/2021/08/29/000000
で、PostgreSQL と Amazon Redshift との違いに触れたが 「【０】サンプルテーブル」をPostgreSQLで実行したら いくつもエラーになった。 その中で、「distkey(listid)」「compound sortkey(listid,sellerid)」 もエラーになったので、調べて纏めてみる。 （個人的な印象としては、Redshiftにはインデックスがないので その代わりになるような役割な機能な印象） 今回の内容は、以下の公式サイトを元に纏めているので 詳細は、こちらを参照。
https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/r_CREATE_TABLE_NEW.html
目次
【０】サンプルテーブル 【１】分散スタイル（DistStyle） 【２】分散キー（DistKey） 【３】ソートキー（SortKey） １）単一ソートキー ２）複合ソートキー（Compound SortKey） ３）インターリーブソートキー（Interleaved SortKey）
【０】サンプルテーブル
公式サイトより抜粋/整形。
例１：salesテーブル
https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/r_CREATE_TABLE_examples.html
create table sales( salesid integer not null, listid integer not null, sellerid integer not null, buyerid integer not null, eventid integer not null encode mostly16, dateid smallint not null, qtysold smallint not null encode mostly8, pricepaid decimal(8,2) encode delta32k, commission decimal(8,2) encode delta32k, saletime timestamp, primary key(salesid), foreign key(listid) references listing(listid), foreign key(sellerid) references users(userid), foreign key(buyerid) references users(userid), foreign key(dateid) references date(dateid) ) -- 【２】分散キー（DistKey） distkey(listid) -- 【３】ソートキー（SortKey） -- ２）複合ソートキー（Compound SortKey） compound sortkey(listid,sellerid);
例２：customer_interleaved テーブル
create table customer_interleaved ( c_custkey integer not null, c_name varchar(25) not null, c_address varchar(25) not null, c_city varchar(10) not null, c_nation varchar(15) not null, c_region varchar(12) not null, c_phone varchar(15) not null, c_mktsegment varchar(10) not null) -- 【１】分散スタイル（DistStyle） diststyle all -- 【３】ソートキー（SortKey） -- ３）インターリーブソートキー（Interleaved SortKey） interleaved sortkey (c_custkey, c_city, c_mktsegment);
【１】分散スタイル（DistStyle）
* テーブル全体のデータディストリビューションスタイルを 定義するキーワード
構文
DISTSTYLE { AUTO | EVEN | KEY | ALL }
| Option値 | 説明 | 備考 |
|---|---|---|
| AUTO | 分散スタイルを小さなテーブルに割り当て、その後テーブルが大きくなると、テーブルを EVEN 分散に変更 | デフォルト |
| EVEN | ラウンドロビン分散方式で、テーブルデータをクラスター内のノード全体に均等に分散 | - |
| KEY | データは、DISTKEY 列の値で分散 | - |
| ALL | テーブル全体のコピーがすべてのノードに分散 | その分、ストレージ要件が倍増しテーブルに関する負荷とメンテナンス時間が増大 |
AUTO
* 以下のサイトを参照。
https://dev.classmethod.jp/articles/20190501-amazon-redshift-diststyle-auto/
【２】分散キー（DistKey）
* テーブルの分散キーとして使用する列を指定する制約 => Redshiftはテーブルデータを複数ノードに分散して格納する * DistKey は１つのみ指定可能
構文
DISTKEY ( column_name )
【３】ソートキー（SortKey）
* テーブルに対して 1 つ以上のソートキーを指定 * データをテーブルにロードすると、 データはソートキーとして指定された列に従ってソートされる
構文
[COMPOUND | INTERLEAVED ] SORTKEY ( column_name [,...]) | [ SORTKEY AUTO ]
１）単一ソートキー（Single-column SortKey）
* 単一カラムのみをソートキーとして指定
サンプル
sortkey(c_custkey);
２）複合ソートキー（Compound SortKey）
* 複数カラムを指定したソートキー
指定する基準について
* ORDER BY, GROUP BY, PARTION BY をよく使うキーに置いて効果的
サンプル
-- 上記の「例１：salesテーブル」より抜粋
compound sortkey(listid,sellerid);
３）インターリーブソートキー（Interleaved SortKey）
* 複数カラムを指定したソートキー
「２）複合ソートキー（Compound SortKey）」との相違
* 指定カラムを単独で使用してもパフォーマンス向上に繋がる点 => ただし、「デメリット」があるので、そちらも参照。
デメリット
* インターリーブソートキーの性能を維持するためには 定期的に VACUUM REINDEX を実行する必要がある => VACUUM REINDEXは実行コストが非常に高いため、 運用面と相談して選択する必要がありそう => VACUUM REINDEX については、以下の関連記事を参照のこと。
https://dk521123.hatenablog.com/entry/2021/09/05/214403
補足：インターリーブ（interleave）
* データを何らかの領域で不連続な形で配置し 性能を向上させる技法
参考文献
https://knowledge.insight-lab.co.jp/bi/redshift-ddl-performance
https://www.task-notes.com/entry/20150901/1441076400
https://dev.classmethod.jp/articles/redshift-sortkey-usecase/
https://recipe.kc-cloud.jp/archives/3575
https://recipe.kc-cloud.jp/archives/3032
https://d1.awsstatic.com/events/jp/2017/summit/slide/D3T1-5.pdf
関連記事
Amazon Redshift ～ 入門編 ～
https://dk521123.hatenablog.com/entry/2020/02/22/002139
Amazon Redshift ～ 他DB・サービスとの違い ～
https://dk521123.hatenablog.com/entry/2021/08/29/000000
Amazon Redshift ～ VACUUM ～
https://dk521123.hatenablog.com/entry/2021/09/05/214403
