Хранилища

Прежде чем разбирать, что такое разделение вычислительных ресурсов, полезно понять, что в 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 — Сервисы с возможностью чтения и записи и только для чтения в хранилище

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

Сервисы, включая основной сервис, могут работать с одной репликой, однако для продакшна это не рекомендуется — для высокой доступности используйте не менее 2 реплик. На уровнях Scale и Enterprise основные и вторичные сервисы с одной репликой доступны без обращения в службу поддержки. Сервисы Scale и Enterprise со стандартными профилями 1:4 поддерживают вертикальное автоматическое масштабирование в режиме самообслуживания, тогда как для сервисов Enterprise с пользовательскими профилями изменение размера по вертикали выполняется с помощью службы поддержки. Размер сервисов уровня Basic не изменяется. Подробнее см. в разделе Крупные сервисы с одной репликой.

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

Запланированное масштабирование работает для отдельных сервисов в хранилище. Ограничения хранилища по-прежнему действуют — планируйте расписания так, чтобы суммарное количество реплик во всех сервисах в периоды пиковой нагрузки не превышало лимит хранилища. Подробнее см. в разделе Автоматическое масштабирование.

Когда в хранилище появляется несколько сервисов, поведение 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

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

• Переход основного сервиса в режим простоя: автоматический переход основного сервиса в режим простоя включен по умолчанию.

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

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

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

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

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

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

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

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

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

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