> ## Documentation Index
> Fetch the complete documentation index at: https://clickhouse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Хранилища

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

export const ScalePlanFeatureBadge = ({feature = 'Эта возможность', linking_verb_are = false}) => {
  return <div className="scalePlanFeatureContainer">
            <div className="scalePlanFeatureBadge">
                Возможность плана Scale
            </div>
            <div>
                <p>{feature} {linking_verb_are ? 'доступны' : 'доступна'} в тарифах Scale и Enterprise. Чтобы перейти на более высокий тариф, откройте страницу тарифов в облачной консоли.</p>
            </div>
        </div>;
};

export const Image = ({img, alt, size = "lg"}) => {
  const normalizedSize = ["sm", "md", "lg"].includes(size) ? size : "lg";
  return <div className={`ch-image-${normalizedSize}`}>
      <Frame>
        <img src={img} alt={alt} />
      </Frame>
    </div>;
};

<ScalePlanFeatureBadge feature="Разделение вычислительных ресурсов" />

<div id="what-is-compute-compute-separation">
  ## Что такое разделение вычислительных ресурсов?
</div>

Прежде чем разбирать, что такое разделение вычислительных ресурсов, полезно понять, что в ClickHouse Cloud означает **сервис**.

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

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

<Image img="https://mintcdn.com/private-7c7dfe99/5su3gw1SIJE0qay9/images/cloud/reference/compute-compute-1.webp?fit=max&auto=format&n=5su3gw1SIJE0qay9&q=85&s=731a3bd86df91d481e64a47266304a7d" size="md" alt="Один сервис в ClickHouse Cloud" width="1349" height="1100" data-path="images/cloud/reference/compute-compute-1.webp" />

<br />

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

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

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

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

<Image img="https://mintcdn.com/private-7c7dfe99/5su3gw1SIJE0qay9/images/cloud/reference/compute-compute-2.webp?fit=max&auto=format&n=5su3gw1SIJE0qay9&q=85&s=4a13a1251c8a5ff2dbe48787b6f37aa7" size="md" alt="Разделение вычислительных ресурсов в ClickHouse Cloud" width="1349" height="1100" data-path="images/cloud/reference/compute-compute-2.webp" />

<br />

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

<div id="what-is-a-warehouse">
  ## Что такое хранилище?
</div>

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

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

<Image img="https://mintcdn.com/private-7c7dfe99/5su3gw1SIJE0qay9/images/cloud/reference/compute-compute-8.webp?fit=max&auto=format&n=5su3gw1SIJE0qay9&q=85&s=ccb205d3a9b8867e17cbb57fc51372c5" size="lg" alt="Пример хранилища с основным и вторичным сервисами" background="white" width="1582" height="226" data-path="images/cloud/reference/compute-compute-8.webp" />

<br />

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

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

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

<div id="access-controls">
  ## Управление доступом
</div>

<div id="database-credentials">
  ### Учетные данные базы данных
</div>

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

<Image img="https://mintcdn.com/private-7c7dfe99/5su3gw1SIJE0qay9/images/cloud/reference/compute-compute-3.webp?fit=max&auto=format&n=5su3gw1SIJE0qay9&q=85&s=0aa35634538a24cb7f266ad76bb387a4" size="md" alt="Доступ пользователей между сервисами, использующими одни и те же данные" width="1349" height="1100" data-path="images/cloud/reference/compute-compute-3.webp" />

<br />

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

<div id="network-access-control">
  ### Управление сетевым доступом
</div>

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

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

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

<Image img="https://mintcdn.com/private-7c7dfe99/5su3gw1SIJE0qay9/images/cloud/reference/compute-compute-4.webp?fit=max&auto=format&n=5su3gw1SIJE0qay9&q=85&s=cf5e016ffdc7e86e41981366d4d4ce40" size="md" alt="Параметры управления сетевым доступом" width="1349" height="1100" data-path="images/cloud/reference/compute-compute-4.webp" />

<br />

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

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

<div id="read-vs-read-write">
  ### Сервисы только для чтения и с возможностью чтения и записи
</div>

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

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

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

<Image img="https://mintcdn.com/private-7c7dfe99/5su3gw1SIJE0qay9/images/cloud/reference/compute-compute-5.webp?fit=max&auto=format&n=5su3gw1SIJE0qay9&q=85&s=aea8d20983fa54b714efaf5b0a5287bd" size="lg" alt="Сервисы с возможностью чтения и записи и только для чтения в хранилище" width="1349" height="1100" data-path="images/cloud/reference/compute-compute-5.webp" />

<br />

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

<Note>
  1. Сервисы только для чтения в настоящее время поддерживают операции управления пользователями (CREATE, DROP и т. д.).
  2. [Refreshable materialized views](/docs/ru/concepts/features/materialized-views/refreshable-materialized-view) выполняются **только** на сервисах с возможностью чтения и записи (RW) в хранилище.
  3. Тип сервиса (только для чтения или с возможностью чтения и записи) фиксируется при создании и впоследствии не может быть изменён через Cloud Console. Чтобы переключиться между режимами только для чтения и чтения/записи, создайте в хранилище новый сервис нужного типа.
