Skip to main content
ClickHouse Connect inclut le dialecte SQLAlchemy clickhousedb, basé sur le pilote principal. Il prend en charge SQLAlchemy 1.4.40 et les versions ultérieures, y compris SQLAlchemy 2.x, avec un accent particulier sur les requêtes Core, le DDL ClickHouse, la réflexion et les insertions ORM simples. Installez les dépendances SQLAlchemy avec l’extra du paquet :

Se connecter avec SQLAlchemy

Créez un moteur avec l’une ou l’autre des URL suivantes :
Les paramètres de requête d’URL peuvent contenir des paramètres ClickHouse, des options du client ClickHouse Connect telles que compression, query_limit et des dépassements de délai, ou des options HTTP/TLS telles que ca_cert. Préfixez un paramètre ClickHouse par ch_ pour qu’il soit traité comme un paramètre serveur si nécessaire, par exemple ch_http_max_field_name_size=99999. Consultez Arguments et paramètres de connexion pour connaître les options client disponibles.

Paramètres par requête

Transmettez les paramètres ClickHouse via les options d’exécution de SQLAlchemy. Les paramètres peuvent être définis au niveau du moteur, de la connexion ou de l’instruction. Une valeur définie sur l’instruction prévaut sur une valeur de connexion ou de moteur avec la même clé.

Formats de lecture par requête

Définissez les formats de lecture ClickHouse pour un moteur, une connexion ou une instruction à l’aide des options d’exécution SQLAlchemy et de query_formats. Les formats définis au niveau de l’instruction sont appliqués en premier et remplacent les keys et wildcards correspondants définis au niveau de la connexion ou du moteur.

Paramètres côté serveur

SQLAlchemy génère normalement des paramètres côté client. Pour utiliser les paramètres côté serveur de ClickHouse, activez-les lors de la création du moteur :
Dans ce mode, chaque valeur liée doit avoir un type SQLAlchemy compatible avec ClickHouse. Les listes IN prises en charge deviennent des paramètres ClickHouse Array typés. Le compilateur lève une CompileError lorsqu’il ne peut pas déduire un type compatible ni traiter un bind en toute sécurité.

Requêtes Core

Le dialecte prend en charge les requêtes SELECT de SQLAlchemy Core avec des jointures, des filtres, le tri, des clauses LIMIT et OFFSET, et DISTINCT.
Le DELETE léger est pris en charge et nécessite une clause WHERE explicite :

Sous-colonnes JSON

Pour une colonne déclarée ou représentée en JSON ClickHouse, utilisez des crochets pour sélectionner un segment à la fois dans le chemin d’une sous-colonne stockée :
payload["severity"] est compilé selon la syntaxe d’identifiant pointé de ClickHouse. Chaque partie est entourée de guillemets séparément, par exemple `events`.`payload`.`severity`. Cette syntaxe lit la sous-colonne JSON stockée dans ClickHouse et n’appelle pas getSubcolumn. Chaînez [] ou .subcolumn() une fois pour chaque segment du chemin. Chaque segment doit être une chaîne non vide. Passer type_ à .subcolumn() encapsule le chemin pointé dans un CAST SQL et affecte ce type à l’expression SQLAlchemy. Sans type_, .subcolumn("segment") se comporte comme ["segment"]. Un chemin non typé a le type Dynamic de ClickHouse. ClickHouse n’autorise pas les valeurs Dynamic directement dans ORDER BY ou GROUP BY. Passez type_ lorsqu’une sous-colonne y est utilisée. Pour du code à typage statique, importez json_subcolumn depuis clickhouse_connect.cc_sqlalchemy. Cet assistant accepte également un segment à la fois et préserve le type de résultat Python de type_ :
Dans cet exemple, les vérificateurs de types considèrent request_id comme un ColumnElement[int]. Chaque segment est entouré de guillemets individuellement, y compris les noms contenant des espaces ou des accents graves. Les accents graves ne font pas d’un point un caractère littéral pour le traitement des chemins JSON par ClickHouse. Lorsque json_type_escape_dots_in_keys est activé, utilisez l’encodage %2E de ClickHouse pour les points littéraux dans les clés. Accédez à une clé nommée a.b avec payload["a%2Eb"], et non payload["a.b"].

Extensions des requêtes ClickHouse

Importez select depuis clickhouse_connect.cc_sqlalchemy pour exposer des méthodes ClickHouse typées aux outils de vérification statique des types. Le sqlalchemy.select standard propose également ces méthodes à l’exécution.
Les méthodes Select de ClickHouse sont : Par exemple, un GLOBAL ANY LEFT JOIN ClickHouse peut être chaîné sans avoir à imbriquer une FromClause personnalisée :
Utilisez la syntaxe explicite Lambda pour les fonctions d’ordre supérieur de ClickHouse :
La construction standard SQLAlchemy values() est compilée vers la syntaxe de fonction de table VALUES de ClickHouse, y compris lorsqu’elle est utilisée dans une expression de table commune. La forme CTE nécessite SQLAlchemy 2.0.42 ou version ultérieure, où Values.cte() a été ajoutée.

CTE matérialisées

