Compresión de páginas de MariaDB: ahorrar espacio de almacenamiento con una pérdida mínima de rendimiento

Página de MariaDB La compresión reduce las necesidades de memoria física al comprimir las páginas de InnoDB antes de escribirlas en el disco, lo que reduce notablemente los volúmenes de E/S. Te mostraré cómo ahorrar memoria y mantener baja la latencia, cuáles son los requisitos previos y qué ajustes son los más eficaces en la práctica.

Puntos centrales

Estos puntos clave, presentados de forma concisa, ofrecen una introducción a los aspectos más importantes.

• Página a página La compresión reduce el espacio necesario y las operaciones de E/S.
• Sin comprimir El pool de búferes limita la carga de la CPU en la RAM.
• Flexible Activación por tabla con PAGE_COMPRESSED.
• sistema de archivos-Es obligatorio que admita la técnica «Sparse/Hole Punching».
• Elección del algoritmo controla la frecuencia, la latencia y el consumo de CPU.

Cómo funciona técnicamente la compresión de páginas de InnoDB

Comprimí cada página de InnoDB justo antes de que se escriba en el disco, de modo que el espacio de tabla solo ocupe los bytes realmente reducidos y el sistema de archivos marque las áreas libres como «sparse». En el Pool de búferes Sigo manteniendo las páginas sin comprimir, lo que reduce la carga de la CPU en la memoria RAM y permite que los accesos de lectura frecuentes sigan siendo rápidos. Por defecto, las páginas de InnoDB tienen un tamaño de 16 K, pero los bloques almacenados resultan, tras la compresión, de un tamaño variablemente menor, lo que ahorra mucho espacio, especialmente en campos de texto o JSON. Al leer, descomprimo la página directamente después de cargarla en la RAM, es decir, justo en el límite de E/S, donde el ahorro en la transmisión es más significativo. De este modo, desplazo la carga de E/S en relación con la CPU, pero solo en aquellos casos en los que resulte razonable.

Compresión de páginas frente a la compresión clásica de tablas InnoDB

La compresión clásica se basa en ROW_FORMAT=COMPRESSED junto con KEY_BLOCK_SIZE, lo que genera un formato de página comprimido fijo y supone una carga adicional a la hora de tomar decisiones durante la escritura o la actualización. Yo prefiero la Página La compresión, porque mantiene la flexibilidad: si no se consigue comprimir una página, InnoDB puede almacenarla sin comprimir sin modificar el formato completo del archivo. El buffer pool sigue trabajando con páginas de 16 K sin comprimir, lo que agiliza las aciertos en la caché y simplifica las rutas de la CPU. En cargas de trabajo OLTP típicas, con muchas inserciones y actualizaciones moderadas, la compresión de páginas ofrece un mejor equilibrio entre ahorro de espacio y latencia. Como resultado, a menudo obtengo una ventaja notable en las operaciones de E/S sin una sobrecarga elevada en cada Actualización al riesgo.

Requisitos y configuración básica

Para la compresión de páginas, necesito tener instalado InnoDB y activo innodb_file_per_table, para que cada tabla utilice su propio espacio de tabla. El sistema de archivos es fundamental: debe admitir archivos dispersos y «hole-punching», algo que sí ofrecen ext4 y XFS y que, por lo general, está presente en los volúmenes en la nube modernos. Para elegir el algoritmo, configuro innodb_compression_algorithm; normalmente se trata de zlib, lz4 o lzo, dependiendo de la velocidad deseada y del perfil de la CPU. Quien evalúe la capa de almacenamiento se beneficiará de un formato compacto Comparación de sistemas de archivos y tiene en cuenta también las opciones de controladores y volúmenes. De este modo se crea una Configuración, que ahorra espacio, reduce las operaciones de E/S y funciona de forma fiable.

Activación a nivel de tabla

Activo la compresión de páginas por tabla, una vez que las variables globales están correctamente configuradas, para poder abordar de forma específica los registros que aportan el mayor beneficio posible. Para las tablas nuevas, configuro las opciones directamente en el DDL; en el caso de las tablas existentes, una instrucción ALTER TABLE se encarga de la conversión mediante la reescritura. Defino el nivel de compresión con PAGE_COMPRESSION_LEVEL; el comportamiento depende del Algoritmo . Como la transición lleva tiempo, programo ventanas de mantenimiento y compruebo el espacio necesario con y sin compresión a partir de fragmentos de datos reales. Así es como compruebo Gastos y un resultado sin sorpresas.

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;

