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

​

Зачем изолировать чтение от записи

• Запись больше не ухудшает чтение. Непрерывная ингестия OpenTelemetry — сами вставки и следующие за ними фоновые слияния — конкурирует с запросами панелей мониторинга и поиска за CPU и память. Пока идёт ингестия, задержка чтения может заметно вырастать, а после её остановки возвращается к норме.
• Чтение больше не мешает записи. Конкуренция работает в обе стороны: тяжёлый ad-hoc запрос или ресурсоёмкая отрисовка панели мониторинга могут исчерпать память сервиса, и вставки не просто замедлятся, а полностью завершатся ошибкой.
• Вычислительные ресурсы только для чтения полностью отданы запросам. Сервисы только для чтения не выполняют фоновых слияний за пределами системных таблиц. Кроме того, они переходят в простой без задержки — в отличие от сервисов с возможностью чтения и записи, которые слияния могут удерживать в активном состоянии.
• Каждая сторона рассчитывается отдельно. Модель оценки ресурсов оценивает вычислительные ресурсы для приёма и для запросов по отдельности, а хранилище позволяет выделить под каждую задачу собственный сервис. Выше заложенного в модели базового уровня в 1 QPS преобладают вычислительные ресурсы под запросы: в разобранном примере при 5 QPS получается 58 vCPU на приём против 290 на запросы — то есть небольшой сервис записи может обслуживать значительно более крупный сервис чтения.
• Простой и autoscaling настраиваются для каждого сервиса отдельно. У каждого сервиса своё количество реплик и свои настройки автомасштабирования и автоматического перехода в простой, поэтому сервис записи может работать постоянно для непрерывной ингестии, а сервис чтения — простаивать в нерабочие часы.
• Хранилище не дублируется. Сервисы в составе хранилища используют одну и ту же папку объектного хранилища и одни и те же таблицы, а хранилище оплачивается только один раз.
• Доступ можно ограничить для каждой конечной точки. IP Access List применяются к каждому сервису отдельно, поэтому конечная точка записи может быть доступна только с ваших коллекторов, а конечная точка чтения — только из вашего развертывания ClickStack. См. наше руководство по управлению сетевым доступом.

​

Архитектура

• Первый сервис в хранилище всегда создаётся с возможностью чтения и записи, а тип сервиса задаётся при создании и не меняется — чтобы перейти от режима только для чтения к режиму чтения и записи (или наоборот), создайте в хранилище новый сервис.
• Все сервисы в хранилище используют одного облачного провайдера, один регион, одну версию ClickHouse и один Keeper, а также расписание обновлений основного сервиса.
• Для ингестии используйте один сервис с возможностью чтения и записи. Слияния распределяются между всеми сервисами с возможностью чтения и записи, которые используют общее хранилище, поэтому слияние для вставки на одном сервисе может быть выполнено другим. Если этот другой сервис при этом обслуживает тяжёлые запросы, они будут конкурировать со слиянием за CPU и память на том сервисе, где оно выполняется, — тем самым замедляя слияния для вставок первого сервиса, а вместе с ними и производительность вставки. Оставьте запросные рабочие нагрузки на сервисе только для чтения и добавляйте второй сервис с возможностью чтения и записи только в том случае, если требуется отделить слияния от ингестии.

​

Настройка изолированного развертывания

CREATE DATABASE otel;
CREATE USER hyperdx_ingest IDENTIFIED WITH sha256_password BY '<strong-password>';
GRANT SELECT, INSERT, CREATE DATABASE, CREATE TABLE, CREATE VIEW ON otel.* TO hyperdx_ingest;

CLICKHOUSE_ENDPOINT=https://<read-write-service>.clickhouse.cloud:8443
CLICKHOUSE_USER=hyperdx_ingest
CLICKHOUSE_PASSWORD=<strong-password>
HYPERDX_OTEL_EXPORTER_CLICKHOUSE_DATABASE=otel

SELECT 
    user, 
    query_kind, 
    http_user_agent,
    count()
FROM clusterAllReplicas('default', system.query_log)
WHERE event_time > now() - toIntervalMinute(10) 
  AND type = 'QueryFinish'
  AND is_initial_query = 1
GROUP BY ALL
ORDER BY count() DESC;

SELECT 
    hostName() AS host, 
    query_kind, 
    count()
FROM clusterAllReplicas('all_groups.default', system.query_log)
WHERE event_time > now() - toIntervalMinute(10) 
  AND type = 'QueryFinish'
  AND is_initial_query = 1
GROUP BY ALL;

​

Разделение слияний и ингестии

• Не полагайтесь на автоматический переход в режим ожидания ни для одного из сервисов с возможностью чтения и записи. Сервис с отключёнными слияниями всё равно обрабатывает события загрузки и удаления частей, порождаемые вставками в других местах хранилища, а большое количество неслитых частей само по себе может препятствовать переходу в режим ожидания. Рассчитывайте на то, что оба сервиса с возможностью чтения и записи будут постоянно активны.
• Не направляйте запросы ни на один из сервисов с возможностью чтения и записи. Тяжёлые запросы SELECT на таком сервисе конкурируют со слияниями за CPU и память — а именно этот сценарий отказа данная топология и позволяет избежать. Направьте ClickStack на сервис только для чтения, как описано выше.
• Мутации, если они у вас есть, отслеживаются на том сервисе, который их выполняет. В обсервабилити мутации редки: схема ClickStack задаёт ttl_only_drop_parts = 1, поэтому при обычном хранении данных во время TTL-слияний удаляются целые истёкшие части, а не вычищаются отдельные строки мутациями. Если вы всё же отправите на сервис приёма ALTER, порождающий мутацию, она будет выполнена сервисом слияний, и её прогресс появится в system.mutations именно там, а не на сервисе приёма.

​

Администрирование и DDL

• Создание таблиц — выполняется автоматически коллектором ClickStack при первом приёме данных
• Изменение TTL для настройки срока хранения
• Создание materialized view для ускорения запросов
• Добавление индексов пропуска данных, проекций и других оптимизаций производительности

CREATE DATABASE otel
SETTINGS distributed_ddl_task_timeout=0

​

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

claude mcp add --transport http clickstack https://mcp.clickhouse.cloud/clickstack \
  --header "x-service-id: <read-only-agent-service-id>"

​

Alerts

​

Изоляция вычисления оповещений

• Общие оповещения и связанные с ними панели мониторинга существуют только на сервисе оповещений и не видны пользователям, работающим с сервисом запросов. Уведомления в любом случае доставляются в те же пункты назначения, так что пользователи теряют из виду определения, а не сами оповещения.
• Источники на сервисе оповещений — это отдельные объекты. Те из них, что используют стандартную схему OpenTelemetry, определяются автоматически, но пользовательские источники нужно настроить и там, прежде чем оповещение сможет на них ссылаться.

​

Дополнительные замечания