> ## Documentation Index > Fetch the complete documentation index at: https://private-7c7dfe99-parallel-read-in-order-multi-part.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Оценка ресурсов > Рекомендации по оценке ресурсов для развертываний Управляемого ClickStack Ниже приведена модель для оценки вычислительных ресурсов и ресурсов хранения, необходимых для развертывания ClickStack на основе ожидаемого объёма приёма. Полученные значения являются **лишь оценками** и должны использоваться как **начальная отправная точка** — это не готовая рекомендация. Фактические требования зависят от сложности запросов, параллелизма, политик хранения и колебаний пропускной способности ингестии. Всегда отслеживайте использование ресурсов и при необходимости масштабируйте систему. **Все значения основаны на несжатом исходном объёме приёма** Все значения на этой странице — пропускная способность (MB/s, TB/month), размер CPU и хранилища — выражены в терминах **несжатого исходного объёма приёма**, то есть объёма данных в том виде, в котором они создаются вашими приложениями и отправляются в OpenTelemetry Collector до применения какого-либо сжатия. Именно эту величину следует оценивать по вашим существующим конвейерам журналов, трассировок и метрик. Значения хранилища в таблице ниже уже рассчитаны с учётом предполагаемого **коэффициента сжатия 10x**, применённого к этому исходному объёму. При развертывании ClickStack закладывайте вычислительные ресурсы на две независимые рабочие нагрузки: **приём** и **запросы**. | Рабочая нагрузка | Оценка ресурсов | | - | - | | **Ingest** | 1 vCPU на каждые 10 MB/s устойчивой пропускной способности приёма | | **Query** | 1 vCPU на 1 QPS и на каждые 10 MB/s устойчивой пропускной способности приёма | **Изоляция запросов и приёма** В большинстве самоуправляемых развертываний приём и запросы используют одни и те же узлы. В этом случае используйте **общее число CPU** как отправную точку. Изолированное масштабирование — когда вычислительные ресурсы для приёма и запросов выделяются независимо — поддерживается в ClickHouse Cloud через [отдельные вычислительные пулы, то есть Warehouses](/ru/products/cloud/features/infrastructure/warehouses). * Для хранилища предполагается **коэффициент сжатия 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**, который уже поддерживает другие рабочие нагрузки, например аналитику приложений в реальном времени, настоятельно рекомендуется изолировать трафик обсервабилити. Используйте [**Управляемые хранилища**](/ru/products/cloud/features/infrastructure/warehouses), чтобы создать **дочерний сервис**, выделенный под ClickStack. Это позволяет: * Изолировать нагрузку от приёма данных и запросов существующих приложений * Независимо масштабировать рабочие нагрузки обсервабилити * Не допускать влияния запросов обсервабилити на аналитику в продакшне * При необходимости использовать одни и те же базовые данные в разных сервисах Такой подход гарантирует, что существующие рабочие нагрузки не пострадают, а ClickStack сможет масштабироваться независимо по мере роста объёма данных обсервабилити. Эту же возможность можно использовать, чтобы выделить рассчитанные выше вычислительные ресурсы для приёма данных и для запросов в виде отдельных сервисов, которые можно масштабировать независимо друг от друга. См. наше руководство [Изоляция рабочих нагрузок чтения и записи](/ru/clickstack/managing/isolating-read-write). Для крупных развертываний или рекомендаций по индивидуальному сайзингу обратитесь в службу поддержки, чтобы получить более точную оценку.