Saltar al contenido principal

Ajustes de conexión

Para un análisis detallado y completo de cada opción, con valores predeterminados, parámetros DSN, buenas prácticas y solución de problemas, consulta la Referencia de configuración.
Al abrir una conexión, se puede usar una estructura Options para controlar el comportamiento del cliente. Están disponibles los siguientes ajustes:
Ejemplo completo

TLS

A bajo nivel, todos los métodos de conexión del cliente (DSN/OpenDB/Open) usarán el paquete tls de Go para establecer una conexión segura. El cliente sabe que debe usar TLS si la estructura Options contiene un puntero tls.Config distinto de nil.
Ejemplo completo Esta configuración mínima de TLS.Config suele ser suficiente para conectarse al puerto nativo seguro (normalmente, el 9440) de un servidor ClickHouse. Si el servidor ClickHouse no tiene un certificado válido (caducado, con un hostname incorrecto o no firmado por una autoridad de certificación raíz reconocida públicamente), InsecureSkipVerify puede establecerse en true, pero se desaconseja encarecidamente.
Ejemplo completo Si se necesitan parámetros de TLS adicionales, el código de la aplicación debe configurar los campos deseados en la estructura tls.Config. Esto puede incluir conjuntos de cifrado específicos, forzar una versión concreta de TLS (como 1.2 o 1.3), añadir una cadena interna de certificados de una CA, añadir un certificado de cliente (y su clave privada) si lo requiere el ClickHouse server, y la mayoría de las demás opciones propias de una configuración de seguridad más especializada.

Autenticación

Especifique una estructura Auth en los detalles de conexión para definir un nombre de usuario y una contraseña.
Ejemplo completo

Conexión a varios nodos

Se pueden especificar varias direcciones mediante la estructura Addr.
Ejemplo completo Hay tres estrategias de conexión disponibles:
  • ConnOpenInOrder (predeterminada) - las direcciones se recorren en orden. Las direcciones posteriores solo se utilizan si falla la conexión con las direcciones anteriores de la lista. En la práctica, se trata de una estrategia de conmutación por error.
  • ConnOpenRoundRobin - La carga se distribuye entre las direcciones mediante una estrategia round-robin.
  • ConnOpenRandom - Se selecciona un nodo aleatoriamente de la lista de direcciones.
Esto se puede controlar mediante la opción ConnOpenStrategy
Ejemplo completo

Pool de conexiones

El cliente mantiene un pool de conexiones y las reutiliza entre consultas según sea necesario. Como máximo, se usará MaxOpenConns en un momento dado, y MaxIdleConns controla el tamaño máximo del pool. El cliente obtiene una conexión del pool para cada ejecución de consulta y la devuelve al pool para reutilizarla. Una conexión se usa durante toda la vida útil de un batch y se libera en Send(). No se garantiza que se use la misma conexión del pool en consultas posteriores, a menos que el usuario establezca MaxOpenConns=1. Esto rara vez es necesario, pero puede serlo en casos en los que se usen tablas temporales. Además, tenga en cuenta que ConnMaxLifetime es, de forma predeterminada, de 1 h. Esto puede hacer que la carga en ClickHouse se desequilibre si algunos nodos abandonan el cluster. Esto puede ocurrir cuando un nodo deja de estar disponible; las conexiones se redistribuyen entre los demás nodos. Estas conexiones persistirán y no se actualizarán durante 1 h de forma predeterminada, incluso si el nodo problemático vuelve al cluster. Considere reducir este valor en casos de workload elevado. La agrupación de conexiones está habilitada tanto para Native (TCP) como para el protocolo HTTP.

Registro

El cliente admite el registro estructurado a través del paquete estándar log/slog de Go mediante el campo Logger de Options. Los campos Debug y Debugf anteriores están obsoletos, pero siguen funcionando por compatibilidad con versiones anteriores (prioridad: Debugf > Logger > no-op).
También puedes enriquecer el logger con contexto de la aplicación:
Ejemplo completo

Compresión

La compatibilidad con los métodos de compresión depende del protocolo subyacente que se utilice. En el protocolo nativo, el cliente admite compresión LZ4 y ZSTD. Esto se realiza únicamente a nivel de bloque. La compresión puede habilitarse añadiendo una configuración Compression a la conexión.
Ejemplo completo Hay técnicas de compresión adicionales disponibles cuando se usa el transporte HTTP: gzip, deflate y br. Consulta Base de datos/API SQL: compresión para obtener más detalles.

TCP vs HTTP

El transporte se cambia con una sola opción de configuración; todo lo demás de esta guía se aplica a ambos. Esto es lo que cambia: Para cambiar cualquiera de las dos API a HTTP:
Última modificación el 10 de junio de 2026