Что такое Change Data Capture

Проблема: устаревшие данные и пропущенные изменения

Представьте ситуацию: у вас есть основная база данных с заказами и отдельная аналитическая система. Как синхронизировать данные между ними?

Традиционный подход — polling (опрос):

-- Каждые 5 минут запрашиваем изменения
SELECT * FROM orders
WHERE updated_at > :last_sync_time;

Этот подход имеет критические недостатки:

1. Задержка данных — изменения появляются с опозданием в минуты
2. Пропущенные DELETE — удаленные записи невозможно отследить
3. Высокая нагрузка на БД — постоянные запросы к production базе
4. Пропуск быстрых изменений — если запись изменилась дважды между опросами, вы увидите только последнее состояние

Решение: Change Data Capture

Change Data Capture (CDC) — это паттерн, позволяющий захватывать изменения данных в момент их возникновения. Вместо опроса базы данных, CDC использует встроенные механизмы СУБД для получения потока событий об изменениях.

Как это работает?

Каждая современная СУБД ведет журнал транзакций (WAL в PostgreSQL, binlog в MySQL). Этот журнал содержит каждое изменение, которое было зафиксировано в базе данных. CDC-системы читают этот журнал и преобразуют записи в поток событий.

Сравнение подходов: Polling vs Log-based CDC

Почему log-based CDC надежнее?

Ключевое преимущество: log-based CDC использует тот же журнал транзакций, который СУБД использует для обеспечения durability. Если транзакция была зафиксирована — она гарантированно попадет в журнал. А значит, CDC увидит это изменение.

Транзакция COMMIT → Запись в WAL → Debezium читает WAL → Событие в Kafka

Это не дополнительный механизм, а использование встроенной функциональности базы данных.

Последовательность событий в CDC

Use Cases для CDC

1. Синхронизация данных между системами

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

PostgreSQL → Debezium → Kafka → Elasticsearch
                              → Redis Cache
                              → Data Warehouse

2. Event-Driven Architecture

Используйте изменения в базе данных как источник бизнес-событий. Когда заказ меняет статус в БД, автоматически отправляется уведомление клиенту.

3. Аудит и Compliance

CDC сохраняет полную историю изменений: кто, когда и что изменил. Это критично для финансовых систем и GDPR compliance.

4. Миграции без простоя

При миграции на новую систему CDC позволяет синхронизировать данные в реальном времени, пока обе системы работают параллельно.

5. Материализованные представления

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

Ключевой инсайт

Log-based CDC — это не хак, а использование фундаментального механизма СУБД.

Transaction log (WAL) — это источник истины для самой базы данных. Debezium просто читает тот же журнал, который PostgreSQL использует для recovery после сбоев.

Это означает:

• Гарантия полноты — если транзакция зафиксирована, событие будет
• Минимальный overhead — чтение журнала почти не влияет на производительность БД
• Consistent ordering — события идут в том же порядке, что и транзакции

Что дальше?

В следующем уроке мы изучим архитектуру Debezium — платформы, которая реализует log-based CDC для различных СУБД. Вы узнаете о трех режимах развертывания и поймете, когда использовать каждый из них.