Guide de traduction SQL pour Amazon Redshift

Référence de traduction SQL d’Amazon Redshift vers ClickHouse

​

Types de données

Les utilisateurs qui déplacent des données entre ClickHouse et Redshift remarqueront immédiatement que ClickHouse propose une gamme de types plus étendue, et également moins restrictive. Alors que Redshift oblige les utilisateurs à spécifier les longueurs possibles des chaînes, même lorsqu’elles sont variables, ClickHouse supprime cette restriction et cette contrainte pour l’utilisateur en stockant les chaînes comme des octets, sans encodage. Le type String de ClickHouse n’a donc ni limite ni exigence de longueur.

En outre, vous pouvez exploiter les Arrays, Tuples et Enums, absents de Redshift en tant que types natifs (même si les Arrays/Structs peuvent être imités avec SUPER), ce qui est une source fréquente de frustration pour les utilisateurs. ClickHouse permet aussi de conserver des états d’agrégation, soit au moment de la requête, soit même dans une table. Cela permet de préagréger les données, généralement à l’aide d’une vue matérialisée, et peut considérablement améliorer les performances des requêtes courantes.

Ci-dessous, nous indiquons le type ClickHouse équivalent pour chaque type Redshift :

Redshift	ClickHouse
SMALLINT	Int8 *
INTEGER	Int32 *
BIGINT	Int64 *
DECIMAL	UInt128, UInt256, Int128, Int256, Decimal(P, S), Decimal32(S), Decimal64(S), Decimal128(S), Decimal256(S) - (haute précision et plages de valeurs étendues)
REAL	Float32
DOUBLE PRECISION	Float64
BOOLEAN	Bool
CHAR	String, FixedString
VARCHAR **	String
DATE	Date32
TIMESTAMP	DateTime, DateTime64
TIMESTAMPTZ	DateTime, DateTime64
GEOMETRY	Types de données géo
GEOGRAPHY	Types de données Geo (moins aboutis, p. ex. sans systèmes de coordonnées - cela peut être émulé avec des fonctions)
HLLSKETCH	AggregateFunction(uniqHLL12, X)
SUPER	Tuple, Nested, Array, JSON, Map
TIME	DateTime, DateTime64
TIMETZ	DateTime, DateTime64
VARBYTE **	String associé aux fonctions Bit et d’encodage

_{* ClickHouse prend également en charge les entiers non signés avec des plages de valeurs étendues, c.-à-d. UInt8, UInt32, UInt32 et UInt64.
**Le type String de ClickHouse n’est pas limité par défaut, mais il peut être restreint à des longueurs spécifiques à l’aide de contraintes.}

​

Syntaxe DDL

​

Clés de tri

ClickHouse et Redshift reposent tous deux sur le concept de « clé de tri », qui définit la manière dont les données sont triées lors de leur stockage. Redshift définit la clé de tri à l’aide de la clause SORTKEY :

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

En revanche, ClickHouse utilise une clause ORDER BY pour définir l’ordre de tri :

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

Dans la plupart des cas, vous pouvez utiliser dans ClickHouse les mêmes colonnes de clé de tri et le même ordre que dans Redshift, en supposant que vous utilisez le type COMPOUND par défaut. Lorsque des données sont ajoutées à Redshift, vous devez exécuter les commandes VACUUM et ANALYZE pour réordonner les données nouvellement ajoutées et mettre à jour les statistiques du planificateur de requêtes ; sinon, l’espace non trié augmente. Aucun processus de ce type n’est nécessaire dans ClickHouse.

Redshift prend en charge quelques fonctionnalités pratiques pour les clés de tri. La première concerne les clés de tri automatiques (avec SORTKEY AUTO). Bien que cela puisse convenir pour démarrer, des clés de tri explicites garantissent les meilleures performances et la meilleure efficacité de stockage lorsque la clé de tri est optimale. La seconde est la clé de tri INTERLEAVED, qui accorde le même poids à un sous-ensemble de colonnes de la clé de tri afin d’améliorer les performances lorsqu’une requête utilise une ou plusieurs colonnes de tri secondaires. ClickHouse prend en charge des projections explicites, qui permettent d’obtenir le même résultat final avec une configuration légèrement différente.

Vous devez savoir que le concept de « clé primaire » recouvre des réalités différentes dans ClickHouse et Redshift. Dans Redshift, la clé primaire se rapproche du concept traditionnel des SGBDR, destiné à imposer des contraintes. Cependant, celles-ci ne sont pas strictement appliquées dans Redshift et servent plutôt d’indications pour le planificateur de requêtes et la distribution des données entre les nœuds. Dans ClickHouse, la clé primaire désigne les colonnes utilisées pour construire l’index primaire sparse, qui sert à garantir que les données sont ordonnées sur le disque, afin de maximiser la compression tout en évitant de surcharger l’index primaire et de gaspiller de la mémoire.