Уплотнение базы данных: что это, зачем и как применять

Что такое уплотнение базы данных

Под уплотнением понимают цепочку операций, которые:

• удаляют «мертвые» версии запись и освобождают неиспользуемое пространство; 
• пересобирают B-дерево индексов в правильном порядке; 
• уменьшают размер сегмента хранения, возвращая байты в файловую систему; 
• обновляют статистику, чтобы оптимизатор строил адекватный план поиск.

После процедуры движок управляет набором страниц без лишних «дыр», а каждое поле описания находится в предсказуемом смещении. В PostgreSQL за это отвечает VACUUM, в Oracle — автоматический Segment Advisor, в отечественных NewSQL-движках (например, YDB) — внутренний цикл «сборщик мусора + compaction». Чем активнее выполняются транзакции, тем быстрее база снова начинает уплотняться — поэтому важно, чтобы операция была не стихийной, а управляемой.

Зачем нужно уплотнение: ключевые причины и выгоды

1. DELETE/UPDATE оставляют «пустой» блок, который не сразу удаляется физически. 
2. Индекс теряет локальность: для чтения одного диапазона требуется обращаться к разным частям файла. 
3. Запросы начинают сканировать лишние страницы; конкурентные блокировки растут, задержки на лог-репликации увеличиваются.

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

Виды уплотнения: логическое и физическое

Для распределенных хранилищ, таких как ClickHouse и СУБД Greenplum граница стирается: логическое «MERGE PARTS» фактически создает новый сегмент и удаляет старый, комбинируя оба подхода.

Методы уплотнения в популярных СУБД

В отечественных СУБД, например в Linter или Байтскрипт, уплотнение инициируется системной процедурой COMPACT и может выполняться онлайн, если задействован режим MVCC.

Как понять, что база нуждается в уплотнении

• Размер сегмента вырос, хотя общее количество строк стабильно. 
• Среднее время ответа репрезентативного запроса удвоилось. 
• n_dead_tup (PostgreSQL) > 20 % от n_live_tup; DATA_FREE (InnoDB) превышает 1 ГБ. 
• В sys.dm_db_index_physical_stats внешняя фрагментация > 30 %, внутренняя > 20 %. 
• Мониторинг в Zabbix или Р-Vision APM фиксирует скачки latency после автокоммита.

Когда хотя бы один критерий нарушает SLA, база переходит из разряда «работает» в разряд «необходимо уплотнять».

Этапы процесса уплотнения: от анализа до проверки

1. Анализ — собираем информация о фрагментации, строим контрольные графики. 
2. Резервное копирование — off-line dump, snapshot LVM или аппаратный снимок SAN. 
3. Выбор метода — логический либо физический, с оглядкой на окно недоступности и объем диска. 
4. Запуск — выполняем указанную команда, параллельно отслеживая wait-events. 
5. Проверка результата — сравниваем время выборки, глубину индекса, размер файла; в PostgreSQL дополнительно смотрим pg_freespacemap. 
6. Мониторинг — на дашборде Grafana фиксируем новый интервал: например, каждые 10 млн транзакций или раз в неделю, в зависимости от бизнес-нагрузки.

Хорошая практика — тестовый прогон на стенде с копией продакшена. Он показывает, сколько часов займет процедура и какое окно действительно нужно.

Заключение: регулярное уплотнение как часть обслуживания базы данных

Уплотнение — не разовая «оптимизация», а элемент планового поддержание. Четкий регламент, описание шагов и критерии запуска превращают потенциальную аварию в управляемую процедуру. Правильный метод и своевременная операция повышают эффективность, экономят место и удерживают SLA без дорогого аппаратного апгрейда. Пример крупной телеком-площадки показывает: после перехода на ежемесячный compact размер основного сегмента PostgreSQL сократился с 1,3 ТБ до 820 ГБ, а среднее время запроса отчета упало с 480 мс до 210 мс. Пользователи продолжают получать стабильный доступ, а инженеры — предсказуемый вывод диагностики и отсутствие ночных внеплановых вызовов.