> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-vortex-format.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Выбор сервиса для вашей рабочей нагрузки

> Выберите сервисы ClickHouse или Postgres в ClickHouse Cloud для аналитики или транзакций, Управляемый ClickStack для обсервабилити либо chDB для локального анализа.

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

ClickHouse Cloud — это платформа управляемых сервисов, включая ClickHouse для аналитики и ClickHouse Managed Postgres для транзакционных рабочих нагрузок. Эти сервисы работают на разных движках баз данных — ClickHouse и PostgreSQL — с различным поведением SQL. Каждый сервис можно использовать отдельно либо сочетать их в рамках ClickHouse Cloud.

<h2 id="workload-map">
  Сопоставление рабочей нагрузки с отправной точкой
</h2>

| Что требуется вашему приложению | С чего начать оценку | Что проверить перед выбором |
| - | - | - |
| Агрегации, фильтрация и сравнения по большим объёмам истории событий или результатов | [сервис ClickHouse в ClickHouse Cloud](/ru/products/cloud/getting-started/intro) | Репрезентативные запросы, пакеты ингестии, актуальность данных, конкурентные запросы, а также организация обновлений и повторных попыток |
| Транзакционное состояние приложения: заказы, резервирование товаров или задания, переходы состояний которых требуют транзакций и ограничений целостности | [ClickHouse Managed Postgres в ClickHouse Cloud](/ru/products/managed-postgres/overview) | Границы транзакций, ограничения целостности, индексы, управление соединениями, а также поддерживаемые возможности и доступность сервиса |
| Транзакционное состояние приложения плюс аналитические запросы, которым нужна отдельная система обслуживания | [Сервисы Postgres и ClickHouse в ClickHouse Cloud](/ru/products/managed-postgres/sync-to-clickhouse/clickpipes) | Какие таблицы требуют репликации, допустимая задержка репликации, изменения схемы, а также стоимость и эксплуатация двух сервисов |
| Управляемое решение для поиска и анализа логов, метрик и трейсов приложения | [Управляемый ClickStack](/ru/clickstack/getting-started/managed) | Инструментирование, ингестия телеметрии, срок хранения и процессы обсервабилити, необходимые вашей команде |
| Анализ файлов или данных в памяти внутри локального приложения или notebook | [chDB](/ru/chdb/index) | Локальные ресурсы и необходимость отдельно размещённого, общего сервиса базы данных |

Актуальную информацию о доступности, регионах и ограничениях смотрите в документации соответствующего продукта. ClickHouse Managed Postgres сейчас находится в стадии public beta; см. [краткое руководство](/ru/products/managed-postgres/quickstart).

О самоуправляемом ClickHouse server и других локальных вариантах см. [режимы развертывания](/ru/get-started/about/deployment-modes).

<h2 id="report-results-and-history">
  Пример: результаты отчётов и история запусков
</h2>

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

* **Результаты:** запросы извлекают несколько строк по одному отчёту или агрегируют данные по множеству отчётов, датасетов и временных интервалов? Какая таблица предположительно вырастет до сотен миллионов строк?
* **Записи о запусках:** при завершении запуска создаётся одна неизменяемая запись или приложению нужно координировать владение выполняющимися задачами и переходы их статусов?
* **Корректность:** должны ли несколько записей изменяться в одной транзакции? Должна ли база данных обеспечивать уникальность и не допускать, чтобы два воркера захватили одну и ту же задачу?
* **Актуальность:** как быстро успешная запись должна становиться видимой и допустимо ли для запросов работать с неполной или отстающей аналитической копией?

<h3 id="completed-runs">
  Завершённые запуски и аналитические результаты
</h3>

Сервис ClickHouse в ClickHouse Cloud стоит рассматривать в тех случаях, когда основная рабочая нагрузка — это анализ по строкам результатов, а записи о запусках можно добавлять по факту их завершения. Небольшая таблица с метаданными сама по себе не требует второй базы данных.

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

Если вы храните несколько версий записи о запуске, определите, каким образом запросы выбирают актуальную версию. [ReplacingMergeTree](/ru/reference/engines/table-engines/mergetree-family/replacingmergetree) поддерживает дедупликацию во время запроса с помощью `FINAL`; при этом корректность не должна зависеть от того, успели ли уже пройти фоновые слияния. В [справочнике по update](/ru/reference/statements/update) описан другой механизм обновления и его ограничения. Не следует рассчитывать, что какой-либо из этих подходов обеспечивает транзакционные гарантии в стиле PostgreSQL.

<h3 id="transactional-job-state">
  Транзакционное состояние задач
</h3>

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

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

<h3 id="transactions-and-analytics">
  Транзакции и аналитика вместе
</h3>

Если обе рабочие нагрузки оправдывают наличие отдельных сервисов, храните транзакционное состояние в Postgres, а нужные таблицы реплицируйте в ClickHouse с помощью [ClickPipes](/ru/products/managed-postgres/sync-to-clickhouse/clickpipes) или [WalShadow](/ru/products/managed-postgres/sync-to-clickhouse/walshadow). Учитывайте задержку репликации и продолжайте обращаться к транзакционному источнику для решений, требующих актуального состояния приложения. Репликация не объединяет запись в Postgres и чтение из ClickHouse в одну транзакцию.

[Расширение pg\_clickhouse](/ru/products/managed-postgres/extensions/pg_clickhouse/introduction) позволяет обращаться к ClickHouse через Postgres. Однако общая точка входа для запросов не превращает два сервиса в один движок базы данных и не отменяет необходимости учитывать актуальность данных.

<h2 id="check-fit">
  Проверьте пригодность до развёртывания ресурсов
</h2>

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

Для управляемого развертывания дополнительно проверьте:

* Требования к региону, сети, управлению доступом и восстановлению.
* Ожидаемое время активности, объём сохранённых данных, резервные копии и плату за передачу данных — см. [руководство по биллингу ClickHouse Cloud](/ru/products/cloud/reference/billing/billing-overview) или [руководство по ценам Managed Postgres](/ru/products/managed-postgres/pricing).
* Допустима ли для нерегулярной аналитической рабочей нагрузки задержка подключения, связанная с [автоматическим переходом в режим простоя](/ru/products/cloud/features/autoscaling/idling).
* Ответственность команды за проектирование схемы, повторные попытки на стороне приложения, оптимизацию запросов и контроль расходов — даже если инфраструктурой управляет сервис.

Для сервисов ClickHouse или Postgres в ClickHouse Cloud используйте [ClickHouse CLI](/ru/products/cloud/features/cli), чтобы создавать ресурсы и управлять ими из терминала. Для Управляемого ClickStack и chDB следуйте руководствам по продуктам, ссылки на которые приведены в карте рабочих нагрузок.