Despliegue de ClickHouse

Qué configuramos y por qué

Desplegaremos ClickHouse, un sistema de gestión de bases de datos (SGBD) columnar diseñado para el procesamiento analítico en línea (OLAP). ClickHouse fue desarrollado por Yandex y es conocido por su increíble velocidad en el procesamiento de grandes volúmenes de datos, a menudo superando en decenas o cientos de veces a las bases de datos relacionales tradicionales para tareas analíticas. Es ideal para escenarios donde se requiere agregar y analizar enormes cantidades de información en tiempo real, como registros (logs), métricas, transacciones financieras, datos de IoT y eventos de usuario.

Al final, el lector obtendrá un servidor ClickHouse completamente funcional, optimizado para un alto rendimiento y listo para recibir datos. Esto permitirá crear potentes aplicaciones analíticas, dashboards, sistemas de monitoreo e informes, procesando consultas en milisegundos incluso con gigabytes o terabytes de información.

Existen alternativas a ClickHouse, como PostgreSQL con extensiones (por ejemplo, TimescaleDB), Apache Druid, Apache Doris o soluciones gestionadas en la nube como Amazon Redshift, Google BigQuery, Snowflake. Cada una de estas soluciones tiene sus ventajas y desventajas. Los servicios en la nube ofrecen facilidad de escalado y la ausencia de necesidad de gestionar la infraestructura, pero a menudo conllevan altos costos operativos y bloqueo de proveedor (vendor lock-in). Las soluciones autoalojadas (self-hosted), como ClickHouse en un VPS, proporcionan un control total sobre los datos y la infraestructura, lo cual es crítico para proyectos con datos sensibles o requisitos estrictos de seguridad y privacidad. La elección de una solución autoalojada en un VPS permite reducir significativamente los costos en comparación con las alternativas en la nube, especialmente con una carga predecible, y obtener el máximo rendimiento ajustando finamente el sistema a sus necesidades. Además, esto brinda una experiencia invaluable en la administración de sistemas de alta carga.

Qué configuración de VPS se necesita para esta tarea

Para ClickHouse, varios parámetros son críticamente importantes: la cantidad de memoria RAM, la velocidad del subsistema de disco y el número de núcleos del procesador. La red también es importante si planea cargar datos activamente o utilizar la replicación entre servidores.

Requisitos mínimos para un servidor de prueba o de producción pequeño (hasta 100 GB de datos):

• CPU: 2-4 núcleos (preferiblemente con alta frecuencia, ya que ClickHouse escala bien con los núcleos para el procesamiento paralelo de consultas).
• RAM: 8 GB. ClickHouse utiliza la RAM de manera eficiente para el almacenamiento en caché de datos y la ejecución de consultas. Cuanta más RAM, menos accesos al disco.
• Disco: 200 GB NVMe SSD. La velocidad del disco es uno de los factores clave del rendimiento de ClickHouse. Los NVMe SSD superan significativamente a los SATA SSD y HDD.
• Red: 1 Gbit/s.

Plan de VPS recomendado para un servidor de producción mediano (cientos de GB - 1-2 TB de datos):

Para tareas más serias, donde el volumen de datos puede alcanzar varios terabytes, o se requiere un alto procesamiento paralelo de consultas, se recomienda la siguiente configuración:

• CPU: 8 núcleos (Intel Xeon o AMD EPYC modernos).
• RAM: 32-64 GB.
• Disco: 1-2 TB NVMe SSD. Posibilidad de expansión o uso de varios discos para RAID 0/1.
• Red: 10 Gbit/s.

Para este nivel de rendimiento y recursos, se puede considerar un VPS con las características indicadas, que ofrece planes flexibles con NVMe SSD y un alto ancho de banda de red.

Cuándo se necesita un servidor dedicado, no un VPS

Un servidor dedicado se vuelve necesario cuando:

• El volumen de datos supera los 2-3 TB en un solo nodo: La gestión de grandes volúmenes de datos en un VPS puede ser compleja debido a las limitaciones de espacio en disco.
• Se requiere el máximo rendimiento de E/S: Los servidores dedicados a menudo ofrecen acceso directo al subsistema de disco sin virtualización, lo cual es crítico para ClickHouse.
• Se necesita un ancho de banda de red alto y estable: Para clústeres de ClickHouse o carga intensiva de datos.
• Se requiere hardware específico: Por ejemplo, controladores RAID especiales, discos NVMe con rendimiento garantizado o un mayor número de núcleos/RAM de lo disponible en un VPS.
• Requisitos regulatorios o de seguridad: Algunos estándares exigen una separación física completa de los recursos de hardware.

