Pular para o conteúdo principal
Recomenda-se usar argumentos nomeados na maioria dos métodos da API, considerando a quantidade de argumentos possíveis, muitos dos quais são opcionais.Métodos não documentados aqui não são considerados parte da API e podem ser removidos ou alterados.

Inicialização do cliente

A classe clickhouse_connect.driver.client fornece a interface principal entre uma aplicação Python e o servidor de banco de dados ClickHouse. Use a função clickhouse_connect.get_client para obter uma instância de Client, que aceita os seguintes argumentos:

Argumentos de conexão

Argumentos de HTTPS/TLS

Argumento settings

Por fim, o argumento settings de get_client é usado para enviar configurações adicionais do ClickHouse ao servidor em cada solicitação do cliente. Observe que, na maioria dos casos, usuários com acesso readonly=1 não podem alterar configurações enviadas com uma consulta; por isso, o ClickHouse Connect descarta essas configurações na solicitação final e registra um aviso. As configurações a seguir se aplicam apenas a consultas/sessões HTTP usadas pelo ClickHouse Connect e não são documentadas como configurações gerais do ClickHouse. Para outras configurações do ClickHouse que podem ser enviadas com cada consulta, consulte a documentação do ClickHouse.

Exemplos de criação de clientes

  • Sem nenhum parâmetro, um cliente ClickHouse Connect se conectará à porta HTTP padrão em localhost, com o usuário default e sem senha:
  • Conectar-se a um servidor ClickHouse externo seguro (HTTPS)
  • Conectar-se com um ID de sessão e outros parâmetros de conexão personalizados e configurações do ClickHouse.

Ciclo de vida do cliente e boas práticas

Criar um cliente ClickHouse Connect é uma operação custosa, que envolve estabelecer uma conexão, recuperar metadados do servidor e inicializar configurações. Siga estas boas práticas para ter o melhor desempenho:

Princípios fundamentais

  • Reutilize clientes: Crie os clientes uma única vez na inicialização da aplicação e reutilize-os durante todo o seu ciclo de vida
  • Evite criação frequente: Não crie um novo cliente para cada consulta ou solicitação (isso desperdiça centenas de milissegundos por operação)
  • Faça a limpeza corretamente: Sempre feche os clientes ao encerrar a aplicação para liberar os recursos do pool de conexões
  • Compartilhe quando possível: Um único cliente pode processar muitas consultas simultâneas por meio do seu pool de conexões (veja as observações sobre threads abaixo)

Padrões básicos

✅ Bom: reutilize um único cliente
❌ Errado: criar clientes repetidamente

Aplicações multithread

Instâncias de cliente NÃO são thread-safe ao usar IDs de sessão. Por padrão, os clientes têm um ID de sessão gerado automaticamente, e consultas simultâneas dentro da mesma sessão gerarão um ProgrammingError.
Para compartilhar um cliente entre threads com segurança:
Alternativa para sessões: Se você precisar de sessões (por exemplo, para tabelas temporárias), crie um cliente separado para cada thread:

Limpeza adequada

Sempre feche os clientes ao encerrar. Observe que client.close() descarta o cliente e fecha as conexões HTTP do pool apenas quando o cliente tem seu próprio gerenciador de pool (por exemplo, quando é criado com opções personalizadas de TLS/proxy). Para o pool compartilhado padrão, use client.close_connections() para liberar os sockets de forma proativa; caso contrário, as conexões são liberadas automaticamente por expiração por inatividade e ao encerrar o processo.
Ou use um gerenciador de contexto:

Quando usar vários clientes

Vários clientes são apropriados para:
  • Servidores diferentes: um cliente por servidor ClickHouse ou cluster
  • Credenciais diferentes: clientes separados para diferentes usuários ou níveis de acesso
  • Bancos de dados diferentes: quando você precisa trabalhar com vários bancos de dados
  • Sessões isoladas: quando você precisa de sessões separadas para tabelas temporárias ou configurações específicas da sessão
  • Isolamento por thread: quando as threads precisam de sessões independentes (como mostrado acima)

Argumentos comuns dos métodos

Vários métodos do cliente usam um ou ambos os argumentos comuns parameters e settings. Esses argumentos nomeados são descritos abaixo.

Argumento parameters

Os métodos query* e command do cliente ClickHouse Connect aceitam o argumento nomeado opcional parameters, usado para vincular expressões Python a uma expressão de valor do ClickHouse. Há dois tipos de vinculação disponíveis.

Vinculação no servidor

O ClickHouse oferece suporte à vinculação no servidor para a maioria dos valores de uma consulta, em que o valor vinculado é enviado separadamente da consulta como um parâmetro de consulta HTTP. O ClickHouse Connect adicionará os parâmetros de consulta apropriados se detectar uma expressão de vinculação no formato {<name>:<datatype>}. Para vinculação no servidor, o argumento parameters deve ser um dicionário do Python.
  • Vinculação no servidor com dicionário do Python, valor DateTime e valor de texto
