Skip to main content
Passe argumentos nomeados para fábricas de cliente e métodos com muitos parâmetros 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

Use clickhouse_connect.get_client para criar um Client síncrono ou instale o extra async e use await em clickhouse_connect.get_async_client para criar um AsyncClient nativo.

Argumentos de conexão

A função de fábrica assíncrona também aceita connector_limit=100, connector_limit_per_host=20 e keepalive_timeout=30.0 para configurar o pool de conexões do aiohttp. Ela não aceita pool_mgr. O backend chDB síncrono aceita path e chdb_options; consulte backend embutido do chDB.

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.

Backend embutido do chDB

Instale clickhouse-connect[chdb] para usar o backend experimental do chDB no próprio processo. Ele disponibiliza os métodos síncronos do cliente para consulta, insert, streaming e Arrow:
O padrão é um banco de dados em memória. Passe path="/data/my_chdb" ou use dsn="chdb:///data/my_chdb" para armazenamento persistente. O backend permite apenas um caminho de engine por processo e não oferece suporte a get_async_client nem a dados externos.

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
  • 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

Reutilize um único cliente:
Evite criar clientes repetidamente:

Aplicações multithread

Instâncias de Client 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 Client entre threads com segurança:
Alternativa para sessões: Se você precisar de sessões (por exemplo, para tabelas temporárias), crie um Client 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 vinculação no servidor para valores da consulta. O valor vinculado é enviado separadamente da consulta como um parâmetro HTTP. O ClickHouse Connect usa esse modo quando detecta uma expressão no formato {<name>:<datatype>}. Passe os valores como um dicionário Python. Use None do Python para valores anuláveis. Valores None aninhados são compatíveis dentro de parâmetros Array e Tuple e dentro de literais Map quando dict_parameter_format está definido como "map".
  • Vinculação no servidor com dicionário Python, valor DateTime e valor String
Isso equivale a:
A vinculação no servidor tem suporte para consultas SELECT. Ela não funciona com ALTER, DELETE, INSERT nem com outros tipos de instrução SQL.

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:
A vinculação de datetime trata valores sem timezone como horário local. O cliente formata um datetime sem timezone tal como está. O ClickHouse o interpreta usando o timezone declarado em um placeholder no servidor, como {dt:DateTime('Europe/Berlin')}, depois session_timezone, quando definido, e por fim o timezone do servidor. Um datetime com timezone é convertido para o timezone declarado no placeholder, quando presente; caso contrário, para o timezone do servidor informado no momento da conexão. Se a configuração session_timezone for diferente desse timezone do servidor, declare um timezone no placeholder para preservar o instante desejado para valores com timezone.Para compatibilidade temporária com a conversão local do host mais antiga, defina common.set_setting("naive_datetime_binding", "legacy") antes de vincular parâmetros. Para preservar um instante, anexe o tzinfo pretendido ao valor datetime antes de passá-lo como parâmetro. Inserts por meio de client.insert interpretam valores datetime sem timezone no timezone local do processo por padrão. Defina a configuração global naive_datetime_insert como "server" para interpretá-los como horário local no timezone da coluna ou, quando a coluna não tiver um, no timezone do servidor. Consulte objetos datetime sem timezone.Para um placeholder {value:DateTime64(precision)} no servidor, o tipo declarado preserva automaticamente a precisão de frações de segundo, inclusive dentro de indicações Array e Tuple.A vinculação %s no lado do cliente não tem tipo declarado. Envolva um datetime em DT64Param quando ele precisar ser formatado com precisão de frações de segundo:
Para compatibilidade retroativa, um nome de parâmetro de dicionário terminado em _64 também solicita a formatação DateTime64 quando esse nome exato com sufixo não está presente na consulta.Um parâmetro datetime.time ou datetime.timedelta é formatado como um literal [-]HH:MM:SS[.ffffff] para colunas Time e Time64 do ClickHouse, em ambos os estilos de vinculação e dentro de valores Array e Tuple. O cliente adiciona as aspas, portanto, não coloque aspas no placeholder na consulta. Um timedelta pode ser negativo e pode exceder 24 horas. Um Timedelta do pandas mantém seus nanossegundos e formata uma fração de nove dígitos para Time64(9). As informações de timezone em um time com timezone são ignoradas porque o Time do ClickHouse não tem timezone.

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 Client

Use Client.command para instruções que não retornam um conjunto de dados tabular ou para consultas que retornam um valor primitivo ou uma linha. Dependendo da resposta, ele retorna uma string, um inteiro, uma sequência de strings ou QuerySummary. Uma leitura que produz um conjunto de resultados vazio retorna uma string vazia.

Exemplos do comando

Instruções DDL