Ubicación: en qué influye

La elección de la ubicación del VPS influye en:

• Latencia (ping) a usuarios/fuentes de datos: Ubique el servidor más cerca de su audiencia principal o fuentes de datos para minimizar los retrasos.
• Legislación: Diferentes países tienen diferentes leyes sobre el almacenamiento y procesamiento de datos. Asegúrese de que la ubicación elegida cumpla con sus requisitos legales.
• Costo: Los precios de los VPS pueden variar según la región.
• Disponibilidad de red: Algunas ubicaciones pueden tener mejor conectividad con ciertas regiones del mundo.

Preparación del servidor

Comencemos con la configuración básica del servidor. Utilizaremos Ubuntu 24.04 LTS como el sistema operativo más estable y compatible. Todos los comandos se ejecutan como un usuario con privilegios sudo.

1. Conexión por SSH

Después de obtener los datos de acceso al VPS, conéctese a él por SSH:

ssh root@ВАШ_IP_АДРЕС

2. Creación de un nuevo usuario y configuración de sudo

No se recomienda trabajar como usuario root. Crearemos un nuevo usuario y lo añadiremos al grupo sudo.

# Reemplace 'ваш_пользователь' con el nombre de usuario deseado
adduser ваш_пользователь
usermod -aG sudo ваш_пользователь

Establezca una contraseña segura para el nuevo usuario. Ahora, salga de la sesión de root e inicie sesión con el nuevo usuario:

exit
ssh ваш_пользователь@ВАШ_IP_АДРЕС

3. Configuración de claves SSH (recomendado)

Para mejorar la seguridad, se recomienda usar claves SSH en lugar de contraseñas. Si aún no tiene una clave SSH, genérela en su máquina local:

# En su máquina local
ssh-keygen -t ed25519 -C "ваш[email protected]"

Luego, copie la clave pública al servidor:

# En su máquina local
ssh-copy-id ваш_пользователь@ВАШ_IP_АДРЕС

Después de verificar, desactive el inicio de sesión con contraseña para SSH, editando el archivo /etc/ssh/sshd_config:

sudo nano /etc/ssh/sshd_config

Encuentre las líneas y establezca los valores:

PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no

Reinicie el servicio SSH:

sudo systemctl restart ssh

4. Actualización del sistema e instalación de utilidades básicas

Asegúrese de que su sistema esté actualizado y que los paquetes necesarios estén instalados.

# Actualizar la lista de paquetes
sudo apt update
# Actualizar todos los paquetes instalados a las últimas versiones
sudo apt upgrade -y
# Instalar utilidades útiles, si no están presentes
sudo apt install -y curl wget git htop rsync unattended-upgrades

5. Configuración del firewall (UFW)

Configuraremos el firewall básico UFW para permitir SSH, HTTP/HTTPS y los puertos de ClickHouse.

# Permitir SSH (puerto 22 por defecto)
sudo ufw allow ssh
# Permitir HTTP (puerto 80)
sudo ufw allow http
# Permitir HTTPS (puerto 443)
sudo ufw allow https
# Permitir el protocolo nativo de ClickHouse (puerto 9000 por defecto)
sudo ufw allow 9000/tcp
# Permitir la interfaz HTTP de ClickHouse (puerto 8123 por defecto)
sudo ufw allow 8123/tcp
# Habilitar el firewall
sudo ufw enable
# Verificar el estado del firewall
sudo ufw status verbose

6. Instalación de Fail2Ban

Fail2Ban ayuda a proteger el servidor contra ataques de fuerza bruta, bloqueando las direcciones IP desde las cuales se producen múltiples intentos fallidos de inicio de sesión.

# Instalación de Fail2Ban
sudo apt install -y fail2ban
# Iniciar y habilitar el inicio automático
sudo systemctl enable fail2ban
sudo systemctl start fail2ban
# Verificar el estado
sudo systemctl status fail2ban

Fail2Ban protege SSH por defecto. Para servicios adicionales, se puede configurar en /etc/fail2ban/jail.local.

Instalación de software — paso a paso

Instalación de software — paso a paso

