Skip to main content

Synopsis

Description

Le module chdb_hook s’intègre à la commande PostgreSQL COPY afin d’utiliser chDB pour copier des données TO ou FROM l’un des formats de données pris en charge par chDB, dans des fichiers locaux, des buckets AWS S3, Google Cloud Storage, et bien d’autres. Il s’intègre également à CREATE TABLE, si bien qu’une table peut déduire ses colonnes et charger ses lignes depuis n’importe laquelle de ces mêmes cibles.

Chargement

Chargez chdb_hook de l’une des façons suivantes en tant que superutilisateur. Utilisez celle qui correspond le mieux à votre cas d’utilisation :
  • Explicitement, via la commande LOAD ; valable pour la durée d’une session :
    La SQL Console de ClickHouse Cloud ne prend pas encore en charge la commande LOAD 'chdb_hook', mais celle-ci peut être exécutée via psql ou toute autre connexion à la base de données. Sinon, contactez votre interlocuteur Support pour l’ajouter à la configuration de votre service Postgres ; elle pourra ensuite être utilisée dans la SQL Console.
  • Pour toutes les sessions, via le paramètre [session_preload_libraries], dans postgresql.conf :
    Ou via ALTER SYSTEM :
    Ce paramètre peut également être défini base de données par base de données via ALTER DATABASE :
    Ou pour des utilisateurs et des groupes spécifiques via ALTER ROLE :
  • Au démarrage du serveur, via le paramètre [shared_preload_libraries], afin qu’il soit toujours disponible pour toutes les sessions et toutes les bases de données :
Notez que le chargement de chdb_hook permet aux utilisateurs disposant des rôles pg_read_server_files ou pg_write_server_files d’effectuer des opérations COPY depuis et vers des fichiers du serveur Postgres, ainsi que vers du stockage cloud.

Surcharge de COPY

Lors du chargement, chdb_hook se greffe sur la commande Postgres COPY pour copier des données TO ou FROM l’un quelconque des formats de données pris en charge par chDB, dans des fichiers locaux, des buckets AWS S3, Google Cloud Storage, et bien plus encore. Pour charger une table depuis un CSV file dans S3, par exemple, créez la table puis appelez COPY avec une URL s3:// :

Privilèges

Un COPY chdb_hook requiert les mêmes privilèges que le COPY qu’il remplace : SELECT sur la relation ou sur chaque colonne copiée pour COPY TO, et INSERT pour COPY FROM. Une URL file:// lit ou écrit un fichier sur le serveur, et requiert donc également l’appartenance à pg_read_server_files ou pg_write_server_files. COPY FROM requiert une transaction en lecture-écriture.

Schémas d’URL

chdb_hook ne s’exécute que pour les cibles COPY de type URL utilisant l’un des schémas suivants :

Formats d’URL

Le format des URL varie selon le target.

File

Doit être un chemin absolu sur le serveur Postgres. Un chemin relatif provoque une erreur. L’utilisateur Postgres doit être membre du rôle pg_read_server_files ou pg_write_server_files, selon le cas. L’utilisateur système Postgres doit disposer d’un accès en lecture ou en écriture au fichier, selon le cas. Pour COPY TO, si le chemin n’existe pas, chdb_hook créera les répertoires parents manquants ; il doit pour cela disposer des permissions nécessaires sur le système de fichiers. Exemple :

HTTP

Toute URL HTTP ordinaire, y compris dans un stockage cloud public. Pour COPY TO, chdb_hook tentera d’envoyer les données à l’URL via POST. Exemple :

S3

Les URL S3 peuvent prendre la forme d’un URI S3
Ou d’une URL d’objet :

GCS

Les URL GCS prennent la forme d’une URL publique :
Ou un URI Cloud Storage, que chdb_hook convertit en URL publique :

Azure Blob Storage

Utilisez une URL blob.windows.net avec un nom de compte comme sous-domaine :
Ou utilisez un autre nom d’hôte :

Azure ABFS

Les URL ABFS doivent utiliser ce format :

URL HDFS

Les URL HDFS peuvent adopter la forme classique des URL de type HTTP, avec un port optionnel :

Caractères génériques dans les chemins

