En este ejemplo, aprenderá a configurar un clúster sencillo de ClickHouse que replica y escala. Consta de dos segmentos y dos réplicas, con un clúster de 3 nodos de ClickHouse Keeper para gestionar la coordinación y mantener el cuórum en el clúster.
La arquitectura del clúster que va a configurar se muestra a continuación:

Requisitos previos
- Ya has configurado previamente un servidor ClickHouse local
- Estás familiarizado con conceptos básicos de configuración de ClickHouse, como los archivos de configuración
- Tienes Docker instalado en tu equipo
Configurar la estructura de directorios y el entorno de prueba
En este tutorial, utilizará Docker compose para configurar el clúster de ClickHouse. Esta configuración puede adaptarse para funcionar también con máquinas locales independientes, máquinas virtuales o instancias en la nube.
Ejecute los siguientes comandos para configurar la estructura de directorios de este ejemplo:
mkdir cluster_2S_2R
cd cluster_2S_2R
# Create clickhouse-keeper directories
for i in {01..03}; do
mkdir -p fs/volumes/clickhouse-keeper-${i}/etc/clickhouse-keeper
done
# Create clickhouse-server directories
for i in {01..04}; do
mkdir -p fs/volumes/clickhouse-${i}/etc/clickhouse-server
doneAñada el siguiente archivo docker-compose.yml al directorio clickhouse-cluster:
version: '3.8'
services:
clickhouse-01:
image: "clickhouse/clickhouse-server:latest"
user: "101:101"
container_name: clickhouse-01
hostname: clickhouse-01
volumes:
- ${PWD}/fs/volumes/clickhouse-01/etc/clickhouse-server/config.d/config.xml:/etc/clickhouse-server/config.d/config.xml
- ${PWD}/fs/volumes/clickhouse-01/etc/clickhouse-server/users.d/users.xml:/etc/clickhouse-server/users.d/users.xml
ports:
- "127.0.0.1:8123:8123"
- "127.0.0.1:9000:9000"
depends_on:
- clickhouse-keeper-01
- clickhouse-keeper-02
- clickhouse-keeper-03
clickhouse-02:
image: "clickhouse/clickhouse-server:latest"
user: "101:101"
container_name: clickhouse-02
hostname: clickhouse-02
volumes:
- ${PWD}/fs/volumes/clickhouse-02/etc/clickhouse-server/config.d/config.xml:/etc/clickhouse-server/config.d/config.xml
- ${PWD}/fs/volumes/clickhouse-02/etc/clickhouse-server/users.d/users.xml:/etc/clickhouse-server/users.d/users.xml
ports:
- "127.0.0.1:8124:8123"
- "127.0.0.1:9001:9000"
depends_on:
- clickhouse-keeper-01
- clickhouse-keeper-02
- clickhouse-keeper-03
clickhouse-03:
image: "clickhouse/clickhouse-server:latest"
user: "101:101"
container_name: clickhouse-03
hostname: clickhouse-03
volumes:
- ${PWD}/fs/volumes/clickhouse-03/etc/clickhouse-server/config.d/config.xml:/etc/clickhouse-server/config.d/config.xml
- ${PWD}/fs/volumes/clickhouse-03/etc/clickhouse-server/users.d/users.xml:/etc/clickhouse-server/users.d/users.xml
ports:
- "127.0.0.1:8125:8123"
- "127.0.0.1:9002:9000"
depends_on:
- clickhouse-keeper-01
- clickhouse-keeper-02
- clickhouse-keeper-03
clickhouse-04:
image: "clickhouse/clickhouse-server:latest"
user: "101:101"
container_name: clickhouse-04
hostname: clickhouse-04
volumes:
- ${PWD}/fs/volumes/clickhouse-04/etc/clickhouse-server/config.d/config.xml:/etc/clickhouse-server/config.d/config.xml
- ${PWD}/fs/volumes/clickhouse-04/etc/clickhouse-server/users.d/users.xml:/etc/clickhouse-server/users.d/users.xml
ports:
- "127.0.0.1:8126:8123"
- "127.0.0.1:9003:9000"
depends_on:
- clickhouse-keeper-01
- clickhouse-keeper-02
- clickhouse-keeper-03
clickhouse-keeper-01:
image: "clickhouse/clickhouse-keeper:latest-alpine"
user: "101:101"
container_name: clickhouse-keeper-01
hostname: clickhouse-keeper-01
volumes:
- ${PWD}/fs/volumes/clickhouse-keeper-01/etc/clickhouse-keeper/keeper_config.xml:/etc/clickhouse-keeper/keeper_config.xml
ports:
- "127.0.0.1:9181:9181"
clickhouse-keeper-02:
image: "clickhouse/clickhouse-keeper:latest-alpine"
user: "101:101"
container_name: clickhouse-keeper-02
hostname: clickhouse-keeper-02
volumes:
- ${PWD}/fs/volumes/clickhouse-keeper-02/etc/clickhouse-keeper/keeper_config.xml:/etc/clickhouse-keeper/keeper_config.xml
ports:
- "127.0.0.1:9182:9181"
clickhouse-keeper-03:
image: "clickhouse/clickhouse-keeper:latest-alpine"
user: "101:101"
container_name: clickhouse-keeper-03
hostname: clickhouse-keeper-03
volumes:
- ${PWD}/fs/volumes/clickhouse-keeper-03/etc/clickhouse-keeper/keeper_config.xml:/etc/clickhouse-keeper/keeper_config.xml
ports:
- "127.0.0.1:9183:9181"Cree los siguientes subdirectorios y archivos:
for i in {01..04}; do
mkdir -p fs/volumes/clickhouse-${i}/etc/clickhouse-server/config.d
mkdir -p fs/volumes/clickhouse-${i}/etc/clickhouse-server/users.d
touch fs/volumes/clickhouse-${i}/etc/clickhouse-server/config.d/config.xml
touch fs/volumes/clickhouse-${i}/etc/clickhouse-server/users.d/users.xml
done- El directorio
config.dcontiene el archivo de configuración del servidor ClickHouseconfig.xml, en el que se define la configuración personalizada de cada nodo de ClickHouse. Esta configuración se combina con el archivo de configuración predeterminadoconfig.xmlde ClickHouse, incluido en cada instalación de ClickHouse. - El directorio
users.dcontiene el archivo de configuración de usuariosusers.xml, en el que se define la configuración personalizada para los usuarios. Esta configuración se combina con el archivo de configuración predeterminadousers.xmlde ClickHouse, incluido en cada instalación de ClickHouse.
Configurar nodos de ClickHouse
Configuración del servidor
Ahora modifique cada archivo de configuración vacío config.xml ubicado en
fs/volumes/clickhouse-{}/etc/clickhouse-server/config.d. Las líneas resaltadas
a continuación deben ajustarse para que sean específicas de cada nodo:
<clickhouse replace="true">
<logger>
<level>debug</level>
<log>/var/log/clickhouse-server/clickhouse-server.log</log>
<errorlog>/var/log/clickhouse-server/clickhouse-server.err.log</errorlog>
<size>1000M</size>
<count>3</count>
</logger>
<display_name>cluster_2S_2R node 1</display_name>
<listen_host>0.0.0.0</listen_host>
<http_port>8123</http_port>
<tcp_port>9000</tcp_port>
<user_directories>
<users_xml>
<path>users.xml</path>
</users_xml>
<local_directory>
<path>/var/lib/clickhouse/access/</path>
</local_directory>
</user_directories>
<distributed_ddl>
<path>/clickhouse/task_queue/ddl</path>
</distributed_ddl>
<remote_servers>
<cluster_2S_2R>
<shard>
<internal_replication>true</internal_replication>
<replica>
<host>clickhouse-01</host>
<port>9000</port>
</replica>
<replica>
<host>clickhouse-03</host>
<port>9000</port>
</replica>
</shard>
<shard>
<internal_replication>true</internal_replication>
<replica>
<host>clickhouse-02</host>
<port>9000</port>
</replica>
<replica>
<host>clickhouse-04</host>
<port>9000</port>
</replica>
</shard>
</cluster_2S_2R>
</remote_servers>
<zookeeper>
<node>
<host>clickhouse-keeper-01</host>
<port>9181</port>
</node>
<node>
<host>clickhouse-keeper-02</host>
<port>9181</port>
</node>
<node>
<host>clickhouse-keeper-03</host>
<port>9181</port>
</node>
</zookeeper>
<macros>
<shard>01</shard>
<replica>01</replica>
</macros>
</clickhouse>| Directorio | File |
|---|---|
fs/volumes/clickhouse-01/etc/clickhouse-server/config.d |
config.xml |
fs/volumes/clickhouse-02/etc/clickhouse-server/config.d |
config.xml |
fs/volumes/clickhouse-03/etc/clickhouse-server/config.d |
config.xml |
fs/volumes/clickhouse-04/etc/clickhouse-server/config.d |
config.xml |
Cada sección del archivo de configuración anterior se explica con más detalle a continuación.
Redes y logging
La comunicación externa a través de la interfaz de red se habilita al activar la configuración de listen host. Esto garantiza que el host del servidor ClickHouse sea accesible desde otros hosts:
<listen_host>0.0.0.0</listen_host>El puerto de la API HTTP está configurado como 8123:
<http_port>8123</http_port>El puerto TCP para la comunicación mediante el protocolo nativo de ClickHouse entre clickhouse-client
y otras herramientas nativas de ClickHouse, y clickhouse-server y otros clickhouse-servers
está configurado en 9000:
<tcp_port>9000</tcp_port>La configuración de logging se define en el bloque <logger>. Esta configuración de ejemplo
genera un log de depuración que rotará cada 1000 M un máximo de tres veces:
<logger>
<level>debug</level>
<log>/var/log/clickhouse-server/clickhouse-server.log</log>
<errorlog>/var/log/clickhouse-server/clickhouse-server.err.log</errorlog>
<size>1000M</size>
<count>3</count>
</logger>Para obtener más información sobre la configuración de logging, consulte los comentarios incluidos en el archivo de configuración predeterminado de ClickHouse.
Configuración del clúster
La configuración del clúster se establece en el bloque <remote_servers>.
Aquí se define el nombre del clúster cluster_2S_2R.
El bloque <cluster_2S_2R></cluster_2S_2R> define el layout del clúster
mediante las configuraciones <shard></shard> y <replica></replica>, y actúa como
plantilla para las consultas DDL distribuidas, es decir, consultas que se ejecutan en todo el
clúster mediante la cláusula ON CLUSTER. De forma predeterminada, las consultas DDL distribuidas
están permitidas, pero también se pueden deshabilitar con la configuración allow_distributed_ddl_queries.
internal_replication se establece en true para que los datos se escriban en una única réplica.
<remote_servers>
<!-- cluster name (should not contain dots) -->
<cluster_2S_2R>
<!-- <allow_distributed_ddl_queries>false</allow_distributed_ddl_queries> -->
<shard>
<!-- Optional. Whether to write data to just one of the replicas. Default: false (write data to all replicas). -->
<internal_replication>true</internal_replication>
<replica>
<host>clickhouse-01</host>
<port>9000</port>
</replica>
<replica>
<host>clickhouse-03</host>
<port>9000</port>
</replica>
</shard>
<shard>
<internal_replication>true</internal_replication>
<replica>
<host>clickhouse-02</host>
<port>9000</port>
</replica>
<replica>
<host>clickhouse-04</host>
<port>9000</port>
</replica>
</shard>
</cluster_2S_2R>
</remote_servers>La sección <cluster_2S_2R></cluster_2S_2R> define la estructura del cluster
y actúa como plantilla para las distributed DDL queries, es decir, queries que se ejecutan
en todo el cluster mediante la cláusula ON CLUSTER.
Configuración de Keeper
La sección <ZooKeeper> indica a ClickHouse dónde se está ejecutando ClickHouse Keeper (o ZooKeeper).
Como estamos utilizando un cluster de ClickHouse Keeper, es necesario especificar cada <node> del cluster,
junto con su hostname y número de puerto mediante las etiquetas <host> y <port> respectivamente.
La configuración de ClickHouse Keeper se explica en el siguiente paso del tutorial.
<zookeeper>
<node>
<host>clickhouse-keeper-01</host>
<port>9181</port>
</node>
<node>
<host>clickhouse-keeper-02</host>
<port>9181</port>
</node>
<node>
<host>clickhouse-keeper-03</host>
<port>9181</port>
</node>
</zookeeper>Configuración de macros
Además, la sección <macros> se utiliza para definir sustituciones de parámetros para
tablas replicadas. Estas aparecen listadas en system.macros y permiten usar sustituciones
como {shard} y {replica} en las consultas.
<macros>
<shard>01</shard>
<replica>01</replica>
</macros>Configuración de usuario
Ahora modifique cada archivo de configuración vacío users.xml ubicado en
fs/volumes/clickhouse-{}/etc/clickhouse-server/users.d con el siguiente contenido:
<?xml version="1.0"?>
<clickhouse replace="true">
<profiles>
<default>
<max_memory_usage>10000000000</max_memory_usage>
<use_uncompressed_cache>0</use_uncompressed_cache>
<load_balancing>in_order</load_balancing>
<log_queries>1</log_queries>
</default>
</profiles>
<users>
<default>
<access_management>1</access_management>
<profile>default</profile>
<networks>
<ip>::/0</ip>
</networks>
<quota>default</quota>
<access_management>1</access_management>
<named_collection_control>1</named_collection_control>
<show_named_collections>1</show_named_collections>
<show_named_collections_secrets>1</show_named_collections_secrets>
</default>
</users>
<quotas>
<default>
<interval>
<duration>3600</duration>
<queries>0</queries>
<errors>0</errors>
<result_rows>0</result_rows>
<read_rows>0</read_rows>
<execution_time>0</execution_time>
</interval>
</default>
</quotas>
</clickhouse>En este ejemplo, el usuario default está configurado sin contraseña para simplificar.
En la práctica, esto no es recomendable.
Configurar ClickHouse Keeper
A continuación, configure ClickHouse Keeper, que se usa para la coordinación.
Configuración de Keeper
Para que la replicación funcione, es necesario configurar un clúster de ClickHouse Keeper. ClickHouse Keeper proporciona el sistema de coordinación para la replicación de datos y actúa como reemplazo directo de ZooKeeper, que también podría utilizarse. No obstante, se recomienda ClickHouse Keeper, ya que ofrece mejores garantías y fiabilidad, además de utilizar menos recursos que ZooKeeper. Para lograr alta disponibilidad y mantener el quorum, se recomienda ejecutar al menos tres nodos de ClickHouse Keeper.
Cree los archivos keeper_config.xml para cada nodo de ClickHouse Keeper
con el siguiente comando desde la raíz de la carpeta de ejemplo:
for i in {01..03}; do
touch fs/volumes/clickhouse-keeper-${i}/etc/clickhouse-keeper/keeper_config.xml
doneModifique los archivos de configuración vacíos que se crearon en el
directorio de cada nodo fs/volumes/clickhouse-keeper-{}/etc/clickhouse-keeper. Las
líneas resaltadas a continuación deben modificarse para que sean específicas de cada nodo:
<clickhouse replace="true">
<logger>
<level>information</level>
<log>/var/log/clickhouse-keeper/clickhouse-keeper.log</log>
<errorlog>/var/log/clickhouse-keeper/clickhouse-keeper.err.log</errorlog>
<size>1000M</size>
<count>3</count>
</logger>
<listen_host>0.0.0.0</listen_host>
<keeper_server>
<tcp_port>9181</tcp_port>
<server_id>1</server_id>
<log_storage_path>/var/lib/clickhouse/coordination/log</log_storage_path>
<snapshot_storage_path>/var/lib/clickhouse/coordination/snapshots</snapshot_storage_path>
<coordination_settings>
<operation_timeout_ms>10000</operation_timeout_ms>
<session_timeout_ms>30000</session_timeout_ms>
<raft_logs_level>information</raft_logs_level>
</coordination_settings>
<raft_configuration>
<server>
<id>1</id>
<hostname>clickhouse-keeper-01</hostname>
<port>9234</port>
</server>
<server>
<id>2</id>
<hostname>clickhouse-keeper-02</hostname>
<port>9234</port>
</server>
<server>
<id>3</id>
<hostname>clickhouse-keeper-03</hostname>
<port>9234</port>
</server>
</raft_configuration>
</keeper_server>
</clickhouse>| Directorio | Archivo |
|---|---|
fs/volumes/clickhouse-keeper-01/etc/clickhouse-keeper |
keeper_config.xml |
fs/volumes/clickhouse-keeper-02/etc/clickhouse-keeper |
keeper_config.xml |
fs/volumes/clickhouse-keeper-03/etc/clickhouse-keeper |
keeper_config.xml |
Cada archivo de configuración contendrá la siguiente configuración única (que se muestra a continuación).
El server_id utilizado debe ser único para ese nodo específico de ClickHouse Keeper
en el clúster y coincidir con el <id> del servidor definido en la sección <raft_configuration>.
tcp_port es el puerto que utilizan los clientes de ClickHouse Keeper.
<tcp_port>9181</tcp_port>
<server_id>{id}</server_id>La siguiente sección se utiliza para configurar los servidores que participan en el quórum del algoritmo de consenso Raft:
<raft_configuration>
<server>
<id>1</id>
<hostname>clickhouse-keeper-01</hostname>
<!-- Puerto TCP utilizado para la comunicación entre nodos de ClickHouse Keeper -->
<port>9234</port>
</server>
<server>
<id>2</id>
<hostname>clickhouse-keeper-02</hostname>
<port>9234</port>
</server>
<server>
<id>3</id>
<hostname>clickhouse-keeper-03</hostname>
<port>9234</port>
</server>
</raft_configuration>Prueba la configuración
Asegúrate de que Docker esté ejecutándose en tu equipo.
Inicia el clúster con el comando docker-compose up desde la raíz del directorio cluster_2S_2R:
docker-compose up -dDeberías ver que docker empieza a descargar las imágenes de ClickHouse y Keeper, y, a continuación, inicia los contenedores:
[+] Running 8/8
✔ Network cluster_2s_2r_default Created
✔ Container clickhouse-keeper-03 Started
✔ Container clickhouse-keeper-02 Started
✔ Container clickhouse-keeper-01 Started
✔ Container clickhouse-01 Started
✔ Container clickhouse-02 Started
✔ Container clickhouse-04 Started
✔ Container clickhouse-03 StartedPara verificar que el clúster está funcionando, conéctese a cualquiera de los nodos y ejecute la siguiente consulta. A continuación se muestra el comando para conectarse al primer nodo:
# Connect to any node
docker exec -it clickhouse-01 clickhouse-clientSi todo ha ido bien, verás el indicador del cliente de ClickHouse:
cluster_2S_2R node 1 :)Ejecute la siguiente consulta para comprobar qué topologías de clúster están definidas en qué hosts:
SELECT
cluster,
shard_num,
replica_num,
host_name,
port
FROM system.clusters; ┌─cluster───────┬─shard_num─┬─replica_num─┬─host_name─────┬─port─┐
1. │ cluster_2S_2R │ 1 │ 1 │ clickhouse-01 │ 9000 │
2. │ cluster_2S_2R │ 1 │ 2 │ clickhouse-03 │ 9000 │
3. │ cluster_2S_2R │ 2 │ 1 │ clickhouse-02 │ 9000 │
4. │ cluster_2S_2R │ 2 │ 2 │ clickhouse-04 │ 9000 │
5. │ default │ 1 │ 1 │ localhost │ 9000 │
└───────────────┴───────────┴─────────────┴───────────────┴──────┘Ejecute la siguiente consulta para comprobar el estado del clúster de ClickHouse Keeper:
SELECT *
FROM system.zookeeper
WHERE path IN ('/', '/clickhouse') ┌─name───────┬─value─┬─path────────┐
1. │ task_queue │ │ /clickhouse │
2. │ sessions │ │ /clickhouse │
3. │ keeper │ │ / │
4. │ clickhouse │ │ / │
└────────────┴───────┴─────────────┘El comando mntr también se usa habitualmente para verificar que ClickHouse Keeper
está en ejecución y para obtener información sobre el estado de la relación entre los tres nodos de Keeper.
En la configuración utilizada en este ejemplo, hay tres nodos que trabajan juntos.
Los nodos elegirán un líder y los nodos restantes serán followers.
El comando mntr proporciona información relacionada con el rendimiento y con si un nodo
determinado es follower o leader.
Ejecute el siguiente comando desde un shell en clickhouse-keeper-01, clickhouse-keeper-02 y
clickhouse-keeper-03 para comprobar el estado de cada nodo de Keeper. El comando
para clickhouse-keeper-01 se muestra a continuación:
docker exec -it clickhouse-keeper-01 /bin/sh -c 'echo mntr | nc 127.0.0.1 9181'A continuación se muestra un ejemplo de respuesta de un nodo seguidor:
zk_version v23.3.1.2823-testing-46e85357ce2da2a99f56ee83a079e892d7ec3726
zk_avg_latency 0
zk_max_latency 0
zk_min_latency 0
zk_packets_received 0
zk_packets_sent 0
zk_num_alive_connections 0
zk_outstanding_requests 0
zk_server_state follower
zk_znode_count 6
zk_watch_count 0
zk_ephemerals_count 0
zk_approximate_data_size 1271
zk_key_arena_size 4096
zk_latest_snapshot_size 0
zk_open_file_descriptor_count 46
zk_max_file_descriptor_count 18446744073709551615A continuación se muestra un ejemplo de respuesta de un nodo líder:
zk_version v23.3.1.2823-testing-46e85357ce2da2a99f56ee83a079e892d7ec3726
zk_avg_latency 0
zk_max_latency 0
zk_min_latency 0
zk_packets_received 0
zk_packets_sent 0
zk_num_alive_connections 0
zk_outstanding_requests 0
zk_server_state leader
zk_znode_count 6
zk_watch_count 0
zk_ephemerals_count 0
zk_approximate_data_size 1271
zk_key_arena_size 4096
zk_latest_snapshot_size 0
zk_open_file_descriptor_count 48
zk_max_file_descriptor_count 18446744073709551615
zk_followers 2
zk_synced_followers 2Con esto, has configurado correctamente un clúster de ClickHouse con dos segmentos y dos réplicas. En el siguiente paso, crearás una tabla en el clúster.
Crear una base de datos
Ahora que ha verificado que el clúster está correctamente configurado y en funcionamiento, volverá a crear la misma tabla que se usa en el tutorial del conjunto de datos de ejemplo de precios de propiedades del Reino Unido. Consta de alrededor de 30 millones de filas con precios pagados por propiedades inmobiliarias en Inglaterra y Gales desde 1995.
Conéctese al cliente de cada host ejecutando cada uno de los siguientes comandos desde pestañas o ventanas de terminal independientes:
docker exec -it clickhouse-01 clickhouse-client
docker exec -it clickhouse-02 clickhouse-client
docker exec -it clickhouse-03 clickhouse-client
docker exec -it clickhouse-04 clickhouse-clientPuedes ejecutar la consulta siguiente desde clickhouse-client de cada host para confirmar que todavía no se ha creado ninguna base de datos,
aparte de las predeterminadas:
SHOW DATABASES; ┌─name───────────────┐
1. │ INFORMATION_SCHEMA │
2. │ default │
3. │ information_schema │
4. │ system │
└────────────────────┘Desde el cliente clickhouse-01, ejecute la siguiente consulta DDL distribuida con la cláusula
ON CLUSTER para crear una nueva base de datos llamada uk:
CREATE DATABASE IF NOT EXISTS uk
ON CLUSTER cluster_2S_2R;Puedes volver a ejecutar la misma consulta que antes desde el cliente de cada host
para confirmar que la base de datos se ha creado en todo el clúster, a pesar de haber ejecutado
la consulta solo desde clickhouse-01:
SHOW DATABASES; ┌─name───────────────┐
1. │ INFORMATION_SCHEMA │
2. │ default │
3. │ information_schema │
4. │ system │
5. │ uk │
└────────────────────┘Crear una tabla en el clúster
Ahora que ya se ha creado la base de datos, el siguiente paso es crear una tabla con replicación.
Ejecute la siguiente consulta desde cualquiera de los clientes host:
CREATE TABLE IF NOT EXISTS uk.uk_price_paid_local
ON CLUSTER cluster_2S_2R
(
price UInt32,
date Date,
postcode1 LowCardinality(String),
postcode2 LowCardinality(String),
type Enum8('terraced' = 1, 'semi-detached' = 2, 'detached' = 3, 'flat' = 4, 'other' = 0),
is_new UInt8,
duration Enum8('freehold' = 1, 'leasehold' = 2, 'unknown' = 0),
addr1 String,
addr2 String,
street LowCardinality(String),
locality LowCardinality(String),
town LowCardinality(String),
district LowCardinality(String),
county LowCardinality(String)
)
ENGINE = ReplicatedMergeTree('/clickhouse/tables/{database}/{table}/{shard}', '{replica}')
ORDER BY (postcode1, postcode2, addr1, addr2);Observe que es idéntica a la consulta utilizada en la instrucción CREATE original del tutorial del
conjunto de datos de ejemplo precios de propiedades del Reino Unido,
excepto por la cláusula ON CLUSTER y el uso del motor ReplicatedMergeTree.
La cláusula ON CLUSTER está diseñada para la ejecución distribuida de consultas DDL (Data Definition Language)
como CREATE, DROP, ALTER y RENAME, lo que garantiza que estos
cambios de esquema se apliquen en todos los nodos de un clúster.
El motor
ReplicatedMergeTree
funciona igual que el motor de tabla MergeTree convencional, pero también replicará los datos.
Requiere que se especifiquen dos parámetros:
zoo_path: La ruta de Keeper/ZooKeeper a los metadatos de la tabla.replica_name: El nombre de la réplica de la tabla.
El parámetro zoo_path puede establecerse con cualquier valor que elija, aunque se recomienda seguir
la convención de usar el prefijo
/clickhouse/tables/{shard}/{database}/{table}donde:
{database}y{table}se reemplazarán automáticamente.{shard}y{replica}son macros que se definieron previamente en el archivoconfig.xmlde cada nodo de ClickHouse.
Puede ejecutar la consulta siguiente desde el cliente de cada host para confirmar que la tabla se ha creado en todo el clúster:
SHOW TABLES IN uk; ┌─name────────────────┐
1. │ uk_price_paid_local │
└─────────────────────┘Insertar datos en una tabla distribuida
Para insertar datos en la tabla, no se puede usar ON CLUSTER, ya que no
se aplica a consultas DML (lenguaje de manipulación de datos) como INSERT, UPDATE
y DELETE. Para insertar datos, es necesario utilizar el
motor de tablas
Distributed.
Como aprendió en la guía para configurar un clúster con 2 segmentos y 1 réplica, las tablas distribuidas son tablas que pueden acceder a segmentos ubicados en distintos
hosts y se definen mediante el motor de tablas Distributed.
La tabla distribuida actúa como la interfaz entre todos los segmentos del clúster.
Desde cualquiera de los clientes de los hosts, ejecute la siguiente consulta para crear una tabla distribuida utilizando la tabla replicada existente que creamos en el paso anterior:
CREATE TABLE IF NOT EXISTS uk.uk_price_paid_distributed
ON CLUSTER cluster_2S_2R
ENGINE = Distributed('cluster_2S_2R', 'uk', 'uk_price_paid_local', rand());En cada host verá ahora las siguientes tablas de la base de datos uk:
┌─name──────────────────────┐
1. │ uk_price_paid_distributed │
2. │ uk_price_paid_local │
└───────────────────────────┘Los datos se pueden insertar en la tabla uk_price_paid_distributed desde cualquiera de los
clientes host mediante la siguiente consulta:
INSERT INTO uk.uk_price_paid_distributed
SELECT
toUInt32(price_string) AS price,
parseDateTimeBestEffortUS(time) AS date,
splitByChar(' ', postcode)[1] AS postcode1,
splitByChar(' ', postcode)[2] AS postcode2,
transform(a, ['T', 'S', 'D', 'F', 'O'], ['terraced', 'semi-detached', 'detached', 'flat', 'other']) AS type,
b = 'Y' AS is_new,
transform(c, ['F', 'L', 'U'], ['freehold', 'leasehold', 'unknown']) AS duration,
addr1,
addr2,
street,
locality,
town,
district,
county
FROM url(
'http://prod1.publicdata.landregistry.gov.uk.s3-website-eu-west-1.amazonaws.com/pp-complete.csv',
'CSV',
'uuid_string String,
price_string String,
time String,
postcode String,
a String,
b String,
c String,
addr1 String,
addr2 String,
street String,
locality String,
town String,
district String,
county String,
d String,
e String'
) SETTINGS max_http_get_redirects=10;Ejecute la siguiente consulta para confirmar que los datos insertados se han distribuido de forma uniforme entre los nodos de nuestro clúster:
SELECT count(*)
FROM uk.uk_price_paid_distributed;
SELECT count(*) FROM uk.uk_price_paid_local; ┌──count()─┐
1. │ 30212555 │ -- 30.21 million
└──────────┘
┌──count()─┐
1. │ 15105983 │ -- 15.11 million
└──────────┘Conclusión
La ventaja de esta topología de clúster con 2 segmentos y 2 réplicas es que ofrece tanto escalabilidad como tolerancia a fallos. Los datos se distribuyen entre hosts distintos, lo que reduce los requisitos de almacenamiento y de E/S por nodo, mientras que las consultas se procesan en paralelo en ambos segmentos para mejorar el rendimiento y el uso de memoria. Lo más importante es que el clúster puede tolerar la pérdida de un nodo y seguir atendiendo consultas sin interrupciones, ya que cada segmento tiene una réplica de respaldo disponible en otro nodo.
La principal desventaja de esta topología de clúster es el mayor consumo de almacenamiento: requiere el doble de capacidad de almacenamiento que una configuración sin réplicas, ya que cada segmento está duplicado. Además, aunque el clúster puede sobrevivir al fallo de un solo nodo, la pérdida simultánea de dos nodos puede dejarlo inoperativo, según qué nodos fallen y cómo se distribuyan los segmentos. Esta topología logra un equilibrio entre disponibilidad y coste, por lo que resulta adecuada para entornos de producción en los que se requiere cierto nivel de tolerancia a fallos sin asumir el coste de factores de replicación más altos.
Para saber cómo ClickHouse Cloud procesa las consultas, ofreciendo tanto escalabilidad como tolerancia a fallos, consulte la sección "Réplicas paralelas".