API directa
Método raw_query de Client
Client.raw_query permite usar directamente la interfaz HTTP de consultas de ClickHouse a través de la conexión del cliente. El valor devuelto es un objeto bytes sin procesar. Proporciona un práctico envoltorio con enlace de parámetros, manejo de errores, reintentos y gestión de configuración mediante una interfaz mínima:
Es responsabilidad de quien realiza la llamada procesar el objeto
bytes resultante. Tenga en cuenta que Client.query_arrow es simplemente un envoltorio ligero sobre este método que usa el formato de salida Arrow de ClickHouse.
Método raw_stream de Client
Client.raw_stream tiene la misma API que raw_query, pero devuelve un flujo io.IOBase de fragmentos de bytes. Cierre el flujo cuando termine el procesamiento. AsyncClient.raw_stream debe esperarse con await y devuelve un StreamContext asíncrono para usar con async with y async for.
Método raw_insert de Client
Client.raw_insert permite realizar inserciones directas de objetos bytes o generadores de objetos bytes mediante la conexión del Client. Como no procesa la carga útil de la inserción, ofrece un rendimiento muy alto. El método proporciona opciones para especificar la configuración y el formato de inserción:
Es responsabilidad de quien realiza la llamada garantizar que
insert_block esté en el formato especificado y use el método de compresión indicado. ClickHouse Connect usa estas inserciones sin procesar para cargas de archivos y tablas de PyArrow, delegando el análisis en el servidor de ClickHouse.
Guardar los resultados de consultas como archivos
raw_stream. Por ejemplo, si quieres guardar los resultados de una consulta en un archivo CSV, puedes usar el siguiente fragmento de código:
output.csv con el siguiente contenido:
Casos de uso multihilo, multiproceso y asíncronos/controlados por eventos
QueryContext o InsertContext, respectivamente, estos objetos auxiliares no son seguros en entornos multihilo y no deben compartirse entre varios flujos de procesamiento. Consulte información adicional sobre los objetos de contexto en las secciones QueryContexts e InsertContexts.
Además, en una aplicación que tiene dos o más consultas y/o inserciones “en curso” al mismo tiempo, hay otras dos consideraciones que deben tenerse en cuenta. La primera es la “sesión” de ClickHouse asociada con la consulta o inserción, y la segunda es el pool de conexiones HTTP utilizado por las instancias de Client de ClickHouse Connect.
AsyncClient
await a get_async_client para crear e inicializar un Client. Los métodos de E/S, como query, command e insert, son corrutinas:
get_async_client desactiva por defecto los ID de sesión automáticos para que las corrutinas concurrentes puedan compartir un Client. Pasa un session_id explícito o autogenerate_session_id=True solo cuando necesites estado de sesión y evites consultas concurrentes en esa sesión.
Administración de los ID de sesión de ClickHouse
- Asociar ajustes de ClickHouse específicos con múltiples consultas (consulta los ajustes de usuario). El comando
SETde ClickHouse se usa para cambiar los ajustes en el ámbito de una sesión de usuario. - Hacer seguimiento de las tablas temporales.
Client síncrono usa un ID de sesión generado. Por lo tanto, las sentencias SET y las tablas temporales persisten entre solicitudes de ese Client. La factoría async no genera un ID de sesión de forma predeterminada. ClickHouse no permite consultas concurrentes en la misma sesión, y el Client genera un ProgrammingError si se intenta, así que usa uno de los siguientes patrones:
- Crea una instancia
Clientindependiente para cada hilo/proceso/controlador de eventos que necesite aislamiento de sesión. Esto conserva el estado de sesión por Client (tablas temporales y valores deSET). - Usa un
session_idúnico para cada consulta mediante el argumentosettingsal llamar aquery,commandoinsert, si no necesitas un estado de sesión compartido. - Desactiva las sesiones en un Client compartido estableciendo
autogenerate_session_id=Falseantes de crear el Client (o pásalo directamente aget_client).
autogenerate_session_id=False directamente a get_client(...).
En este caso, ClickHouse Connect no envía un session_id; el servidor no trata las solicitudes independientes como si pertenecieran a la misma sesión. Las tablas temporales y la configuración a nivel de sesión no persistirán entre solicitudes.
Personalización del grupo de conexiones HTTP
urllib3 para gestionar la conexión HTTP subyacente con el servidor. De forma predeterminada, todas las instancias de Client comparten el mismo grupo de conexiones, lo que resulta suficiente para la mayoría de los casos de uso. Este grupo predeterminado mantiene hasta 8 conexiones HTTP Keep Alive con cada servidor ClickHouse que utiliza la aplicación.
En aplicaciones multihilo de gran tamaño, puede ser conveniente usar grupos de conexiones independientes. Se pueden proporcionar grupos de conexiones personalizados mediante el argumento de palabra clave pool_mgr de la función principal clickhouse_connect.get_client:
urllib3.
El Client async tiene su propio grupo de aiohttp en lugar de usar urllib3. Configúrelo mediante connector_limit, connector_limit_per_host y keepalive_timeout en get_async_client. La llamada a await async_client.close_connections() rota el grupo sin interrumpir las solicitudes en curso.