Ahorro de espacio de almacenamiento en la práctica

Cuanto más homogéneos y con mayor contenido de texto sean los datos, mejor funciona la Compresión; Las tablas de registros y de informes suelen ofrecer resultados notables. En cargas de trabajo típicas, suelo observar una reducción de entre 40 y 60 % en el espacio de memoria ocupado con zlib, mientras que lz4 suele situarse entre 30 y 50 % en muchos casos y, a cambio, deja más ancho de banda disponible. Los datos binarios muy distribuidos aportan menos beneficios, pero incluso en esos casos los volúmenes de E/S y los costes suelen reducirse de forma notable. Siempre realizo pruebas con instantáneas de producción en el entorno de staging para obtener ratios significativos e identificar picos de latencia. El resultado: menos datos en el soporte de almacenamiento, tiempos de transferencia más cortos y un mejor Escala.

Rendimiento: cómo evaluar correctamente la E/S frente a la CPU

Primero compruebo si el cuello de botella está en el soporte de datos o en la CPU , ya que de ello depende la elección del método de compresión. En entornos limitados por E/S, los volúmenes de lectura y escritura se reducen considerablemente, por lo que el rendimiento efectivo aumenta, a menudo con una carga adicional de tan solo 5-10 % en comparación con las tablas sin comprimir cuando se utilizan algoritmos rápidos. Los sistemas limitados por la CPU se benefician de lz4 o lzo, que funcionan muy rápido y solo alcanzan tasas ligeramente inferiores. Además, tengo en cuenta el Búfer de doble escritura, ya que influye en el comportamiento de escritura y, junto con la compresión de páginas, determina las características de E/S. Dado que el grupo de búferes permanece sin comprimir, las aciertos frecuentes en la caché apenas afectan a la Latencia de.

Elección del algoritmo y nivel de compresión

Yo decido el Algoritmo-Valoro la elección en función de patrones de datos, velocidad de lectura/escritura y margen de la CPU, en lugar de guiarme únicamente por la tasa de compresión. Zlib suele ofrecer el mayor ahorro de espacio con un esfuerzo computacional moderado, mientras que lz4/lzo destacan por su baja latencia. Utilizo LZMA o bzip2 sobre todo para archivos o tablas que se modifican con poca frecuencia, ya que el coste en CPU es mayor. El nivel de compresión (PAGE_COMPRESSION_LEVEL) regula la relación entre velocidad y esfuerzo, aunque con una utilidad marginal decreciente más allá de los niveles medios. Una breve serie de mediciones con el conjunto de datos real permite encontrar rápidamente la mejor opción. Nivel.

Algoritmo	Tasa típica	Costes de la CPU	Idoneidad	Notas
zlib	40–60 %	Medio	Muchas tablas OLTP y de informes	Bien Saldo de velocidad/latencia
lz4	30–50 %	Bajo	Elevados requisitos de rendimiento	Muy rápido Descompresión
lzo	30–50 %	Bajo	Cargas de trabajo con gran volumen de escritura	Baja latencia en las inserciones
lzma	50–70 %	Alta	Archivos/datos inactivos	Para las enfermedades raras Cambios
bzip2	50–70 %	Alta	Historiales selectivos	Lento, buena cuota

No perder de vista el seguimiento y las métricas

Mido el rendimiento, la latencia, la carga de la CPU y Pool de búferes-Índice de aciertos, porque solo la visión global muestra el efecto real. Una disminución de los volúmenes de E/S con una latencia constante o mejorada indica que la configuración ha dado en el blanco. Si la carga de la CPU supera un nivel aceptable, compruebo el algoritmo y el nivel y, si es necesario, cambio a lz4. Además, presto atención al tamaño del registro de repetición (redo log) y al comportamiento de los puntos de control (checkpoints), ya que ambos influyen en el perfil de escritura. A largo plazo, identifico tendencias y puedo responder de forma proactiva a los cambios Cargas de trabajo reaccionar.

