Skip to main content
Ниже приведена модель для оценки вычислительных ресурсов и ресурсов хранения, необходимых для развертывания ClickStack на основе ожидаемого объёма приёма. Полученные значения являются лишь оценками и должны использоваться как начальная отправная точка — это не готовая рекомендация. Фактические требования зависят от сложности запросов, параллелизма, политик хранения и колебаний пропускной способности ингестии. Всегда отслеживайте использование ресурсов и при необходимости масштабируйте систему.
Все значения основаны на несжатом исходном объёме приёмаВсе значения на этой странице — пропускная способность (MB/s, TB/month), размер CPU и хранилища — выражены в терминах несжатого исходного объёма приёма, то есть объёма данных в том виде, в котором они создаются вашими приложениями и отправляются в OpenTelemetry Collector до применения какого-либо сжатия.Именно эту величину следует оценивать по вашим существующим конвейерам журналов, трассировок и метрик. Значения хранилища в таблице ниже уже рассчитаны с учётом предполагаемого коэффициента сжатия 10x, применённого к этому исходному объёму.
При развертывании ClickStack закладывайте вычислительные ресурсы на две независимые рабочие нагрузки: приём и запросы.
Изоляция запросов и приёмаВ большинстве самоуправляемых развертываний приём и запросы используют одни и те же узлы. В этом случае используйте общее число CPU как отправную точку. Изолированное масштабирование — когда вычислительные ресурсы для приёма и запросов выделяются независимо — поддерживается в ClickHouse Cloud через отдельные вычислительные пулы, то есть Warehouses.
  • Для хранилища предполагается коэффициент сжатия 10x — обычно это консервативная оценка для журналов и трассировок.
  • SLA для запросов: P50 — 1.5 секунды, P99 — 5 секунд.
  • Мы предполагаем, что большинство запросов выполняется по недавним данным и следует логнормальному распределению с пиком примерно на одном часе и хвостом примерно до шести часов. Пользователи могут захотеть выделить отдельные вычислительные ресурсы для запросов к более старым данным. В ClickHouse Cloud эти ресурсы могут простаивать (и, следовательно, не создавать затрат), когда не используются.
  • Хотя вычислительные ресурсы для запросов можно масштабировать независимо от ресурсов для приёма, они всё равно неразрывно связаны с объёмом приёма. Мы предполагаем, что с ростом приёма увеличивается плотность данных, что приводит к большим объёмам сканирования во время выполнения запросов и, как следствие, к более высоким требованиям к вычислительным ресурсам для запросов.
В следующей таблице приведены примеры размеров ресурсов на основе растущей пропускной способности приёма в мегабайтах в секунду, а также соответствующих объёмов данных в терабайтах в месяц. Предполагается устойчивое среднее значение 1 QPS от ClickStack по всем типам запросов (поиск, панели мониторинга, оповещения).

​
Уточнение допущений по сайзингу для вашей среды

Модель предполагает устойчивое среднее значение 1 QPS для ClickStack с учётом всех типов запросов, включая поиск, панели мониторинга и оповещения. При более высоких объёмах запросов линейно масштабируйте требования к CPU, умножая базовую потребность в CPU на целевой QPS. Например, развертывание с приёмом данных на скорости 100 МБ/с и целевым значением 9 QPS потребует 90 CPU на запросы (10 × 9) вместо базовых 10, что даст пересчитанный итог в 100 CPU (10 на приём + 90 на запросы). Оценки хранилища исходят из консервативного коэффициента сжатия 10x. На практике журналы, трассировки и метрики часто сжимаются лучше. Мы рекомендуем заранее, до выхода в продакшн, провести тестирование на выборке данных, чтобы определить ваш коэффициент сжатия и требования к хранилищу. Чтобы рассчитать необходимый объём хранилища для более длительного срока хранения, умножьте объём хранилища в месяц на количество месяцев хранения. Здесь предполагается относительно сбалансированное распределение запросов. Рабочие нагрузки со смещением в сторону более тяжёлых исторических или архивных запросов могут требовать существенно иных вычислительных ресурсов, поэтому их следует проверять с помощью нагрузочного тестирования. Мы планируем представить более гибкую модель сайзинга, которая позволит экстраполировать вычислительные ресурсы для запросов на основе различных профилей распределения запросов.

​
Пример расчёта

Требования: приём 1,5 ПБ/месяц, 5 QPS, хранение в течение 3 месяцев. Преобразование в MB/s Модель сайзинга выражается в MB/s. Переведём 1,5 ПБ/месяц (1 500 ТБ) в постоянную пропускную способность:
  • 1 500 ТБ = 1 500 000 000 МБ
  • Секунд в месяце (30 дней): 30 × 24 × 60 × 60 = 2 592 000
  • MB/s = 1 500 000 000 ÷ 2 592 000 ≈ 579 MB/s
Ресурсы для приёма При 1 vCPU на каждые 10 MB/s постоянного приёма: 579 ÷ 10 = ~58 vCPU для приёма Ресурсы для запросов Ресурсы для запросов зависят как от пропускной способности ингестии, так и от QPS. При 5 QPS: (579 ÷ 10) × 5 = 58 × 5 = 290 vCPU для запросов Хранилище При постоянной скорости 579 MB/s в течение 30 дней исходный объём приёма составляет 1 500 ТБ/месяц. Применяя предполагаемый коэффициент сжатия 10×:
  • В сжатом виде за месяц: 1 500 ТБ ÷ 10 = 150 ТБ/месяц
  • Для хранения в течение 3 месяцев: 150 ТБ × 3 = 450 ТБ всего
Сводка

​
Изоляция рабочих нагрузок обсервабилити

Если вы добавляете ClickStack в существующий сервис ClickHouse Cloud, который уже поддерживает другие рабочие нагрузки, например аналитику приложений в реальном времени, настоятельно рекомендуется изолировать трафик обсервабилити. Используйте Управляемые хранилища, чтобы создать дочерний сервис, выделенный под ClickStack. Это позволяет:
  • Изолировать нагрузку от приёма данных и запросов существующих приложений
  • Независимо масштабировать рабочие нагрузки обсервабилити
  • Не допускать влияния запросов обсервабилити на аналитику в продакшне
  • При необходимости использовать одни и те же базовые данные в разных сервисах
Такой подход гарантирует, что существующие рабочие нагрузки не пострадают, а ClickStack сможет масштабироваться независимо по мере роста объёма данных обсервабилити. Для крупных развертываний или рекомендаций по индивидуальному подбору размера обратитесь в службу поддержки, чтобы получить более точную оценку.
Последнее изменение 12 июня 2026 г.