@clickhouse/client- solo para Node.js@clickhouse/client-web- navegadores (Chrome/Firefox), Cloudflare Workers
Skills de AI agentEl client de JS incluye skills de AI agent que pueden ayudar a los agentes de programación a trabajar con el client. Instálalas con:
Requisitos del entorno (Node.js)
Requisitos del entorno (web)
Instalación
Compatibilidad con ClickHouse
Es probable que el client también funcione con versiones anteriores; sin embargo, esta compatibilidad se ofrece sobre la base del mejor esfuerzo y no está garantizada. Si utiliza una versión de ClickHouse anterior a la 23.3, consulte la política de seguridad de ClickHouse y considere actualizar.
Ejemplos
API del client
Creación de una instancia de client
createClient:
Configuración
Parámetros de configuración específicos de Node.js
Configuración de URL
http[s]://[username:password@]hostname:port[/database][?param1=value1¶m2=value2]. En casi todos los casos, el nombre de un parámetro concreto refleja su ruta en la interfaz de opciones de configuración, con algunas excepciones. Se admiten los siguientes parámetros:
- (1) Para los booleanos, los valores válidos son
true/1yfalse/0. - (2) A cualquier parámetro con el prefijo
clickhouse_setting_och_se le eliminará ese prefijo, y el resto se añadirá aclickhouse_settingsdel client. Por ejemplo,?ch_async_insert=1&ch_wait_for_async_insert=1será lo mismo que:
clickhouse_settings deben pasarse como 1/0 en la URL.
- (3) Igual que (2), pero para la configuración de
http_header. Por ejemplo,?http_header_x-clickhouse-auth=foobarserá equivalente a:
Conectar
Recopila los datos de tu conexión
Los detalles de su servicio de ClickHouse Cloud están disponibles en la consola de ClickHouse Cloud.
Seleccione un servicio y haga clic en Connect:

curl de ejemplo.

