Utilisez des arguments nommés pour les fabriques de clients et les méthodes comportant de nombreux paramètres facultatifs.Les méthodes qui ne sont pas documentées ici ne sont pas considérées comme faisant partie de l’API et peuvent être supprimées ou modifiées.
Initialisation du client
clickhouse_connect.get_client pour créer un Client synchrone, ou installez l’extra async et attendez clickhouse_connect.get_async_client pour créer un AsyncClient natif.
Arguments de connexion
La fabrique asynchrone accepte aussi
connector_limit=100, connector_limit_per_host=20 et keepalive_timeout=30.0 pour configurer son pool de connexions aiohttp. Elle n’accepte pas pool_mgr. Le backend chDB synchrone accepte path et chdb_options ; voir backend chDB intégré.
Arguments HTTPS/TLS
Argument settings
settings de get_client permet de transmettre au serveur des settings ClickHouse supplémentaires pour chaque requête client. Notez que, dans la plupart des cas, les utilisateurs disposant d’un accès readonly=1 ne peuvent pas modifier les settings envoyés avec une requête ; ClickHouse Connect supprimera donc ces settings de la requête finale et consignera un avertissement. Les settings suivants s’appliquent uniquement aux requêtes/sessions HTTP utilisées par ClickHouse Connect et ne sont pas documentés comme des settings généraux de ClickHouse.
Pour les autres settings ClickHouse pouvant être envoyés avec chaque requête, consultez la documentation ClickHouse.
Exemples de création de client
- Sans paramètre, un client ClickHouse Connect se connecte au port HTTP par défaut sur
localhost, avec l’utilisateur par défaut et sans mot de passe :
- Connexion à un serveur ClickHouse externe sécurisé (HTTPS)
- Connexion avec un ID de session, d’autres paramètres de connexion personnalisés et des settings de ClickHouse.
Backend chDB intégré
clickhouse-connect[chdb] pour utiliser le backend chDB expérimental intégré au processus. Il expose les méthodes synchrones query, insert, streaming et Arrow du client :
path="/data/my_chdb" ou utilisez dsn="chdb:///data/my_chdb" pour bénéficier d’un stockage persistant. Le backend n’autorise qu’un seul path de moteur par processus et ne prend pas en charge get_async_client ni les données externes.
Cycle de vie du client et bonnes pratiques
Principes fondamentaux
- Réutilisez les clients : créez les clients une seule fois au démarrage de l’application et réutilisez-les pendant toute sa durée de vie
- Évitez les créations fréquentes : ne créez pas de nouveau client pour chaque requête ou demande
- Nettoyez correctement : fermez toujours les clients lors de l’arrêt afin de libérer les ressources du pool de connexions
- Partagez quand c’est possible : un seul client peut gérer de nombreuses requêtes concurrentes grâce à son pool de connexions (voir les remarques sur les threads ci-dessous)
Quelques principes de base
Applications multithreadées
Nettoyage approprié
client.close() libère le client et ferme les connexions HTTP du pool uniquement lorsque le client possède son propre gestionnaire de pool (par exemple, s’il a été créé avec des options TLS/proxy personnalisées). Pour le pool partagé par défaut, utilisez client.close_connections() pour fermer explicitement les sockets ; sinon, les connexions sont récupérées automatiquement à l’expiration de l’inactivité et à la fin du processus.
Quand utiliser plusieurs clients
- Serveurs différents : un client par serveur ClickHouse ou cluster
- Identifiants différents : des clients distincts pour différents utilisateurs ou niveaux d’accès
- Bases de données différentes : lorsque vous devez travailler avec plusieurs bases de données
- Sessions isolées : lorsque vous avez besoin de sessions distinctes pour des tables temporaires ou des paramètres propres à la session
- Isolation par thread : lorsque les threads ont besoin de sessions indépendantes (comme indiqué ci-dessus)
Arguments courants des méthodes
parameters et settings. Ces arguments nommés sont décrits ci-dessous.
Argument parameters
query* et command du ClickHouse Connect Client acceptent un argument nommé facultatif, parameters, utilisé pour associer des expressions Python à une expression de valeur ClickHouse. Deux types de liaison sont possibles.
Liaison côté serveur
{<name>:<datatype>}. Transmettez les valeurs sous la forme d’un dictionnaire Python.
Utilisez None de Python pour les valeurs Nullable. Les valeurs None imbriquées sont prises en charge dans les paramètres Array et Tuple, ainsi que dans les littéraux Map lorsque dict_parameter_format est défini sur "map".
- Liaison côté serveur avec dictionnaire Python, valeur DateTime et valeur de chaîne de caractères
Liaison côté client
parameters doit être un dictionnaire ou une séquence. La liaison côté client utilise le formatage de chaînes Python de style “printf” pour la substitution des paramètres.
Notez que, contrairement à la liaison côté serveur, la liaison côté client ne fonctionne pas pour les identifiants de base de données tels que les noms de base de données, de table ou de colonne, car le formatage de style Python ne permet pas de distinguer les différents types de chaînes, qui doivent être mis en forme différemment (backticks ou guillemets doubles pour les identifiants de base de données, guillemets simples pour les valeurs de données).
- Exemple avec un dictionnaire Python, une valeur DateTime et l’échappement des chaînes
- Exemple avec une séquence Python (Tuple), Float64 et IPv4Address
La liaison de Pour la rétrocompatibilité, un nom de paramètre de dictionnaire se terminant par
datetime considère les valeurs naïves comme des heures d’horloge. Le client met en forme un datetime naïf tel quel. ClickHouse l’interprète en utilisant le fuseau horaire déclaré dans un espace réservé côté serveur tel que {dt:DateTime('Europe/Berlin')}, puis session_timezone lorsqu’il est défini, puis le fuseau horaire du serveur. Un datetime avec fuseau horaire est converti dans le fuseau horaire déclaré dans l’espace réservé lorsqu’il est présent, sinon dans le fuseau horaire du serveur indiqué au moment de la connexion. Si le paramètre session_timezone diffère de ce fuseau horaire du serveur indiqué, déclarez un fuseau horaire dans l’espace réservé afin de conserver l’instant souhaité pour les valeurs avec fuseau horaire.Pour une compatibilité temporaire avec l’ancienne conversion locale à l’hôte, définissez common.set_setting("naive_datetime_binding", "legacy") avant de lier les paramètres. Pour préserver un instant, attachez le tzinfo voulu à la valeur datetime avant de la transmettre en tant que paramètre. Les insertions via client.insert interprètent par défaut les valeurs datetime naïves dans le fuseau horaire local du processus. Définissez le paramètre global naive_datetime_insert sur "server" pour les interpréter comme des heures locales dans le fuseau horaire de la colonne, ou dans le fuseau horaire du serveur lorsque la colonne n’en possède pas. Consultez Objets datetime sans fuseau horaire.Pour un espace réservé {value:DateTime64(precision)} côté serveur, le type déclaré préserve automatiquement la précision à la sous-seconde, y compris dans les indications Array et Tuple.La liaison %s côté client n’a pas de type déclaré. Enveloppez un datetime dans DT64Param lorsqu’il doit être mis en forme avec une précision à la sous-seconde :_64 demande également un formatage DateTime64 lorsque ce nom suffixé exact n’est pas présent dans la requête.Un paramètre datetime.time ou datetime.timedelta est mis en forme comme un littéral [-]HH:MM:SS[.ffffff] pour les colonnes ClickHouse Time et Time64, dans les deux styles de liaison et dans les valeurs Array et Tuple. Le client ajoute les guillemets ; ne mettez donc pas l’espace réservé entre guillemets dans la requête. Un timedelta peut être négatif et dépasser 24 heures. Un Timedelta pandas conserve ses nanosecondes et met en forme une fraction de neuf chiffres pour Time64(9). Les informations de fuseau horaire d’un time avec fuseau horaire sont ignorées, car ClickHouse Time ne possède pas de fuseau horaire.Argument settings
settings facultatif pour transmettre les settings utilisateur du serveur ClickHouse pour l’instruction SQL concernée. L’argument settings doit être un dictionnaire. Chaque élément doit contenir un nom de setting ClickHouse et la valeur associée. Notez que les valeurs seront converties en chaînes de caractères lorsqu’elles seront envoyées au serveur comme paramètres de requête.
Comme pour les settings au niveau du client, ClickHouse Connect ignorera tous les settings que le serveur marque comme readonly=1, avec un message de log associé. Les settings qui s’appliquent uniquement aux requêtes via l’interface HTTP de ClickHouse sont toujours valides. Ces settings sont décrits dans l’API get_client.
Exemple d’utilisation des settings ClickHouse :
Méthode command du Client
Client.command pour les instructions qui ne renvoient pas de jeu de données tabulaire, ou pour les requêtes qui renvoient une valeur primitive ou une ligne de valeurs. Selon la réponse, cette méthode peut renvoyer une chaîne, un entier, une séquence de chaînes ou QuerySummary. Une lecture qui produit un jeu de résultats vide renvoie une chaîne vide.
Exemples de commandes
Instructions DDL
Requêtes simples renvoyant une seule valeur
Commandes avec paramètres
Commandes avec settings
Méthode query du Client
Client.query récupère un jeu de données tabulaire au format Native de ClickHouse et renvoie un QueryResult. Le résultat complet est matérialisé dès qu’une propriété du résultat est consultée. Utilisez une méthode de streaming pour les résultats qui ne doivent pas être conservés en mémoire.
Exemples de requêtes
Requête de base
Accéder au résultat de la requête
Requête avec paramètres côté client
Requête avec paramètres côté serveur
Requête avec setting
L’objet QueryResult
query de base renvoie un objet QueryResult avec les propriétés publiques suivantes :
result_rows— Matrice de résultats orientée par lignes.result_columns— Matrice de résultats orientée par colonnes.result_set—result_rowsouresult_columns, selon l’orientation de la requête.column_names— Tuple contenant les noms des colonnes du résultat.column_types— Tuple d’objetsClickHouseType.row_count— Nombre de lignes de résultat matérialisées.query_id— ID de requête renvoyé ou généré pour la requête. Une chaîne vide signifie qu’aucun n’était disponible.summary— Dictionnaire décodé à partir de l’en-tête de réponseX-ClickHouse-Summary.first_item— Première ligne sous forme de dictionnaire, ouNonesi le résultat est vide.first_row— Première ligne sous forme de séquence, ouNonesi le résultat est vide.column_block_stream,row_block_streametrows_stream— Contextes de flux internes. Utilisez plutôt les méthodes de streaming correspondantes du client.
StreamContext prises en charge.
Consommer les résultats des requêtes avec NumPy, Pandas ou Arrow
Méthodes du Client pour les requêtes en streaming
Méthode insert du Client
Client.insert. Elle accepte les paramètres suivants :
Cette méthode renvoie
QuerySummary. Son dictionnaire summary contient les valeurs renvoyées par le server. written_rows est une propriété pratique, tandis que written_bytes() et query_id() renvoient les valeurs correspondantes. En cas d’échec de l’insertion, une exception est levée.
Pour les méthodes d’insertion spécialisées qui fonctionnent avec les Pandas DataFrames, les tables PyArrow et les DataFrames basés sur Arrow, voir Insertion avancée (méthodes d’insertion spécialisées).
Un tableau NumPy est une Sequence of Sequences valide et peut être utilisé comme argument
data de la méthode principale insert ; une méthode spécialisée n’est donc pas nécessaire.Exemples
users existe déjà, avec le schéma (id UInt32, name String, age UInt8).
Insertion simple par ligne
Insertion par colonnes
Insertion avec des types de colonnes explicitement spécifiés
Insérer dans une base de données spécifique
Insertions depuis des fichiers
API brute
Python DB-API 2.0
clickhouse_connect.dbapi implémente l’interface de connexion et de curseur définie par la PEP 249. Il déclare un niveau d’API de 2.0, threadsafety=2 et paramstyle="pyformat". Le module fournit également les constructeurs de types PEP 249 Date, Time, Timestamp et Binary, ainsi que les fonctions DateFromTicks, TimeFromTicks et TimestampFromTicks.
Cursor.execute et Cursor.executemany acceptent des arguments nommés supplémentaires settings et query_formats. settings transmet les paramètres de ClickHouse. query_formats applique des formats de lecture selon le type ClickHouse lorsqu’une instruction renvoie des lignes, en utilisant le même mapping que Client.query. executemany utilise le mécanisme Native d’insertion en bloc du driver pour les instructions INSERT ... VALUES compatibles, avec une séquence matérialisée de lignes. fetchone, fetchmany et fetchall consomment le jeu de résultats matérialisé courant.
Cursor.description déduit null_ok du type de chaque colonne de résultat. Les types non nullables renvoient False, et les types nullables renvoient True, y compris les wrappers Nullable, Variant et Dynamic. None signifie que la nullabilité est inconnue. Lorsqu’une requête commençant par SELECT ou WITH, en ignorant les commentaires initiaux, ne renvoie ni lignes ni métadonnées de colonnes, le curseur exécute une requête de métadonnées avec LIMIT 0 pour renseigner description. Si cette requête de métadonnées échoue, description reste vide.
ClickHouse ne fournit pas de transactions traditionnelles via cette interface HTTP. Connection.commit() et Connection.rollback() sont des opérations sans effet. Les règles de concurrence liées aux ID de session s’appliquent toujours lorsqu’une connexion est partagée.
Classes et fonctions utilitaires
clickhouse_connect.__version__.
Exceptions
clickhouse_connect.driver.exceptions. DatabaseError et OperationalError exposent un attribut numérique code contenant le code d’erreur ClickHouse, ainsi qu’un attribut name contenant le nom symbolique tel que UNKNOWN_TABLE, afin que les applications puissent s’appuyer sur exc.code au lieu d’analyser le message. code est défini même lorsque show_clickhouse_errors est désactivé, tandis que name exige les détails de l’erreur (True ou "scrub"). Tous deux valent None lorsqu’ils ne sont pas disponibles, par exemple en cas d’erreurs de transport. Utilisez show_clickhouse_errors="scrub" lorsque les utilisateurs finaux doivent voir les erreurs SQL sans informations sur l’hôte ou la version du server. Ce paramètre contrôle également les messages StreamFailureError en cours de transmission et les messages de transport génériques. Il régit uniquement str(exc). Les erreurs de transport restent attachées en tant que __cause__, et les traces de pile peuvent contenir le texte d’erreur d’origine de l’hôte, de l’URL ou de la bibliothèque.
Utilitaires SQL ClickHouse
clickhouse_connect.driver.binding peuvent être utilisées pour construire correctement les requêtes ClickHouse SQL et en échapper correctement le contenu. De même, les fonctions du module clickhouse_connect.driver.parser peuvent être utilisées pour analyser les noms de types de données ClickHouse.