Ahora que el servidor está preparado, procedamos con la instalación de ClickHouse. Utilizaremos el repositorio oficial de ClickHouse para Ubuntu 24.04 para obtener la versión más reciente (para 2026, asumiremos que será la versión 25.8).

1. Adición del repositorio oficial de ClickHouse

Añadiremos la clave GPG del repositorio y el repositorio mismo a la lista de fuentes de paquetes APT.

# Устанавливаем пакеты для работы с HTTPS-репозиториями
sudo apt install -y apt-transport-https ca-certificates dirmngr
# Добавляем GPG-ключ ClickHouse
sudo gpg --no-default-keyring --keyring /usr/share/keyrings/clickhouse.gpg --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 8F24D2886737F059
# Добавляем репозиторий ClickHouse для стабильной ветки
echo "deb [signed-by=/usr/share/keyrings/clickhouse.gpg] https://packages.clickhouse.com/deb stable main" | sudo tee /etc/apt/sources.list.d/clickhouse.list
# Обновляем список пакетов
sudo apt update

2. Instalación de ClickHouse Server y Client

Instalaremos la parte del servidor de ClickHouse y el cliente para interactuar con él.

# Устанавливаем ClickHouse Server и Client (версия 25.8 или новее будет выбрана автоматически из репозитория)
sudo apt install -y clickhouse-server clickhouse-client

3. Inicio y verificación del estado de ClickHouse

Después de la instalación, ClickHouse debería iniciarse automáticamente. Verificaremos su estado.

# Проверяем статус сервиса ClickHouse
sudo systemctl status clickhouse-server

Debería ver el estado active (running). Si no, inícielo manualmente:

# Запускаем сервис ClickHouse
sudo systemctl start clickhouse-server
# Включаем автозапуск при загрузке системы
sudo systemctl enable clickhouse-server

4. Conexión a ClickHouse a través del cliente

Intentaremos conectarnos al servidor a través del cliente CLI.

# Подключаемся к локальному серверу ClickHouse
clickhouse-client

Debería ver el mensaje ClickHouse client version 25.8.x.x. Connected to ClickHouse server version 25.8.x.x.. Ahora puede ejecutar consultas. Por ejemplo:

# Создаем тестовую базу данных
CREATE DATABASE my_database;
# Создаем тестовую таблицу
CREATE TABLE my_database.test_table (id UInt64, name String) ENGINE = MergeTree() ORDER BY id;
# Вставляем данные
INSERT INTO my_database.test_table VALUES (1, 'Test User 1'), (2, 'Test User 2');
# Выбираем данные
SELECT * FROM my_database.test_table;
# Выходим из клиента
exit;

5. Verificación de la disponibilidad de la interfaz HTTP

ClickHouse también proporciona una interfaz HTTP, que por defecto está disponible en el puerto 8123.

# Проверяем доступность HTTP-интерфейса
curl http://localhost:8123/

Debería recibir una respuesta "Ok." o similar, indicando que la interfaz funciona correctamente.

Configuración

La instalación básica de ClickHouse está lista, pero para uso en producción y para garantizar la seguridad, se requiere una configuración adicional. Los archivos de configuración principales de ClickHouse se encuentran en /etc/clickhouse-server/.

• config.xml: Archivo de configuración principal del servidor.
• users.xml: Configuración de usuarios, roles y permisos de acceso.
• conf.d/: Directorio para archivos de configuración adicionales que sobrescriben o complementan config.xml. Esto permite gestionar fácilmente los cambios y las actualizaciones.

1. Configuración principal (config.xml y conf.d)

Se recomienda no modificar directamente config.xml, sino crear sus propios archivos en /etc/clickhouse-server/conf.d/. Por ejemplo, crearemos el archivo z-custom-config.xml para nuestras configuraciones. Los archivos en conf.d se cargan en orden alfabético, por lo que el prefijo z- garantiza que nuestras configuraciones se apliquen al final y sobrescriban las estándar.

sudo nano /etc/clickhouse-server/conf.d/z-custom-config.xml

Ejemplo de contenido para z-custom-config.xml:

