Ситуация: после включения сжатия индекса чтение ускорилось, хотя нагрузка на процессор выросла. Объясните механизм этого эффекта.
Сжатие индекса может ускорить чтение, потому что уменьшает объём данных, который нужно прочитать с диска или из буферного кэша. Дополнительные затраты процессора на распаковку оказываются меньше выигрыша от сокращения операций ввода-вывода и количества страниц.
Индексы хранятся в страницах фиксированного размера, а чтение страницы обычно является минимальной единицей работы подсистемы хранения. По мере роста таблиц стоимость чтения большого числа страниц стала часто ограничивать производительность сильнее, чем вычисления процессора.
Сжатие появилось как способ повысить эффективность хранения и уменьшить объём данных, проходящих через дисковую подсистему и память. Дополнительные вычисления при этом рассматриваются как обмен относительно дешёвого CPU на более дорогие операции ввода-вывода.
Большой индекс занимает больше страниц, хуже помещается в buffer pool и требует больше чтений при сканировании или диапазонном поиске. Это увеличивает задержку, давление на память и конкуренцию между запросами.
Однако сжатие не является безусловным ускорителем. Если данные уже находятся в памяти, чтение почти не ограничено вводом-выводом, а процессор загружен, распаковка может увеличить задержку. Дополнительные затраты также возникают при вставках, обновлениях и перестроении индекса.
Сжатие повышает число логических записей, помещающихся на одной физической странице. Поэтому индекс занимает меньше страниц, его уровни могут стать компактнее, а диапазонное чтение — обратиться к меньшему числу страниц.
Основные источники выигрыша:
Распаковка требует CPU. Поэтому итоговый эффект определяется балансом между стоимостью ввода-вывода, степенью сжатия и доступными процессорными ресурсами. На чтение с высокой долей случайных обращений сжатие тоже может помочь, но только если сокращение числа страниц компенсирует стоимость обработки.
Конкретные режимы зависят от СУБД. Например, SQL Server различает построчное и постраничное сжатие: постраничное дополнительно использует общие значения внутри страницы и обычно даёт больший коэффициент сжатия, но требует больше CPU. Нельзя переносить детали реализации одного движка на другой без проверки документации.
Сжатие может ухудшить запись: изменённая строка иногда перестаёт помещаться в прежнее представление страницы, возникают дополнительные перестроения, а обслуживание индекса становится дороже. Также слабее сжимаются данные с высокой энтропией, например случайные идентификаторы или уже сжатые бинарные значения.
Решение принимают по измерениям: сравнивают задержку, логические и физические чтения, CPU, объём индекса, использование кэша и влияние на операции записи. Сжимать следует не только ради уменьшения размера, а ради улучшения профиля конкретной нагрузки.
В отчётной системе большой некластеризованный индекс регулярно сканировался, а задержка была связана с чтением большого числа страниц. Рассматривались три варианта: оставить индекс без сжатия, применить менее агрессивное построчное сжатие или выбрать постраничное сжатие.
Отказ от сжатия не увеличивал CPU, но сохранял высокие объёмы чтения. Построчное сжатие уменьшало размер и риск роста CPU, однако давало ограниченный выигрыш. Постраничное сжатие обеспечивало более компактный индекс, но требовало проверить нагрузку на процессор и стоимость изменений.
Для преимущественно читаемого индекса выбрали постраничное сжатие после теста на рабочем распределении данных. На стенде проверили, что уменьшение числа чтений компенсирует дополнительные вычисления. Для часто изменяемого индекса оставили менее агрессивный режим, поскольку экономия на чтении не оправдывала увеличение стоимости записи.
Вопрос: Всегда ли сжатый индекс занимает меньше места пропорционально коэффициенту сжатия данных?
Нет. Коэффициент зависит от структуры страниц, повторяемости значений, типов столбцов и накладных расходов самого индекса. Заголовки страниц, указатели, выравнивание и значения с низкой избыточностью ограничивают выигрыш. Поэтому размер нужно измерять на фактических данных, а не выводить из среднего размера строк.
Вопрос: Почему сжатие может ускорить запрос даже при отсутствии дисковых чтений?
Страница из памяти всё равно обрабатывается целиком или частично, а более компактное представление означает меньше страниц для обхода и меньший объём данных в кэше. Это может уменьшить стоимость сканирования и повысить эффективность использования памяти. Но при CPU-нагруженной системе распаковка способна перевесить этот выигрыш.
Вопрос: Почему одинаковый режим сжатия может быть выгоден одному индексу и вреден другому?
Индексы отличаются размером, частотой чтения и изменения, характером доступа и повторяемостью значений. Большой редко изменяемый индекс, который часто сканируется, обычно лучше подходит для сжатия: выигрыш в чтении велик, а стоимость записи мала. Маленький индекс с частыми точечными обновлениями может почти не экономить ввод-вывод, но постоянно платить за дополнительную обработку.