Planificar adecuadamente las copias de seguridad y el mantenimiento

Las copias de seguridad completas e incrementales se benefician de la menor volumen de datos, ya que se copian menos bytes, mientras que los volcados lógicos suelen mantener su tamaño. Compruebo los tiempos de restauración con datos reales para poder sopesar el ahorro de espacio obtenido frente a la duración práctica de la restauración. Documento los cambios en el algoritmo o en el nivel y compruebo la compatibilidad de las herramientas de copia de seguridad con la versión de MariaDB utilizada. Además, valido la integridad tras operaciones ALTER TABLE de gran envergadura, especialmente cuando se han cambiado muchas tablas a la compresión de páginas. De este modo, se mantiene la Tiempo de reinicio previsible y la estrategia de seguridad fiable.

Comprender el sistema de archivos y el nivel de almacenamiento

Para que los archivos dispersos funcionen, el sistema de archivos necesita Perforación, que está disponible en ext4 y XFS y es muy habitual en entornos de alojamiento web. Presto especial atención a las opciones de montaje y a la profundidad de la cola, ya que influyen considerablemente en las curvas de rendimiento de E/S. En el caso de ext4, compruebo, por ejemplo, los intervalos de confirmación y los modos de diario, y tengo en cuenta cómo afecta la recolección de basura a los SSD/NVMe. Echar un vistazo a los Opciones de ext4 ayuda a adaptar los efectos de la compresión de páginas a las características del sistema de archivos. Así es como utilizo el espacio físico Almacenamiento es eficaz y evita los efectos secundarios.

Guía práctica para la introducción

Empiezo con un entorno de prueba y copio datos representativos de producción para obtener los primeros valores de medición de la tasa, la latencia y Rendimiento para obtenerla. A continuación, activo la compresión de páginas, en primer lugar, en tablas grandes, en las que predomina la lectura, o en archivos con pocas actualizaciones. Evalúo los resultados basándome en indicadores claros y los comparo con la situación inicial antes de aplicar el cambio a otras tablas. La comunicación temprana con los equipos de aplicaciones evita sorpresas durante las ventanas de mantenimiento y garantiza unas expectativas claras. Tras cada ampliación, ajusto el nivel y Algoritmo hasta que el ahorro de memoria y la latencia se sitúen dentro del rango objetivo.

Combinación con otras optimizaciones

Unos buenos índices reducen el número de páginas que hay que leer, por eso compruebo Cobertura del índice y las cardinalidades de forma regular. Las consultas bien formuladas, las uniones adecuadas y el uso selectivo de EXPLAIN reducen las operaciones de E/S y mantienen alta la tasa de aciertos de la caché. Un tamaño de pool de búfer suficientemente grande evita cargas innecesarias desde el disco y hace que la sobrecarga de la compresión en el hotset sea prácticamente imperceptible. En cuanto al hardware, los SSD y NVMe resultan muy ventajosos gracias a su elevado número de IOPS y su baja latencia, lo que potencia las ventajas de la compresión de páginas. En resumen, la compresión influye en el diseño de las consultas, el trabajo con índices y Ampliación de la capacidad de almacenamiento se combinan, creando así una ruta de datos optimizada.

Compatibilidad, versiones y limitaciones

Estoy al tanto de en qué entornos es compatible la compresión de páginas y cuáles son sus limitaciones. En sistemas de archivos Linux habituales, como ext4 y XFS, el «hole-punching» funciona de forma estable. ZFS se comporta de manera diferente: dado que el «punching» no está disponible de forma equivalente en este sistema, en ZFS prefiero utilizar la nativo Activo la compresión ZFS y prescindo de la compresión de páginas. En configuraciones de contenedores con OverlayFS, prefiero montar el directorio de datos como un montaje Bind desde el host, para que el «punching» y los archivos dispersos funcionen de forma fiable. Además, no combino la compresión de páginas con el cifrado de tablas InnoDB a nivel de archivo: el cifrado hace que los datos resulten en gran medida aleatorios para los algoritmos de compresión y, en algunos casos, también bloquea el «punching». Quien necesite ambas cosas, debe optar por el cifrado de volumen o de sistema de archivos por debajo de InnoDB.

