Pular para o conteúdo principal

Este tópico não se aplica ao ClickHouse Cloud, em que Parallel Replicas funcionam como múltiplos shards em clusters tradicionais shared-nothing do ClickHouse, e o armazenamento de objetos substitui as réplicas, garantindo alta disponibilidade e tolerância a falhas.

O que são shards de tabela no ClickHouse?

Em clusters ClickHouse shared-nothing tradicionais, o sharding é usado quando ① os dados são grandes demais para um único servidor ou ② um único servidor é lento demais para processar os dados. A figura a seguir ilustra o caso ①, em que a tabela uk_price_paid_simple excede a capacidade de uma única máquina:
Nesse caso, os dados podem ser divididos entre vários servidores ClickHouse na forma de shards de tabela:
Cada shard contém um subconjunto dos dados e funciona como uma tabela ClickHouse comum, que pode ser consultada de forma independente. No entanto, as consultas processam apenas esse subconjunto, o que pode ser um caso de uso válido, dependendo da distribuição dos dados. Normalmente, uma tabela distribuída (muitas vezes uma por servidor) fornece uma visão unificada do conjunto completo de dados. Ela não armazena os dados por conta própria, mas encaminha consultas SELECT para todos os shards, reúne os resultados e encaminha INSERTS para distribuir os dados de maneira uniforme.

Criação de tabela distribuída

Para ilustrar o encaminhamento de consultas SELECT e o roteamento de INSERT, vamos considerar a tabela de exemplo O que são partes de tabela, dividida entre dois shards em dois servidores ClickHouse. Primeiro, mostramos a instrução DDL para criar a tabela distribuída correspondente a essa configuração:
A cláusula ON CLUSTER transforma a instrução DDL em uma instrução de DDL distribuído, fazendo com que o ClickHouse crie a tabela em todos os servidores listados na definição do cluster test_cluster cluster definition. O DDL distribuído exige um componente adicional, o Keeper, na arquitetura do cluster. Para os parâmetros do motor Distributed, especificamos o nome do cluster (test_cluster), o nome do banco de dados (uk) da tabela de destino fragmentada, o nome dessa tabela de destino fragmentada (uk_price_paid_simple) e a chave de sharding para o roteamento de INSERT. Neste exemplo, usamos a função rand para atribuir linhas aos shards aleatoriamente. No entanto, qualquer expressão — inclusive expressões complexas — pode ser usada como chave de sharding, dependendo do caso de uso. A próxima seção mostra como funciona o roteamento de INSERT.

Roteamento de INSERT

O diagrama abaixo ilustra como os INSERTs em uma tabela distribuída são processados no ClickHouse:
① Um INSERT (com uma única linha) destinado à tabela distribuída é enviado a um servidor ClickHouse que hospeda a tabela, diretamente ou por meio de um balanceador de carga. ② Para cada linha do INSERT (apenas uma no nosso exemplo), o ClickHouse avalia a chave de sharding (aqui, rand()), calcula o resultado módulo o número de servidores shard e usa esse valor como o ID do servidor de destino (os IDs começam em 0 e aumentam de 1 em 1). A linha é então encaminhada e ③ inserida no shard da tabela no servidor correspondente. A próxima seção explica como funciona o encaminhamento de SELECT.

Encaminhamento de SELECT

Este diagrama mostra como consultas SELECT são processadas usando uma tabela distribuída no ClickHouse:
① Uma consulta SELECT de agregação direcionada à tabela distribuída é enviada ao servidor ClickHouse correspondente, diretamente ou por meio de um balanceador de carga. ② A tabela distribuída encaminha a consulta para todos os servidores que hospedam shards da tabela de destino, onde cada servidor ClickHouse calcula seu resultado de agregação local em paralelo. Em seguida, o servidor ClickHouse que hospeda a tabela distribuída originalmente consultada ③ coleta todos os resultados locais, ④ mescla-os no resultado global final e ⑤ o retorna ao cliente que enviou a consulta.

O que são réplicas de tabela no ClickHouse?

A replicação no ClickHouse garante integridade dos dados e failover ao manter cópias dos dados dos shards em vários servidores. Como falhas de hardware são inevitáveis, a replicação evita a perda de dados ao garantir que cada shard tenha várias réplicas. As gravações podem ser direcionadas a qualquer réplica, seja diretamente ou por meio de uma tabela distribuída, que seleciona uma réplica para a operação. As alterações são propagadas automaticamente para as demais réplicas. Em caso de falha ou manutenção, os dados permanecem disponíveis em outras réplicas e, quando um host com falha se recupera, ele se sincroniza automaticamente para se manter atualizado. Observe que a replicação exige um componente Keeper na arquitetura do cluster. O diagrama a seguir ilustra um cluster do ClickHouse com seis servidores, em que os dois shards de tabela Shard-1 e Shard-2 apresentados anteriormente têm, cada um, três réplicas. Uma consulta é enviada a esse cluster:
O processamento de consultas funciona de forma semelhante ao de configurações sem réplicas, com apenas uma réplica de cada shard executando a consulta.
As réplicas não apenas garantem a integridade dos dados e o failover, mas também melhoram o throughput do processamento de consultas ao permitir que várias consultas sejam executadas em paralelo em diferentes réplicas.
① Uma consulta direcionada à tabela distribuída é enviada ao servidor ClickHouse correspondente, seja diretamente ou por meio de um balanceador de carga. ② A tabela distribuída encaminha a consulta para uma réplica de cada shard, em que cada servidor ClickHouse que hospeda a réplica selecionada calcula, em paralelo, seu resultado local da consulta. O restante funciona da mesma forma que em configurações sem réplicas e não é mostrado no diagrama acima. O servidor ClickHouse que hospeda a tabela distribuída inicialmente direcionada coleta todos os resultados locais, mescla-os no resultado global final e o retorna ao cliente que enviou a consulta. Observe que o ClickHouse permite configurar a estratégia de encaminhamento de consultas para ②. Por padrão — diferentemente do diagrama acima — a tabela distribuída prefere uma réplica local, se disponível, mas outras estratégias de balanceamento de carga podem ser usadas.

Onde encontrar mais informações

Para mais detalhes além desta introdução geral sobre shards e réplicas de tabelas, confira nosso guia de implantação e escalonamento. Também recomendamos fortemente este vídeo tutorial para se aprofundar em shards e réplicas no ClickHouse:
Última modificação em 25 de junho de 2026