Amazon Redshift SQL 変換ガイド

データ型

ClickHouse と Redshift 間でデータを移動するユーザーは、ClickHouse がより幅広く、かつ制約の少ない型を提供していることにすぐ気付くでしょう。Redshift では、可変長の場合であってもユーザーは文字列の長さを指定する必要がありますが、ClickHouse は文字列をエンコードせずバイト列として格納することで、この制限と負担をユーザーから取り除きます。そのため、ClickHouse の String 型には長さの上限や長さ指定の要件がありません。

さらに、Redshift には第一級のデータ型としては存在しない（SUPER を使用して配列や構造体を模倣することは可能なものの、多くのユーザーの不満の原因となっている）Array、Tuple、Enum を活用できます。加えて ClickHouse では、集約状態をクエリ時、あるいはテーブル内に保持することも可能です。これにより、通常はマテリアライズドビューを使用してデータを事前集約でき、よく実行されるクエリのパフォーマンスを劇的に向上させることができます。

以下では、各 Redshift 型に対して同等の ClickHouse 型を対応付けて示します。

Redshift	ClickHouse
`SMALLINT`	`Int8` *
`INTEGER`	`Int32` *
`BIGINT`	`Int64` *
`DECIMAL`	`UInt128`, `UInt256`, `Int128`, `Int256`, `Decimal(P, S)`, `Decimal32(S)`, `Decimal64(S)`, `Decimal128(S)`, `Decimal256(S)` - （高精度かつ広い範囲を扱える）
`REAL`	`Float32`
`DOUBLE PRECISION`	`Float64`
`BOOLEAN`	`Bool`
`CHAR`	`String`, `FixedString`
`VARCHAR` **	`String`
`DATE`	`Date32`
`TIMESTAMP`	`DateTime`, `DateTime64`
`TIMESTAMPTZ`	`DateTime`、`DateTime64`
`GEOMETRY`	地理データ型
`GEOGRAPHY`	Geo Data Types（機能はまだ十分ではない（例: 座標系がない）が、関数でエミュレート可能）
`HLLSKETCH`	`AggregateFunction(uniqHLL12, X)`
`SUPER`	`Tuple`, `Nested`, `Array`, `JSON`, `Map`
`TIME`	`DateTime`, `DateTime64`
`TIMETZ`	`DateTime`, `DateTime64`
`VARBYTE` **	`String` を `Bit` 関数および Encoding 関数と組み合わせて使用する

_{* ClickHouse は、より広い範囲を持つ符号なし整数、すなわち UInt8、UInt32、UInt32、UInt64 もサポートしています。}
_{**ClickHouse の String 型はデフォルトでは長さが無制限ですが、Constraints を使用して特定の長さに制限できます。}

DDL 構文

ソートキー

ClickHouse と Redshift の両方には「ソートキー」という概念があり、データを保存する際にどのような順序で格納するかを定義します。Redshift では、 SORTKEY 句を使ってソートキーを定義します。

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

一方、ClickHouse では ORDER BY 句を使ってソート順を指定します。

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

一方、ClickHouse では ORDER BY 句を使ってソート順を指定します。

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

Redshift はソートキー用のいくつかの便利な機能をサポートしています。1 つは自動ソートキー（SORTKEY AUTO の使用）です。これは導入初期には適切な場合がありますが、ソートキーが最適な場合には、明示的なソートキーを指定するほうが最高のパフォーマンスとストレージ効率を得られます。2 つ目は INTERLEAVED ソートキーで、ソートキー内の一部のカラムに同じ重みを与えることで、クエリが 1 つ以上のセカンダリソートカラムを利用する場合のパフォーマンスを向上させます。ClickHouse は明示的な projections をサポートしており、セットアップはやや異なりますが、同様の結果を実現します。

「primary key」という概念が ClickHouse と Redshift で異なるものを表していることを理解しておく必要があります。Redshift における primary key は、制約を強制することを意図した、従来の RDBMS の概念に似ています。しかし、Redshift ではこれらは厳密には強制されず、代わりにクエリプランナーおよびノード間でのデータ分散のためのヒントとして機能します。ClickHouse では、primary key はスパースなプライマリインデックスを構成するために使用されるカラムを示し、ディスク上でデータが順序付けられていることを保証して圧縮率を最大化しつつ、プライマリインデックスを汚染してメモリを無駄に消費することを避けます。

データ型​

DDL 構文​

ソートキー​

データ型

DDL 構文

ソートキー