Set up docs MCPНиже приведена модель для оценки вычислительных ресурсов и ресурсов хранения, необходимых для развертывания ClickStack на основе ожидаемого объёма приёма. Полученные значения являются лишь оценками и должны использоваться как начальная отправная точка — это не готовая рекомендация. Фактические требования зависят от сложности запросов, параллелизма, политик хранения и колебаний пропускной способности ингестии. Всегда отслеживайте использование ресурсов и при необходимости масштабируйте систему.
При развертывании ClickStack закладывайте вычислительные ресурсы на две независимые рабочие нагрузки: приём и запросы.
| Рабочая нагрузка | Оценка ресурсов |
|---|---|
| Ingest | 1 vCPU на каждые 10 MB/s устойчивой пропускной способности приёма |
| Query | 1 vCPU на 1 QPS и на каждые 10 MB/s устойчивой пропускной способности приёма |
Допущения
- Для хранилища предполагается коэффициент сжатия 10x — обычно это консервативная оценка для журналов и трассировок.
- SLA для запросов: P50 — 1.5 секунды, P99 — 5 секунд.
- Мы предполагаем, что большинство запросов выполняется по недавним данным и следует логнормальному распределению с пиком примерно на одном часе и хвостом примерно до шести часов. Пользователи могут захотеть выделить отдельные вычислительные ресурсы для запросов к более старым данным. В ClickHouse Cloud эти ресурсы могут простаивать (и, следовательно, не создавать затрат), когда не используются.
- Хотя вычислительные ресурсы для запросов можно масштабировать независимо от ресурсов для приёма, они всё равно неразрывно связаны с объёмом приёма. Мы предполагаем, что с ростом приёма увеличивается плотность данных, что приводит к большим объёмам сканирования во время выполнения запросов и, как следствие, к более высоким требованиям к вычислительным ресурсам для запросов.
В следующей таблице приведены примеры размеров ресурсов на основе растущей пропускной способности приёма в мегабайтах в секунду, а также соответствующих объёмов данных в терабайтах в месяц. Предполагается устойчивое среднее значение 1 QPS от ClickStack по всем типам запросов (поиск, панели мониторинга, оповещения).
| MB/s | TB/month | CPUs для приёма | CPUs для запросов | Всего CPU | Общее хранилище (в месяц) (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 |
Уточнение допущений по сайзингу для вашей среды
Модель предполагает устойчивое среднее значение 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 ТБ всего
Сводка
| Ресурс | Значение |
|---|---|
| Ресурсы для приёма | 58 vCPU |
| Ресурсы для запросов | 290 vCPU |
| Общие вычислительные ресурсы | 348 vCPU |
| Хранилище в месяц (сжатое) | 150 ТБ |
| Хранилище для хранения в течение 3 месяцев | 450 ТБ |
Изоляция рабочих нагрузок обсервабилити
Если вы добавляете ClickStack в существующий сервис ClickHouse Cloud, который уже поддерживает другие рабочие нагрузки, например аналитику приложений в реальном времени, настоятельно рекомендуется изолировать трафик обсервабилити.
Используйте Управляемые хранилища, чтобы создать дочерний сервис, выделенный под ClickStack. Это позволяет:
- Изолировать нагрузку от приёма данных и запросов существующих приложений
- Независимо масштабировать рабочие нагрузки обсервабилити
- Не допускать влияния запросов обсервабилити на аналитику в продакшне
- При необходимости использовать одни и те же базовые данные в разных сервисах
Такой подход гарантирует, что существующие рабочие нагрузки не пострадают, а ClickStack сможет масштабироваться независимо по мере роста объёма данных обсервабилити.
Для крупных развертываний или рекомендаций по индивидуальному подбору размера обратитесь в службу поддержки, чтобы получить более точную оценку.