Вычислительные ресурсы ClickHouse по требованию

Добавляйте вычислительные ресурсы для рабочих нагрузок ClickHouse Cloud без изменения размера основного сервиса. В закрытой предварительной версии поддерживаются только отдельные типы запросов.

On-Demand Compute доступен в виде закрытой предварительной версии. На него не распространяются SLO и SLA ClickHouse Cloud, кроме того, могут действовать известные и неизвестные ограничения. См. Ограничения.

Записаться в список ожидания.

On-Demand Compute — это возможность ClickHouse Cloud, которая предоставляет вашему облачному сервису (тенанту) дополнительную и мгновенно доступную мощность для поддерживаемых рабочих нагрузок без изменения размера сервиса и без создания ещё одного. Эта работа выполняется на воркерах ClickHouse, вне собственных вычислительных ресурсов вашего сервиса. Воркеры берутся из управляемого пула, общего для всех тенантов в одном регионе, однако каждый воркер в один момент времени назначается только одному тенанту.

В период закрытой предварительной версии On-Demand Compute поддерживает только запросы SELECT. Вы подключаете запрос к этому механизму с помощью настроек уровня запроса, сеанса или пользователя, а ClickHouse назначает воркеры из пула для его выполнения через ваш существующий сервис и конечную точку.

Этим она отличается от разделения вычислительных ресурсов (compute-compute separation). Хранилище предоставляет выделенные долгоживущие вычислительные ресурсы через несколько сервисов, использующих общие данные. On-Demand Compute же предоставляет временные воркеры из общего пула через ваш существующий сервис.

On-Demand Compute использует совершенно новые возможности:

• Выполнение запросов без сохранения состояния на вычислительных ресурсах по требованию
• Новый CBO (оптимизатор на основе стоимости)
• Новое выполнение распределённого запроса

​

Когда использовать On-Demand Compute

В период закрытой предварительной версии используйте On-Demand Compute для подходящих ресурсоёмких запросов SELECT, которые вы хотите выполнять вне вычислительных ресурсов основного сервиса:

• Ad hoc и аналитические запросы: выполняйте ресурсоёмкие запросы SELECT на дополнительных воркерах.
• Некритичные рабочие нагрузки чтения: перенесите отдельные операции чтения с основного сервиса.
• Запросы к озеру данных: обращайтесь к поддерживаемым данным Apache Iceberg, Delta Lake или SharedMergeTree на дополнительных воркерах.
• Временные дополнительные вычислительные ресурсы: запрашивайте воркеры для подходящих запросов, не меняя размер основного сервиса.

Закрытая предварительная версия поддерживает только запросы SELECT. Воркеры не выполняют запросы INSERT, DDL, мутации и фоновые операции.

​

Как это работает

1. Вы отправляете подходящий SELECT-запрос в свой сервис ClickHouse Cloud, запрашивая определённое число воркеров. Ваша конечная точка, аутентификация и конфигурация RBAC при этом не меняются
2. Затем ваш кластер подключается к пулу и запрашивает указанное число воркеров
3. Воркеры арендуются на срок не менее 60 секунд; если запрос выполняется дольше, аренда продлевается автоматически
4. Воркеры получают запрос и выполняют его
5. Затем ответ отправляется обратно вашему клиенту
6. Воркеры очищаются.

В период закрытой предварительной версии каждый воркер располагает 8 vCPUs и 32 GiB памяти. Число воркеров, запрашиваемых запросом, задаётся параметром distributed_plan_workers_num.

​

Использование On-Demand Compute

​

Настройки

Используйте эти настройки, чтобы начать работу с On-Demand Compute:

Настройка	Требуемое значение	Назначение
make_distributed_plan	Yes	Включает экспериментальный distributed query plan. Требуется для On-Demand Compute.
distributed_plan_workers_num	Yes	Количество воркеров, арендуемых для этого запроса. Если значение равно 0 (значение по умолчанию), запрос выполняется на вашем сервисе, а не в пуле воркеров.
enable_parallel_replicas	Yes (установите 0)	Параллельные реплики несовместимы с distributed plan.
distributed_plan_fallback_to_local_execution	No (по умолчанию 0)	Позволяет вернуться к локальному выполнению, если план не удаётся распределить (действует только при включённом make_distributed_plan)

В период предварительного доступа задавайте настройки на уровне запроса либо создайте отдельного пользователя с другими настройками. Тогда сразу видно, какие операторы используют On-Demand Compute.

​

Пример

Некоторые запросы нельзя распределить между воркерами:

SELECT count()
FROM nyctaxi.trips
SETTINGS distributed_plan_fallback_to_local_execution = 0, make_distributed_plan = 1, distributed_plan_workers_num = 5

Query id: c1c96ede-0c4c-414f-b103-f27f0b7d34c7


Elapsed: 0.992 sec.

Received exception from server (version 26.9.1):
Code: 344. DB::Exception: Received from nuqae0jhz5.eu-west-1.aws.clickhouse-staging.com:9440. DB::Exception: make_distributed_plan cannot distribute this query: it contains the step ReadFromPreparedSource which could not execute remotely. (SUPPORT_IS_DISABLED)

Чтобы запросы гарантированно переключались на локальное выполнение, если распределённое выполнение невозможно, используйте настройку distributed_plan_fallback_to_local_execution:

SELECT count()
FROM nyctaxi.trips
SETTINGS distributed_plan_fallback_to_local_execution = 1, make_distributed_plan = 1, distributed_plan_workers_num = 5

Query id: c7b09855-e3c3-40ef-9790-5374e0726f26

   ┌─count()─┐
1. │   21932 │
   └─────────┘

1 row in set. Elapsed: 0.896 sec.

SELECT
    sum(l_extendedprice * l_discount) AS revenue
FROM lineitem
WHERE
    l_shipdate >= DATE '1994-01-01'
    AND l_shipdate < DATE '1994-01-01' + INTERVAL 1 YEAR
    AND l_discount BETWEEN 0.06 - 0.01 AND 0.06 + 0.01
    AND l_quantity < 24
SETTINGS
    make_distributed_plan = 1,
    distributed_plan_workers_num = 5,
    enable_parallel_replicas = 0

Этот запрос запрашивает пять воркеров. Количество воркеров, которое выделит ClickHouse, зависит от ограничений закрытой предварительной версии и доступной ёмкости пула.

​

Одновременные запросы

Одновременные запросы одного и того же сервиса ClickHouse Cloud могут совместно использовать назначенные воркеры. ClickHouse запрашивает дополнительные воркеры только в том случае, если запросу требуется больше воркеров, чем уже назначено сервису.

Например, если два одновременных запроса требуют по три воркера каждый, они могут использовать одни и те же три воркера. Если ещё один запрос потребует пять воркеров, ClickHouse может задействовать три уже назначенных воркера и запросить ещё два из пула.

См. пример ниже:

SELECT ... SETTINGS make_distributed_plan = 1, distributed_plan_workers_num = 3, ...;
SELECT ... SETTINGS make_distributed_plan = 1, distributed_plan_workers_num = 3, ...;

Они используют одни и те же три воркера.

Если третий параллельный запрос затребует пять воркеров:

SELECT ... SETTINGS make_distributed_plan = 1, distributed_plan_workers_num = 5, ...;

Этот запрос выполняется на трёх уже имеющихся воркерах и двух только что арендованных.

​

Когда пул не может удовлетворить запрос

В период закрытой предварительной версии доступность воркеров не гарантируется. Если доступно меньше воркеров, чем запрошено, запрос выполняется с теми воркерами, которые может выделить ClickHouse. Например, запрос на пять воркеров может быть выполнен с тремя.

Если не удаётся получить ни одного воркера, запрос завершается с ошибкой.