Les chemins d’URL peuvent contenir des globs dans les commandes COPY FROM. Les fichiers doivent correspondre au motif de chemin complet, et non seulement au suffixe ou au préfixe. Seule exception : lorsque le chemin désigne un répertoire existant et n’utilise pas de globs, un * est implicitement ajouté au chemin afin de sélectionner tous les fichiers du répertoire. Les caractères génériques pris en charge :
  • * : correspond à un nombre quelconque de caractères, à l’exception de /, y compris la chaîne vide.
  • ? : correspond à un seul caractère quelconque.
  • {groucho,harpo,chico} : substitue l’une des chaînes “groucho”, “harpo” ou “chico”. Ces chaînes peuvent contenir /.
  • {N..M} : correspond à tout nombre >= N et <= M.
  • ** : correspond de manière récursive à tous les fichiers d’un répertoire.
Par exemple, pour charger les données de ces fichiers en une seule commande : Utilisez {some,another}_prefix pour faire correspondre les deux noms de répertoire et some_file_{1..3}.csv' pour faire correspondre les fichiers, comme ceci :

Options

La commande COPY de chdb_hook prend en charge les options suivantes :

format :

Le format à lire ou à écrire. Doit être l’un des formats proposés par chDB, parmi lesquels TSV, CSV, Parquet, Iceberg, JSON, et bien d’autres. Omettez-le ou définissez-le sur auto pour laisser chDB déduire le format à partir de l’extension du nom de fichier figurant à la fin de l’URL.

structure

La structure de données chDB d’une ligne. Elle se compose d’une liste de noms de colonnes, de ClickHouse data types et de modificateurs. Si elle est omise, chdb_hook fait correspondre les types de données Postgres à des types ClickHouse généralement appropriés ; voir Postgres vers chDB pour plus de détails. Si la valeur est auto, chDB tente d’inférer les types. Exemple :

access_key et access_secret

Credentials à long terme de l’utilisateur du compte AWS permettant d’authentifier les requests.
  • S3 : un [access key ID et access secret] AWS, souvent définis à l’aide des environment variables AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY
  • GCS : un HMAC key and secret GCP
  • Azure : un nom de storage account Azure et une access key

session_token

Token de session AWS à utiliser avec access_key et access_secret, souvent défini par la variable d’environnement AWS_SESSION_TOKEN. Utilisé uniquement pour les URL S3.

compression

Format de compression du fichier. À utiliser lorsque la compression ne peut pas être déduite du nom du fichier. Valeurs prises en charge :
  • auto (par défaut)
  • none
  • gzip ou gz
  • brotli ou br
  • xz ou LZMA
  • zstd ou zst
  • lz4
  • bz2
  • snappy

timeout

Timeout de requête en millisecondes. S’applique aux URL HTTP, S3, GCS et Azure. Valeur par défaut : 30000 (30 s).

Débogage

En cas d’erreur, la commande COPY de chdb_hook inclut la requête chDB qu’elle a tenté d’exécuter dans le contexte de l’erreur :
chdb_hook utilise des placeholders de la forme {name:Type} pour les query parameters afin de se prémunir contre les vulnérabilités d’injection SQL et de limiter le risque de consigner des données sensibles telles que des credentials. Si vous avez toutefois besoin de consulter le contenu de ces parameters pour déboguer un issue, définissez temporairement le GUC Postgres [log_min_messages] sur DEBUG1 ou une valeur supérieure : chdb_hook enverra alors la query et les parameters dans le log Postgres (jamais au client), où ils apparaîtront ainsi :
Ne laissez pas [log_min_messages] réglé sur un niveau de débogage au-delà d’une seule session de débogage, afin d’éviter de consigner des informations sensibles telles que des credentials, et parce que PostgreSQL journalise lui aussi des informations de débogage et peut rapidement saturer le log.

Surcharge de CREATE TABLE

chdb_hook s’accroche également à CREATE TABLE, ce qui permet à une table de dériver ses colonnes et de charger ses lignes depuis une URL. Pour créer une table dont la structure est dérivée d’une URL, passez l’URL dans l’option structure_from et laissez la liste de colonnes vide :
Utilisez copy_from pour charger les lignes ainsi que les colonnes :
copy_from n’infère les colonnes que lorsque le statement n’en nomme aucune lui-même. Une column list, une clause INHERITS, un type OF ou une partition définissent chacun des colonnes : copy_from ne copie alors que :
Les deux options prennent en charge les mêmes schémas d’URL et options que COPY : credentials, format, compression, timeout et même une structure explicite, tout s’applique. Postgres conserve les paramètres de stockage restants :
Ni structure_from ni copy_from ne fonctionnent avec IF NOT EXISTS. Utilisez COPY pour charger une relation existante.

