Skip to main content

Что такое разделение вычислительных ресурсов?

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

Рис. 1 — Один сервис в ClickHouse Cloud Вместо одного сервиса можно создать несколько сервисов с доступом к одному и тому же общему хранилищу. Это позволяет выделять ресурсы под конкретные рабочие нагрузки без дублирования данных. Эта концепция называется разделением вычислительных ресурсов. Разделение вычислительных ресурсов означает, что у каждого сервиса есть собственный набор реплик и конечная точка, но при этом все они используют одну и ту же папку в объектном хранилище и получают доступ к одним и тем же таблицам, представлениям и т. д. Это означает, что вы можете подобрать подходящий объем вычислительных ресурсов для своей рабочей нагрузки. Для одних рабочих нагрузок достаточно одной небольшой реплики, а другим могут потребоваться высокая доступность (HA) и сотни гигабайт памяти на нескольких репликах. Разделение вычислительных ресурсов также позволяет отделить операции чтения от операций записи, чтобы они не мешали друг другу:
Рис. 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 реплик. На уровнях Scale и Enterprise основные и вторичные сервисы с одной репликой доступны без обращения в службу поддержки. Сервисы Scale и Enterprise со стандартными профилями 1:4 поддерживают вертикальное автоматическое масштабирование в режиме самообслуживания, тогда как для сервисов Enterprise с пользовательскими профилями изменение размера по вертикали выполняется с помощью службы поддержки. Размер сервисов уровня Basic не изменяется. Подробнее см. в разделе Крупные сервисы с одной репликой. По умолчанию общее количество реплик во всех сервисах хранилища ограничено 50. Подробнее см. в разделе ограничения использования. Чтобы увеличить лимит, обратитесь в службу поддержки. Запланированное масштабирование работает для отдельных сервисов в хранилище. Ограничения хранилища по-прежнему действуют — планируйте расписания так, чтобы суммарное количество реплик во всех сервисах в периоды пиковой нагрузки не превышало лимит хранилища. Подробнее см. в разделе Автоматическое масштабирование.

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

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

Ограничения

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

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

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

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

Цены

Стоимость вычислительных ресурсов одинакова для всех сервисов в хранилище (основного и вторичных). Плата за хранение данных взимается только один раз — она включена в первый (исходный) сервис. Воспользуйтесь калькулятором цен на странице pricing, чтобы оценить стоимость с учетом размера вашей рабочей нагрузки и выбранного уровня. В таблице Usage Breakdown будет показана разбивка затрат на вычислительные ресурсы по сервисам.

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

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

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

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

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

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

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

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

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