Par défaut, ClickHouse intègre une expression de table commune ; ainsi, le corps d’une CTE référencée plusieurs fois est exécuté une fois par référence. Passez materialized=True à .cte() pour générer WITH <name> AS MATERIALIZED (...), ce qui calcule le corps une seule fois :
Le serveur ne matérialise la CTE que si le mot-clé est présent, si enable_materialized_cte=1 et si l’analyseur est activé. Définissez enable_materialized_cte au niveau de l’instruction, de la connexion ou du moteur, comme indiqué dans Paramètres par requête. L’analyseur est activé par défaut sur tous les serveurs prenant en charge cette fonctionnalité. Définir explicitement enable_analyzer=1 constitue donc une mesure de précaution. enable_materialized_cte est un paramètre ClickHouse expérimental. Avec enable_materialized_cte=0 ou enable_analyzer=0, la requête aboutit et renvoie les mêmes lignes. ClickHouse ignore silencieusement MATERIALIZED et intègre de nouveau la CTE, de sorte qu’un paramètre oublié dégrade les performances sans générer d’erreur. Les CTE matérialisées nécessitent ClickHouse 26.3 ou une version ultérieure. Les serveurs plus anciens rejettent le mot-clé avec une erreur de syntaxe. Pour une instruction construite avec le sqlalchemy.select standard, utilisez plutôt cte() au niveau du module. Cette fonction prend l’instruction comme premier argument et correspond par ailleurs à Select.cte() :
Le mot-clé est généré uniquement avec le dialecte ClickHouse. Une instruction partagée avec un autre backend y est donc compilée sans modification. ClickHouse ne prend pas en charge les CTE matérialisées récursives. Les helpers SQLAlchemy lèvent une ValueError lorsque recursive=True et materialized=True sont tous deux définis.

DDL et introspection

ClickHouse Connect fournit les types de données ClickHouse, les moteurs de table, les structures de dictionnaire, le DDL des bases de données et l’introspection des tables.
Les colonnes introspectées utilisent server_default pour les expressions DEFAULT, ainsi que des attributs propres au dialecte tels que clickhouse_codec, clickhouse_ttl, clickhouse_materialized et clickhouse_alias, lorsqu’ils sont présents. Les arguments de clé MergeTree tels que order_by, partition_by, primary_key, sample_by et ttl acceptent des colonnes SQLAlchemy, des expressions SQL ainsi que de simples chaînes de caractères.

Insertions et utilisation de l’ORM de base

Les insertions Core et les modèles ORM simples sont pris en charge. Préférez les insertions Core pour les flux de données volumineux.

Migrations avec Alembic

ClickHouse Connect inclut une intégration à Alembic pour les migrations de schéma de ClickHouse. Installez-la avec :
Importez clickhouse_connect.cc_sqlalchemy.alembic dans le fichier env.py d’Alembic pour enregistrer l’intégration du dialecte. L’autogénération prend en charge les évolutions courantes des tables, notamment la création et la suppression de tables, l’ajout, la modification et la suppression de colonnes, les valeurs par défaut et les commentaires. Utilisez des opérations manuelles pour renommer les tables et les colonnes. Examinez chaque migration générée avant de l’appliquer. Les helpers op.* spécifiques à ClickHouse couvrent :
  • les index de saut de données, y compris les opérations d’ajout, de matérialisation et de suppression.
  • les projections, y compris les opérations d’ajout, de matérialisation et de suppression.
  • la modification et la réinitialisation des paramètres de table MergeTree.
  • la création et la suppression de vues matérialisées.
  • la création, la suppression et le rechargement de dictionnaires.
Les index de saut de données de ClickHouse ne sont pas des index SQLAlchemy. Index, Column(index=True), op.create_index et op.drop_index sont rejetés afin d’éviter un DDL partiel ou incorrect. Utilisez op.add_clickhouse_index et op.drop_clickhouse_index. Consultez l’exemple complet d’Alembic. Les utilisateurs qui migrent depuis clickhouse-sqlalchemy devraient également lire le guide de migration.

Portée et limites

  • ClickHouse ne fournit pas de transactions traditionnelles via ce dialecte HTTP. engine.begin() et Session.commit() organisent le travail côté Python, mais commit et rollback sont des opérations sans effet côté serveur.
  • UPDATE, les transactions en deux phases, les séquences, RETURNING et les niveaux d’isolation avancés ne sont pas implémentés par ce dialecte. Utilisez du ClickHouse SQL explicite pour les mutations côté serveur si nécessaire.
  • Column(..., primary_key=True) fournit l’identité de l’objet SQLAlchemy. Cela ne crée pas de contrainte d’unicité côté serveur. Définissez le tri et, si nécessaire, les expressions de clé primaire via le moteur de table.
  • Les métadonnées traditionnelles de clés étrangères, de contraintes d’unicité et d’index standard ne sont pas disponibles, car ClickHouse n’applique pas ces contraintes.
  • La gestion des relations ORM, les mises à jour de type unit-of-work, les cascades, ainsi que le chargement eager ou lazy des relations, ne font pas partie du périmètre ORM pris en charge.
Dernière modification le 14 août 2026