En cuanto al tamaño de página de InnoDB (innodb_page_size), suelo mantenerlo en 16K. Los tamaños de página más pequeños pueden dificultar la compresión y aumentar la sobrecarga administrativa. Las tablas temporales o las tablas MEMORY/de trabajo no se ven afectadas por la compresión de páginas; la mejora solo se produce en el espacio de tabla .ibd correspondiente.

Activación, desactivación y reconstrucciones sin sorpresas

La modificación mediante ALTER TABLE siempre provoca una reconstrucción de la tabla. Por eso, tengo pensado hacer lo siguiente:

• Ventanas de mantenimiento con SLA claros y espacio de almacenamiento suficiente para la copia temporal.
• Comprobación previa con EXPLAIN para ALTER, con el fin de ver el procedimiento esperado (INPLACE/COPY, nivel de bloqueo).
• Estrategia de procesamiento por lotes opcional: primero las tablas grandes que rara vez se modifican, después las medianas y, por último, las tablas más activas —si es que hay alguna—.

Para desactivarlo, sigo un procedimiento simétrico y establezco PAGE_COMPRESSED=0. A continuación, ejecuto un OPTIMIZE TABLE o vuelvo a ejecutar un ALTER-Rebuild, para que el tablespace se vuelva a escribir sin huecos y el consumo de espacio físico se refleje de forma realista.

Cargas masivas, actualizaciones en caliente y desfragmentación

En el caso de grandes volúmenes de datos, los cargo directamente comprimidos si hay escasez de E/S, o bien acelero la importación cargándolos sin comprimir y, a continuación, cambio a PAGE_COMPRESSED mediante ALTER TABLE. A continuación, la reconstrucción impone la estructura óptima con el máximo efecto de «perforación». En el caso de tablas con un gran número de actualizaciones in situ, programo reescrituras periódicas (OPTIMIZE TABLE o rotaciones de particiones), ya que los cambios repetidos pueden reducir las ventajas de la compresión con el paso del tiempo. Para las columnas BLOB/TEXT, apuesto por un formato de línea moderno (p. ej., DYNAMIC), de modo que los datos grandes fuera de página se gestionen de forma eficiente y la vecindad de páginas no aumente innecesariamente.

Comprobar y demostrar la eficacia

Para comprobar si la compresión de páginas funciona, utilizo unos sencillos comandos del sistema y las vistas de MariaDB:

# Comparar el tamaño aparente con los bloques ocupados
ls -ls --block-size=1 *.ibd
du -h --apparent-size *.ibd
du -h *.ibd

# Comprobar el grado de fragmentación (punching) por archivo
filefrag -v your_table.ibd | tail -n +1

# En MariaDB: comprobar el estado de las tablas y las opciones DDL
SHOW TABLE STATUS LIKE 'log_entries'\G
SHOW CREATE TABLE log_entries\G

El tamaño aparente (ls) se mantiene en el volumen lógico de datos, mientras que muestra los bloques realmente ocupados. Una diferencia apreciable indica que el «hole-punching» funciona correctamente. Correlaciono esta medición con las métricas de E/S (lecturas/escrituras por segundo, profundidad de la cola, latencia) y la carga de la CPU para evaluar el efecto global.

Detalles de la copia de seguridad: cómo realizar correctamente la copia de seguridad y la restauración de datos dispersos

Para que las copias de seguridad respeten el ahorro de espacio, me aseguro de que las herramientas sean compatibles con el formato „sparse“. Al copiar archivos físicos, utilizo los parámetros adecuados para que los huecos no se «rellenen»:

# Copiar conservando las áreas dispersas
cp --sparse=always source.ibd dest.ibd
rsync -S --progress source.ibd dest.ibd
tar --sparse -cvf backup.tar /var/lib/mysql/datadir

# Comprobar si el destino sigue siendo «sparse»
du -h dest.ibd
ls -ls dest.ibd

