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

# Сравнение PostgreSQL и ClickHouse

> Руководство по миграции с PostgreSQL на ClickHouse

<h2 id="why-use-clickhouse-over-postgres">
  Почему стоит использовать ClickHouse для аналитики по данным Postgres?
</h2>

Коротко: потому что ClickHouse разработан для быстрой аналитики, в частности для запросов `GROUP BY`, как OLAP-база данных, тогда как Postgres — это OLTP-база данных, предназначенная для транзакционных рабочих нагрузок.

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

OLAP, или системы онлайн-аналитической обработки, предназначены именно для таких задач — для работы с аналитическими нагрузками. Основная цель таких баз данных — дать инженерам возможность эффективно выполнять запросы и агрегировать огромные объёмы данных. OLAP-системы реального времени, такие как ClickHouse, позволяют проводить такой анализ по мере приёма данных в реальном времени.

Более подробное сравнение ClickHouse и PostgreSQL см. [здесь](/ru/get-started/migrate/postgres/appendix#postgres-vs-clickhouse-equivalent-and-different-concepts).

Чтобы увидеть возможную разницу в производительности ClickHouse и Postgres при аналитических запросах, см. [Rewriting PostgreSQL Queries in ClickHouse](/ru/get-started/migrate/postgres/migration-guide/migration-guide-part2).

<Tip>
  **Оставьте Postgres для транзакций и добавьте ClickHouse для аналитики**

  Вы можете перенести аналитические запросы в ClickHouse, сохранив Postgres в качестве транзакционного источника истины для вашего приложения. Реплицируйте зафиксированные изменения в ClickHouse с помощью CDC (фиксация изменений данных) и продолжайте выполнять транзакции приложения в Postgres.

  Вы можете использовать существующее развёртывание Postgres или [ClickHouse Managed Postgres](/ru/products/managed-postgres/overview). Об архитектуре и гарантиях репликации см. [как Postgres и ClickHouse работают вместе](/ru/products/managed-postgres/overview#transactions-and-analytics).
</Tip>

<h2 id="migration-strategies">
  Стратегии миграции
</h2>

При миграции из PostgreSQL в ClickHouse выбор подходящей стратегии зависит от вашего сценария использования, инфраструктуры и требований к данным. В целом CDC (фиксация изменений данных) в реальном времени — оптимальный подход для большинства современных сценариев, тогда как ручная пакетная загрузка с последующими периодическими обновлениями подходит для более простых сценариев или разовых миграций.

Ниже описаны две основные стратегии миграции: **CDC в реальном времени** и **Ручная пакетная загрузка + периодические обновления**.

<h3 id="real-time-replication-cdc">
  Репликация в реальном времени (CDC)
</h3>

CDC (фиксация изменений данных) — это процесс, который поддерживает синхронизацию таблиц между двумя базами данных. Для большинства миграций из PostgreSQL это самый эффективный подход, хотя и более сложный, поскольку он обрабатывает вставки, обновления и удаления из PostgreSQL в ClickHouse почти в реальном времени. Он особенно подходит для сценариев, где важна Real-time аналитика.

Репликацию в реальном времени с помощью CDC в ClickHouse можно реализовать через [ClickPipes](/ru/integrations/clickpipes/postgres/deduplication), если вы используете ClickHouse Cloud, или через [PeerDB](https://github.com/PeerDB-io/peerdb), если вы развертываете ClickHouse on-prem. Эти решения берут на себя всю сложность синхронизации данных в реальном времени, включая первоначальную загрузку, фиксируя вставки, обновления и удаления из PostgreSQL и реплицируя их в ClickHouse. Такой подход гарантирует, что данные в ClickHouse всегда остаются актуальными и точными без ручного вмешательства.

<h3 id="manual-bulk-load-periodic-updates">
  Ручная пакетная загрузка + периодические обновления
</h3>

В некоторых случаях достаточно более простого подхода — ручной пакетной загрузки с последующими периодическими обновлениями. Эта стратегия идеально подходит для разовых миграций или ситуаций, где репликация в реальном времени не требуется. Она предполагает пакетную загрузку данных из PostgreSQL в ClickHouse — либо с помощью прямых SQL-команд `INSERT`, либо через экспорт и импорт CSV-файлов. После первоначальной миграции данные в ClickHouse можно периодически обновлять, синхронизируя изменения из PostgreSQL через равные промежутки времени.

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

<h3 id="which-strategy-to-choose">
  Какую стратегию выбрать?
</h3>

Для большинства приложений, которым нужны свежие, актуальные данные в ClickHouse, рекомендуемый подход — CDC (фиксация изменений данных) в реальном времени через ClickPipes. Он обеспечивает непрерывную синхронизацию данных при минимальных затратах на настройку и поддержку. В то же время ручная пакетная загрузка с периодическими обновлениями — вполне подходящий вариант для более простых разовых миграций или рабочих нагрузок, где обновления в реальном времени не критичны.

***

**[Начните с этого руководства по миграции PostgreSQL](/ru/get-started/migrate/postgres/migration-guide/migration-guide-part1).**