<yandex>
    <logger>
        <level>information</level>
        <log>/var/log/clickhouse-server/clickhouse-server.log</log>
        <errorlog>/var/log/clickhouse-server/clickhouse-server.err.log</errorlog>
        <size_limit>100M</size_limit>
        <count>10</count>
    </logger>

    <listen_host>0.0.0.0</listen_host> <!-- Escuchar todas las interfaces, para producción es mejor especificar una IP concreta -->
    <max_memory_usage>0</max_memory_usage> <!-- 0 significa sin límites, o capacidad de RAM  0.8 -->
    <max_memory_usage_for_all_queries>0</max_memory_usage_for_all_queries>

    <query_log>
        <database>system</database>
        <table>query_log</table>
        <flush_interval_milliseconds>7500</flush_interval_milliseconds>
    </query_log>

    <query_thread_log>
        <database>system</database>
        <table>query_thread_log</table>
        <flush_interval_milliseconds>7500</flush_interval_milliseconds>
    </query_thread_log>

    <merge_tree>
        <max_bytes_to_merge_at_once>16106127360</max_bytes_to_merge_at_once> <!-- 15GB -->
        <max_rows_to_merge_at_once>10000000</max_rows_to_merge_at_once>
    </merge_tree>

    <tcp_port_secure>9440</tcp_port_secure> <!-- Puerto para conexiones TLS (protocolo nativo) -->
    <http_port_secure>8443</http_port_secure> <!-- Puerto para conexiones TLS (HTTP) -->
</yandex>

Nota: Para listen_host en producción, es mejor especificar una dirección IP de servidor concreta o una IP interna si ClickHouse está detrás de un proxy/balanceador. max_memory_usage y max_memory_usage_for_all_queries se deben configurar en función de la cantidad real de RAM y la carga, para evitar el desbordamiento de memoria.

2. Configuración de usuarios y seguridad (users.xml)

El archivo users.xml (o los archivos en users.d/) define los usuarios, sus contraseñas, permisos y configuraciones. Por defecto, existe un usuario default sin contraseña, lo cual es extremadamente inseguro.

sudo nano /etc/clickhouse-server/users.d/z-custom-users.xml

Ejemplo de contenido de z-custom-users.xml:

<yandex>
    <users>
        <default>
            <!-- Deshabilitamos el usuario 'default' si no es necesario, o le asignamos una contraseña -->
            <password>your_strong_default_password</password>
            <networks>
                <ip>::/0</ip>
            </networks>
            <profile>default</profile>
            <quota>default</quota>
        </default>

        <admin>
            <password>your_admin_password_here</password>
            <networks>
                <ip>127.0.0.1</ip>
                <ip>::1</ip>
                <ip>SU_IP_DESDE_LA_QUE_SE_CONECTARÁ/32</ip> <!-- o 0.0.0.0/0 para todos, pero esto es inseguro -->
            </networks>
            <profile>default</profile>
            <quota>default</quota>
        </admin>

        <app_user>
            <password>your_app_password_here</password>
            <networks>
                <ip>SU_IP_DE_APLICACIÓN/32</ip>
            </networks>
            <profile>default</profile>
            <quota>default</quota>
            <access_management>
                <grant>SELECT ON my_database. TO app_user</grant>
                <grant>INSERT ON my_database.some_table TO app_user</grant>
            </access_management>
        </app_user>
    </users>
</yandex>

# Instalación de Caddy
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install -y caddy

sudo nano /etc/caddy/Caddyfile

clickhouse.yourdomain.com {
    reverse_proxy localhost:8123
    tls {
        protocols tls1.2 tls1.3
        ciphers ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-GCM-SHA384
    }
    # Opcional: autenticación básica para acceder a la interfaz HTTP
    # basicauth {
    #     admin Jaffe_1234
    # }
}

sudo systemctl reload caddy

# Creamos el directorio para los certificados de ClickHouse
sudo mkdir -p /etc/clickhouse-server/ssl
# Copiamos los certificados (reemplace con sus rutas y dominio)
# Ejemplo para Caddy:
sudo cp /var/lib/caddy/.local/share/caddy/certificates/acme-v02.api.letsencrypt.org-directory/clickhouse.yourdomain.com/clickhouse.yourdomain.com.crt /etc/clickhouse-server/ssl/server.crt
sudo cp /var/lib/caddy/.local/share/caddy/certificates/acme-v02.api.letsencrypt.org-directory/clickhouse.yourdomain.com/clickhouse.yourdomain.com.key /etc/clickhouse-server/ssl/server.key
# Establecemos los permisos correctos
sudo chown -R clickhouse:clickhouse /etc/clickhouse-server/ssl
sudo chmod -R 600 /etc/clickhouse-server/ssl/