Limitations

En raison de quelques problèmes connus et de différences de comportement des types de données entre Postgres et chDB, chdb_hook présente les limitations suivantes :
  • Impossible d’effectuer un COPY sur des relations dont les politiques de row-level security s’appliquent au rôle effectuant la copie. Postgres applique ces politiques en réécrivant COPY TO sous forme de requête, ce que chdb_hook ne prend pas en charge.
  • ClickHouse ne dispose pas de tableau NULL : COPY TO stocke donc un tableau vide ([]) pour un NULL.
  • ClickHouse représente les équivalents de lseg, path ou polygon sous forme de tableaux ; les valeurs NULL de ces types sont donc elles aussi converties par COPY TO en tableau vide ([]).
  • Les valeurs NULL produites pour une structure spécifiée qui ne définit pas la colonne comme Nullable seront émises sous forme de valeurs par défaut. Définissez toujours explicitement les colonnes nullables dans la structure pour éviter cette conversion.
  • Un path ouvert dont le dernier point est identique au premier est émis comme un chemin fermé.
  • Protobuf n’admet pas de valeur null dans un champ répété : il omet donc les valeurs NULL dans les tableaux.
  • Le JSON type de chDB ne prend en charge que les objets JSON ; ne remplacez le mappage String par défaut de json et jsonb par JSON que si toutes les valeurs sont des objets JSON. (ClickHouse/ClickHouse#68428)
  • Le JSON type de chDB ignore les null ; les clés d’objet dont la valeur est NULL seront omises en sortie. Ne remplacez le mappage String par défaut de json et jsonb par JSON que si les valeurs des objets ne sont pas null ou si leur perte est acceptable. (ClickHouse/ClickHouse#68428)
  • Les formats JSON, JSONCompact et JSONColumnsWithMetadata valident toujours l’UTF-8 ; ils émettent donc les valeurs bytea avec des caractères de remplacement.
  • COPY FROM interprète un champ Protobuf Nullable contenant une chaîne vide ou un zéro comme NULL. (chdb-io/chdb-core#152)
  • COPY TO en Parquet supprime les NULL du null map propre à un Tuple Nullable. (ClickHouse/ClickHouse#112427)
  • Les formats Parquet, Arrow, ArrowStream, ORC, Avro, Protobuf, ProtobufList, MsgPack et BSONEachRow n’ont aucun type correspondant au type time de Postgres ou Time64 de chDB. Configurez les colonnes time comme des String dans une structure explicite pour préserver leurs valeurs.
  • La sortie Protobuf tronque les valeurs timestamp à la seconde.
  • La sortie Protobuf ne prend pas en charge les dates antérieures au 1970-01-01. Configurez les colonnes time comme des String dans une structure explicite pour préserver leurs valeurs. (ClickHouse/ClickHouse#111860)
  • Les formats CSVWithNames et CSVWithNamesAndTypes ne peuvent actuellement pas importer de valeurs box ou circle NULL. (ClickHouse/ClickHouse#115523)

Types de données

COPY fait correspondre les types Postgres d’une relation aux types chDB, tandis que CREATE TABLE fait correspondre les types chDB d’une URL aux types Postgres.

Postgres vers chDB

En l’absence d’une option structure explicite, chdb_hook fait correspondre les types Postgres à des équivalents chDB raisonnables. Lorsque ceux-ci ne conviennent pas à votre cas d’usage, précisez la structure afin de remplacer les types générés par ceux dont vous avez besoin. Les types Array correspondent à des Array du type d’élément associé. ClickHouse contraint la nullabilité par column, tandis que Postgres la contraint par array : les elements sont donc toujours Nullable. Aucun type Postgres ne correspond à Map ou Tuple, mais la structure peut en désigner un. Un Map peut être converti en array de paires clé-valeur, et un Tuple en array. Utilisez text[] pour une prise en charge hétérogène.

Conversion des timestamps

Dans les formats texte brut (TSV, CSV, etc.), le hook COPY émet les valeurs DateTime et DateTime64 au format ISO-8601, YYYY-MM-DDThh:mm:ssZ, sans tenir compte du paramètre datestyle courant. Cela garantit que les valeurs timestamptz restent cohérentes, même si une source qui importe ces valeurs utilise une time zone différente. L’utilisation d’un type différent dans la sortie structure, tel que Datetime64(3, 'America/Los_Angeles'), n’a aucun effet sur le décalage de la sortie, mais modifie la precision. Exemples de timestamp TZ : Le hook COPY convertit également les valeurs timestamp de la session time zone vers UTC, ce qui garantit qu’elles sont émises par rapport à cette time zone. Une fois chargées dans un nouveau système, celui-ci devrait les convertir vers sa time zone locale. Les valeurs différeront donc si la time zone diffère, mais resteront identiques compte tenu de l’écart entre les time zones. Exemple de l’effet du paramètre timezone sur le timestamp 2026-08-28T12:00:00 :

chDB vers Postgres

chdb_hook fait correspondre les types ClickHouse renvoyés par DESCRIBE aux types Postgres suivants : Tout type chDB absent de ce tableau lève une erreur, notamment Nested, Variant et Dynamic. Utilisez une structure qui les associe à String pour les lire sous forme de texte. Pour certains de ces types, Postgres couvre une plage plus étroite que chDB ; la copie lève donc une erreur sur un Time ou un Time64 dépassant 24 heures, ainsi que sur un Date32 situé en dehors de la plage de dates de Postgres.

Encodage du texte

chDB lit String, FixedString, Enum et JSON sous forme d’octets, sans aucune garantie quant à l’encodage. La copie d’une telle colonne vers text, ou vers tout autre type non binaire, vérifie les octets au regard de l’encodage de la base de données et lève une erreur pour les données qui ne peuvent pas être représentées :
Chaque encoding rejette les caractères NUL, que Postgres ne peut pas stocker dans text. Copiez dans bytea pour conserver les octets tels que chDB les a écrits. Nommez-les ainsi, car CREATE TABLE dérive text pour ces types :
FixedString(N) complète les valeurs plus courtes avec des octets NUL. La copie vers text supprime les NUL de fin, tandis que bytea conserve la totalité des N octets.

Paramètres

chdb_hook.max_memory

Définit la quantité maximale de mémoire allouée à une requête chDB ; sert à renseigner le paramètre chDB max_memory_usage. Nécessite les privileges de superuser. Indiquez un integer correspondant au nombre de mégaoctets, ou une valeur suivie de l’une des unités de mémoire suivantes :
  • B (octets)
  • kB (kilooctets)
  • MB (mégaoctets)
  • GB (gigaoctets)
  • TB (téraoctets)
Vaut 0 par défaut, ce qui signifie aucune limite de mémoire.

chdb_hook.max_threads

Le nombre maximal de threads de query processing pour une requête chDB, utilisé pour définir le paramètre chDB max_threads. Nécessite le privilège de superuser. La valeur par défaut est 0, ce qui laisse chDB déterminer la valeur. Nous recommandons vivement de définir chdb_hook.max_threads avant d’exécuter un COPY volumineux, afin d’éviter que chDB ne sature le CPU au détriment de PostgreSQL.

chdb_hook.max_parsing_threads

Le nombre maximal de threads que chDB peut utiliser pour parser des données dans les formats d’entrée qui prennent en charge le parsing parallèle ; il sert à définir le paramètre chDB max_parsing_threads. Nécessite les privilèges de superuser. La valeur par défaut est 0, ce qui laisse chDB déterminer la valeur. Nous recommandons de définir chdb_hook.max_parsing_threads avant d’effectuer un COPY sur un grand volume de données, afin d’éviter que chDB ne sature l’utilisation du CPU au détriment de PostgreSQL.

Politique de versionnage

chdb_hook respecte le Semantic Versioning pour ses releases publiques.
  • La major version est incrémentée en cas de changements d’API
  • La minor version est incrémentée en cas de changements SQL rétrocompatibles
  • La version de patch est incrémentée en cas de changements portant uniquement sur le binary
Une fois installé, PostgreSQL la version via la fonction pg_get_loaded_modules() de Postgres 18.

Auteurs

Copyright (c) 2026, ClickHouse
Dernière modification le 26 septembre 2026