Повторите запрос. Если проблема сохраняется, обратитесь к команде сопровождения аккаунта ClickHouse — возможно, пул предварительной версии исчерпан или неверно масштабирован.

​

Monitoring

Используйте system.query_log в вашем сервисе, чтобы узнать, сколько воркеров было выделено для вашего запроса.

​

Количество выделенных воркеров

SELECT
    ProfileEvents['StatelessWorkerRequested'],
    ProfileEvents['StatelessWorkerProvided']
FROM clusterAllReplicas(default, system.query_log)
WHERE query_id = '<YOUR_QUERY_ID>'
  AND type != 'QueryStart';

Задайте log_comment = 'on-demand' (или имя рабочей нагрузки) для запросов On-Demand, чтобы фильтровать их без разбора Settings.

SELECT
    sum(l_extendedprice * l_discount) AS revenue
FROM lineitem
WHERE
    l_shipdate >= DATE '1994-01-01'
    AND l_shipdate < DATE '1994-01-01' + INTERVAL 1 YEAR
    AND l_discount BETWEEN 0.06 - 0.01 AND 0.06 + 0.01
    AND l_quantity < 24
SETTINGS
    make_distributed_plan = 1,
    distributed_plan_workers_num = 5,
    enable_parallel_replicas = 0,
    log_comment = 'on-demand-private-preview'

​

Доступные регионы

On-Demand Compute привязан к регионам: воркеры выполняются в том же регионе, что и ваш сервис.

Cloud	Регион	Примечания
AWS	us-east-1
AWS	eu-west-1

Если вашего региона нет в списке, запросите его в листе ожидания. Мы будем подключать новые регионы по мере роста спроса.

​

Тарификация

В период закрытой предварительной версии функция On-Demand Compute бесплатна, но с ограничением по объёму использования (см. Ограничения). Если вам требуется увеличить это ограничение, обратитесь к команде сопровождения аккаунта ClickHouse.

Тарификация появится после завершения предварительной версии. Участники предварительной версии получат уведомление до перевода функции в статус бета и до начала взимания платы.

Предполагается та же модель, что и для вычислительных ресурсов ClickHouse Cloud: вы платите за используемые вычислительные ресурсы (арендованное время воркеров), а не за объём просканированных данных или число прочитанных строк.

​

Ограничения

Приведённые ниже ограничения действуют в период закрытой предварительной версии. Возможны и другие ограничения. О непредвиденном поведении сообщайте в ClickHouse Support или команде сопровождения аккаунта ClickHouse.

• Только запросы SELECT. Воркеры не выполняют запросы INSERT, мутации, DDL и фоновые операции.
• Поддерживаемый формат. Закрытая предварительная версия поддерживает Apache Iceberg, Delta Lake и SharedMergeTree.
• Параллельные реплики. Параллельные реплики должны быть отключены.
• Размер воркера. Каждый воркер имеет 8 vCPUs и 32 GiB памяти.
• Ограничение на число воркеров. В период закрытой предварительной версии каждый запрос может запросить не более пяти воркеров.
• Ёмкость пула. Доступность воркеров не гарантируется. Запрос может получить меньше воркеров, чем запрашивалось. Если свободных воркеров нет, запрос завершается ошибкой.
• Производительность. Производительность зависит от запроса. Назначение воркеров, распределённое планирование и передача этапов плана могут увеличивать задержку. Некоторые виды запросов могут выполняться медленнее, чем на основном сервисе (типичные запросы, выполняющиеся менее секунды, скорее всего, будут работать быстрее в вашем кластере)
• Совместимость запросов. Распределённый планировщик способен выполнить удалённо не любой план запроса. Для неподдерживаемых запросов может возвращаться исключение SUPPORT_IS_DISABLED.

​

Roadmap

On-Demand Compute — это основа. Что уже в работе или запланировано далее:

