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

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

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

<div id="why-use-clickhouse-over-postgres">
  ## Почему стоит использовать ClickHouse вместо Postgres?
</div>

Коротко: потому что 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).

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

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

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

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

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 всегда остаются актуальными и точными без ручного вмешательства.

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

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

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

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

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

***

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