Agregue a /etc/clickhouse-server/conf.d/z-custom-config.xml (o cree un archivo separado, por ejemplo, ssl.xml):

<yandex>
    <openSSL>
        <server>
            <certificate_file>/etc/clickhouse-server/ssl/server.crt</certificate_file>
            <private_key_file>/etc/clickhouse-server/ssl/server.key</private_key_file>
            <dh_params_file>/etc/clickhouse-server/ssl/dhparam.pem</dh_params_file> <!-- Opcional, pero recomendado -->
            <verification_mode>none</verification_mode> <!-- 'none' para autofirmados, 'relaxed'/'strict' para CA -->
            <load_common_names>true</load_common_names>
            <cache_sessions>true</cache_sessions>
            <disable_protocols>sslv2,sslv3,tlsv1,tlsv1_1</disable_protocols>
            <prefer_server_ciphers>true</prefer_server_ciphers>
            <ciphers>ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256</ciphers>
        </server>
        <client>
            <verification_mode>none</verification_mode>
        </client>
    </openSSL>
</yandex>

Genere dhparam.pem (esto puede llevar algún tiempo):

sudo openssl dhparam -out /etc/clickhouse-server/ssl/dhparam.pem 2048
sudo chown clickhouse:clickhouse /etc/clickhouse-server/ssl/dhparam.pem
sudo chmod 600 /etc/clickhouse-server/ssl/dhparam.pem

Después de todos los cambios, reinicie ClickHouse:

sudo systemctl restart clickhouse-server

5. Verificación de la operatividad

Verificación HTTP/HTTPS:

# Verificación de la interfaz HTTP a través de Caddy
curl -k https://clickhouse.yourdomain.com/

Debería recibir "Ok.". Si configuró basicauth, debe agregar -u admin:password.

Verificación del protocolo nativo con TLS:

clickhouse-client --host localhost --port 9440 --secure --user admin --password your_admin_password_here

Debería conectarse con éxito. Si surgen problemas con TLS, revise los registros de ClickHouse (/var/log/clickhouse-server/clickhouse-server.err.log).

Copias de seguridad y mantenimiento

Las copias de seguridad fiables y el mantenimiento regular son críticos para cualquier sistema en producción, incluyendo ClickHouse.

¿Qué respaldar?

• Datos de ClickHouse: Datos principales de las tablas, almacenados en /var/lib/clickhouse/data/.
• Metadatos de ClickHouse: Estructuras de tablas, bases de datos, usuarios, ubicados en /var/lib/clickhouse/metadata/.
• Archivos de configuración: /etc/clickhouse-server/ (incluyendo config.xml, users.xml y todos los archivos en conf.d/, users.d/).
• Registros (Logs): Aunque los registros no son críticos para la recuperación, son útiles para la auditoría y depuración.

Script simple de copia de seguridad automática

Para ClickHouse, se recomienda utilizar mecanismos integrados, como ALTER TABLE ... FREEZE PARTITION para crear "instantáneas" de datos o herramientas especializadas como clickhouse-backup. Consideraremos un enfoque simple con el sistema de archivos y clickhouse-backup.

Opción 1: Instantánea del sistema de archivos (para entornos de prueba)

Este es el método menos recomendado para producción, pero el más simple para pequeños volúmenes de datos. Requiere detener ClickHouse o usar instantáneas LVM.

#!/bin/bash
BACKUP_DIR="/mnt/backups/clickhouse_$(date +%Y%m%d%H%M%S)"
CLICKHOUSE_DATA_DIR="/var/lib/clickhouse"
CONFIG_DIR="/etc/clickhouse-server"

echo "Stopping ClickHouse server..."
sudo systemctl stop clickhouse-server

echo "Creating backup directory: $BACKUP_DIR"
sudo mkdir -p "$BACKUP_DIR"

echo "Copying ClickHouse data..."
sudo rsync -ah --stats "$CLICKHOUSE_DATA_DIR" "$BACKUP_DIR/"

echo "Copying ClickHouse configuration..."
sudo rsync -ah --stats "$CONFIG_DIR" "$BACKUP_DIR/"

echo "Starting ClickHouse server..."
sudo systemctl start clickhouse-server

echo "Backup completed successfully to $BACKUP_DIR"

Opción 2: Uso de clickhouse-backup

clickhouse-backup es una herramienta especializada para crear y restaurar copias de seguridad de ClickHouse. Soporta varios almacenamientos, incluyendo S3.

