Pular para o conteúdo principal
O conteúdo a seguir apresenta um modelo para estimar os recursos de computação e armazenamento necessários para uma implantação do ClickStack com base no volume de ingestão esperado. Os valores obtidos são apenas estimativas e devem ser usados como uma linha de base inicial — não são uma resposta prescritiva. Os requisitos reais dependem da complexidade das consultas, da concorrência, das políticas de retenção e da variação na vazão de ingestão. Sempre monitore o uso de recursos e escale conforme necessário.
Todos os valores são baseados em ingestão bruta não comprimidaTodos os números nesta página — throughput (MB/s, TB/mês), dimensionamento de CPU e armazenamento — são expressos em termos de volume bruto de ingestão não comprimido, ou seja, o tamanho dos dados conforme são produzidos pelas suas aplicações e enviados ao OpenTelemetry Collector antes da aplicação de qualquer compressão.Esse é o valor que você deve estimar com base nos pipelines existentes de logs, traces e métricas. Os valores de armazenamento na tabela abaixo já consideram uma taxa de compressão de 10x aplicada a esse volume bruto.
Ao implantar o ClickStack, provisione capacidade computacional para cobrir duas cargas de trabalho independentes: ingestão e consulta.
Carga de trabalhoRecursos estimados
Ingestão1 vCPU por 10 MB/s de throughput de ingestão sustentado
Consulta1 vCPU por 1 QPS e por 10 MB/s de throughput de ingestão sustentado
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.
  • 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.
A tabela a seguir apresenta exemplos de dimensionamento com base no aumento do throughput de ingestão em megabytes por segundo, juntamente com os volumes de dados correspondentes em terabytes por mês. Isso pressupõe uma média sustentada de 1 QPS do ClickStack em todos os tipos de consulta (pesquisa, dashboards, alertas).
MB/sTB/mêsCPUs de ingestãoCPUs de consultaCPUs totaisArmazenamento total (por mês) (GB)
1025.921342,592
2051.842685,184
50129.65152012,960
100259.210304025,920
200518.420608051,840
5001,29650150200129,600
10002,592100300400259,200

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
Compute de ingestão Com 1 vCPU para cada 10 MB/s de ingestão sustentada: 579 ÷ 10 = ~58 vCPUs para ingestão Compute de consulta O compute de consulta escala tanto com a vazão de ingestão quanto com o QPS. Com 5 QPS: (579 ÷ 10) × 5 = 58 × 5 = 290 vCPUs para consulta Armazenamento Com 579 MB/s sustentados ao longo de 30 dias, a ingestão bruta equivale a 1.500 TB/mês. Aplicando a taxa de compressão assumida de 10x:
  • 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
Resumo
RecursoValor
Compute de ingestão58 vCPUs
Compute de consulta290 vCPUs
Compute total348 vCPUs
Armazenamento por mês (comprimido)150 TB
Armazenamento para retenção de 3 meses450 TB

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
Essa abordagem garante que suas cargas de trabalho existentes não sejam afetadas, ao mesmo tempo em que permite que o ClickStack escale de forma independente à medida que os dados de observabilidade aumentam. Para implantações maiores ou orientações sobre dimensionamento personalizado, entre em contato com o suporte para obter uma estimativa mais precisa.
Última modificação em 10 de junho de 2026