> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-mintlify-8c05c8a2.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
> Référence de traduction SQL
# Migration de Snowflake vers ClickHouse
## Types de données
### Numériques
Les utilisateurs qui déplacent des données entre ClickHouse et Snowflake remarqueront immédiatement que ClickHouse offre une granularité plus fine pour la déclaration des types numériques. Par exemple, Snowflake propose le type Number pour les valeurs numériques. Cela oblige l’utilisateur à spécifier une précision (nombre total de chiffres) et une échelle (nombre de chiffres à droite de la virgule), jusqu’à un total de 38. Les déclarations d’entiers sont synonymes de Number et définissent simplement une précision et une échelle fixes, tout en conservant la même plage de valeurs. Cette commodité est possible, car la modification de la précision (l’échelle est de 0 pour les entiers) n’a pas d’incidence sur la taille des données sur disque dans Snowflake : le nombre minimal d’octets requis pour une plage numérique donnée est utilisé au moment de l’écriture, au niveau de la micro-partition. L’échelle a toutefois un impact sur l’espace de stockage, partiellement compensé par la compression. Un type `Float64` offre une plage de valeurs plus étendue, au prix d’une perte de précision.
À l’inverse, ClickHouse propose plusieurs niveaux de précision, signés et non signés, pour les flottants et les entiers. Avec ces types, vous pouvez spécifier explicitement la précision requise pour les entiers afin d’optimiser le stockage et la surcharge mémoire. Un type Decimal, équivalent au type Number de Snowflake, offre également une précision et une échelle deux fois plus élevées, jusqu’à 76 chiffres. En plus d’une valeur `Float64` similaire, ClickHouse propose aussi un `Float32` lorsque la précision est moins critique et que la compression est primordiale.
### Chaînes
ClickHouse et Snowflake adoptent des approches opposées pour le stockage des
données textuelles. Le `VARCHAR` de Snowflake contient des caractères Unicode en UTF-8, ce qui permet à l'utilisateur de
spécifier une longueur maximale. Cette longueur n'a aucun impact sur le stockage ni sur
les performances : le nombre minimal d'octets est toujours utilisé pour stocker une chaîne, et
elle sert uniquement à imposer des contraintes utiles aux outils en aval. D'autres types, tels
que `Text` et `NChar`, sont simplement des alias de ce type. À l'inverse, ClickHouse
stocke toutes les [données de chaîne sous forme d'octets bruts](/fr/reference/data-types/string) avec le type `String`
(aucune indication de longueur n'est requise), en laissant
à l'utilisateur la gestion de l'encodage, avec des
[fonctions à l'exécution de la requête](/fr/reference/functions/regular-functions/string-functions#lengthUTF8)
disponibles pour différents encodages. Pour en comprendre la logique, nous renvoyons le lecteur à ["Opaque data argument"](https://utf8everywhere.org/#cookie).
Le type `String` de ClickHouse est donc, dans son implémentation, davantage comparable
au type Binary de Snowflake. [Snowflake](https://docs.snowflake.com/en/sql-reference/collation) et [ClickHouse](/fr/reference/statements/select/order-by#collation-support)
prennent tous deux en charge la « collation », ce qui permet aux utilisateurs de redéfinir la manière dont les chaînes sont triées et comparées.
### Types semi-structurés
Snowflake prend en charge les types `VARIANT`, `OBJECT` et `ARRAY` pour les
données semi-structurées.
ClickHouse propose les types équivalents [`Variant`](/fr/reference/data-types/variant),
`Object` (désormais obsolète au profit du type `JSON` natif) et [`Array`](/fr/reference/data-types/array).
En outre, ClickHouse propose le type [`JSON`](/fr/reference/data-types/newjson)
qui remplace le type `Object('json')`, désormais obsolète, et qui offre d'excellentes
performances ainsi qu'une grande efficacité de stockage [par rapport à d'autres types JSON natifs](https://jsonbench.com/).
ClickHouse prend également en charge les [`Tuple`s](/fr/reference/data-types/tuple) nommés et les tableaux de Tuple
via le type [`Nested`](/fr/reference/data-types/nested-data-structures/index),
ce qui permet aux utilisateurs de mapper explicitement des structures imbriquées. Cela permet d'appliquer des codecs et des
optimisations de type à toute la hiérarchie, contrairement à Snowflake, qui
oblige l'utilisateur à utiliser les types `OBJECT`, `VARIANT` et `ARRAY` pour l'objet
externe et ne permet pas le [typage interne explicite](https://docs.snowflake.com/en/sql-reference/data-types-semistructured#characteristics-of-an-object).
Ce typage interne simplifie également les requêtes sur les valeurs numériques imbriquées dans ClickHouse,
qui n'ont pas besoin d'être converties et peuvent être utilisées dans des définitions d'index.
Dans ClickHouse, des codecs et des types optimisés peuvent aussi être appliqués aux sous-structures.
Cela offre aussi l'avantage supplémentaire de maintenir une excellente compression
avec les structures imbriquées, comparable à celle des données aplaties. En revanche, du fait de
l'impossibilité d'appliquer des types spécifiques aux sous-structures, Snowflake recommande d'[aplatir
les données pour obtenir une compression optimale](https://docs.snowflake.com/en/user-guide/semistructured-considerations#storing-semi-structured-data-in-a-variant-column-vs-flattening-the-nested-structure).
Snowflake [impose également des restrictions de taille](https://docs.snowflake.com/en/user-guide/semistructured-considerations#data-size-limitations)
pour ces types de données.
### Référence des types
| Snowflake | ClickHouse | Remarque | |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | - |
| [`NUMBER`](https://docs.snowflake.com/en/sql-reference/data-types-numeric) | [`Decimal`](/fr/reference/data-types/decimal) | ClickHouse prend en charge une précision et une échelle deux fois plus élevées que Snowflake : 76 chiffres contre 38. | |
| [`FLOAT`, `FLOAT4`, `FLOAT8`](https://docs.snowflake.com/en/sql-reference/data-types-numeric#data-types-for-floating-point-numbers) | [`Float32`, `Float64`](/fr/reference/data-types/float) | Dans Snowflake, tous les nombres à virgule flottante sont codés sur 64 bits. | |
| [`VARCHAR`](https://docs.snowflake.com/en/sql-reference/data-types-text#varchar) | [`String`](/fr/reference/data-types/string) | | |
| [`BINARY`](https://docs.snowflake.com/en/sql-reference/data-types-text#binary) | [`String`](/fr/reference/data-types/string) | | |
| [`BOOLEAN`](https://docs.snowflake.com/en/sql-reference/data-types-logical) | [`Bool`](/fr/reference/data-types/boolean) | | |
| [`DATE`](https://docs.snowflake.com/en/sql-reference/data-types-datetime#date) | [`Date`](/fr/reference/data-types/date), [`Date32`](/fr/reference/data-types/date32) | `DATE` dans Snowflake offre une plage de dates plus étendue que ClickHouse ; par exemple, la valeur minimale de `Date32` est `1900-01-01`, et celle de `Date`, `1970-01-01`. Dans ClickHouse, `Date` offre un stockage plus économique (deux octets). | |
| [`TIME(N)`](https://docs.snowflake.com/en/sql-reference/data-types-datetime#time) | Pas d’équivalent direct, mais peut être représenté par [`DateTime`](/fr/reference/data-types/datetime) et [`DateTime64(N)`](/fr/reference/data-types/datetime64). | `DateTime64` utilise les mêmes notions de précision. | |
| [`TIMESTAMP`](https://docs.snowflake.com/en/sql-reference/data-types-datetime#timestamp) - [`TIMESTAMP_LTZ`](https://docs.snowflake.com/en/sql-reference/data-types-datetime#timestamp-ltz-timestamp-ntz-timestamp-tz), [`TIMESTAMP_NTZ`](https://docs.snowflake.com/en/sql-reference/data-types-datetime#timestamp-ltz-timestamp-ntz-timestamp-tz), [`TIMESTAMP_TZ`](https://docs.snowflake.com/en/sql-reference/data-types-datetime#timestamp-ltz-timestamp-ntz-timestamp-tz) | [`DateTime`](/fr/reference/data-types/datetime) et [`DateTime64`](/fr/reference/data-types/datetime64) | `DateTime` et `DateTime64` peuvent éventuellement avoir un paramètre TZ défini pour la colonne. S’il n’est pas présent, le fuseau horaire du serveur est utilisé. De plus, un paramètre `--use_client_time_zone` est disponible pour le client. | |
| [`VARIANT`](https://docs.snowflake.com/en/sql-reference/data-types-semistructured#variant) | [`JSON`, `Tuple`, `Nested`](/fr/reference/formats/index) | Le type `JSON` est expérimental dans ClickHouse. Ce type déduit les types des colonnes au moment de l’insertion. `Tuple`, `Nested` et `Array` peuvent aussi être utilisés pour définir explicitement des structures typées, comme alternative. | |
| [`OBJECT`](https://docs.snowflake.com/en/sql-reference/data-types-semistructured#object) | [`Tuple`, `Map`, `JSON`](/fr/reference/formats/index) | `OBJECT` et `Map` sont tous deux comparables au type `JSON` dans ClickHouse, où les clés sont des `String`. ClickHouse exige que la valeur reste cohérente et fortement typée, tandis que Snowflake utilise `VARIANT`. Cela signifie que les valeurs associées à différentes clés peuvent être de types différents. Si c’est nécessaire dans ClickHouse, définissez explicitement la hiérarchie à l’aide de `Tuple` ou utilisez le type `JSON`. | |
| [`ARRAY`](https://docs.snowflake.com/en/sql-reference/data-types-semistructured#array) | [`Array`](/fr/reference/data-types/array), [`Nested`](/fr/reference/data-types/nested-data-structures/index) | `ARRAY` dans Snowflake utilise `VARIANT` pour ses éléments, un supertype. À l’inverse, dans ClickHouse, ils sont fortement typés. | |
| [`GEOGRAPHY`](https://docs.snowflake.com/en/sql-reference/data-types-geospatial#geography-data-type) | [`Point`, `Ring`, `Polygon`, `MultiPolygon`](/fr/reference/data-types/geo) | Snowflake impose un système de coordonnées (WGS 84), tandis que ClickHouse l’applique au moment de la requête. | |
| [`GEOMETRY`](https://docs.snowflake.com/en/sql-reference/data-types-geospatial#geometry-data-type) | [`Point`, `Ring`, `Polygon`, `MultiPolygon`](/fr/reference/data-types/geo) | | |
| Type ClickHouse | Description |
| ---------------- | -------------------------------------------------------------------------------------------------------------------- |
| `IPv4` et `IPv6` | Types spécifiques aux IP, permettant potentiellement un stockage plus efficace que dans Snowflake. |
| `FixedString` | Permet d’utiliser une longueur fixe d’octets, ce qui est utile pour les hachages. |
| `LowCardinality` | Permet d’encoder n’importe quel type sous forme de dictionnaire. Utile lorsque la cardinalité attendue est \< 100k. |
| `Enum` | Permet un encodage efficace de valeurs nommées sur 8 ou 16 bits. |
| `UUID` | Pour un stockage efficace des UUID. |
| `Array(Float32)` | Les vecteurs peuvent être représentés sous forme d’Array de Float32 avec des fonctions de distance prises en charge. |
Enfin, ClickHouse offre la capacité unique de stocker l’
[état des fonctions d’agrégation](/fr/reference/data-types/aggregatefunction). Cet
état est spécifique à l’implémentation, mais il permet de stocker le résultat d’une agrégation
pour l’interroger ultérieurement (avec les fonctions de fusion correspondantes). En général, cette
fonctionnalité est utilisée via une vue matérialisée et, comme illustré ci-dessous, permet
d’améliorer les performances de requêtes spécifiques avec un coût de stockage minimal en
stockant le résultat incrémental de requêtes sur des données insérées (plus de détails ici).