Instalación de clickhouse-backup:

# Descarga la última versión (verifica la actual en GitHub)
wget https://github.com/Altinity/clickhouse-backup/releases/download/v1.2.0/clickhouse-backup_1.2.0_amd64.deb
sudo dpkg -i clickhouse-backup_1.2.0_amd64.deb
rm clickhouse-backup_1.2.0_amd64.deb

Configuración de clickhouse-backup (/etc/clickhouse-backup/config.yml):

Configure los parámetros de conexión a ClickHouse y al almacenamiento remoto (por ejemplo, S3).

# Ejemplo /etc/clickhouse-backup/config.yml
clickhouse:
  username: admin # Su usuario de ClickHouse
  password: your_admin_password_here
  host: 127.0.0.1
  port: 9000 # O 9440, si usa TLS
  secure: false # true, si usa TLS

s3:
  bucket: my-clickhouse-backups
  region: us-east-1
  access_key: ${S3_ACCESS_KEY} # Use variables de entorno para los secretos
  secret_key: ${S3_SECRET_KEY}
  endpoint: s3.amazonaws.com # O su endpoint compatible con S3
  force_path_style: false
  acl: private
  compression: "zstd"
  compression_level: 1
  disable_ssl: false
  allow_multipart_download: true
  max_part_size: 100M

Los secretos (S3_ACCESS_KEY, S3_SECRET_KEY) es mejor pasarlos a través de variables de entorno para el script cron.

Script de copia de seguridad con clickhouse-backup:

#!/bin/bash
export S3_ACCESS_KEY="YOUR_ACTUAL_S3_ACCESS_KEY"
export S3_SECRET_KEY="YOUR_ACTUAL_S3_SECRET_KEY"

# Crear una copia de seguridad local
clickhouse-backup create --schema --data
# Enviar la copia de seguridad a S3
clickhouse-backup upload latest --remote-storage s3
# Limpiar copias de seguridad locales antiguas (por ejemplo, mantener las 7 últimas)
clickhouse-backup delete local --keep-days 7
# Limpiar copias de seguridad remotas antiguas (por ejemplo, mantener las 30 últimas)
clickhouse-backup delete remote --keep-days 30 --remote-storage s3

echo "ClickHouse backup completed."

Guarde este script como /usr/local/bin/clickhouse_backup.sh y hágalo ejecutable:

sudo chmod +x /usr/local/bin/clickhouse_backup.sh

Configuración de Cron para el inicio automático:

Agregue una tarea a cron para ejecutar el script diariamente.

sudo crontab -e

Agregue una línea para ejecutar el script, por ejemplo, a las 2 de la mañana:

0 2 * * * /usr/local/bin/clickhouse_backup.sh >> /var/log/clickhouse_backup.log 2>&1

¿Dónde almacenar las copias de seguridad?

• Almacenamiento externo compatible con S3: Opción recomendada. Los almacenamientos en la nube (AWS S3, MinIO, Wasabi, Backblaze B2) ofrecen alta fiabilidad y disponibilidad.
• VPS separado: Se puede configurar rsync o SFTP en un VPS separado, menos potente, dedicado específicamente al almacenamiento de copias de seguridad.
• Almacenamiento en red (NAS/SAN): Para entornos corporativos.

IMPORTANTE: Nunca almacene las copias de seguridad en el mismo servidor que los datos originales.

Actualizaciones: rolling vs maintenance window

La actualización de ClickHouse requiere precaución. Siempre pruebe las actualizaciones en un entorno de staging antes de aplicarlas en producción.

• Maintenance Window (Ventana de mantenimiento): El enfoque más simple. Detenga ClickHouse, actualice los paquetes, inicie. Esto causa una interrupción del servicio. Para la mayoría de las instalaciones de VPS, esto es aceptable si una interrupción de unos pocos minutos es tolerable.

  
  sudo systemctl stop clickhouse-server
  sudo apt update
  sudo apt upgrade -y clickhouse-server clickhouse-client
  sudo systemctl start clickhouse-server
              

• Rolling Updates (Actualizaciones graduales): Para clústeres de ClickHouse con replicación. Permite actualizar los nodos uno por uno, minimizando la interrupción. Esto está fuera del alcance de esta guía, pero es importante conocer esta posibilidad para la escalabilidad.

