Compaction, VACUUM и merges¶

Тип материала: архитектурный разбор. Схемы и примеры иллюстративные, если не указано иное.

Версии в источниках: PostgreSQL 17, MySQL 8.4, Oracle 19c, Cassandra 5.0, Redis 7.4 и ClickHouse 25.8 либо явно названный сервис.

Механизм¶

Эти операции обслуживают накопленные версии, но не взаимозаменяемы. PostgreSQL VACUUM освобождает dead tuples для повторного использования и обновляет visibility/freeze; Cassandra compaction объединяет SSTables; ClickHouse merges объединяют parts и применяют engine-specific правила.

flowchart LR
  Versions[Old tuples runs or parts] --> Safe[Check visibility and safety horizon]
  Safe --> Work[Vacuum compaction or merge]
  Work --> Reclaim[Reusable space or new files]
  Long[Long readers or missing repair] --> Safe

Операция чтения или записи по шагам¶

PG UPDATE оставляет старую tuple до ухода snapshots. Cassandra DELETE оставляет timestamped tombstone до безопасной очистки. ClickHouse ReplacingMergeTree INSERT новой версии оставляет обе rows до merge/query-time dedup. Background process не обязан немедленно довести каждую бизнес-сущность до единственной физической записи.

Консистентность, отказ и восстановление¶

Длинный reader тормозит GC snapshot-based systems; слишком ранний tombstone GC может воскресить replica data. CH merge не проходит между partitions и не исправляет уже накопленную incremental MV. Диск нужен одновременно старым и новым files; заполнение диска может остановить maintenance и writes.

Выбор, эксплуатация и ограничения¶

Настраивать thresholds, scheduling и ресурсы по update/TTL profile. TWCS полезен при временных immutable данных; PG autovacuum thresholds нужно соотносить с churn горячих tables. Manual OPTIMIZE/VACUUM FULL — invasive operation, не универсальный cron repair.

Типичные ошибки проектирования¶

Считать физическое отсутствие дублей условием правильности query. Вопрос: merge завершился — аналитика верна? Только если engine semantics, source versions и downstream aggregates соответствуют контракту.

Вопросы на собеседовании¶

Как доказать применимость механизма? Назвать invariant, scope, isolation/acknowledgement boundary, версию, допустимые interleavings и процедуру восстановления. Один успешный запрос или статическая диаграмма этого не доказывают.

Практические упражнения¶

Для трёх engines составьте state before/after maintenance, prerequisites safe deletion и метрики backlog. Оцените временный disk headroom на rewrite без заявления фиксированного коэффициента.

Дополнительные источники¶

Политика версий и проверки. Статическая проверка статьи не является runtime/fault verification механизма.