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

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

​

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

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

​

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

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

​

Использование 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)

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

​

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

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, ...;

​

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

​

Monitoring

​

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

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

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'

​

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

​

Тарификация

​

Ограничения

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

​

Roadmap

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

​

Security

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

​

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

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

​

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

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

​

FAQ