En el caso de las copias de seguridad de instantáneas (por ejemplo, a nivel de dispositivo de bloques), el ahorro varía en función del proveedor. En el caso de los volcados lógicos (mysqldump, mariadb-dump), el tamaño de la exportación apenas varía, pero los tiempos de restauración se reducen si la reconstrucción posterior vuelve a activar la compresión de páginas, lo que reduce los volúmenes de E/S durante la reconstrucción.

Replicación, alta disponibilidad y implementaciones en producción

La compresión de páginas funciona de forma transparente para la replicación y los binlogs, ya que lo que se replica son los cambios SQL, no las páginas comprimidas. Prefiero aplicar primero los cambios DDL en las réplicas y observar la latencia y las operaciones de E/S antes de realizar el cambio en el servidor primario. En topologías multisource o en cascada, me aseguro de que en todas partes se haya configurado el algoritmo adecuado (innodb_compression_algorithm), para que un DDL idéntico produzca el mismo comportamiento. Para implementaciones sin tiempo de inactividad, combino la migración con planes de conmutación y conmutación por error.

Configuración avanzada: perfiles de E/S y puntos de control

Dado que la compresión modifica el número y el tamaño de los bloques que se van a escribir, ajusto los parámetros de E/S de InnoDB al nuevo perfil. Un valor realista de innodb_io_capacity (y *_max) ayuda a generar puntos de control limpios, sin picos repentinos de vaciado. Compruebo si el búfer de doble escritura se adapta a las nuevas características de escritura y superviso la relación entre las páginas sucias y la tasa de fsync. En dispositivos con alto grado de paralelismo (NVMe), escalo los hilos de escritura y la profundidad de la cola del dispositivo de bloques, para que la menor cantidad de datos se traduzca en una reducción real de la latencia.

Solución de problemas y dificultades habituales

• Picos de CPU tras la activación: Cambiar el algoritmo a lz4/lzo o reducir moderadamente el valor de PAGE_COMPRESSION_LEVEL; aumentar el tamaño de los conjuntos activos en el pool de búferes.
• El I/O disminuye, pero la latencia varía: Comprobar los puntos de control y la tasa de páginas sucias; unos registros de redo demasiado pequeños provocan vaciados frecuentes.
• Un ahorro de espacio inesperadamente reducido: Comprobar la estructura de datos (muchos campos binarios/aleatorios), forzar la reconstrucción, analizar los patrones BLOB/TEXT y, si es necesario, cambiar a zlib.
• No afecta al tamaño del archivo: Comprobar si el sistema de archivos admite „hole-punching“, evitar las capas de contenedor y no «desesparsificar» las copias dispersas.
• Tablas muy comentadas: Utilizar la compresión de páginas de forma selectiva; valorar alternativas (comprimir únicamente las tablas de archivo y de registro).

Ejemplos prácticos de configuración

Para empezar con buen pie, prefiero que la configuración global sea concisa y fácil de gestionar:

[mysqld]
innodb_file_per_table=1
innodb_compression_algorithm=zlib   # o lz4/lzo, según el perfil
# ajustar el resto de parámetros de E/S según la plataforma
# innodb_io_capacity=...
# innodb_io_capacity_max=...

Defino la compresión de forma explícita para cada tabla, con el fin de evitar efectos secundarios no deseados. Tras importaciones de gran volumen o numerosas actualizaciones, utilizo de forma selectiva la instrucción OPTIMIZE TABLE para recalibrar los huecos y reducir la fragmentación acumulada con el tiempo.

Brevemente resumido

La compresión de páginas de InnoDB reduce notablemente el consumo de memoria y alivia la carga de E/S a la CPU, sin modificar el pool de búferes. Los algoritmos bien elegidos, como lz4 o zlib, ofrecen en muchas cargas de trabajo un ahorro de entre 30 y 60 % y mantienen la latencia dentro de los límites aceptables. Son fundamentales un sistema de archivos con «hole-punching», la opción innodb_file_per_table y una activación adecuada a nivel de tabla. Quien realice pruebas con datos reales, incorpore la monitorización y ajuste con precisión los niveles y los algoritmos, logrará unos costes bajos de forma duradera y un rendimiento fiable. Actuación. De este modo, ahorrará espacio, mantendrá sus sistemas ágiles y dispondrá de capacidad adicional para los conjuntos de datos cada vez más grandes.