Después de cada actualización, se recomienda revisar los registros de ClickHouse en busca de errores y asegurarse de que todos los servicios funcionen correctamente.

Solución de problemas + Preguntas frecuentes

¿Qué hacer si ClickHouse no se inicia?

Primero, revise los registros de ClickHouse: /var/log/clickhouse-server/clickhouse-server.log y /var/log/clickhouse-server/clickhouse-server.err.log. Las causas comunes son: errores en los archivos de configuración (sintaxis XML), falta de memoria, puerto ocupado, problemas con los permisos de acceso a los archivos de datos o registros. Use el comando sudo systemctl status clickhouse-server para una visión rápida del estado y los últimos errores.

¿Cómo verificar qué puertos usa ClickHouse?

Por defecto, ClickHouse usa el puerto 9000 para el protocolo nativo y el 8123 para la interfaz HTTP. Si ha configurado TLS, estos pueden ser 9440 y 8443 respectivamente. Puede verificar los puertos en uso con el comando sudo netstat -tulnp | grep clickhouse o sudo lsof -i -P -n | grep LISTEN | grep clickhouse. Asegúrese de que estos puertos estén abiertos en su firewall (UFW).

¿Cómo restablecer la contraseña de un usuario de ClickHouse?

Las contraseñas de los usuarios se almacenan en /etc/clickhouse-server/users.xml o en archivos en /etc/clickhouse-server/users.d/. Para restablecer la contraseña, edite el archivo correspondiente, cambie el valor de la etiqueta <password> para el usuario deseado y reinicie ClickHouse: sudo systemctl restart clickhouse-server. Asegúrese de que la nueva contraseña sea segura.

¿Qué configuración mínima de VPS es adecuada para un proyecto pequeño?

Para un proyecto pequeño, por ejemplo, con datos de hasta 100 GB y baja carga, un VPS con 2-4 núcleos de CPU, 8 GB de RAM y 200 GB de SSD NVMe es suficiente. Sin embargo, si se espera un crecimiento activo de datos o consultas complejas, se recomienda aumentar la RAM a 16-32 GB y utilizar discos NVMe más rápidos y de mayor capacidad.

¿Qué elegir — VPS o dedicado para esta tarea?

Para un despliegue inicial, proyectos pequeños y medianos, así como para aprender ClickHouse, un VPS es una excelente opción económica. Ofrece recursos suficientes y flexibilidad. Un servidor dedicado se vuelve preferible si trabaja con terabytes de datos, requiere el máximo rendimiento del subsistema de disco, tiene altos requisitos de seguridad y aislamiento, o necesita total libertad en la elección del hardware. Esto también es relevante para clústeres de producción de alta carga.

¿Cómo optimizar el rendimiento de ClickHouse?

La optimización de ClickHouse incluye varios aspectos: la elección correcta del motor de tablas (MergeTree y sus variantes), la optimización de los esquemas de datos (almacenamiento columnar, tipos de datos correctos), la indexación (ORDER BY, PRIMARY KEY), la configuración de los parámetros del servidor (por ejemplo, max_memory_usage, max_threads), el uso de vistas materializadas y el almacenamiento en caché, así como la limpieza y fusión regular de particiones.

Conclusiones y próximos pasos

Ha desplegado y configurado ClickHouse con éxito en su VPS, asegurando su seguridad básica y un mecanismo de copia de seguridad. Ahora tiene una potente herramienta para análisis de alto rendimiento, capaz de procesar grandes volúmenes de datos a una velocidad increíble. Este servidor está listo para recibir datos y ejecutar consultas analíticas complejas.

Los siguientes pasos para el desarrollo posterior de su servidor ClickHouse pueden incluir:

• Integración con fuentes de datos: Configure la carga de datos en streaming desde Kafka, RabbitMQ, PostgreSQL, MySQL u otros sistemas utilizando motores de tabla especializados (por ejemplo, Kafka Engine) o herramientas ETL.
• Monitorización: Implemente un sistema de monitorización (por ejemplo, Prometheus + Grafana) para rastrear las métricas de ClickHouse (carga de CPU, uso de memoria, E/S de disco, número de consultas, latencias) y la salud general del servidor.
• Escalabilidad y alta disponibilidad: Para sistemas en producción, considere la creación de un clúster de ClickHouse con replicación de datos (utilizando ZooKeeper o ClickHouse Keeper) y sharding para la escalabilidad horizontal y la garantía de tolerancia a fallos.