Isso gera a seguinte consulta no servidor:
A vinculação no servidor é compatível apenas (no servidor ClickHouse) com consultas SELECT. Não funciona com ALTER, DELETE, INSERT nem com outros tipos de consultas. Isso pode mudar no futuro; consulte https://github.com/ClickHouse/ClickHouse/issues/42092.

Vinculação no lado do cliente

O ClickHouse Connect também oferece suporte à vinculação de parâmetros no lado do cliente, o que pode proporcionar mais flexibilidade na geração de consultas SQL com template. Para a vinculação no lado do cliente, o argumento parameters deve ser um dicionário ou uma sequência. A vinculação no lado do cliente usa a formatação de strings no estilo “printf” do Python para a substituição de parâmetros. Observe que, diferentemente da vinculação no servidor, a vinculação no lado do cliente não funciona para identificadores de banco de dados, como nomes de database, table ou coluna, já que a formatação no estilo Python não consegue distinguir entre os diferentes types de strings, e elas precisam ser formatadas de maneira diferente (backticks ou aspas duplas para identificadores de banco de dados, aspas simples para valores de dados).
  • Exemplo com Dicionário Python, valor DateTime e escape de string
Isso gera a seguinte consulta no servidor:
  • Exemplo com Sequence do Python (Tuple), Float64 e IPv4Address
Isso gera a seguinte consulta no servidor:
Para vincular argumentos DateTime64 (tipos do ClickHouse com precisão de frações de segundo), é necessário usar uma de duas abordagens personalizadas:
  • Envolva o valor Python datetime.datetime na nova classe DT64Param, por exemplo:
    • Se estiver usando um dicionário de valores de parâmetro, acrescente a string _64 ao nome do parâmetro

Argumento settings

Todos os principais métodos “insert” e “select” do cliente ClickHouse Connect aceitam um argumento nomeado opcional settings para passar configurações de usuário do servidor ClickHouse para a instrução SQL correspondente. O argumento settings deve ser um dicionário. Cada item deve conter o nome de uma configuração do ClickHouse e o respectivo valor. Observe que os valores serão convertidos em strings quando enviados ao servidor como parâmetros de consulta. Assim como acontece com as configurações no nível do cliente, o ClickHouse Connect descartará todas as configurações que o servidor marcar como readonly=1, com a respectiva mensagem de log. As configurações que se aplicam apenas a consultas feitas pela interface HTTP do ClickHouse são sempre válidas. Essas configurações são descritas na API get_client. Exemplo de uso das configurações do ClickHouse:

Método command do cliente

Use o método Client.command para enviar consultas SQL ao servidor ClickHouse que normalmente não retornam dados ou que retornam um único valor primitivo ou array, em vez de um conjunto de dados completo. Este método aceita os seguintes parâmetros:

Exemplos do comando

Instruções DDL

Consultas simples que retornam valores individuais

Comandos com parâmetros

Comandos com configurações

Método query do cliente

O método Client.query é a principal forma de recuperar um único conjunto de dados em “lote” do servidor ClickHouse. Ele usa o formato Native do ClickHouse sobre HTTP para transmitir grandes conjuntos de dados (até aproximadamente um milhão de linhas) com eficiência. Esse método aceita os seguintes parâmetros:

Exemplos de consulta

Consulta básica

Acessando os resultados da consulta

Consulta com parâmetros no cliente

Consulta com parâmetros do lado do servidor

Consulta com configurações

O objeto QueryResult

O método base query retorna um objeto QueryResult com as seguintes propriedades públicas:
  • result_rows — Uma matriz dos dados retornados na forma de uma sequência de linhas, em que cada elemento de linha é uma sequência de valores de coluna.
  • result_columns — Uma matriz dos dados retornados na forma de uma sequência de colunas, em que cada elemento de coluna é uma sequência dos valores de linha dessa coluna
  • column_names — Uma tupla de strings que representa os nomes das colunas em result_set
  • column_types — Uma tupla de instâncias de ClickHouseType que representa o tipo de dado do ClickHouse de cada coluna em result_columns
  • query_id — O query_id da consulta do ClickHouse (útil para examinar a consulta na tabela system.query_log)
  • summary — Quaisquer dados retornados pelo cabeçalho de resposta HTTP X-ClickHouse-Summary
  • first_item — Uma propriedade de conveniência para recuperar a primeira linha da resposta como um dicionário (as chaves são os nomes das colunas)
  • first_row — Uma propriedade de conveniência para retornar a primeira linha do resultado
  • column_block_stream — Um gerador de resultados de consulta em formato orientado a colunas. Essa propriedade não deve ser acessada diretamente (veja abaixo).
  • row_block_stream — Um gerador de resultados de consulta em formato orientado a linhas. Essa propriedade não deve ser acessada diretamente (veja abaixo).
  • rows_stream — Um gerador de resultados de consulta que produz uma única linha por chamada. Essa propriedade não deve ser acessada diretamente (veja abaixo).
  • summary — Conforme descrito no método command, um dicionário com informações resumidas retornadas pelo ClickHouse
