Хранилища

Scale plan feature

Разделение вычислительных ресурсов (compute-compute) is available in the Scale and Enterprise plans. To upgrade, visit the plans page in the cloud console.

Что такое 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 — Пример хранилища

Все сервисы в хранилище используют общие:

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

Контроль доступа

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

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

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

Контроль сетевого доступа

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

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

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

Рис. 5 — Alice запрещен доступ к сервису 2 из-за настроек контроля сетевого доступа

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

Сервисы read-write и read-only

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

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

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

Рис. 6 — Сервисы read-write и read-only в warehouse

Примечание

1. Сервисы read-only в настоящее время поддерживают операции управления пользователями (CREATE, DROP и т. д.).
2. Refreshable materialized views выполняются только на сервисах read-write (RW) в warehouse.

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

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

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

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

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

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

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

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

Примечание

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

Ограничения

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

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

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

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

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

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

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

Например:

CREATE DATABASE db_test_ddl_single_query_setting
SETTINGS distributed_ddl_task_timeout=0

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

• В настоящее время действует мягкий лимит в 5 сервисов на один warehouse. Свяжитесь со службой поддержки, если вам требуется более 5 сервисов в одном warehouse.
• Основные сервисы не могут иметь только одну реплику Хотя вторичные сервисы могут иметь одну реплику, у основного сервиса должно быть как минимум 2.
• Переход основного сервиса в простой На данный момент поведение по умолчанию таково, что основной сервис не может автоматически переходить в простой. Эта возможность отключается после создания вторичного сервиса. Чтобы включить ее, обратитесь в службу поддержки и запросите включение перехода родительского сервиса в простой. Автоматический переход родительского сервиса в простой будет включен по умолчанию во 2 квартале 2026 года (существующие сервисы получат доступ к этой функции, а для новых сервисов она будет включена по умолчанию).

Цены

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

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

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

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

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

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

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

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

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

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

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

• Вы можете выбрать «Sort by warehouse» на странице сервисов в правом верхнем углу, а затем нажать на значок карандаша рядом с именем хранилища;
• Вы можете нажать на имя хранилища у любого из сервисов и переименовать хранилище там.

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

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

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