Consultas simples que retornam valores individuais

Comandos com parâmetros

Comandos com configurações

Método query do Client

Client.query recupera um conjunto de dados tabular no formato Native do ClickHouse e retorna um QueryResult. O resultado completo é materializado quando uma propriedade do resultado é acessada. Use um método de streaming para resultados que não devem ser mantidos na memória.

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 — Matriz de resultados orientada por linhas.
  • result_columns — Matriz de resultados orientada por colunas.
  • result_setresult_rows ou result_columns, de acordo com a orientação da consulta.
  • column_names — Tupla com os nomes das colunas do resultado.
  • column_types — Tupla de objetos ClickHouseType.
  • row_count — Número de linhas de resultado materializadas.
  • query_id — ID da consulta informado ou gerado para a requisição. Uma string vazia significa que nenhum estava disponível.
  • summary — Dicionário decodificado do cabeçalho de resposta X-ClickHouse-Summary.
  • first_item — Primeira linha como um dicionário, ou None para um resultado vazio.
  • first_row — Primeira linha como uma sequência, ou None para um resultado vazio.
  • column_block_stream, row_block_stream e rows_stream — Contextos internos de streaming. Use os métodos de streaming correspondentes do cliente.
Consulte Consultas em streaming para ver as APIs StreamContext compatíveis.

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 Client

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 QuerySummary. Seu dicionário summary contém valores informados pelo servidor. written_rows é uma propriedade de conveniência, enquanto written_bytes() e query_id() retornam os valores correspondentes. Uma falha na inserção gera uma exceção. Para métodos especializados de inserção que funcionam com Pandas DataFrames, tabelas PyArrow e DataFrames com Arrow como backend, consulte Advanced Inserting (Specialized Insert Methods).
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).

Python DB-API 2.0

O módulo clickhouse_connect.dbapi implementa a interface de conexão e cursor do PEP 249. Ele declara nível de API 2.0, threadsafety=2 e paramstyle="pyformat". O módulo também fornece os construtores de tipo do PEP 249 Date, Time, Timestamp e Binary, e as funções DateFromTicks, TimeFromTicks e TimestampFromTicks.
Cursor.execute e Cursor.executemany aceitam os argumentos nomeados adicionais settings e query_formats. settings passa configurações do ClickHouse. query_formats aplica formatos de leitura por tipo do ClickHouse quando uma instrução retorna linhas, usando o mesmo mapeamento de Client.query. executemany usa o caminho nativo de inserção em massa do driver para instruções INSERT ... VALUES compatíveis com uma sequência materializada de linhas. fetchone, fetchmany e fetchall consomem o resultado materializado atual. Cursor.description deriva null_ok do tipo de cada coluna de resultado. Tipos não anuláveis retornam False, e tipos anuláveis retornam True, incluindo wrappers Nullable, Variant e Dynamic. None significa que a anulabilidade é desconhecida. Quando uma consulta que começa com SELECT ou WITH, ignorando comentários iniciais, não retorna linhas nem metadados de coluna, o cursor executa uma consulta de metadados LIMIT 0 para preencher description. Se essa consulta de metadados falhar, description permanece vazio. O ClickHouse não oferece transações tradicionais por meio desta interface HTTP. Connection.commit() e Connection.rollback() são operações sem efeito. As regras de concorrência de ID de sessão ainda se aplicam quando uma conexão é compartilhada.

Classes utilitárias e funções

Os módulos a seguir fornecem helpers públicos adicionais usados por aplicativos cliente. A versão do pacote instalado é exposta como a string clickhouse_connect.__version__.

Exceções

Exceções personalizadas, incluindo a hierarquia de exceções da DB-API 2.0, são definidas em clickhouse_connect.driver.exceptions. DatabaseError e OperationalError expõem um atributo numérico code com o código de erro do ClickHouse e um atributo name com o nome simbólico, como UNKNOWN_TABLE, para que os aplicativos possam tomar decisões com base em exc.code em vez de analisar a mensagem. code é definido mesmo quando show_clickhouse_errors está desabilitado, enquanto name requer detalhes do erro (True ou "scrub"). Ambos são None quando indisponíveis, como em erros de transporte. Use show_clickhouse_errors="scrub" quando os usuários finais precisarem ver erros de SQL sem informações de host ou versão do servidor. A configuração também controla mensagens de StreamFailureError no meio do stream e mensagens genéricas de transporte. Ela controla apenas str(exc). Os erros de transporte ainda são anexados como __cause__, e os rastreamentos de pilha podem conter o host, a URL ou o texto de erro da biblioteca original.

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).

AsyncClient

Para usar o asyncio de forma nativa, consulte Uso avançado (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 14 de agosto de 2026