Isolando workloads de leitura e escrita

​

Por que isolar leituras de gravações

• As gravações deixam de degradar as leituras. A ingestão contínua do OpenTelemetry — os próprios inserts, somados às mesclagens em segundo plano que vêm depois — compete com as consultas de dashboards e buscas por CPU e memória. A latência de leitura pode piorar de forma perceptível enquanto a ingestão está em execução, e se recupera assim que ela para.
• As leituras deixam de atrapalhar as gravações. A contenção ocorre nos dois sentidos: uma consulta ad-hoc pesada ou a renderização custosa de um dashboard pode esgotar a memória do service e fazer os inserts falharem por completo, e não apenas ficarem mais lentos.
• O compute somente leitura fica totalmente dedicado às consultas. Os read-only services não executam mesclagens em segundo plano fora das system tables. Eles também entram em idle sem atraso, ao contrário dos read-write services, que as mesclagens podem manter ativos.
• Cada lado é dimensionado separadamente. O sizing model estima o compute de ingestão e o compute de consulta separadamente, e um warehouse permite provisionar cada um como um service próprio. Acima do baseline de 1 QPS do modelo, o compute de consulta domina — seu exemplo prático a 5 QPS chega a 58 vCPUs para ingestão contra 290 para consultas —, de modo que um service de gravação pequeno pode alimentar um service de leitura muito maior.
• Idling e autoscaling são configurados por service. Cada service tem sua própria contagem de réplicas e suas próprias configurações de autoscaling e auto-idling, de modo que o service de gravação pode permanecer sempre ativo para a ingestão contínua enquanto o service de leitura fica em idle fora do horário de trabalho.
• O armazenamento não é duplicado. Os services em um warehouse compartilham a mesma pasta de armazenamento de objetos e as mesmas tabelas, e o armazenamento é cobrado apenas uma vez.
• O acesso pode ser restringido por endpoint. As IP access lists são aplicadas por service, portanto o endpoint de gravação pode ficar acessível apenas a partir dos seus collectors e o endpoint de leitura apenas a partir da sua implantação do ClickStack. Consulte nosso guia sobre Controle de acesso de rede.

​

Arquitetura

• O primeiro service de um warehouse é sempre read-write, e o tipo do service é definido no momento da criação — para alternar entre read-only e read-write, crie um novo service no warehouse.
• Todos os services de um warehouse compartilham o mesmo cloud provider, região, versão do ClickHouse e Keeper, além do upgrade schedule do primary service.
• Use um service read-write para ingestão. As mesclagens são distribuídas entre todos os services read-write que compartilham o storage, portanto a mesclagem referente a um insert feito em um service pode ser executada por outro. Se esse outro service também estiver atendendo consultas pesadas, essas consultas vão competir com a mesclagem por CPU e memória no service que a executa — o que atrasa as mesclagens dos inserts do primeiro service e, com elas, o desempenho de insert. Mantenha os workloads de consulta no service read-only e só adicione um segundo service read-write se precisar separar as mesclagens da ingestão.

​

Configurando uma implantação isolada

CREATE DATABASE otel;
CREATE USER hyperdx_ingest IDENTIFIED WITH sha256_password BY '<strong-password>';
GRANT SELECT, INSERT, CREATE DATABASE, CREATE TABLE, CREATE VIEW ON otel.* TO hyperdx_ingest;

CLICKHOUSE_ENDPOINT=https://<read-write-service>.clickhouse.cloud:8443
CLICKHOUSE_USER=hyperdx_ingest
CLICKHOUSE_PASSWORD=<strong-password>
HYPERDX_OTEL_EXPORTER_CLICKHOUSE_DATABASE=otel

SELECT 
    user, 
    query_kind, 
    http_user_agent,
    count()
FROM clusterAllReplicas('default', system.query_log)
WHERE event_time > now() - toIntervalMinute(10) 
  AND type = 'QueryFinish'
  AND is_initial_query = 1
GROUP BY ALL
ORDER BY count() DESC;

SELECT 
    hostName() AS host, 
    query_kind, 
    count()
FROM clusterAllReplicas('all_groups.default', system.query_log)
WHERE event_time > now() - toIntervalMinute(10) 
  AND type = 'QueryFinish'
  AND is_initial_query = 1
GROUP BY ALL;

​

Separando mesclagens da ingestão

• Não conte com o auto-idling em nenhum dos read-write services. Um serviço com mesclagens desabilitadas ainda processa os eventos de download e remoção de partes gerados por inserts em outros pontos do warehouse, e uma contagem alta de partes não mescladas pode, por si só, impedir o idling. Planeje manter ambos os read-write services continuamente ativos.
• Mantenha as consultas fora dos dois read-write services. Consultas SELECT pesadas em um read-write service competem com o trabalho de mesclagem por CPU e memória — justamente o modo de falha que essa topologia existe para evitar. Aponte o ClickStack para o read-only service conforme descrito acima.
• As mutações, quando houver, são rastreadas no serviço que as executa. Mutações são raras em observabilidade — o schema do ClickStack define ttl_only_drop_parts = 1, de modo que a retenção comum descarta partes expiradas inteiras durante as mesclagens de TTL, em vez de remover linhas por mutação. Se você enviar ao serviço de ingestão um ALTER que gere mutação, ele será executado pelo serviço de mesclagem, e seu progresso aparecerá em system.mutations nesse serviço, e não no serviço de ingestão.

​

Administração e DDL

• Criação de tabelas — realizada automaticamente pelo ClickStack collector na primeira ingestão
• Como modificar o TTL para alterar a retenção
• Criação de visões materializadas para acelerar consultas
• Adição de skip indexes, projeções e outras otimizações de desempenho

CREATE DATABASE otel
SETTINGS distributed_ddl_task_timeout=0

​

Isolando workloads agênticos

claude mcp add --transport http clickstack https://mcp.clickhouse.cloud/clickstack \
  --header "x-service-id: <read-only-agent-service-id>"

​

Alertas

​

Isolando a avaliação de alertas

• Os alertas comuns, e quaisquer dashboards associados a eles, existem apenas no service de alertas e não ficam visíveis para os usuários que trabalham no service de consulta. As notificações são entregues aos mesmos destinos em qualquer um dos casos, então o que os usuários perdem é a visibilidade das definições, não o alerta em si.
• As sources no service de alertas são objetos separados. Aquelas que usam o schema padrão do OpenTelemetry são detectadas automaticamente, mas sources custom também precisam ser configuradas ali antes que um alerta possa referenciá-las.

​

Considerações adicionais