• Устранение известных ограничений (пробелы, связанные с SUPPORT_IS_DISABLED)
• Пулы воркеров разных размеров
• Стабилизация производительности запросов до уровня выполнения с сохранением состояния
• Поддержка фоновых слияний
• Тарификация
• Калибровка автомасштабирования пула воркеров
• Встроенное обсервабилити
• Отдельные разрешения для On-Demand Compute
• Расширение рабочих нагрузок для озёр данных (запись, compaction и т. д.)

​

Security

Воркеры берутся из предварительно прогретого пула, общего для всех сервисов в одном регионе, поэтому действует одно безусловное правило: воркер обслуживает только один сервис одновременно и никогда не передаётся от одного сервиса другому.

Способ подключения к ClickHouse при этом не меняется. Клиенты по-прежнему подключаются к конечной точке вашего сервиса с прежней аутентификацией, и только ваш сервис взаимодействует с воркерами от вашего имени. У воркеров нет конечных точек, доступных клиентам.

• Один сервис на воркер: воркер арендуется единственным сервисом на всё время аренды. Он никогда не используется двумя сервисами одновременно.
• Никакого повторного использования между сервисами: по завершении аренды воркер уничтожается и заменяется новым. Воркер никогда не переназначается другому сервису.
• Никаких сохраняемых данных: у воркеров нет постоянного хранилища, и они не переживают окончание аренды.
• Тот же регион, что и у вашего сервиса: воркеры работают в том же регионе, что и сервис, который их арендует, в соответствии со строгими правилами резидентности данных.
• Существующее управление доступом продолжает действовать: IP Access List и частные конечные точки управляют доступом к конечной точке вашего сервиса ровно так же, как и раньше. On-Demand Compute не добавляет конечных точек, которые нужно настраивать или защищать.
• Существующая аутентификация и RBAC: запросы выполняются от имени того же пользователя и с теми же привилегиями, что и любой другой запрос в вашем сервисе. У воркеров нет отдельной модели идентичности или разрешений.

​

Сетевая изоляция

Пока воркер арендован вашим сервисом, платформа разрешает сетевой трафик между этим воркером и вашим сервисом и блокирует всё остальное. Ограничение применяется на сетевом уровне, а не в движке запросов, поэтому оно не зависит ни от самого запроса, ни от его настроек, ни от плана, который строит оптимизатор.

• Доступ к вашим воркерам есть только у вашего сервиса. Путь существует на время текущей аренды воркера и только для этого сервиса.
• Неназначенные воркеры недоступны. У воркера, ожидающего в пуле, нет сетевого пути ни к одному сервису и обратно, пока он не арендован.
• Воркеры, арендованные разными сервисами, не могут связаться друг с другом. Воркеры в рамках одной аренды обмениваются между собой этапами плана и промежуточными результатами. Воркеры из разных аренд остаются изолированными друг от друга, даже если используют общий пул.
• Путь удаляется вместе с воркером. Завершение аренды уничтожает воркер, а вместе с ним исчезает и единственный получатель, к которому был разрешён трафик.
• Путь для запросов остаётся узким. Ваш сервис обращается к сервису назначения воркеров, чтобы арендовать воркеры и продлевать аренду. По этому пути не передаются данные запросов, и он ограничен API назначения.

​

Внутренняя аутентификация и авторизация

Сетевая изоляция определяет, кто может добраться до воркера. Аутентификация определяет, что вызывающей стороне разрешено делать после того, как она до него добралась, и эти два механизма применяются независимо друг от друга: вызывающая сторона должна удовлетворять обоим.

Каждое соединение между вашим сервисом, службой назначения воркеров и самими воркерами аутентифицируется. Ничто не считается доверенным: все учётные данные выпускаются платформой и выдаются отдельно на каждую аренду.

• Отдельные учётные данные для каждого воркера: когда воркеры арендуются вашим сервисом, платформа выпускает для каждого из них уникальный подписанный токен. Токен действует только для этого конкретного воркера и только для вашего сервиса.
• Короткий срок жизни и привязка к аренде: срок действия токенов истекает вместе с породившей их арендой. При продлении аренды выпускаются новые токены, а после её завершения старые токены больше ничего не аутентифицируют.
• Проверка через платформу: воркер проверяет предъявленный ему токен в службе идентификации платформы, а не доверяет данным, переданным в запросе.