As propriedades *_stream retornam um Context do Python que pode ser usado como iterador para os dados retornados. Elas só devem ser acessadas indiretamente usando os métodos *_stream do Client. Os detalhes completos sobre o streaming de resultados de consulta (usando objetos StreamContext) estão descritos em Consultas avançadas (Streaming Queries).

Consumindo resultados de consultas com NumPy, Pandas ou Arrow

O ClickHouse Connect fornece métodos de consulta especializados para os formatos de dados NumPy, Pandas e Arrow. Para informações detalhadas sobre como usar esses métodos, incluindo exemplos, recursos de streaming e tratamento avançado de tipos, consulte Consultas avançadas (consultas com NumPy, Pandas e Arrow).

Métodos de consulta em streaming do cliente

Para transmitir grandes conjuntos de resultados, o ClickHouse Connect oferece vários métodos de streaming. Consulte Consultas avançadas (consultas em streaming) para mais detalhes e exemplos.

Método insert do cliente

Para o caso de uso comum de inserir vários registros no ClickHouse, existe o método Client.insert. Ele aceita os seguintes parâmetros: Esse método retorna um dicionário de “resumo da consulta”, conforme descrito no método “command”. Uma exceção será lançada se a inserção falhar por qualquer motivo. Para métodos especializados de inserção que funcionam com Pandas DataFrames, PyArrow Tables e DataFrames com suporte a Arrow, consulte Inserção avançada (Métodos especializados de inserção).
Um array NumPy é uma Sequence of Sequences válida e pode ser usado como argumento data no método insert principal, portanto não é necessário um método especializado.

Exemplos

Os exemplos abaixo partem do pressuposto de que já existe uma tabela users com o esquema (id UInt32, name String, age UInt8).

Inserção básica orientada por linhas

Inserção orientada a colunas

Inserir com tipos de coluna explícitos

Inserir em um banco de dados específico

Inserções a partir de arquivos

Para inserir dados diretamente de arquivos em tabelas do ClickHouse, consulte Inserção avançada (Inserções a partir de arquivos).

API bruta

Para casos de uso avançados que exigem acesso direto às interfaces HTTP do ClickHouse, sem transformações de tipo, consulte Uso avançado (API bruta).

Classes utilitárias e funções

As classes e funções a seguir também são consideradas parte da API clickhouse-connect “pública” e, assim como as classes e os métodos documentados acima, permanecem estáveis entre lançamentos secundários. Alterações incompatíveis nessas classes e funções ocorrerão apenas em um lançamento secundário (não em um patch) e permanecerão disponíveis com status de obsoletas por pelo menos um lançamento secundário.

Exceções

Todas as exceções personalizadas (incluindo as definidas na especificação DB API 2.0) são definidas no módulo clickhouse_connect.driver.exceptions. As exceções efetivamente detectadas pelo driver usarão um desses tipos.

Utilitários de ClickHouse SQL

As funções e a classe DT64Param no módulo clickhouse_connect.driver.binding podem ser usadas para construir e escapar corretamente consultas em ClickHouse SQL. Da mesma forma, as funções no módulo clickhouse_connect.driver.parser podem ser usadas para analisar nomes de tipos de dados do ClickHouse.

Casos de uso multithread, multiprocesso e assíncronos/orientados a eventos

Para mais informações sobre como usar o ClickHouse Connect em aplicações multithread, multiprocesso e assíncronas/orientadas a eventos, consulte Uso avançado (Casos de uso multithread, multiprocesso e assíncronos/orientados a eventos).

Wrapper do AsyncClient

Para obter informações sobre como usar o wrapper do AsyncClient em ambientes com asyncio, consulte Uso avançado (wrapper do AsyncClient).

Gerenciando IDs de sessão do ClickHouse

Para obter informações sobre como gerenciar IDs de sessão do ClickHouse em aplicações multithread ou concorrentes, consulte Uso avançado (Gerenciando IDs de sessão do ClickHouse).

Personalizando o pool de conexões HTTP

Para saber como personalizar o pool de conexões HTTP em aplicações grandes e multithread, consulte Uso avançado (Personalizando o pool de conexões HTTP).
Última modificação em 2 de julho de 2026