Amazon Redshift SQL 変換ガイド

ClickHouse と Redshift の間でデータを移行するユーザーは、ClickHouse のほうがより幅広い型を備え、しかも制約が少ないことにすぐ気付くでしょう。Redshift では、可変長であっても文字列の長さを指定する必要がありますが、ClickHouse では文字列をエンコーディングせずにバイト列として格納するため、この制約や手間がありません。したがって、ClickHouse の String 型 には制限がなく、長さの指定も不要です。

さらに、Redshift にはない Arrays、Tuples、Enums を第一級の機能として利用できます (SUPER を使って Arrays/Structs を擬似的に表現することは可能ですが、これはユーザーのよくある不満点です) 。また ClickHouse では、集計状態をクエリ実行時だけでなく、テーブルに永続化することもできます。これにより、通常は materialized view を使ってデータを事前集計でき、一般的なクエリの性能を大幅に向上させることができます。

以下では、各 Redshift 型に対応する ClickHouse の同等の型を示します:

ClickHouse と Redshift はどちらも「ソートキー」という概念を持っており、これは データの保存時のソート順を定義するものです。Redshift では、ソートキーを SORTKEY 句で定義します。

CREATE TABLE some_table(...) SORTKEY (column1, column2)

一方、ClickHouseでは、ソート順を指定するために ORDER BY 句を使用します。

CREATE TABLE some_table(...) ENGINE = MergeTree ORDER BY (column1, column2)

ほとんどの場合、デフォルトの COMPOUND 型を使用していれば、ClickHouse では Redshift と同じソートキーのカラムと順序を使用できます。Redshift では、データが 追加されたら、VACUUM と ANALYZE コマンドを実行して、新しく追加されたデータを再ソートし、クエリプランナー用の統計情報を更新する必要があります。そうしないと、 未ソート領域が増えていきます。ClickHouse では、そのような処理は必要ありません。

Redshift は、ソートキーに関する便利な機能をいくつかサポートしています。1 つ目は 自動ソートキー (SORTKEY AUTO の使用) です。これは使い始めには適していますが、 ソートキーを最適に設計できるのであれば、明示的に指定したソートキーのほうが、パフォーマンスとストレージ 効率の両面で最良の結果を得られます。2 つ目は INTERLEAVED ソートキーで、 クエリが 1 つ以上の二次ソートカラムを使用する場合のパフォーマンスを向上させるため、 ソートキー内の一部のカラムに同等の重みを与えます。ClickHouse では、 明示的な プロジェクション をサポートしており、設定方法はやや異なるものの、 最終的には同様の結果を実現できます。

「主キー」という概念は、 ClickHouse と Redshift では意味が異なることに注意してください。Redshift では、主キーは従来の 制約を強制することを意図した RDBMS の概念に近いものです。ただし、Redshift ではこれらは 厳密には強制されず、代わりにクエリプランナーへのヒントや、 ノード間でのデータ分散のために使われます。ClickHouse では、主キーは スパースプライマリインデックスの構築に使用されるカラムを指し、これはデータがディスク上で 順序付けされるようにするために使われます。これにより、圧縮を最大化しつつ、プライマリインデックスの肥大化や メモリの無駄遣いを防げます。