Перейти к содержимому 
Страница MariaDB Сжатие позволяет сократить объем занимаемой физической памяти за счет сжатия страниц InnoDB перед записью на носитель, что приводит к заметному снижению объема операций ввода-вывода. Я покажу, как сэкономить память и минимизировать задержку, какие условия необходимо соблюдать и какие настройки дают наибольший эффект на практике.
Центральные пункты
Эти краткие тезисы дают представление об основных аспектах.
- По страницам Сжатие позволяет сократить занимаемое место и снизить нагрузку на ввод-вывод.
- Несжатый Буферный пул ограничивает нагрузку на ЦП в оперативной памяти.
- Гибкий Активация для каждой таблицы с помощью PAGE_COMPRESSED.
- файловая система- Поддержка метода «Sparse/Hole Punching» является обязательной.
- Выбор алгоритма регулирует частоту, задержку и загрузку процессора.
Как технически работает сжатие страниц InnoDB
Я сжимаю каждую страницу InnoDB непосредственно перед тем, как она попадает на диск, благодаря чему табличное пространство занимает только фактически сжатый объем в байтах, а файловая система помечает свободные области как «разреженные». В Пул буферов Я по-прежнему храню страницы в несжатом виде, что позволяет снизить нагрузку на процессор при работе с оперативной памятью и обеспечить высокую скорость частых операций чтения. По умолчанию страницы InnoDB имеют размер 16 КБ, однако после сжатия размер сохраняемых блоков становится переменным, что позволяет значительно сэкономить место, особенно в случае текстовых полей или полей JSON. При чтении я распаковываю страницу сразу после загрузки в ОЗУ, то есть именно на границе ввода-вывода, где экономия при передаче данных имеет наибольшее значение. Таким образом, я переношу нагрузку с ВВОД/ВЫВОД к ЦП, но только в тех местах, где это оправдано.
Сжатие страниц против классического сжатия таблиц InnoDB
Классическая компрессия основана на использовании ROW_FORMAT=COMPRESSED в сочетании с KEY_BLOCK_SIZE, что создает фиксированный сжатый формат страницы и приводит к дополнительной нагрузке при принятии решений во время записи или обновления. Я предпочитаю Страница Сжатие, поскольку оно остается гибким: если сжатие не удается, InnoDB может сохранить страницу в несжатом виде, не изменяя общий формат файла. Буферный пул продолжает работать с несжатыми страницами размером 16 КБ, что ускоряет попадания в кэш и упрощает пути обработки ЦП. При типичных OLTP-нагрузках с большим количеством вставок и умеренным количеством обновлений сжатие страниц обеспечивает лучший баланс между экономией места и задержкой. В результате я часто получаю ощутимое преимущество в производительности ввода-вывода без значительных накладных расходов при каждой Обновление рисковать.
Требования и базовая конфигурация
Для сжатия страниц я предполагаю наличие InnoDB и включаю innodb_file_per_table, чтобы каждая таблица использовала свой собственный табличный пространство. Решающую роль играет файловая система: она должна поддерживать разреженные файлы и технологию «hole-punching», что характерно для ext4 и XFS и, как правило, присутствует в современных облачных томах. Для выбора алгоритма я использую параметр innodb_compression_algorithm, обычно zlib, lz4 или lzo, в зависимости от требуемой скорости и профиля ЦП. Тем, кто тщательно подбирает уровень хранения, выгодно использовать компактный Сравнение файловых систем при этом учитывая также параметры драйверов и томов. В результате получается Конфигурация, которая экономит место, снижает нагрузку на ввод-вывод и обеспечивает надежную работу.
Активация на уровне таблицы
Я включаю сжатие страниц для каждой таблицы после того, как настрою глобальные переменные, чтобы целенаправленно обращаться именно к тем записям, которые приносят максимальную пользу. Для новых таблиц я задаю параметры непосредственно в DDL, а для существующих таблиц перенастройку осуществляет команда ALTER TABLE путем перезаписи. Уровень сжатия я задаю с помощью PAGE_COMPRESSION_LEVEL, поведение зависит от используемого Алгоритм . Поскольку переход требует времени, я планирую окна технического обслуживания и проверяю занимаемое пространство с компрессией и без неё на основе реальных фрагментов данных. Таким образом, я контролирую Расходы и результат без неожиданностей.
CREATE TABLE log_entries (
id BIGINT UNSIGNED PRIMARY KEY,
created_at DATETIME NOT NULL,
level VARCHAR(20),
message TEXT
) ENGINE=InnoDB
PAGE_COMPRESSED=1
PAGE_COMPRESSION_LEVEL=6;
ALTER TABLE log_entries
ENGINE=InnoDB,
PAGE_COMPRESSED=1;
Экономия места на диске на практике
Чем однороднее и чем больше в данных текста, тем эффективнее действует Компрессия; Таблицы журналов и отчётов, как правило, дают заметный эффект. В типичных рабочих нагрузках я часто наблюдаю сокращение объёма занятой памяти на 40–60 % при использовании zlib, тогда как lz4 в большинстве случаев обеспечивает сокращение на 30–50 %, оставляя при этом больше пропускной способности. Сильно распределенные бинарные данные дают меньший выигрыш, но и в этом случае объемы ввода-вывода и затраты часто заметно сокращаются. Я всегда провожу тестирование с использованием производственных снимков на промежуточном сервере, чтобы получить значимые показатели и выявить пики задержки. Результат: меньше данных на носителе, более короткое время передачи, лучшее Масштабирование.
Производительность: как правильно оценить соотношение ввода-вывода и процессора
Сначала я проверяю, находится ли узкое место на носителе данных или на CPU , поскольку от этого зависит выбор метода сжатия. В средах с ограниченным вводом-выводом объемы чтения и записи значительно снижаются, в результате чего эффективная производительность повышается — зачастую при дополнительной нагрузке всего 5–10 % по сравнению с несжатыми таблицами при использовании быстрых алгоритмов. Системы, ограниченные производительностью ЦП, выигрывают от использования lz4 или lzo, которые работают очень быстро и достигают лишь немного более низких скоростей сжатия. Кроме того, я обращаю внимание на Буфер двойной записи, поскольку он влияет на поведение записи и вместе с сжатием страниц определяет характеристики ввода-вывода. Поскольку буферный пул остаётся несжатым, частые попадания в кэш практически не влияют на Латентность от.
Выбор алгоритма и уровень сжатия
Я решаю Алгоритм-Я выбираю алгоритм сжатия, ориентируясь на шаблоны данных, скорость чтения/записи и запас производительности процессора, а не только на коэффициент сжатия. Zlib часто обеспечивает максимальную экономию места при умеренной вычислительной нагрузке, тогда как lz4/lzo отличаются низкой задержкой. LZMA или bzip2 я использую в основном для архивов или редко изменяемых таблиц, поскольку затраты на процессор в этом случае выше. Уровень сжатия (PAGE_COMPRESSION_LEVEL) регулирует соотношение между скоростью и затратами, однако за пределами средних уровней предельная выгода снижается. Краткая серия измерений с использованием реального набора данных позволяет быстро определить оптимальный вариант Уровень.
| Алгоритм | Типичная ставка | Стоимость процессора | Пригодность | Примечания |
|---|---|---|---|---|
| zlib | 40–60 % | Средний | Множество таблиц OLTP и отчетности | Хороший сайт Баланс из скорости/задержки |
| lz4 | 30–50 % | Низкий | Высокие требования к пропускной способности | Очень быстро Декомпрессия |
| lzo | 30–50 % | Низкий | Рабочие нагрузки, требующие интенсивного ввода текста | Низкая задержка при вставке |
| lzma | 50–70 % | Высокий | Архив/неактуальные данные | Для редких Изменения |
| bzip2 | 50–70 % | Высокий | Избранные истории | Медленно, хороший рейтинг |
Отслеживание показателей и мониторинг
Я измеряю пропускную способность, задержку, загрузку ЦП и Пул буферов-Показатель «Hitrate», поскольку только общая картина показывает реальный эффект. Снижение объёмов ввода-вывода при неизменной или улучшенной задержке свидетельствует о том, что настройки подошли. Если загрузка ЦП превышает безопасный уровень, я проверяю алгоритм и уровень сжатия и, при необходимости, переключаюсь на lz4. Кроме того, я обращаю внимание на размер журнала повторения (redo-log) и поведение контрольных точек (checkpoint), поскольку оба этих фактора влияют на профиль записи. В долгосрочной перспективе я выявляю тенденции и могу проактивно реагировать на изменения Рабочие нагрузки реагировать.
Тщательное планирование резервного копирования и технического обслуживания
При полном и инкременльном резервном копировании файлов наблюдается снижение объем данных, поскольку при этом копируется меньшее количество байтов, в то время как логические дампы, как правило, сохраняют свой размер. Я тестирую время восстановления на реальных данных, чтобы сопоставить экономию места с фактической продолжительностью восстановления. Я документирую изменения в алгоритме или уровне и проверяю совместимость инструментов резервного копирования с используемой версией MariaDB. Кроме того, я проверяю целостность данных после крупных операций ALTER TABLE, особенно если многие таблицы были переведены на сжатие страниц. Таким образом, Время перезапуска предсказуемая, а стратегия обеспечения надежная.
Понимание файловой системы и уровня хранения данных
Чтобы файлы Sparse работали, файловая система должна Пробивание отверстий, что доступно в файловых системах ext4 и XFS и широко используется в хостинг-средах. Я обращаю внимание на параметры монтирования и глубину очереди, поскольку они сильно влияют на характеристики ввода-вывода. Для ext4 я, например, проверяю интервалы фиксации (commit) и режимы ведения журнала, а также учитываю, как сборка мусора влияет на работу SSD/NVMe. Взгляд на подходящие Параметры ext4 помогает согласовать эффекты сжатия страниц со свойствами файловой системы. Вот как я использую физический Хранение эффективно и предотвращает побочные эффекты.
Практическое руководство по введению
Я начну с тестовой среды и скопирую типичные производственные данные, чтобы получить первые показатели коэффициента пропускной способности, задержки и Пропускная способность . После этого я сначала включаю сжатие страниц для больших таблиц, в которых преобладает чтение, или для архивов с небольшим количеством обновлений. Я оцениваю результаты по четким показателям и сравниваю их с исходным состоянием, прежде чем переводить на новый режим другие таблицы. Своевременное взаимодействие с командами разработчиков приложений позволяет избежать неожиданностей во время окон технического обслуживания и обеспечивает четкие ожидания. После каждого расширения я корректирую уровень и Алгоритм до тех пор, пока экономия памяти и задержка не войдут в целевой диапазон.
В сочетании с другими оптимизациями
Хорошие показатели позволяют сократить количество прочитанных страниц, поэтому я проверяю Охват индекса и кардинальности на регулярной основе. Четко сформулированные запросы, правильные соединения и целенаправленное использование EXPLAIN снижают количество операций ввода-вывода и поддерживают высокий коэффициент попадания в кэш. Достаточно большой размер пула буферов предотвращает ненужные операции чтения с диска и делает накладные расходы на сжатие в «горячем наборе» практически незаметными. С точки зрения аппаратного обеспечения SSD-накопители и NVMe окупаются благодаря высокому показателю IOPS и низкой задержке, что усиливает преимущества сжатия страниц. В целом сжатие играет важную роль наряду с проектированием запросов, работой с индексами и Расширение памяти объединяются, образуя таким образом оптимизированный конвейер данных.
Совместимость, версии и ограничения
Я слежу за тем, в каких средах поддерживается сжатие страниц и где проходят границы. В распространенных файловых системах Linux, таких как ext4 и XFS, метод «hole-punching» работает стабильно. ZFS ведет себя иначе: поскольку в ней этот метод недоступен в полной мере, в случае с ZFS я скорее использую родной Включаю сжатие ZFS и отказываюсь от сжатия страниц. В конфигурациях контейнеров с OverlayFS я предпочитаю подключать каталог данных в качестве bind-mount с хоста, чтобы обеспечить надежную работу punch-операций и разреженных файлов. Кроме того, я не сочетаю сжатие страниц с шифрованием таблиц InnoDB на уровне файлов: шифрование делает данные в значительной степени случайными для алгоритмов сжатия и частично блокирует функцию «punching». Тем, кому требуется и то, и другое, рекомендуется использовать шифрование тома/файловой системы на уровне ниже InnoDB.
Что касается размера страницы InnoDB (innodb_page_size), я обычно оставляю значение 16K. Меньшие размеры страниц могут затруднять сжатие и увеличивать накладные расходы на управление. Временные таблицы или таблицы MEMORY/рабочие таблицы не подвергаются сжатию страниц — выигрыш наблюдается только в соответствующем табличном пространстве .ibd.
Активация, деактивация и восстановление без неожиданностей
Изменение с помощью команды ALTER TABLE всегда приводит к перестроению таблицы. Поэтому я планирую:
- Окно технического обслуживания с четко определёнными SLA и достаточным объёмом дискового пространства для временной копии.
- Предварительная проверка с помощью EXPLAIN для команды ALTER, чтобы увидеть ожидаемый порядок действий (INPLACE/COPY, уровень блокировки).
- Дополнительная стратегия группировки: сначала большие таблицы, которые редко изменяются, затем средние, а в конце — «горячие» таблицы — если таковые имеются.
Чтобы отключить эту функцию, я действую симметрично и устанавливаю PAGE_COMPRESSED=0. Затем я выполняю OPTIMIZE TABLE или повторную команду ALTER-Rebuild, чтобы табличное пространство снова записывалось без «дырок» и физическое потребление места отражалось реалистично.
Массовая загрузка, «горячие» обновления и дефрагментация
При работе с большими объёмами данных я либо загружаю данные непосредственно в сжатом виде, если ресурсы ввода-вывода ограничены, либо ускоряю импорт, загружая данные в несжатом виде, а затем с помощью команды ALTER TABLE переключаюсь на формат PAGE_COMPRESSED. Затем при перестроении таблицы обеспечивается оптимальная организация данных с максимальным эффектом «лох-панчинг». Для таблиц с большим количеством обновлений на месте я планирую регулярные перезаписи (OPTIMIZE TABLE или перенос партиций), поскольку в результате повторяющихся изменений преимущества сжатия со временем могут снижаться. Для столбцов BLOB/TEXT я использую современный формат строк (например, DYNAMIC), чтобы обеспечить эффективную обработку больших объёмов данных вне страницы и не допустить ненужного увеличения соседних страниц.
Проверить и подтвердить эффективность
Я проверяю, работает ли сжатие страниц, с помощью простых системных команд и представлений MariaDB:
# Сравнение кажущегося размера и размера занятых блоков
ls -ls --block-size=1 *.ibd
du -h --apparent-size *.ibd
du -h *.ibd
# Проверка степени фрагментации (punching) для каждого файла
filefrag -v your_table.ibd | tail -n +1
# В MariaDB: проверка статуса таблицы и опций DDL
SHOW TABLE STATUS LIKE 'log_entries'\G
SHOW CREATE TABLE log_entries\G
Кажущийся размер (ls) соответствует логическому объему данных, в то время как ls показывает фактически занятые блоки. Заметная разница свидетельствует о правильной работе механизма «hole-punching». Я сопоставляю эти результаты с показателями ввода-вывода (число операций чтения/записи в секунду, глубина очереди, задержка) и загрузкой ЦП, чтобы оценить общий эффект.
Сведения о резервном копировании: правильное резервное копирование и восстановление разреженных данных
Чтобы резервные копии учитывали экономию места, я обращаю внимание на поддержку разреженных данных в инструментах. При копировании физических файлов я использую соответствующие параметры, чтобы „пробелы“ не «заполнялись»:
# Копирование с сохранением разреженных областей
cp --sparse=always source.ibd dest.ibd
rsync -S --progress source.ibd dest.ibd
tar --sparse -cvf backup.tar /var/lib/mysql/datadir
# Проверка, остаётся ли целевой файл разреженным
du -h dest.ibd
ls -ls dest.ibd
В случае резервного копирования с использованием моментальных снимков (например, на уровне блочных устройств) степень экономии варьируется в зависимости от поставщика. В случае логических дампов (mysqldump, mariadb-dump) размер экспорта практически не изменяется, однако время восстановления сокращается, если при последующей перестройке снова включается сжатие страниц, что позволяет уменьшить объемы ввода-вывода при восстановлении.
Репликация, обеспечение высокой доступности и внедрение в производственной среде
Сжатие страниц работает прозрачно для репликации и бинарных журналов, поскольку реплицируются изменения SQL, а не сжатые страницы. Я предпочитаю сначала развертывать изменения DDL на репликах и отслеживать задержки и операции ввода-вывода, прежде чем перенастраивать основной сервер. В случае многоисточниковых или каскадных топологий я слежу за тем, чтобы везде был установлен подходящий алгоритм (innodb_compression_algorithm), чтобы идентичные DDL-команды обеспечивали одинаковое поведение. Для внедрения без простоев я совмещаю переход с планами переключения/перехода на резервный сервер.
Расширенная настройка: профили ввода-вывода и контрольные точки
Поскольку сжатие изменяет количество и размер записываемых блоков, я настраиваю параметры ввода-вывода InnoDB в соответствии с новым профилем. Реалистичное значение innodb_io_capacity (и *_max) помогает создавать корректные контрольные точки без внезапных пиков сброса. Я проверяю, согласуется ли буфер двойной записи с новой характеристикой записи, и отслеживаю соотношение между «грязными» страницами и частотой fsync. На устройствах с высокой степенью параллелизма (NVMe) я масштабирую потоки записи и глубину очереди блочного устройства, чтобы меньший объём данных приводил к реальному сокращению задержки.
Устранение неполадок и типичные трудности
- Пиковые значения нагрузки на ЦП после активации: Переключиться на алгоритм lz4/lzo или умеренно снизить значение PAGE_COMPRESSION_LEVEL, увеличить размер горячих наборов в буферном пуле.
- Уровень ввода-вывода снижается, но задержка колеблется: Проверить установку контрольных точек и долю «грязных» страниц; слишком маленькие журналы повторения приводят к частым сбросам.
- Неожиданно небольшая экономия места: Проверить структуру данных (много двоичных/случайных полей), принудительно выполнить перестроение, проанализировать шаблоны BLOB/TEXT, при необходимости перейти на zlib.
- Не влияет на размер файла: Проверить поддержку функции „Hole-Punching“ в файловой системе, избегать использования контейнерного уровня, не «уплотнять» разреженную копию.
- Таблицы, о которых так много говорят: Использовать сжатие страниц выборочно; рассмотреть альтернативные варианты (сжимать только таблицы архивов и журналов).
Практические примеры настройки
Чтобы начать с чистого листа, я считаю, что глобальная конфигурация должна быть лаконичной и удобной в управлении:
[mysqld]
innodb_file_per_table=1
innodb_compression_algorithm=zlib # или lz4/lzo в зависимости от профиля
# Настройте остальные параметры ввода-вывода в соответствии с платформой
# innodb_io_capacity=...
# innodb_io_capacity_max=...
Для каждой таблицы я явно задаю степень сжатия, чтобы избежать нежелательных побочных эффектов. После крупных импортов данных или большого количества обновлений я целенаправленно использую команду OPTIMIZE TABLE, чтобы заново откалибровать пробелы и уменьшить фрагментацию, образовавшуюся с течением времени.
Краткое резюме
Сжатие страниц InnoDB заметно снижает потребление памяти и снижает нагрузку на ВВОД/ВЫВОД на ЦП без изменения буферного пула. Правильно подобранные алгоритмы, такие как lz4 или zlib, обеспечивают во многих рабочих нагрузках экономию 30–60 % и при этом остаются в допустимом диапазоне задержки. Решающее значение имеют файловая система с функцией «hole-punching», параметр innodb_file_per_table и правильная активация на уровне таблиц. Те, кто проводит тесты с реальными данными, интегрирует мониторинг и точно настраивает уровень и алгоритм, достигают стабильно низких затрат при надёжной Производительность. Таким образом, вы сэкономите место, обеспечите высокую производительность ваших систем и получите дополнительные ресурсы для растущих наборов данных.