Resumen de la conexión
url (incluidos
el protocolo y el puerto) y password se especifican mediante variables de entorno, y que se usa el usuario default.
Ejemplo: Crear una instancia de Client de Node.js usando variables de entorno para la configuración.
Pool de conexiones (solo Node.js)
10, pero puede cambiarlo con la opción de configuración max_open_connections.
No se garantiza que se use la misma conexión del pool en las consultas posteriores, a menos que el usuario establezca max_open_connections: 1. Esto rara vez es necesario, pero puede ser obligatorio en casos en los que se utilicen tablas temporales.
Véase también: configuración de Keep-Alive.
ID de consulta
command, exec, insert, select) proporcionará query_id en el resultado. El client asigna este identificador único a cada consulta y puede ser útil para obtener los datos de system.query_log,
si está habilitado en la configuración del servidor, o para cancelar consultas de larga duración (consulte el ejemplo). Si es necesario, el usuario puede sobrescribir query_id en los parámetros de los métodos command/query/exec/insert.
Parámetros base para todos los métodos del client
Método de consulta
SELECT, o para enviar DDL como CREATE TABLE, y debe usarse con await. Se espera que el conjunto de resultados devuelto se consuma en la aplicación.
Abstracciones de result set y fila
ResultSet proporciona varios métodos prácticos para procesar datos en su aplicación.
La implementación de ResultSet en Node.js usa Stream.Readable internamente, mientras que la versión web usa la API web ReadableStream.
Puede consumir el ResultSet llamando a los métodos text o json de ResultSet y cargar en memoria el conjunto completo de filas devuelto por la consulta.
Debe empezar a consumir el ResultSet lo antes posible, ya que mantiene abierto el flujo de respuesta y, en consecuencia, mantiene ocupada la conexión subyacente. El client no almacena en búfer los datos entrantes para evitar un posible uso excesivo de memoria por parte de la aplicación.
Como alternativa, si es demasiado grande para caber en memoria de una sola vez, puede llamar al método stream y procesar los datos en modo streaming. En ese caso, cada uno de los fragmentos de la respuesta se transformará en arrays de filas relativamente pequeños (el tamaño de este array depende del tamaño del fragmento concreto que el client recibe del servidor, ya que puede variar, y del tamaño de cada fila), un fragmento cada vez.
Consulte la lista de formatos de datos compatibles para determinar cuál es el mejor formato para el streaming en su caso. Por ejemplo, si quiere transmitir objetos JSON, puede elegir JSONEachRow, y cada fila se interpretará como un objeto de JS o, quizá, un formato JSONCompactColumns más compacto, que hará que cada fila sea un array compacto de valores. Véase también: archivos en streaming.
JSONEachRow, que consume todo el flujo y analiza el contenido como objetos de JS.
Código fuente.
JSONEachRow mediante el enfoque clásico on('data'). Puede usarse indistintamente con la sintaxis for await const. Código fuente.
CSV con el enfoque clásico on('data'). Esto puede usarse indistintamente con la sintaxis for await const.
Código fuente
JSONEachRow, consumidos con la sintaxis for await const. Esto puede usarse indistintamente con el enfoque clásico on('data').
Código fuente.
La sintaxis
for await const requiere algo menos de código que el enfoque on('data'), pero puede afectar negativamente al rendimiento.
Consulta este issue del repositorio de Node.js para obtener más detalles.ReadableStream de objetos.
Método insert
{ query_id: '...', executed: false }. Si en este caso no se proporcionó query_id en los params del método, en el resultado será una cadena vacía, ya que devolver un UUID aleatorio generado por el client podría resultar confuso, porque la consulta con ese query_id no existirá en la tabla system.query_log.
Si la sentencia insert se envió al servidor, el indicador executed será true.
Método insert y streaming en Node.js
Stream.Readable como con un Array<T> simple, según el formato de datos especificado para el método insert. Consulte también esta sección sobre el streaming de archivos.
Se debe esperar al método insert; sin embargo, es posible especificar un flujo de entrada y esperar a la operación insert más tarde, únicamente cuando el flujo se haya completado (lo que también resolverá la promesa de insert). Esto puede ser útil para listeners de eventos y casos similares, pero el manejo de errores puede no ser sencillo, ya que hay muchos casos límite del lado del client. En su lugar, considere usar async inserts, como se muestra en este ejemplo.
Limitaciones de la versión web
@clickhouse/client-web solo funcionan con los formatos Array<T> y JSON*.
La inserción de streams todavía no es compatible con la versión web debido a la limitada compatibilidad de los navegadores.
En consecuencia, la interfaz InsertParams para la versión web es ligeramente distinta de la versión de Node.js,
ya que values está limitado exclusivamente al tipo ReadonlyArray<T>:
Método command
CREATE TABLE o ALTER TABLE.
Se debe esperar su finalización.
El flujo de respuesta se destruye de inmediato, lo que significa que el socket subyacente se libera.
Método exec
query/insert
y te interesa el resultado, puedes usar exec como alternativa a command.
exec devuelve un stream de lectura que DEBE consumirse o destruirse del lado de la aplicación.
Ping
ping, que se proporciona para comprobar el estado de la conectividad, devuelve true si se puede establecer conexión con el servidor.
Si no se puede establecer conexión con el servidor, el error subyacente también se incluye en el resultado.
/ping, mientras que la versión web usa una consulta simple SELECT 1 para lograr un resultado similar, ya que el endpoint /ping no admite CORS.
Ejemplo: (Node.js/Web) Un ping sencillo a la instancia del servidor ClickHouse. Nota: en la versión web, los errores capturados serán diferentes.
Código fuente.
ping o especificar parámetros adicionales como query_id, puedes usarlo así:
query; consulta la definición de tipo PingParamsWithSelectQuery.
Close (solo para Node.js)
Streaming de archivos (solo Node.js)
- Streaming desde un archivo NDJSON
- Streaming desde un archivo CSV
- Streaming desde un archivo Parquet
- Streaming a un archivo Parquet
query (JSONEachRow, CSV, etc.) y en el nombre del archivo de salida.
Formatos de datos compatibles
format como uno de la familia de formatos JSON (JSONEachRow, JSONCompactEachRow, etc.), el Client serializará y deserializará los datos durante la comunicación por la red.
Los datos proporcionados en formatos de texto “sin procesar” (familias CSV, TabSeparated y CustomSeparated) se envían por la red sin transformaciones adicionales.
Para Parquet, el principal caso de uso de las consultas
SELECT probablemente sea escribir el flujo resultante en un archivo. Consulte el ejemplo en el repositorio del Client.
JSONEachRowWithProgress es un formato solo de salida que admite informes de progreso en el flujo. Consulte este ejemplo para obtener más información.
La lista completa de formatos de entrada y salida de ClickHouse está disponible
aquí.
Tipos de datos de ClickHouse compatibles
El tipo de JS correspondiente es relevante para cualquier formato
JSON*, excepto para los que representan todo como una cadena (p. ej., JSONStringEachRow)
La lista completa de formatos compatibles de ClickHouse está disponible
aquí.
Véase también:
Consideraciones sobre los tipos Date/Date32
Date/Date32 solo se pueden insertar como
cadenas.
Ejemplo: Insertar un valor de tipo Date.
Código fuente
DateTime o DateTime64, puedes usar tanto cadenas como objetos Date de JS. Los objetos Date de JS se pueden pasar a insert tal cual, con date_time_input_format configurado en best_effort. Consulta este ejemplo para obtener más información.
Advertencias sobre los tipos Decimal*
JSON*. Supongamos que tenemos una tabla definida como:
JSON*, ClickHouse devolverá los Decimal como números de forma predeterminada, lo que podría causar una pérdida de precisión. Para evitarlo, puedes convertir los Decimal en cadenas en la consulta:
Tipos integrales: Int64, Int128, Int256, UInt64, UInt128, UInt256
JSON* se devuelve como una cadena para evitar
el desbordamiento de enteros, ya que los valores máximos de estos tipos son mayores que Number.MAX_SAFE_INTEGER.
Sin embargo, este comportamiento se puede modificar
con el ajuste output_format_json_quote_64bit_integers
.
Ejemplo: Ajusta el formato de salida JSON para números de 64 bits.
Ajustes de ClickHouse
Temas avanzados
Consultas con parámetros
name— Identificador provisional.data_type- Tipo de dato del valor del parámetro de la aplicación.
Compresión
GZIP mediante zlib.
response: trueindica a ClickHouse server que devuelva el cuerpo de la respuesta comprimido. Valor predeterminado:response: falserequest: truehabilita la compresión en el cuerpo de la solicitud del Client. Valor predeterminado:request: false
Registro (solo para Node.js)
stdout mediante los métodos console.debug/info y en stderr mediante los métodos console.warn/error.
Puede personalizar la lógica de registro proporcionando una LoggerClass y elegir el nivel de registro deseado mediante el parámetro level (el valor predeterminado es WARN):
TRACE- información de bajo nivel sobre el ciclo de vida de los sockets Keep-AliveDEBUG- información de la respuesta (sin encabezados de autorización ni información del host)INFO- prácticamente no se usa; mostrará el nivel de registro actual cuando se inicialice el ClientWARN- errores no fatales; una solicitudpingfallida se registra como advertencia, ya que el error subyacente se incluye en el resultado devueltoERROR- errores fatales de los métodosquery/insert/exec/command, como una solicitud fallida
Certificados TLS (solo para Node.js)
certs
y que el nombre del archivo de la CA es CA.pem:
Configuración de Keep-Alive (solo Node.js)
Connection: keep-alive. Los sockets inactivos permanecerán en el pool de conexiones durante 2500 milisegundos de forma predeterminada (consulta las notas sobre cómo ajustar esta opción).
keep_alive.idle_socket_ttl debería tener un valor bastante menor que el de la configuración del servidor/LB. La razón principal es que, como HTTP/1.1 permite que el servidor cierre los sockets sin notificar al Client, si el servidor o el balanceador de carga cierra la conexión antes de que lo haga el Client, este podría intentar reutilizar el socket cerrado, lo que provocaría un error socket hang up.
Si estás modificando keep_alive.idle_socket_ttl, ten en cuenta que siempre debe estar sincronizado con la configuración de Keep-Alive de tu servidor/LB y que debe ser siempre menor que esta, para garantizar que el servidor nunca cierre primero la conexión abierta.
Ajuste de idle_socket_ttl
keep_alive.idle_socket_ttl en 2500 milisegundos, ya que puede considerarse el valor predeterminado más seguro; del lado del servidor, keep_alive_timeout puede configurarse en un valor tan bajo como 3 segundos en versiones de ClickHouse anteriores a la 23.11 sin modificar config.xml.
Puedes encontrar el valor correcto del tiempo de espera de Keep-Alive en los encabezados de respuesta del servidor ejecutando el siguiente comando:
Connection y Keep-Alive en la respuesta. Por ejemplo:
keep_alive_timeout es de 10 segundos, y podrías intentar aumentar keep_alive.idle_socket_ttl a 9000 o incluso 9500 milisegundos para mantener los sockets inactivos abiertos un poco más de lo habitual. Presta atención a posibles errores de “Socket hang-up”, ya que indicarían que el servidor cierra las conexiones antes de que lo haga el Client; reduce el valor hasta que los errores desaparezcan.
Resolución de problemas
socket hang up incluso al usar la versión más reciente del Client, tienes las siguientes opciones para resolver este problema:
-
Habilita los logs con un log level de al menos
WARN(predeterminado). Esto te permitirá comprobar si hay algún stream sin consumir o colgando en el código de la aplicación: la capa de transporte lo registrará en el nivel WARN, ya que esto podría hacer que el servidor cierre el socket. Puedes habilitar el registro en la configuración del Client de la siguiente manera: -
Asegúrate de que la configuración deseada se aplique a la instancia de Client correcta. Si tienes varias instancias de Client en tu aplicación, verifica de nuevo que la que usas para las consulta tenga el valor correcto de
keep_alive.idle_socket_ttl. -
Reduce el ajuste
keep_alive.idle_socket_ttlen la configuración del Client en 500 milisegundos. En determinadas situaciones, por ejemplo, cuando hay una latencia de red alta entre el Client y el servidor, esto puede resultar beneficioso, ya que evita el caso en el que una request saliente obtenga un socket que el servidor esté a punto de cerrar. -
Si este error se produce durante consulta de larga ejecución sin entrada ni salida de datos (por ejemplo, un
INSERT FROM SELECTde larga ejecución), podría deberse a que un balanceador de carga u otros componentes de red cierran conexiones de larga duración o requests que tardan mucho en completarse. Puedes intentar forzar la entrada de algunos datos durante las consulta de larga ejecución usando una combinación de estos ajuste de ClickHouse:Ten en cuenta, sin embargo, que el tamaño total de los encabezados recibidos tiene un límite de 16 KB en las versiones recientes de Node.js; tras recibir cierta cantidad de encabezados de progreso, que en nuestras pruebas fue de alrededor de 70-80, se generará una excepción. También es posible usar un enfoque completamente distinto, evitando por completo el tiempo de espera en tránsito; esto puede lograrse aprovechando la “feature” de la HTTP interface por la que las mutations no se cancelan cuando se pierde la conexión. Consulta este Example (parte 2) para obtener más detalles. -
La funcionalidad Keep-Alive puede deshabilitarse por completo. En ese caso, el Client también añadirá el encabezado
Connection: closea cada request, y el HTTP agent subyacente no reutilizará las conexiones. Se ignorará el ajustekeep_alive.idle_socket_ttl, ya que no habrá sockets inactivos. Esto generará una sobrecarga adicional, ya que se establecerá una nueva conexión para cada request. -
Descarta posibles problemas con el resto de la stack de red, incluido Node.js, ejecutando una prueba sencilla desde la línea de comandos con la misma instancia de ClickHouse y la misma ruta de red (es decir, desde la misma máquina o segmento de red, por ejemplo, un pod de Kubernetes), por ejemplo, usando
curl:Puede que te convenga ejecutarlo en un bucle durante varios minutos. Si ves errores similares encurl, es probable que el problema no esté relacionado con la configuración del Client, sino con la stack de red o con la configuración del servidor. -
Para probar la conexión con la funcionalidad nativa de Node.js, puedes intentar crear una request HTTP simple al servidor ClickHouse usando la API integrada
fetch:
-
En algunos casos, el código de la aplicación o los adaptadores del framework pueden añadir un
ping()preventivo antes de la ejecución real de la consulta, lo que puede provocar una situación en la que la solicitudping()se complete correctamente, pero la solicitud de consulta posterior falle con un error “socket hang up” debido al mismo problema subyacente con las conexiones inactivas. Si observa ese patrón en los logs, compruebe si existe alguna opción para deshabilitar los pings preventivos en su framework o en el código de la aplicación. Esto también debería ayudar a reducir la probabilidad de que alguno de los componentes de red intermedios aplique limitación de tasa. - Asegúrese de que la propia aplicación esté recibiendo suficiente tiempo de CPU y de que la red no esté siendo limitada por el proveedor de hosting. Distintos mecanismos de monitorización, como las métricas de pausas de GC, las métricas de retraso del bucle de eventos y otras similares, también pueden ser útiles para descartar posibles problemas de falta de recursos.
- Pruebe a revisar el código de su aplicación con la regla ESLint no-floating-promises habilitada, lo que ayudará a identificar promesas no gestionadas que podrían dar lugar a streams y sockets colgantes.
Usuarios de solo lectura
enable_http_compression. La siguiente configuración dará como resultado un error:
Proxy con una ruta en la URL
clickhouse_server como opción de configuración pathname (con o sin una barra inicial); de lo contrario, si se proporciona directamente en la url, se interpretará como la opción database. Se admiten varios segmentos, por ejemplo, /my_proxy/db.
Proxy inverso con autenticación
http_headers para proporcionar los encabezados necesarios:
Agente HTTP/HTTPS personalizado (experimental, solo para Node.js)
max_open_connections, keep_alive.enabled, tls), que se encargará de gestionar las conexiones al servidor de ClickHouse. Además, si se usan certificados TLS, el agente subyacente se configurará con los certificados necesarios y se aplicarán los encabezados correctos de autenticación TLS.
A partir de la versión 1.2.0, es posible proporcionar un agente HTTP o HTTPS personalizado al Client, en sustitución del agente subyacente predeterminado. Esto puede resultar útil en configuraciones de red complejas. Si se proporciona un agente personalizado, se aplican las siguientes condiciones:
- Las opciones
max_open_connectionsytlsno tendrán efecto y el Client las ignorará, ya que forman parte de la configuración del agente subyacente. keep_alive.enabledsolo regulará el valor predeterminado del encabezadoConnection(true->Connection: keep-alive,false->Connection: close).- Aunque la gestión de sockets keep-alive inactivos seguirá funcionando (ya que no está vinculada al agente, sino al propio socket), ahora es posible desactivarla por completo estableciendo el valor de
keep_alive.idle_socket_ttlen0.
Ejemplos de uso de un agente personalizado
set_basic_auth_header (introducida en la versión 1.2.0), ya que entra en conflicto con los encabezados TLS. Todos los encabezados TLS deben proporcionarse manualmente.
Limitaciones conocidas (Node.js/web)
- No hay mapeadores de datos para los conjuntos de resultados, por lo que solo se usan primitivos del lenguaje. Está previsto añadir mapeadores para determinados tipos de datos con soporte para RowBinary format.
- Existen algunas consideraciones sobre los tipos de datos Decimal* y Date* / DateTime*.
- Al usar formatos de la familia JSON*, los números mayores que Int32 se representan como cadenas, ya que los valores máximos de los tipos Int64+ son mayores que
Number.MAX_SAFE_INTEGER. Consulta la sección Tipos integrales para obtener más detalles.
Limitaciones conocidas (web)
- El streaming de las consultas SELECT funciona, pero está deshabilitado para las inserciones (también a nivel de tipo).
- La compresión de solicitudes está deshabilitada y la configuración se ignora. La compresión de respuestas funciona.
- Todavía no hay soporte para registro.
Consejos para optimizar el rendimiento
- Para reducir el consumo de memoria de la aplicación, considere usar streams para inserciones grandes (p. ej., desde archivos) y consultas cuando corresponda. Para listeners de eventos y casos de uso similares, los async inserts pueden ser otra buena opción, ya que permiten minimizar, o incluso evitar por completo, el batching del lado del Client. Hay ejemplos de async insert disponibles en el repositorio del Client, con
async_insert_como prefijo del nombre de archivo. - El Client no habilita la compresión de solicitudes ni de respuestas de forma predeterminada. Sin embargo, al consultar o insertar grandes volúmenes de datos, podría considerar habilitarla mediante
ClickHouseClientConfigOptions.compression(ya sea solo pararequestoresponse, o para ambos). - La compresión tiene un costo significativo en el rendimiento. Habilitarla para
requestoresponseafectará negativamente a la velocidad de las consultas o las inserciones, respectivamente, pero reducirá la cantidad de tráfico de red transferido por la aplicación.
Contáctanos
#clickhouse-js) o a través de issues de GitHub.