Партиции, реплики

Применительно к PostgreSQL — конкретные инструменты для двух идей из темы «Репликация, шардирование, партиционирование».

Партиционирование в PostgreSQL — реальный встроенный синтаксис:

CREATE TABLE orders (
    id SERIAL,
    created_at DATE NOT NULL,
    total NUMERIC
) PARTITION BY RANGE (created_at);

CREATE TABLE orders_2025 PARTITION OF orders
    FOR VALUES FROM ('2025-01-01') TO ('2026-01-01');
CREATE TABLE orders_2026 PARTITION OF orders
    FOR VALUES FROM ('2026-01-01') TO ('2027-01-01');

Запрос SELECT * FROM orders WHERE created_at >= '2026-01-01' автоматически обращается только к партиции orders_2026, не сканируя остальные годы.

Реплики в PostgreSQL настраиваются через потоковую репликацию (streaming replication) — главный сервер (primary) непрерывно передаёт изменения на реплики (standby), почти в реальном времени.

Копнуть глубже

Read replica для разгрузки основного сервера. Типичная практика: тяжёлые аналитические SELECT-запросы (отчёты, дашборды) направляют на реплику, а основной сервер остаётся свободным для быстрых пользовательских запросов на запись. В Spring это настраивают через несколько DataSource — один для записи (primary), другой для чтения (replica).

Задержка репликации (replication lag). Реплика обновляется не мгновенно — есть небольшая задержка. Если прочитать данные с реплики сразу после записи в primary, можно получить устаревшие данные. Для критичных по консистентности сценариев (“показать только что созданный заказ”) читают именно с primary, а не с реплики.

🎤 Закрыл тему, если можешь объяснить:

• как работает PARTITION BY RANGE в PostgreSQL;
• что такое задержка репликации и почему она важна при чтении с реплики (если дошёл до 2-го слоя).