Los ejemplos de despliegue de esta sección se basan en las recomendaciones proporcionadas a los usuarios de ClickHouse por
el equipo de Soporte y Servicios de ClickHouse. Son ejemplos funcionales, y
le recomendamos que los pruebe y luego los ajuste según sus necesidades. Puede que
encuentre aquí un ejemplo que se adapte exactamente a sus requisitos.
Ofrecemos varias ‘recetas’ de distintas topologías en el repositorio de ejemplos
y le recomendamos echarles un vistazo si los ejemplos de esta sección no se ajustan exactamente a sus
necesidades.
Una copia de los datos. ClickHouse siempre tiene al menos una copia de sus datos, por lo que el número mínimo de réplicas es uno. Este es un detalle importante: puede que no esté acostumbrado a considerar la copia original de sus datos como una réplica, pero ese es el término que se usa en el código y la documentación de ClickHouse. Añadir una segunda réplica de sus datos proporciona tolerancia a fallos.
Un subconjunto de datos. ClickHouse siempre tiene al menos un segmento para sus datos, así que, si no divide los datos entre varios servidores, sus datos se almacenarán en un único segmento. Distribuir los datos entre varios servidores puede servir para repartir la carga si esta supera la capacidad de un solo servidor. El servidor de destino se determina mediante la clave de sharding y se define al crear la tabla distribuida. La clave de sharding puede ser aleatoria o el resultado de una función hash. Los ejemplos de implementación que incluyen sharding usarán rand() como clave de sharding y ofrecerán más información sobre cuándo y cómo elegir una clave de sharding diferente.
ClickHouse Keeper proporciona el sistema de coordinación para la replicación de datos y la ejecución de consultas DDL distribuidas. ClickHouse Keeper es compatible con Apache ZooKeeper.
Última modificación el 19 de junio de 2026