</Note>

<div id="scaling">
  ## Масштабирование
</div>

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

Сервисы, включая основной сервис, могут работать с одной репликой, однако для продакшна это не рекомендуется — для высокой доступности используйте не менее 2 реплик. На уровнях Scale и Enterprise основные и вторичные сервисы с одной репликой доступны без обращения в службу поддержки. Сервисы Scale и Enterprise со стандартными профилями `1:4` поддерживают вертикальное автоматическое масштабирование в режиме самообслуживания, тогда как для сервисов Enterprise с пользовательскими профилями изменение размера по вертикали выполняется с помощью службы поддержки. Размер сервисов уровня Basic не изменяется. Подробнее см. в разделе [Крупные сервисы с одной репликой](/docs/ru/products/cloud/features/large-single-replica-services).

По умолчанию общее количество реплик во всех сервисах хранилища ограничено 50. Подробнее см. в разделе [ограничения использования](/docs/ru/products/cloud/guides/best-practices/usagelimits). Чтобы увеличить лимит, обратитесь в [службу поддержки](https://clickhouse.com/support/program).

[Запланированное масштабирование](/docs/ru/products/cloud/features/autoscaling/scheduled-scaling) работает для отдельных сервисов в хранилище. Ограничения хранилища по-прежнему действуют — планируйте расписания так, чтобы суммарное количество реплик во всех сервисах в периоды пиковой нагрузки не превышало лимит хранилища. Подробнее см. в разделе [Автоматическое масштабирование](/docs/ru/products/cloud/features/autoscaling/overview).

<div id="changes-in-behavior">
  ## Изменения в поведении `clusterAllReplicas`
</div>

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

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

```sql theme={null}
SELECT * FROM clusterAllReplicas('all_groups.default', system, processes)
```

<div id="limitations">
  ## Ограничения
</div>

<div id="workload-isolation-limitations">
  ### Ограничения изоляции рабочих нагрузок
</div>

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

* **Все сервисы с возможностью чтения и записи по умолчанию выполняют фоновые операции слияния.** При вставке данных в ClickHouse база данных сначала записывает данные в промежуточные партиции, а затем выполняет слияния в фоновом режиме. Эти слияния могут потреблять ресурсы памяти и ЦП. Когда два сервиса с возможностью чтения и записи используют общее хранилище, оба выполняют фоновые операции. Это означает, что возможна ситуация, когда запрос `INSERT` выполняется в сервисе 1, а операция слияния завершается сервисом 2.
  Обратите внимание, что сервисы только для чтения не выполняют фоновые слияния. Чтобы отключить слияния на сервисе с возможностью чтения и записи, обратитесь в [службу поддержки](https://clickhouse.com/support/program).

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

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

<div id="callouts">
  ### Полезные примечания
</div>

* **Версии ClickHouse**: [График обновлений](/docs/ru/products/cloud/features/admin-features/upgrades) определяется настройками основного сервиса. У вторичных сервисов не может быть собственного графика релизов, независимого от основного сервиса.

* **Запросы `CREATE`/`RENAME`/`DROP DATABASE` по умолчанию могут блокироваться сервисами в режиме простоя или остановки.** Если выполнять эти запросы, когда сервис находится в режиме простоя или остановлен, они могут зависнуть. Чтобы избежать этого, можно запускать запросы управления базой данных с [`settings distributed_ddl_task_timeout=0`](/docs/ru/reference/settings/session-settings/distributed-ddl#distributed_ddl_task_timeout) на уровне сеанса или отдельного запроса.

Например:

```sql theme={null}
CREATE DATABASE db_test_ddl_single_query_setting
SETTINGS distributed_ddl_task_timeout=0
```

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

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

<div id="pricing">
  ## Цены
</div>

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

Воспользуйтесь калькулятором цен на странице [pricing](https://clickhouse.com/pricing), чтобы оценить стоимость с учетом размера вашей рабочей нагрузки и выбранного уровня. В таблице Usage Breakdown будет показана разбивка затрат на вычислительные ресурсы по сервисам.

<div id="backups">
  ## Резервные копии
</div>

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

<div id="setup-warehouses">
  ## Как настроить хранилище
</div>

<div id="creating-a-warehouse">
  ### Создание хранилища
</div>

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

<Image img="https://mintcdn.com/private-7c7dfe99/5su3gw1SIJE0qay9/images/cloud/reference/compute-compute-7.webp?fit=max&auto=format&n=5su3gw1SIJE0qay9&q=85&s=5e002faee1471dd2cb696c1f8ec3bf74" size="md" alt="Создание нового сервиса в хранилище" width="1504" height="484" data-path="images/cloud/reference/compute-compute-7.webp" />

<br />

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

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

<div id="renaming-a-warehouse">
  ### Переименование хранилища
</div>

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

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

<div id="deleting-a-warehouse">
  ### Удаление хранилища
</div>

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

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