> Какой параметр использовать для партицирования, который не меняется со временем и помогает оптимизировать запрос (Go)

Короткий ответ

Для партицирования выбирайте параметр, который монотонно возрастает и не меняется со временем, например, created_at или суррогатный ключ. Такой подход позволяет использовать range partitioning, оптимизировать запросы по времени и упрощает обслуживание (например, drop старых партиций). Избегайте изменяемых полей вроде status или updated_at, так как это приводит к перемещению строк между партициями и деградации производительности.

Подробное объяснение

Ключевое требование к параметру партицирования - иммутабельность (неизменность значения после вставки). Если поле меняется, строка должна физически перемещаться между партициями, что вызывает блокировки, увеличение write amplification и фрагментацию индексов.

Второе важное свойство - монотонность. Для range partitioning идеально подходит поле, которое только растёт: id (автоинкремент), created_at, event_time. Это позволяет:

• эффективно использовать partition pruning для запросов с фильтром по времени;
• применять стратегию rolling window (удаление старых партиций без DELETE);
• строить инкрементальные агрегации.

Для hash partitioning можно использовать любой стабильный ключ (например, user_id), но он не даёт преимуществ для time-based запросов. В Go-сервисах часто используют created_at с типом time.Time - это естественный выбор для большинства бизнес-задач.

На практике

В реальных системах партицирование по created_at даёт:

• ускорение запросов с фильтром WHERE created_at BETWEEN ... - база сканирует только нужные партиции;
• упрощение архивации: DROP PARTITION вместо массового DELETE;
• улучшение работы с hot rows - новые данные пишутся в последнюю партицию.

Если нужен более гранулярный контроль, комбинируйте: PRIMARY KEY (id, created_at) и партицируйте по created_at. В PostgreSQL это требует включения ключа партицирования в первичный ключ.

Для Go-приложений важно, чтобы поле created_at заполнялось на стороне БД (DEFAULT now()), а не в коде - это гарантирует консистентность и исключает ошибки с часовыми поясами.

Пример кода

SQL
-- PostgreSQL
CREATE TABLE events (
    id BIGSERIAL,
    created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
    payload JSONB,
    PRIMARY KEY (id, created_at)
) PARTITION BY RANGE (created_at);

-- Создание партиций на месяц
CREATE TABLE events_2025_01 PARTITION OF events
    FOR VALUES FROM ('2025-01-01') TO ('2025-02-01');

CREATE TABLE events_2025_02 PARTITION OF events
    FOR VALUES FROM ('2025-02-01') TO ('2025-03-01');

GO
// Go: запрос, который эффективно использует партицирование
rows, err := db.Query(`
    SELECT payload
    FROM events
    WHERE created_at >= $1 AND created_at < $2
`, startTime, endTime)

Как отвечать на собеседовании

Начните с прямого ответа: created_at или монотонный id. Затем объясните два критерия: неизменность и монотонность. Приведите пример, как это влияет на partition pruning. Упомяните trade-off: если запросы часто фильтруют по другому полю, партицирование по времени может не помочь - тогда нужен secondary index или другое распределение. Покажите понимание rolling window и операций с партициями. Если спросят про hash partitioning - скажите, что он подходит для равномерного распределения нагрузки, но не для time-based запросов.

Что проверяет интервьюер

• Понимание физической модели хранения данных и влияния партицирования на производительность.
• Умение выбирать ключ партицирования с учётом паттернов доступа.
• Знание ограничений: внешние ключи, уникальность, первичный ключ.
• Понимание операций обслуживания: merge, split, drop партиций.
• Способность объяснить, почему изменяемые поля - плохой выбор.

Типичные ошибки

• Выбор updated_at - строки будут мигрировать между партициями при каждом обновлении.
• Использование status - кардинальность мала, партиции будут несбалансированными.
• Партицирование по полю, которое не входит в WHERE - нет partition pruning, только overhead.
• Игнорирование требования включения ключа партицирования в первичный ключ (в PostgreSQL).
• Заполнение created_at на стороне приложения - риск рассинхронизации с часами сервера БД.