> ## 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.

# Рекомендации по выбору конфигурации и оборудования

> В этом руководстве приведены общие рекомендации по выбору конфигурации оборудования, вычислительных ресурсов, памяти и дисковой подсистемы для пользователей open-source.

В этом руководстве приведены общие рекомендации по выбору конфигурации оборудования, вычислительных ресурсов, памяти и дисковой подсистемы для пользователей open-source. Если вы хотите упростить развертывание, рекомендуем использовать [ClickHouse Cloud](https://clickhouse.com/cloud): сервис автоматически масштабируется и подстраивается под ваши рабочие нагрузки, сводя к минимуму затраты на управление инфраструктурой.

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

* Параллелизм (запросов в секунду)
* Пропускная способность (обрабатываемых строк в секунду)
* Объем данных
* Политика хранения данных
* Затраты на оборудование
* Затраты на обслуживание

<div id="disk">
  ## Диск
</div>

Выбор типа диска для ClickHouse зависит от объема данных, а также требований к задержкам и пропускной способности.

<div id="optimizing-for-performance">
  ### Оптимизация производительности
</div>

Чтобы добиться максимальной производительности, мы рекомендуем напрямую подключать [SSD-тома с выделенным IOPS от AWS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/provisioned-iops.html) или аналогичное решение вашего облачного провайдера, оптимизированное для операций ввода-вывода.

<div id="optimizing-for-storage-costs">
  ### Оптимизация затрат на хранилище
</div>

Чтобы снизить затраты, можно использовать [EBS-тома SSD общего назначения](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/general-purpose.html).

Также можно реализовать многоуровневое хранилище на SSD и HDD в архитектуре [hot/warm/cold](/docs/ru/concepts/features/operations/delete/ttl#implementing-a-hotwarmcold-architecture). В качестве альтернативы для хранения можно использовать [AWS S3](https://aws.amazon.com/s3/), чтобы обеспечить разделение вычислительных ресурсов и хранилища. Руководство по использованию ClickHouse с открытым исходным кодом с разделением вычислительных ресурсов и хранилища см. [здесь](/docs/ru/guides/oss/deployment-and-scaling/separation-storage-compute). В ClickHouse Cloud разделение вычислительных ресурсов и хранилища доступно по умолчанию.

<div id="cpu">
  ## CPU
</div>

<div id="which-cpu-should-i-use">
  ### Какой CPU выбрать?
</div>

Выбор CPU зависит от характера вашей нагрузки. В целом приложения с большим количеством частых параллельных запросов, обрабатывающие большие объёмы данных или использующие вычислительно затратные UDF, потребуют больше CPU-ядер.

**Приложения с низкой задержкой или клиентские приложения**

Для сценариев, где требуется задержка на уровне десятков миллисекунд, например для клиентских рабочих нагрузок, мы рекомендуем линейки EC2 [i3 line](https://aws.amazon.com/ec2/instance-types/i3/) или [i4i line](https://aws.amazon.com/ec2/instance-types/i4i/) от AWS либо аналогичные варианты от вашего облачного провайдера с оптимизацией под I/O.

**Приложения с высоким параллелизмом**

Для рабочих нагрузок, которым важен высокий параллелизм (100+ запросов в секунду), мы рекомендуем [compute-optimized C series](https://aws.amazon.com/ec2/instance-types/#Compute_Optimized) от AWS или аналогичный вариант от вашего облачного провайдера.

**Сценарий использования хранилища данных**

Для рабочих нагрузок хранилища данных и ad hoc аналитических запросов мы рекомендуем [R-type series](https://aws.amazon.com/ec2/instance-types/#Memory_Optimized) от AWS или аналогичный вариант от вашего облачного провайдера, так как они оптимизированы по памяти.

***

<div id="what-should-cpu-utilization-be">
  ### Какой должна быть загрузка CPU?
</div>

Для ClickHouse нет стандартного целевого уровня загрузки CPU. Используйте такой инструмент, как [iostat](https://linux.die.net/man/1/iostat), чтобы измерять среднюю загрузку CPU, и соответственно подбирайте размер серверов с учетом возможных неожиданных всплесков трафика. Однако для аналитических сценариев или сценариев хранилища данных с ad hoc-запросами стоит ориентироваться на загрузку CPU на уровне 10–20%.

<div id="how-many-cpu-cores-should-i-use">
  ### Сколько ядер CPU следует использовать?
</div>

Необходимое количество CPU зависит от вашей рабочей нагрузки. Однако обычно мы рекомендуем следующие соотношения объема памяти к числу ядер CPU в зависимости от типа CPU:

* **[M-type](https://aws.amazon.com/ec2/instance-types/) (сценарии общего назначения):** соотношение памяти к ядру CPU — 4 ГБ:1
* **[R-type](https://aws.amazon.com/ec2/instance-types/#Memory_Optimized) (сценарии использования хранилища данных):** соотношение памяти к ядру CPU — 8 ГБ:1
* **[C-type](https://aws.amazon.com/ec2/instance-types/#Compute_Optimized) (сценарии, оптимизированные для вычислений):** соотношение памяти к ядру CPU — 2 ГБ:1

Например, при использовании CPU типа M мы рекомендуем выделять 100 ГБ памяти на каждые 25 ядер CPU. Чтобы определить подходящий для вашего приложения объем памяти, необходимо проанализировать использование памяти с помощью данных профилирования. Вы можете прочитать [это руководство по отладке проблем с памятью](/docs/ru/concepts/features/performance/troubleshoot/debugging-memory-issues) или использовать [встроенную панель мониторинга обсервабилити](/docs/ru/guides/oss/deployment-and-scaling/monitoring/monitoring) для мониторинга ClickHouse.

<div id="memory">
  ## Память
</div>

Как и при выборе CPU, выбор соотношения памяти к хранилищу и памяти к CPU зависит от вашего сценария использования.

Требуемый объём оперативной памяти обычно зависит от:

* Сложности запросов.
* Объёма данных, обрабатываемых в запросах.

В целом чем больше памяти, тем быстрее будут выполняться запросы.
Если для вашего сценария использования важна стоимость, подойдут и меньшие объёмы памяти, поскольку можно включить настройки ([`max_bytes_before_external_group_by`](/docs/ru/reference/settings/session-settings#max_bytes_before_external_group_by) и [`max_bytes_before_external_sort`](/docs/ru/reference/settings/session-settings#max_bytes_before_external_sort)), чтобы разрешить выгрузку данных на диск, но учтите, что это может существенно сказаться на производительности запросов.

<div id="what-should-the-memory-to-storage-ratio-be">
  ### Каким должно быть соотношение памяти и хранилища?
</div>

При небольших объёмах данных допустимо соотношение памяти и хранилища 1:1, но общий объём памяти не должен быть меньше 8 ГБ.

Для сценариев с длительным сроком хранения данных или большими объёмами данных мы рекомендуем соотношение памяти и хранилища от 1:100 до 1:130. Например, 100 ГБ оперативной памяти на реплику, если вы храните 10 ТБ данных.

Для сценариев с частым доступом, например для клиентских рабочих нагрузок, мы рекомендуем использовать больше памяти — при соотношении памяти и хранилища от 1:30 до 1:50.

<div id="replicas">
  ## Реплики
</div>

Мы рекомендуем использовать как минимум три реплики на сегмент (или две реплики с [Amazon EBS](https://aws.amazon.com/ebs/)). Кроме того, рекомендуем сначала вертикально масштабировать все реплики и лишь затем добавлять новые реплики (горизонтальное масштабирование).

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

Рассмотрите возможность использования [ClickHouse Cloud](https://clickhouse.com/cloud), который масштабируется автоматически и позволяет легко управлять количеством реплик под ваши задачи.

<div id="example-configurations-for-large-workloads">
  ## Примеры конфигураций для крупных рабочих нагрузок
</div>

Конфигурации ClickHouse во многом зависят от требований вашего приложения. Пожалуйста, [свяжитесь с отделом продаж](https://clickhouse.com/company/contact?loc=docs-sizing-and-hardware-recommendations), если вы хотите, чтобы мы помогли оптимизировать вашу архитектуру по стоимости и производительности.

Для ориентира (а не в качестве рекомендаций) ниже приведены примеры конфигураций пользователей ClickHouse в промышленной эксплуатации:

<div id="fortune-500-b2b-saas">
  ### Fortune 500 B2B SaaS
</div>

<table>
  <tr>
    <td col="2"><strong><em>Хранилище</em></strong></td>
  </tr>

  <tr>
    <td><strong>Ежемесячный прирост данных</strong></td>
    <td>30TB</td>
  </tr>

  <tr>
    <td><strong>Общий объем хранилища (в сжатом виде)</strong></td>
    <td>540TB</td>
  </tr>

  <tr>
    <td><strong>Срок хранения данных</strong></td>
    <td>18 месяцев</td>
  </tr>

  <tr>
    <td><strong>диск на узел</strong></td>
    <td>25TB</td>
  </tr>

  <tr>
    <td col="2"><strong><em>CPU</em></strong></td>
  </tr>

  <tr>
    <td><strong>Параллелизм</strong></td>
    <td>200+ параллельных запросов</td>
  </tr>

  <tr>
    <td><strong>Количество реплик (включая HA-пару)</strong></td>
    <td>44</td>
  </tr>

  <tr>
    <td><strong>vCPU на узел</strong></td>
    <td>62</td>
  </tr>

  <tr>
    <td><strong>Общее количество vCPU</strong></td>
    <td>2700</td>
  </tr>

  <tr>
    <td col="2"><strong><em>Память</em></strong></td>
  </tr>

  <tr>
    <td><strong>Общий объем оперативной памяти</strong></td>
    <td>11TB</td>
  </tr>

  <tr>
    <td><strong>Оперативная память на реплику</strong></td>
    <td>256GB</td>
  </tr>

  <tr>
    <td><strong>Соотношение оперативной памяти и vCPU</strong></td>
    <td>4 GB:1</td>
  </tr>

  <tr>
    <td><strong>Соотношение оперативной памяти и дискового пространства</strong></td>
    <td>1:50</td>
  </tr>
</table>

<div id="fortune-500-telecom-operator-for-a-logging-use-case">
  ### Телеком-оператор из списка Fortune 500 для сценария логирования
</div>

<table>
  <tr>
    <td col="2"><strong><em>Хранилище</em></strong></td>
  </tr>

  <tr>
    <td><strong>Ежемесячный объем логов</strong></td>
    <td>4860TB</td>
  </tr>

  <tr>
    <td><strong>Общий объем хранилища (в сжатом виде)</strong></td>
    <td>608TB</td>
  </tr>

  <tr>
    <td><strong>Срок хранения данных</strong></td>
    <td>30 дней</td>
  </tr>

  <tr>
    <td><strong>Диск на узел</strong></td>
    <td>13TB</td>
  </tr>

  <tr>
    <td col="2"><strong><em>CPU</em></strong></td>
  </tr>

  <tr>
    <td><strong>Число реплик (включая HA-пару)</strong></td>
    <td>38</td>
  </tr>

  <tr>
    <td><strong>vCPU на узел</strong></td>
    <td>42</td>
  </tr>

  <tr>
    <td><strong>общее количество vCPU</strong></td>
    <td>1600</td>
  </tr>

  <tr>
    <td col="2"><strong><em>Память</em></strong></td>
  </tr>

  <tr>
    <td><strong>общий объем оперативной памяти</strong></td>
    <td>10TB</td>
  </tr>

  <tr>
    <td><strong>Оперативная память на реплику</strong></td>
    <td>256GB</td>
  </tr>

  <tr>
    <td><strong>Соотношение оперативной памяти и vCPU</strong></td>
    <td>6 GB:1</td>
  </tr>

  <tr>
    <td><strong>Соотношение оперативной памяти и диска</strong></td>
    <td>1:60</td>
  </tr>
</table>

<div id="further-reading">
  ## Дополнительные материалы
</div>

Ниже приведены опубликованные статьи в блогах компаний об их архитектурах с использованием ClickHouse с открытым исходным кодом:

* [Cloudflare](https://blog.cloudflare.com/http-analytics-for-6m-requests-per-second-using-clickhouse/?utm_source=linkedin\&utm_medium=social\&utm_campaign=blog)
* [eBay](https://innovation.ebayinc.com/tech/engineering/ou-online-analytical-processing/)
* [GitLab](https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/clickhouse_usage/)
* [Lyft](https://eng.lyft.com/druid-deprecation-and-clickhouse-adoption-at-lyft-120af37651fd)
* [MessageBird](https://clickhouse.com/blog/how-messagebird-uses-clickhouse-to-monitor-the-delivery-of-billions-of-messages)
* [Microsoft](https://clickhouse.com/blog/self-service-data-analytics-for-microsofts-biggest-web-properties)
* [Uber](https://www.uber.com/en-ES/blog/logging/)
* [Zomato](https://blog.zomato.com/building-a-cost-effective-logging-platform-using-clickhouse-for-petabyte-scale)