Isolamento de Consultas vs. IngestãoNa maioria das implantações autogerenciadas, a ingestão e a consulta compartilham os mesmos nós. Nesse caso, use o Total de CPUs como linha de base. O escalonamento isolado — em que a computação de ingestão e a de consulta são provisionadas de forma independente — é compatível com o ClickHouse Cloud por meio de pools de computação separados, também conhecidos como Warehouses.
Premissas
Premissas
- Uma taxa de compressão de 10x para armazenamento — normalmente conservadora para logs e traces.
- SLAs de consulta com P50 de 1,5 segundo e P99 de 5 segundos.
- Assumimos que a maioria das consultas ocorre sobre dados recentes, seguindo uma distribuição log-normal que atinge o pico em cerca de uma hora e se estende até cerca de seis horas. Os usuários podem querer provisionar computação dedicada para consultar dados mais antigos. No ClickHouse Cloud, ela pode ficar ociosa (e, portanto, sem gerar custos) quando não estiver em uso.
- Embora a computação de consulta possa ser escalada de forma independente da computação de ingestão, ela continua intrinsicamente vinculada ao volume de ingestão. Assumimos que, à medida que a ingestão aumenta, a densidade dos dados cresce, resultando em volumes de varredura maiores no momento da consulta e, consequentemente, em maiores requisitos de computação para consulta.
Refinando as premissas de dimensionamento para o seu ambiente
O modelo assume uma média sustentada de 1 QPS no ClickStack, agregando todos os tipos de consulta, incluindo busca, dashboards e alertas. Para volumes maiores de consultas, dimensione os requisitos de CPU linearmente, multiplicando-os pelo QPS alvo. Por exemplo, uma implantação com ingestão de 100 MB/s e meta de 9 QPS exigiria 90 CPUs para consultas (10 × 9), em vez da linha de base de 10, resultando em um total revisado de 100 CPUs (10 de ingestão + 90 de consulta). As estimativas de armazenamento assumem uma taxa de compressão conservadora de 10x. Na prática, logs, traces e métricas frequentemente alcançam compressão maior. Recomendamos testar com uma amostra dos dados para determinar sua taxa de compressão e seus requisitos de armazenamento antes da produção. Para calcular o armazenamento necessário para retenção mais longa, multiplique o armazenamento mensal pelo número de meses que precisam ser retidos. Isso pressupõe uma distribuição de consultas relativamente equilibrada. Cargas de trabalho mais voltadas a consultas históricas ou de arquivamento mais pesadas podem ter requisitos de computação significativamente diferentes e devem ser validadas por meio de testes de carga. Planejamos introduzir um modelo de dimensionamento mais flexível que permita extrapolar a capacidade computacional das consultas com base em diferentes padrões de distribuição de consultas.Exemplo prático
Requisitos: 1,5 PB/mês de ingestão, 5 QPS, retenção de 3 meses. Convertendo para MB/s O modelo de dimensionamento é expresso em MB/s. Convertendo 1,5 PB/mês (1.500 TB) em vazão sustentada:- 1.500 TB = 1.500.000.000 MB
- Segundos por mês (30 dias): 30 × 24 × 60 × 60 = 2.592.000
- MB/s = 1.500.000.000 ÷ 2.592.000 ≈ 579 MB/s
- Comprimido por mês: 1.500 TB ÷ 10 = 150 TB/mês
- Para retenção de 3 meses: 150 TB × 3 = 450 TB no total
Isolando cargas de trabalho de observabilidade
Se você estiver adicionando o ClickStack a um serviço existente do ClickHouse Cloud que já atende a outras cargas de trabalho, como análises de aplicações em tempo real, é altamente recomendável isolar o tráfego de observabilidade. Use Warehouses gerenciados para criar um serviço filho dedicado ao ClickStack. Isso permite:- Isolar a carga de ingestão e de consultas das aplicações existentes
- Escalar as cargas de trabalho de observabilidade de forma independente
- Evitar que consultas de observabilidade afetem as análises em produção
- Compartilhar os mesmos conjuntos de dados subjacentes entre serviços, quando necessário