> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-fix-nav-issues.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Estimativa de recursos

> Orientações para estimativa de recursos em implantações do Managed ClickStack

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.

<Warning>
  **Todos os valores são baseados em ingestão bruta não comprimida**

  Todos 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.
</Warning>

Ao implantar o ClickStack, provisione capacidade computacional para cobrir duas cargas de trabalho independentes: **ingestão** e **consulta**.

| Carga de trabalho | Recursos estimados                                                  |
| ----------------- | ------------------------------------------------------------------- |
| **Ingestão**      | 1 vCPU por 10 MB/s de throughput de ingestão sustentado             |
| **Consulta**      | 1 vCPU por 1 QPS e por 10 MB/s de throughput de ingestão sustentado |

<Info>
  **Isolamento de Consultas vs. Ingestão**

  Na 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](/pt-BR/products/cloud/features/infrastructure/warehouses).
</Info>

<Accordion title="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.
</Accordion>

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/s | TB/mês | CPUs de ingestão | CPUs de consulta | CPUs totais | Armazenamento total (por mês) (GB) |
| ---: | -----: | ---------------: | ---------------: | ----------: | ---------------------------------: |
|   10 |  25.92 |                1 |                3 |           4 |                              2,592 |
|   20 |  51.84 |                2 |                6 |           8 |                              5,184 |
|   50 |  129.6 |                5 |               15 |          20 |                             12,960 |
|  100 |  259.2 |               10 |               30 |          40 |                             25,920 |
|  200 |  518.4 |               20 |               60 |          80 |                             51,840 |
|  500 |  1,296 |               50 |              150 |         200 |                            129,600 |
| 1000 |  2,592 |              100 |              300 |         400 |                            259,200 |

<div id="refining-sizing-assumptions">
  ## Refinando as premissas de dimensionamento para o seu ambiente
</div>

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.

<div id="worked-example">
  ### Exemplo prático
</div>

**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**

| Recurso                                | Valor     |
| -------------------------------------- | --------- |
| Compute de ingestão                    | 58 vCPUs  |
| Compute de consulta                    | 290 vCPUs |
| Compute total                          | 348 vCPUs |
| Armazenamento por mês (comprimido)     | 150 TB    |
| Armazenamento para retenção de 3 meses | 450 TB    |

<div id="isolating-workloads">
  ## Isolando cargas de trabalho de observabilidade
</div>

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**](/pt-BR/products/cloud/features/infrastructure/warehouses) 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.
