API bruta
Método raw_query do cliente
Client.raw_query permite usar diretamente a interface HTTP de consulta do ClickHouse por meio da conexão do cliente. O valor retornado é um objeto bytes não processado. Ele oferece um wrapper conveniente com vinculação de parâmetros, tratamento de erros, novas tentativas e gerenciamento de configurações por meio de uma interface mínima:
Cabe a quem faz a chamada lidar com o objeto
bytes resultante. Observe que Client.query_arrow é apenas um wrapper leve em torno desse método, usando o formato de saída Arrow do ClickHouse.
Método raw_stream do Client
Client.raw_stream tem a mesma API de raw_query, mas retorna um fluxo io.IOBase de fragmentos de bytes. Feche o fluxo quando o processamento for concluído. AsyncClient.raw_stream deve ser aguardado com await e retorna um StreamContext assíncrono para uso com async with e async for.
Método raw_insert do cliente
Client.raw_insert permite inserts diretos de objetos bytes ou geradores de objetos bytes usando a conexão do cliente. Como ele não faz nenhum processamento do payload de insert, oferece alto desempenho. O método fornece opções para especificar configurações e o formato de insert:
É responsabilidade de quem chama garantir que o
insert_block esteja no formato especificado e use o método de compressão especificado. O ClickHouse Connect usa esses inserts brutos para uploads de arquivos e tabelas PyArrow, delegando o parsing ao servidor ClickHouse.
Salvando resultados de consultas em arquivos
raw_stream. Por exemplo, se quiser salvar os resultados de uma consulta em um arquivo CSV, poderá usar o seguinte trecho de código:
output.csv com o seguinte conteúdo:
Casos de uso multithread, multiprocesso e assíncronos/orientados a eventos
QueryContext ou InsertContext, respectivamente, esses objetos auxiliares não são thread-safe e não devem ser compartilhados entre vários fluxos de processamento. Veja a discussão adicional sobre objetos de contexto nas seções QueryContexts e InsertContexts.
Além disso, em uma aplicação que tenha duas ou mais consultas e/ou inserts “em andamento” ao mesmo tempo, há mais dois pontos a considerar. O primeiro é a “sessão” do ClickHouse associada à consulta/insert, e o segundo é o pool de conexões HTTP usado pelas instâncias do cliente ClickHouse Connect.
AsyncClient
await com get_async_client para criar e inicializar um cliente. Métodos de E/S, como query, command e insert, são corrotinas:
get_async_client desativa, por padrão, a geração automática de IDs de sessão para que corrotinas concorrentes possam compartilhar um cliente. Passe um session_id explícito ou autogenerate_session_id=True somente quando precisar de estado de sessão e evitar consultas concorrentes nessa sessão.
Gerenciando IDs de sessão do ClickHouse
- Associar configurações específicas do ClickHouse a várias consultas (consulte configurações do usuário). O comando
SETdo ClickHouse é usado para alterar as configurações no escopo de uma sessão de usuário. - Acompanhar tabelas temporárias.
Client síncrono usa um ID de sessão gerado. Instruções SET e tabelas temporárias, portanto, são mantidas entre requisições desse cliente. A fábrica async não gera um ID de sessão por padrão. O ClickHouse não permite consultas simultâneas na mesma sessão, e o cliente gerará um ProgrammingError se isso for tentado, portanto use um dos seguintes padrões:
- Crie uma instância
Clientseparada para cada thread/processo/manipulador de eventos que precise de isolamento de sessão. Isso preserva o estado da sessão de cada cliente (tabelas temporárias e valores deSET). - Use um
session_idexclusivo para cada consulta por meio do argumentosettingsao chamarquery,commandouinsert, se você não precisar de um estado de sessão compartilhado. - Desative as sessões em um cliente compartilhado definindo
autogenerate_session_id=Falseantes de criar o cliente (ou passe isso diretamente paraget_client).
autogenerate_session_id=False diretamente para get_client(...).
Nesse caso, o ClickHouse Connect não envia um session_id; o servidor não considera que requisições separadas pertençam à mesma sessão. Tabelas temporárias e configurações no nível da sessão não serão mantidas entre as requisições.
Personalizando o pool de conexões HTTP
urllib3 para gerenciar a conexão HTTP subjacente com o servidor. Por padrão, todas as instâncias de cliente compartilham o mesmo pool de conexões, o que é suficiente para a maioria dos casos de uso. Esse pool padrão mantém até 8 conexões HTTP Keep Alive para cada servidor ClickHouse usado pela aplicação.
Para aplicações grandes e multithread, pode ser mais adequado usar pools de conexões separados. Pools de conexões personalizados podem ser fornecidos como o argumento nomeado pool_mgr para a função principal clickhouse_connect.get_client:
urllib3.
O cliente assíncrono tem um pool do aiohttp em vez de usar urllib3. Configure-o com connector_limit, connector_limit_per_host e keepalive_timeout em get_async_client. Chamar await async_client.close_connections() renova o pool sem interromper as solicitações em andamento.