Соединение	Что аутентифицируется
Ваш сервис → служба назначения воркеров	Идентичность вашего сервиса на платформе, которая определяет, с какими арендами он может работать.
Ваш сервис → арендованный им воркер	Подписанный токен, действующий только для этого воркера и только на время аренды.
Воркер → воркер в рамках одной аренды	Собственная идентичность каждого воркера на платформе, а также проверка того, что вызывающая сторона по-прежнему удерживает активную аренду на принимающий воркер.

Эти учётные данные являются внутренними и относятся к тому, как ClickHouse Cloud выполняет ваш запрос. Они никогда не раскрываются вашим клиентам и никак не связаны с тем, как вы аутентифицируетесь в ClickHouse: клиенты по-прежнему подключаются со своими существующими учётными данными, а привилегии на запросы всё так же регулируются RBAC вашего сервиса.

​

FAQ

Является ли On-Demand Compute решением с открытым исходным кодом?

Нет. Это архитектура ClickHouse Cloud: ClickHouse server (distributed plan), data plane (пул воркеров и аренды) и control plane. Экспериментальная настройка make_distributed_plan и CBO есть и в ClickHouse OSS, однако общий пул воркеров и stateless-выполнение доступны только в Cloud.

Нужна ли определённая версия для участия в закрытой предварительной версии?

Да. В ходе закрытой предварительной версии используется специальная сборка. За это время могут потребоваться дополнительные обновления.

Каким будет ценообразование?

Пока нам нечего сообщить о публичных тарифах. Однако в период закрытой предварительной версии эта возможность предоставляется бесплатно. При этом принцип ценообразования будет тем же, что и в ClickHouse Cloud: плата взимается за использованные вычислительные ресурсы, а не за объём просканированных данных или число прочитанных строк. Точные ставки будут опубликованы до введения тарификации.

Можно ли использовать это в продакшне?

Реальные рабочие нагрузки запускать можно, но это закрытая предварительная версия: есть известные и неизвестные ограничения, а SLO/SLA на доступность пула воркеров отсутствуют.

Чем это отличается от автомасштабирования моего сервиса?

Автомасштабирование изменяет объём вычислительных ресурсов, выделенных вашему основному сервису. В период закрытой предварительной версии On-Demand Compute предоставляет подходящим запросам SELECT временный доступ к воркерам из управляемого пула без изменения размера основного сервиса. Автомасштабирование управляет постоянной ёмкостью сервиса, тогда как On-Demand Compute даёт временные вычислительные ресурсы под конкретные рабочие нагрузки.

Где можно задать вопросы?

Обратитесь к команде сопровождения аккаунта ClickHouse; она познакомит вас с менеджером продукта On-Demand Compute.

Куда сообщать об ошибках?

Создайте обращение в поддержку (уровень серьёзности 3) или сообщите менеджеру продукта. Укажите query_id, идентификатор вашего сервиса и полный текст исключения.

Может ли другой сервис ClickHouse Cloud получить доступ к воркерам, выполняющим мой запрос?

Нет. Пока воркер арендован вашим сервисом, платформа разрешает трафик только между этим воркером и вашим сервисом и блокирует его для всех остальных сервисов. У неназначенных воркеров и воркеров, арендованных другим сервисом, нет сетевого маршрута к вашему. См. раздел Сетевая изоляция.

Будет ли воркер повторно использован другим сервисом после завершения моего запроса?

Нет. По окончании аренды воркер уничтожается и заменяется новым, а не передаётся следующему сервису.

Доступно ли это в ClickHouse BYOC или ClickHouse Private?

Нет. Закрытая предварительная версия недоступна в ClickHouse BYOC и ClickHouse Private.