Хранилища

Разделение вычислительных ресурсов в ClickHouse Cloud

​

Что такое compute-compute separation?

Прежде чем разбирать, что такое compute-compute separation, полезно понять, что в ClickHouse Cloud означает сервис.

Каждый сервис ClickHouse Cloud включает:

• вычислительные узлы ClickHouse (называемые репликами) с выделенными ресурсами CPU и памяти
• конечную точку (или несколько конечных точек, созданных через консоль ClickHouse Cloud) для подключения к сервису (например, https://dv2fzne24g.us-east-1.aws.clickhouse.cloud:8443) для локальных подключений и подключений сторонних приложений
• папку в объектном хранилище, где сервис хранит все данные и часть метаданных:

Рис. 1 — Один сервис в ClickHouse Cloud

Вместо одного сервиса можно создать несколько сервисов с доступом к одному и тому же общему хранилищу. Это позволяет выделять ресурсы под конкретные рабочие нагрузки без дублирования данных. Эта концепция называется compute-compute separation.

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

Compute-compute separation также позволяет отделить операции чтения от операций записи, чтобы они не мешали друг другу:

Рис. 2 — Разделение вычислительных ресурсов в ClickHouse Cloud

​

Что такое хранилище?

В ClickHouse Cloud хранилище — это набор сервисов, которые работают с одними и теми же данными. У каждого хранилища есть основной сервис (сервис, созданный первым) и один или несколько вторичных сервисов. Например, на снимке экрана ниже показано хранилище “DWH Prod”, состоящее из двух сервисов:

• Основной сервис DWH Prod
• Вторичный сервис DWH Prod Subservice

Рис. 3 — Пример хранилища

Все сервисы в хранилище имеют одинаковые:

• Region (например, us-east1)
• провайдера облачных услуг (AWS, GCP или Azure)
• версию базы данных ClickHouse
• ClickHouse Keeper (для управления репликами)

​

Управление доступом

​

Учетные данные для базы данных

Поскольку все сервисы в хранилище используют один и тот же набор таблиц, для них также действует общее управление доступом. Это означает, что все пользователи базы данных, созданные в Service 1, смогут использовать и Service 2 с теми же разрешениями (привилегиями на таблицы, представления и т. д.), и наоборот. Для каждого сервиса используется отдельная конечная точка, но одни и те же имя пользователя и пароль действуют во всех сервисах. Иными словами, пользователи общие для сервисов, работающих с одним и тем же хранилищем, как показано на рисунке ниже:

Рис. 4 — пользователь Alice создан в Service 1, но может использовать те же учетные данные для доступа ко всем сервисам, использующим одни и те же данные

​

Управление сетевым доступом

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

Параметры IP-фильтрации можно задавать отдельно для каждого сервиса, то есть вы можете контролировать, какое приложение к какому сервису имеет доступ. Это также позволяет запретить пользователям доступ к определённым сервисам.

В примере ниже Alice не имеет доступа к сервису 2 в хранилище:

Рис. 5 — Alice не может получить доступ к сервису 2 из-за настроек управления сетевым доступом

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

​

Сервисы только для чтения и с возможностью чтения и записи

Сервисы могут быть одного из следующих типов:

• с возможностью чтения и записи
  • Могут как читать, так и записывать данные в ClickHouse
  • Выполняют фоновые операции слияния (например, слияние частей после вставки данных), которые потребляют CPU и память
  • Могут экспортировать данные во внешние системы
• только для чтения
  • Могут только читать данные; записывать или изменять данные в ClickHouse они не могут
  • Не выполняют фоновые операции слияния вне системных таблиц, поэтому их ресурсы полностью выделены под запросы на чтение
  • По-прежнему могут экспортировать данные во внешние системы (например, через табличные функции), но не могут изменять данные внутри ClickHouse
  • Переходят в состояние бездействия без задержки, в отличие от сервисов с возможностью чтения и записи, которые фоновые слияния могут удерживать активными

Иногда требуется изолировать критически важные рабочие нагрузки на чтение от накладных расходов на запись и слияние, сделав сервис доступным только для чтения. Это можно сделать для второго сервиса и любых дополнительных сервисов, которые вы создадите; однако первый сервис всегда будет с возможностью чтения и записи, как показано на рисунке ниже:

Рис. 6 — Сервисы с возможностью чтения и записи и только для чтения в хранилище

1. Сервисы только для чтения в настоящее время поддерживают операции управления пользователями (CREATE, DROP и т. д.).
2. Refreshable materialized views выполняются только на сервисах с возможностью чтения и записи (RW) в хранилище.
3. Тип сервиса (только для чтения или с возможностью чтения и записи) фиксируется при создании и впоследствии не может быть изменён через Cloud Console. Чтобы переключиться между режимами только для чтения и чтения/записи, создайте в хранилище новый сервис нужного типа.

​

Масштабирование

Каждый сервис в хранилище можно настроить под вашу рабочую нагрузку по следующим параметрам:

• Количество узлов (реплик). Основной сервис (сервис, который был создан в хранилище первым) должен иметь 2 или более узла. Каждый вторичный сервис может иметь 1 или более узлов.
• Размер узлов (реплик)
• Должен ли сервис автоматически масштабироваться (по горизонтали и по вертикали)
• Должен ли сервис переводиться в режим простоя при отсутствии активности

Дополнительные сведения см. на странице “Автомасштабирование”.

​

Изменения в поведении clusterAllReplicas

Когда в хранилище появляется несколько сервисов, поведение clusterAllReplicas() меняется. При использовании имени кластера default запрос будет выполняться только для реплик текущего сервиса, а не для всех сервисов в хранилище.

Например, если вы вызываете clusterAllReplicas(default, system, processes) из сервиса 1, будут возвращены только процессы, выполняющиеся на сервисе 1. Чтобы выполнять запросы по всем сервисам в хранилище, используйте имя кластера all_groups.default:

SELECT * FROM clusterAllReplicas('all_groups.default', system, processes)

Вторичные одноузловые сервисы могут вертикально масштабироваться, тогда как основные одноузловые сервисы — нет.

​

Ограничения

​

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

Некоторые рабочие нагрузки нельзя изолировать на уровне конкретных сервисов; в отдельных случаях рабочая нагрузка в одном сервисе может влиять на другой сервис в хранилище. К ним относятся:

• Все сервисы с возможностью чтения и записи по умолчанию выполняют фоновые операции слияния. При вставке данных в ClickHouse база данных сначала записывает данные в промежуточные партиции, а затем выполняет слияния в фоновом режиме. Эти слияния могут потреблять ресурсы памяти и ЦП. Когда два сервиса с возможностью чтения и записи используют общее хранилище, оба выполняют фоновые операции. Это означает, что возможна ситуация, когда запрос INSERT выполняется в сервисе 1, а операция слияния завершается сервисом 2. Обратите внимание, что сервисы только для чтения не выполняют фоновые слияния и, следовательно, не тратят на это свои ресурсы. По запросу наша служба поддержки может отключить слияния для сервиса.

• Все сервисы с возможностью чтения и записи выполняют операции вставки для движка таблицы S3Queue. При создании таблицы S3Queue на сервисе с возможностью чтения и записи все остальные сервисы с возможностью чтения и записи в хранилище также могут читать данные из S3 и записывать их в базу данных.

• Вставки в одном сервисе с возможностью чтения и записи могут мешать другому сервису с возможностью чтения и записи перейти в режим простоя, если включен режим простоя. Бывают ситуации, когда один сервис выполняет фоновые операции слияния для другого сервиса. Эти фоновые операции могут мешать второму сервису перейти в режим простоя. После завершения фоновых операций сервис перейдет в режим простоя. Сервисы только для чтения этому не подвержены.

​

Полезные примечания

• Версии ClickHouse: График обновлений определяется настройками основного сервиса. У вторичных сервисов не может быть собственного графика релизов, независимого от основного сервиса.

• Запросы CREATE/RENAME/DROP DATABASE по умолчанию могут блокироваться, если сервис переведён в режим простоя или остановлен. Если выполнять эти запросы, когда сервис находится в режиме простоя или остановлен, они могут зависнуть. Чтобы избежать этого, можно запускать запросы управления базой данных с settings distributed_ddl_task_timeout=0 на уровне сеанса или отдельного запроса.

Например:

CREATE DATABASE db_test_ddl_single_query_setting
SETTINGS distributed_ddl_task_timeout=0

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

• Основной сервис с одной репликой Сегодня по умолчанию вторичные сервисы могут иметь одну реплику, а основной сервис — как минимум две. Чтобы включить основной сервис с одной репликой, обратитесь в службу поддержки. По умолчанию эта возможность будет включена во II квартале 2026 года.
• Переход основного сервиса в режим простоя: автоматический переход основного сервиса в режим простоя включен по умолчанию.

​

Цены

Стоимость вычислительных ресурсов одинакова для всех сервисов в хранилище (основного и вторичных). Плата за хранение данных взимается только один раз — она включена в первый (исходный) сервис.

Воспользуйтесь калькулятором цен на странице pricing, чтобы оценить стоимость с учетом размера вашей рабочей нагрузки и выбранного уровня. В таблице Usage Breakdown будет показана разбивка затрат на вычислительные ресурсы по сервисам.

​

Резервные копии

• Поскольку все сервисы в одном хранилище используют общее хранилище данных, резервные копии создаются только на основном (исходном) сервисе. Таким образом выполняется резервное копирование данных всех сервисов в этом хранилище.
• Если вы восстановите резервную копию с основного сервиса хранилища, она будет восстановлена в совершенно новом сервисе, не связанном с существующим хранилищем. Затем, сразу после завершения восстановления, вы сможете добавить к нему дополнительные сервисы.

​

Как настроить хранилище

​

Создание хранилища

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

Рис. 7 — Нажмите значок плюса, чтобы создать новый сервис в хранилище

На экране создания сервиса в раскрывающемся списке в качестве источника данных для нового сервиса будет выбран исходный сервис. После создания эти два сервиса образуют хранилище.

​

Переименование хранилища

Переименовать хранилище можно двумя способами:

• На странице сервисов в правом верхнем углу выберите “Сортировать по хранилищу”, затем нажмите значок карандаша рядом с названием хранилища
• Нажмите название хранилища в любом из сервисов и переименуйте его там

​

Удаление хранилища

Удаление хранилища означает удаление всех вычислительных сервисов и данных (таблиц, представлений, пользователей и т. д.). Это действие нельзя отменить. Удалить хранилище можно только удалив первый созданный сервис. Для этого:

1. Удалите все сервисы, созданные помимо сервиса, который был создан первым;
2. Удалите первый сервис (предупреждение: на этом шаге будут удалены все данные хранилища).