33.1. Когда сжатие баз данных может быть полезным?
В базах данных обычно хранятся большие объёмы текста и повторяющейся информации. Поэтому сжатие для большинства баз данных может быть довольно эффективным и позволяет сократить объём хранимых данных в 3..5 раз. Postgres Pro Enterprise производит сжатие данных TOAST, но небольшие текстовые поля, умещающиеся в странице, сжатию не подвергаются. Однако сжатие может быть полезно не только для страниц в куче, но и для индексов по текстовым ключам или для индексов с большим количеством повторяющихся значений.
Postgres Pro Enterprise обращается к данным на диске через пул буферов, в котором остаются наиболее востребованные буферы. Интерфейс между менеджером буферов и файловой системой является наиболее подходящим местом для выполнения сжатия. Буферы хранятся на диске в сжатой форме для уменьшения объёма данных на диске и сокращения объёма считываемых данных. А так как пул буферов в памяти содержит несжатые буферы, обращаться к данным в них можно также быстро, как и без сжатия. Поскольку современные серверы имеют достаточно большой объём ОЗУ, обычно в памяти может кешироваться существенная часть базы данных, при обращении к которой не потребуется платить за сжатие.
Помимо очевидного плюса, заключающегося в экономии места, сжатие может также увеличить быстродействие системы. Это объясняется двумя причинами:
- Сокращение объёма дискового ввода/вывода
Сжатие помогает уменьшить объём данных, который приходится записывать или считывать с диска. Коэффициент сжатия 3 обычно означает, что читать придётся в 3 раза меньше данных, или что то же количество записей можно прочитать в три раза быстрее.
- Улучшение кучности
Когда модифицированные буферы сбрасываются из пула на диск, они записываются в произвольные области диска. Реализованный в Postgres Pro Enterprise алгоритм замены кеша принимает решение о вытеснении буфера из пула в зависимости только от частоты обращений к нему и игнорирует его расположение на диске. Поэтому два последовательно записываемых на диск буфера могут располагаться в совершенно разных областях диска. Для жёстких дисков время позиционирования может быть довольно большим — до 10 мс, а значит за секунду возможно выполнить лишь около 100 операций произвольной записи. А скорость последовательной записи может достигать 100 МБ/с и более, то есть около 10000 буферов в секунду (в 100 раз быстрее). Для SSD разрыв между скоростью последовательной и случайной записи меньше, но последовательная запись всё же производится эффективнее. Как это связано со сжатием данных? Размер буфера в Postgres Pro Enterprise фиксированный (по умолчанию 8 КБ), а размер сжатого буфера зависит от содержимого буфера. Поэтому изменённый буфер не всегда сможет уместиться в своё старое расположение на диске. Вот почему мы не можем обращаться к страницам непосредственно по адресу. Вместо этого мы должны ввести отображение адресов для сопоставления логического адреса страницы с его физическим расположением на диске. Этот дополнительный уровень адресации, определённо, добавляет издержки. Но в большинстве случаев это отображение умещается в памяти, так что поиск страницы заключается просто в обращении к элементу массива. Однако добавление этого отображения даёт и положительный эффект: теперь мы можем записывать изменённые страницы последовательно, просто корректируя их записи в карте отображения. Postgres Pro Enterprise прилагает большие усилия, чтобы избежать «лавины записи», когда место в пуле буферов заканчивается, а дополнительное сжатие помогает значительно сократить нагрузку на диск.