Skip to main content
Lo siguiente ofrece un modelo para estimar los recursos de cómputo y almacenamiento necesarios para un despliegue de ClickStack en función del volumen de ingestión previsto. Los valores resultantes son solo estimaciones y deben utilizarse como una línea base inicial; no constituyen una respuesta prescriptiva. Los requisitos reales dependen de la complejidad de las consultas, la concurrencia, las políticas de retención y la variabilidad del rendimiento de ingestión. Supervise siempre el uso de recursos y escale según sea necesario.
Todas las cifras se basan en la ingestión bruta sin comprimirTodas las cifras de esta página —rendimiento (MB/s, TB/mes), dimensionamiento de CPU y almacenamiento— se expresan en términos de volumen de ingestión bruta sin comprimir, es decir, el tamaño de los datos tal como los generan sus aplicaciones y se envían al colector de OpenTelemetry antes de aplicar cualquier compresión.Esta es la cifra que debe estimar a partir de sus canalizaciones actuales de logs, traces y métricas. Las cifras de almacenamiento de la tabla siguiente ya tienen aplicada sobre este volumen bruto la relación de compresión de 10x asumida.
Al desplegar ClickStack, aprovisione cómputo para cubrir dos cargas de trabajo independientes: ingestión y consulta.
Aislamiento de consultas frente a ingestiónEn la mayoría de los despliegues autogestionados, la ingestión y la consulta comparten los mismos nodos. En este caso, use las CPU totales como línea base. El escalado aislado —donde el cómputo de ingestión y el de consulta se aprovisionan de forma independiente— es compatible con ClickHouse Cloud mediante grupos de cómputo independientes, también conocidos como Warehouses.
  • Una relación de compresión de 10x para el almacenamiento, normalmente conservadora para logs y traces.
  • SLA de consultas con un P50 de 1.5 segundos y un P99 de 5 segundos.
  • Suponemos que la mayoría de las consultas se realizan sobre datos recientes, siguiendo una distribución log-normal que alcanza su pico en torno a una hora y se extiende hasta aproximadamente seis horas. Los usuarios pueden optar por aprovisionar cómputo dedicado para consultar datos más antiguos. En ClickHouse Cloud, este puede permanecer inactivo (y, por tanto, no generar costos) cuando no se utilice.
  • Aunque el cómputo de consultas puede escalarse de forma independiente del cómputo de ingestión, sigue estando intrínsecamente vinculado al volumen de ingestión. Suponemos que, a medida que aumenta la ingestión, crece la densidad de datos, lo que da lugar a mayores volúmenes de escaneo en tiempo de consulta y, en consecuencia, a mayores requisitos de cómputo para las consultas.
La siguiente tabla muestra ejemplos de dimensionamiento basados en un rendimiento de ingestión creciente en megabytes por segundo, junto con los volúmenes de datos correspondientes en terabytes por mes. Esto supone un promedio sostenido de 1 QPS desde ClickStack en todos los tipos de consultas (búsqueda, dashboards y alertas).

​
Ajuste de las hipótesis de dimensionamiento para su entorno

El modelo asume un promedio sostenido de 1 QPS desde ClickStack, agregando todos los tipos de consultas, incluidas las búsquedas, los dashboards y las alertas. Para volúmenes de consultas más altos, escale linealmente los requisitos de CPU multiplicándolos por el QPS objetivo. Por ejemplo, una implementación con una tasa de ingesta de 100 MB/s y un objetivo de 9 QPS requeriría 90 CPU para consultas (10 × 9) en lugar de las 10 de base, lo que da un total revisado de 100 CPU (10 de ingesta + 90 de consultas). Las estimaciones de almacenamiento asumen una relación de compresión conservadora de 10x. En la práctica, los logs, las trazas y las métricas suelen lograr una compresión mayor. Recomendamos hacer pruebas con una muestra de datos para determinar la relación de compresión y los requisitos de almacenamiento antes de pasar a producción. Para calcular el almacenamiento necesario para una retención más prolongada, multiplique el almacenamiento mensual por la cantidad de meses que deban conservarse. Esto supone una distribución de consultas relativamente equilibrada. Las cargas de trabajo sesgadas hacia consultas históricas o de archivado más pesadas pueden tener requisitos de cómputo significativamente distintos, y deben validarse mediante pruebas de carga. Tenemos previsto introducir un modelo de dimensionamiento más flexible que permita extrapolar el cómputo de consultas en función de distintos patrones de distribución de consultas.

​
Ejemplo resuelto

Requisitos: 1,5 PB/mes de ingesta, 5 QPS, retención de 3 meses. Conversión a MB/s El modelo de dimensionamiento se expresa en MB/s. Convirtiendo 1,5 PB/mes (1.500 TB) a rendimiento sostenido:
  • 1.500 TB = 1.500.000.000 MB
  • Segundos por mes (30 días): 30 × 24 × 60 × 60 = 2.592.000
  • MB/s = 1.500.000.000 ÷ 2.592.000 ≈ 579 MB/s
Cómputo para la ingesta Con 1 vCPU por cada 10 MB/s de ingesta sostenida: 579 ÷ 10 = ~58 vCPUs para la ingesta Cómputo para consultas El cómputo para consultas escala tanto con el rendimiento de ingesta como con el QPS. Con 5 QPS: (579 ÷ 10) × 5 = 58 × 5 = 290 vCPUs para consultas Almacenamiento Con 579 MB/s sostenidos durante 30 días, la ingesta bruta equivale a 1.500 TB/mes. Aplicando la relación de compresión supuesta de 10x:
  • Comprimido por mes: 1.500 TB ÷ 10 = 150 TB/mes
  • Para una retención de 3 meses: 150 TB × 3 = 450 TB en total
Resumen

​
Aislar las cargas de trabajo de observabilidad

Si está añadiendo ClickStack a un servicio de ClickHouse Cloud existente que ya admite otras cargas de trabajo, como análisis de aplicaciones en tiempo real, se recomienda encarecidamente aislar el tráfico de observabilidad. Use Managed Warehouses para crear un servicio hijo dedicado a ClickStack. Esto le permite:
  • Aislar la carga de ingesta y de consultas de las aplicaciones existentes
  • Escalar las cargas de trabajo de observabilidad de forma independiente
  • Evitar que las consultas de observabilidad afecten a los análisis de producción
  • Compartir los mismos conjuntos de datos subyacentes entre servicios cuando sea necesario
Este enfoque garantiza que sus cargas de trabajo existentes no se vean afectadas y permite que ClickStack escale de forma independiente a medida que aumentan los datos de observabilidad. La misma funcionalidad puede usarse para aprovisionar como servicios separados el cómputo de ingesta y el cómputo de consultas estimados anteriormente, de modo que cada uno pueda escalarse de forma independiente. Consulte nuestra guía sobre Aislar las cargas de trabajo de lectura y escritura. Para implementaciones de mayor tamaño o recomendaciones de dimensionamiento personalizadas, contacte con soporte para obtener una estimación más precisa.
Última modificación el 26 de septiembre de 2026