Сопоставление рабочей нагрузки с отправной точкой
Актуальную информацию о доступности, регионах и ограничениях смотрите в документации соответствующего продукта. ClickHouse Managed Postgres сейчас находится в стадии public beta; см. краткое руководство.
О самоуправляемом ClickHouse server и других локальных вариантах см. режимы развертывания.
Пример: результаты отчётов и история запусков
Предположим, приложение обрабатывает загруженные файлы, формирует отчёты и должно хранить результаты, доступные для запросов, а также историю запусков. Прежде чем выбирать базу данных, разграничьте строки результатов и записи о запусках:- Результаты: запросы извлекают несколько строк по одному отчёту или агрегируют данные по множеству отчётов, датасетов и временных интервалов? Какая таблица предположительно вырастет до сотен миллионов строк?
- Записи о запусках: при завершении запуска создаётся одна неизменяемая запись или приложению нужно координировать владение выполняющимися задачами и переходы их статусов?
- Корректность: должны ли несколько записей изменяться в одной транзакции? Должна ли база данных обеспечивать уникальность и не допускать, чтобы два воркера захватили одну и ту же задачу?
- Актуальность: как быстро успешная запись должна становиться видимой и допустимо ли для запросов работать с неполной или отстающей аналитической копией?
Завершённые запуски и аналитические результаты
Сервис ClickHouse в ClickHouse Cloud стоит рассматривать в тех случаях, когда основная рабочая нагрузка — это анализ по строкам результатов, а записи о запусках можно добавлять по факту их завершения. Небольшая таблица с метаданными сама по себе не требует второй базы данных. Продумайте и протестируйте, как читатели будут отличать полностью завершённый запуск от загруженного лишь частично. Определите стабильные идентификаторы запусков, поведение при повторных попытках и порядок обработки дублирующихся строк результатов. Раздельные вставки в таблицу результатов и в таблицу истории запусков нельзя рассматривать как единую транзакцию, охватывающую обе таблицы. Если вы храните несколько версий записи о запуске, определите, каким образом запросы выбирают актуальную версию. ReplacingMergeTree поддерживает дедупликацию во время запроса с помощьюFINAL; при этом корректность не должна зависеть от того, успели ли уже пройти фоновые слияния. В справочнике по update описан другой механизм обновления и его ограничения. Не следует рассчитывать, что какой-либо из этих подходов обеспечивает транзакционные гарантии в стиле PostgreSQL.
Транзакционное состояние задач
Рассмотрите ClickHouse Managed Postgres, если таблица запусков одновременно служит транзакционной очередью заданий или системой учёта: например, воркер должен атомарно захватить задачу, пока за неё конкурируют другие воркеры, либо несколько записей приложения должны изменяться согласованно с соблюдением ограничений. Postgres также может обслуживать отчётные запросы. Добавляйте аналитический сервис тогда, когда это оправдано требованиями к производительности характерных запросов, параллелизму или изоляции, а не исходя из предположения, что каждому отчётному приложению нужны две базы данных.Транзакции и аналитика вместе
Если обе рабочие нагрузки оправдывают наличие отдельных сервисов, храните транзакционное состояние в Postgres, а нужные таблицы реплицируйте в ClickHouse с помощью ClickPipes или WalShadow. Учитывайте задержку репликации и продолжайте обращаться к транзакционному источнику для решений, требующих актуального состояния приложения. Репликация не объединяет запись в Postgres и чтение из ClickHouse в одну транзакцию. Расширение pg_clickhouse позволяет обращаться к ClickHouse через Postgres. Однако общая точка входа для запросов не превращает два сервиса в один движок базы данных и не отменяет необходимости учитывать актуальность данных.Проверьте пригодность до развёртывания ресурсов
Составьте небольшой набор репрезентативных запросов и протестируйте их на реалистичных объёмах данных. Включите как узкие точечные выборки, так и агрегаты по всей истории, ожидаемую конкурентную нагрузку и важные для вашего приложения проверки корректности. Вместе с результатами бенчмарка указывайте схему, форму запросов, размер оборудования или сервиса и характер ингестии. Для управляемого развертывания дополнительно проверьте:- Требования к региону, сети, управлению доступом и восстановлению.
- Ожидаемое время активности, объём сохранённых данных, резервные копии и плату за передачу данных — см. руководство по биллингу ClickHouse Cloud или руководство по ценам Managed Postgres.
- Допустима ли для нерегулярной аналитической рабочей нагрузки задержка подключения, связанная с автоматическим переходом в режим простоя.
- Ответственность команды за проектирование схемы, повторные попытки на стороне приложения, оптимизацию запросов и контроль расходов — даже если инфраструктурой управляет сервис.