Page MariaDB La compression réduit les besoins en mémoire physique en compressant les pages InnoDB avant leur écriture sur le support de stockage, ce qui réduit sensiblement le volume des E/S. Je vais vous montrer comment économiser de la mémoire et maintenir une faible latence, quelles sont les conditions requises et quels paramètres sont les plus efficaces dans la pratique.
Points centraux
Ces points clés succincts présentent les aspects les plus importants.
- Page par page La compression réduit l'encombrement et les E/S.
- Non compressé Le pool de mémoire tampon limite la charge du processeur dans la mémoire vive.
- Flexible Activation par table avec PAGE_COMPRESSED.
- système de fichiers- La prise en charge du « Sparse/Hole Punching » est obligatoire.
- Choix de l'algorithme contrôle la fréquence, la latence et la charge CPU.
Fonctionnement technique de la compression de pages InnoDB
Je compresse chaque page InnoDB juste avant qu'elle ne soit écrite sur le disque, de sorte que l'espace de table n'occupe que le nombre d'octets effectivement réduit et que le système de fichiers marque les zones libres comme « sparse ». Dans le Pool de mémoire tampon Je continue à conserver les pages non compressées, ce qui permet de limiter la charge du processeur en mémoire vive et de garantir la rapidité des accès en lecture fréquents. Par défaut, les pages InnoDB ont une taille de 16 Ko, mais les blocs stockés sont, après compression, d’une taille variablement plus petite, ce qui permet de gagner beaucoup d’espace, en particulier pour les champs de type texte ou JSON. Lors de la lecture, je décompresse la page directement après son chargement en mémoire vive, c’est-à-dire exactement à la limite d’E/S, là où le gain en termes de transfert est le plus important. Je décharge ainsi la charge de E/S vers le processeur, mais uniquement aux endroits où cela est justifié.
Compression de page vs. compression classique des tables InnoDB
La compression classique repose sur ROW_FORMAT=COMPRESSED associé à KEY_BLOCK_SIZE, ce qui génère un format de page compressé fixe et entraîne une charge décisionnelle supplémentaire lors de l'écriture ou de la mise à jour. Je préfère la Page La compression, car elle reste flexible : si une compression échoue, InnoDB peut stocker la page sans la compresser, sans modifier l'ensemble du format de fichier. Le pool de tampons continue de fonctionner avec des pages de 16 Ko non compressées, ce qui accélère les accès au cache et simplifie les chemins d'accès au processeur. Pour les charges de travail OLTP typiques, caractérisées par de nombreux inserts et un nombre modéré de mises à jour, la compression de page offre un meilleur équilibre entre gain d'espace et latence. Au final, j'obtiens souvent un gain perceptible en termes d'E/S, sans surcoût important à chaque Mise à jour de prendre des risques.
Conditions préalables et configuration de base
Pour la compression des pages, je nécessite InnoDB et j'active innodb_file_per_table, afin que chaque table utilise son propre espace de table. Le système de fichiers joue ici un rôle déterminant : il doit prendre en charge les fichiers dispersés et le « hole-punching », ce qui est le cas avec ext4 et XFS et est généralement disponible dans les volumes cloud modernes. Pour le choix de l’algorithme, je règle le paramètre `innodb_compression_algorithm`, généralement zlib, lz4 ou lzo, en fonction du taux de compression souhaité et du profil du processeur. Ceux qui évaluent la couche de stockage bénéficient d’un format compact Comparaison des systèmes de fichiers tout en tenant compte des options relatives aux pilotes et aux volumes. On obtient ainsi une Configuration, qui permet de gagner de la place, réduit les E/S et fonctionne de manière fiable.
Activation au niveau de la table
J'active la compression par page pour chaque table, après m'être assuré que les variables globales sont correctement définies, afin de cibler précisément les enregistrements qui apportent le plus grand bénéfice possible. Pour les nouvelles tables, je définis les options directement dans le DDL ; pour les tables existantes, une instruction ALTER TABLE effectue la conversion par réécriture. Je définis le niveau de compression à l'aide de PAGE_COMPRESSION_LEVEL ; le comportement dépend du Algorithme . Comme la migration prend du temps, je prévois des fenêtres de maintenance et je vérifie l'espace requis avec et sans compression à l'aide d'extraits de données réels. C'est ainsi que je vérifie Charges et un résultat sans surprise.
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;
Économies d'espace de stockage dans la pratique
Plus les données sont homogènes et riches en texte, plus l'effet est marquant Compression; Les tables de journaux et de rapports permettent généralement d'obtenir des résultats significatifs. Dans des charges de travail typiques, j'observe souvent une réduction de 40 à 60 % de l'espace mémoire occupé avec zlib, tandis que lz4 permet dans de nombreux cas de réduire cet espace de 30 à 50 %, tout en conservant un débit plus élevé. Les données binaires fortement distribuées apportent moins de gains, mais même dans ce cas, les volumes d’E/S et les coûts sont souvent réduits de manière notable. Je réalise toujours mes tests avec des instantanés de production sur un environnement de préproduction afin d’obtenir des ratios significatifs et d’identifier les pics de latence. Résultat : moins de données sur le support de stockage, des temps de transfert plus courts, une meilleure Mise à l'échelle.
Performances : évaluer correctement les E/S par rapport au processeur
Je vérifie d'abord si le goulot d'étranglement se situe au niveau du support de données ou au niveau de la CPU car le choix de la méthode de compression en dépend. Dans les environnements limités par les E/S, les volumes de lecture et d’écriture diminuent considérablement, ce qui augmente les performances effectives, souvent avec une charge supplémentaire de seulement 5 à 10 % par rapport aux tables non compressées, lorsque l’on utilise des algorithmes rapides. Les systèmes limités par le CPU tirent profit de lz4 ou lzo, qui fonctionnent très rapidement et n’atteignent que des taux légèrement inférieurs. Je tiens également compte du Tampon d'écriture double, car il influence le comportement d'écriture et, associé à la compression de page, détermine les caractéristiques d'E/S. Le pool de tampons restant non compressé, les accès fréquents au cache n'ont pratiquement aucun effet sur la Latence de.
Choix de l'algorithme et niveau de compression
Je décide de la Algorithme-Je pose la question en me basant sur des échantillons de données, le taux de lecture/écriture et la marge de manœuvre du processeur, plutôt que de me fier uniquement au taux de compression. Zlib offre souvent le gain d'espace le plus important pour une charge de calcul modérée, tandis que lz4/lzo se distinguent par une faible latence. J’utilise principalement LZMA ou bzip2 pour les archives ou les tables rarement modifiées, car leur coût en ressources CPU est plus élevé. Le niveau de compression (PAGE_COMPRESSION_LEVEL) détermine le rapport entre le taux de compression et la charge de calcul, mais l’utilité marginale diminue au-delà des niveaux moyens. Une brève série de mesures avec le jeu de données réel permet de trouver rapidement la meilleure solution. Niveau.
| Algorithme | Taux type | Coûts CPU | Aptitude | Remarques |
|---|---|---|---|---|
| zlib | 40–60 % | Moyens | De nombreuses tables OLTP/de reporting | Bon Balance en termes de débit/latence |
| lz4 | 30–50 % | Faible | Exigences élevées en matière de débit | Très rapide décompression |
| lzo | 30–50 % | Faible | Tâches nécessitant beaucoup d'écriture | Faible latence lors des insertions |
| lzma | 50–70 % | Haute | Archives/données inactives | Pour les maladies rares Modifications |
| bzip2 | 50–70 % | Haute | Histoires sélectives | Lentement, bon taux |
Garder un œil sur le suivi et les indicateurs
Je mesure le débit, la latence, l'utilisation du processeur et Pool de mémoire tampon- Taux de réussite, car seule une vue d’ensemble permet de mettre en évidence l’effet réel. Une baisse des volumes d’E/S avec une latence stable ou améliorée indique que la configuration est efficace. Si l’utilisation du processeur dépasse un niveau acceptable, je vérifie l’algorithme et le niveau, et je passe à lz4 si nécessaire. De plus, je surveille la taille du redo log et le comportement des points de contrôle, car ces deux éléments influencent le profil d'écriture. À long terme, j'identifie des tendances et je peux réagir de manière proactive aux changements Charges de travail réagir.
Bien planifier les sauvegardes et la maintenance
Les sauvegardes complètes et incrémentielles bénéficient d'une volume de données, car le nombre d'octets copiés est moindre, tandis que les sauvegardes logiques conservent généralement leur taille. Je teste les temps de restauration avec des données réelles afin de pouvoir mettre en balance le gain d'espace obtenu et la durée effective de la restauration. Je documente les modifications apportées à l’algorithme ou au niveau et je vérifie la compatibilité des outils de sauvegarde avec la version de MariaDB utilisée. De plus, je valide l’intégrité après des opérations ALTER TABLE de grande envergure, en particulier lorsque de nombreuses tables ont été converties à la compression de page. Ainsi, la Temps de redémarrage prévisible et la stratégie de sauvegarde fiable.
Comprendre le système de fichiers et la couche de stockage
Pour que les fichiers clairsemés fonctionnent, le système de fichiers a besoin Hole-Punching, qui est disponible sur ext4 et XFS et largement utilisé dans les configurations d'hébergement. Je prête attention aux options de montage et à la profondeur de file d'attente, car elles influencent fortement les courbes de performance d'E/S. Pour ext4, je vérifie notamment les intervalles de validation et les modes de journalisation, et je tiens compte de l’impact du ramassage des déchets (garbage collection) sur les SSD/NVMe. Un coup d’œil aux Options ext4 permet d'adapter les effets de la compression des pages aux caractéristiques du système de fichiers. C'est ainsi que j'utilise l'espace physique Stockage efficace et évite les effets secondaires.
Guide pratique pour l'introduction
Je commence par un environnement de test et je copie des données de production représentatives afin d'obtenir les premières mesures concernant le débit, la latence et Débit . Ensuite, j’active la compression de page, dans un premier temps, pour les tables volumineuses, principalement en lecture, ou pour les archives comportant peu de mises à jour. J’évalue les résultats à l’aide d’indicateurs clairs et je les compare à la situation initiale avant de modifier d’autres tables. Une communication précoce avec les équipes applicatives évite les surprises lors des fenêtres de maintenance et garantit des attentes claires. Après chaque extension, j’ajuste le niveau et Algorithme jusqu'à ce que les économies de mémoire et la latence se situent dans la fourchette visée.
Combinaison avec d'autres optimisations
De bons index permettent de réduire le nombre de pages lues ; c'est pourquoi je vérifie Couverture de l'indice et les cardinalités de manière régulière. Des requêtes bien formulées, des jointures adaptées et l’utilisation ciblée de la commande EXPLAIN réduisent les E/S et maintiennent un taux de réussite élevé dans le cache. Une taille suffisante du pool de tampons évite les chargements inutiles depuis le disque et rend la surcharge liée à la compression pratiquement imperceptible dans l’ensemble actif. Du côté matériel, les SSD et les disques NVMe s’avèrent très avantageux grâce à leur nombre élevé d’IOPS et à leur faible latence, ce qui renforce les avantages de la compression des pages. En résumé, la compression joue un rôle important dans la conception des requêtes, le travail sur les index et Extension de la mémoire ensemble, formant ainsi un chemin de données optimisé.
Compatibilité, versions et limites
Je garde à l'esprit les environnements qui prennent en charge la compression des pages et leurs limites. Sur les systèmes de fichiers Linux courants tels que ext4 et XFS, la technique du « hole punching » fonctionne de manière stable. ZFS se comporte différemment : comme cette technique n'y est pas disponible de manière équivalente, je privilégie plutôt sur ZFS la natif J'active la compression ZFS et je renonce à la compression par page. Dans les configurations de conteneurs utilisant OverlayFS, je préfère monter le répertoire de données depuis l'hôte via un montage « bind », afin que le « punching » et les fichiers « sparse » fonctionnent de manière fiable. De plus, je ne combine pas la compression de page avec le chiffrement des tables InnoDB au niveau des fichiers : le chiffrement rend les données largement aléatoires pour les algorithmes de compression et bloque en partie le « punching ». Si vous avez besoin des deux, optez pour un chiffrement de volume ou de système de fichiers sous InnoDB.
En ce qui concerne la taille de page InnoDB (innodb_page_size), je m'en tiens généralement à 16 Ko. Des tailles de page plus petites peuvent compliquer la compression et augmenter la charge administrative. Les tables temporaires ou les tables MEMORY/de travail ne sont pas affectées par la compression des pages : le gain ne concerne que l'espace de table .ibd correspondant.
Activation, désactivation et reconstructions sans mauvaises surprises
La modification via ALTER TABLE entraîne toujours une reconstruction de la table. Je prévois donc :
- Fenêtre de maintenance avec des SLA clairs et un espace de stockage suffisant pour la copie temporaire.
- Vérification préalable avec EXPLAIN pour ALTER, afin de voir la procédure attendue (INPLACE/COPY, niveau de verrouillage).
- Stratégie de traitement par lots facultative : commencer par les grandes tables qui changent rarement, puis les tables de taille moyenne, et enfin les tables très sollicitées – le cas échéant.
Pour désactiver cette fonctionnalité, je procède de manière symétrique et je définis PAGE_COMPRESSED=0. Ensuite, j'exécute une commande OPTIMIZE TABLE ou une nouvelle commande ALTER-Rebuild afin que l'espace de table soit à nouveau écrit sans « trous » et que l'espace physique occupé soit représenté de manière réaliste.
Chargements en masse, mises à jour à chaud et défragmentation
Pour les données en masse, soit je les charge directement sous forme compressée lorsque les ressources d'E/S sont limitées, soit j'accélère l'importation en les chargeant sans compression, puis en passant à PAGE_COMPRESSED à l'aide de la commande ALTER TABLE. La reconstruction force ensuite la disposition optimale avec un effet de « perforation » maximal. Pour les tables comportant un très grand nombre de mises à jour sur place, je prévois des réécritures régulières (OPTIMIZE TABLE ou rollovers de partition), car les avantages de la compression peuvent s’amenuiser au fil du temps en raison des modifications répétées. Pour les colonnes BLOB/TEXT, j’opte pour un format de ligne moderne (par exemple DYNAMIC), afin que les données hors page volumineuses soient gérées efficacement et que le voisinage des pages ne s’étende pas inutilement.
Vérifier et démontrer l'efficacité
Pour vérifier si la compression des pages fonctionne, j'utilise des commandes système simples et des vues MariaDB :
# Comparer la taille apparente et les blocs occupés
ls -ls --block-size=1 *.ibd
du -h --apparent-size *.ibd
du -h *.ibd
# Vérifier l'étendue de la fragmentation (punching) par fichier
filefrag -v your_table.ibd | tail -n +1
# Dans MariaDB : vérifier l'état des tables et les options DDL
SHOW TABLE STATUS LIKE 'log_entries'\G
SHOW CREATE TABLE log_entries\G
La taille apparente (ls) correspond au volume logique des données, tandis que cette commande affiche les blocs réellement occupés. Une différence notable indique que le « hole-punching » fonctionne correctement. Je recoupe cette mesure avec les indicateurs d'E/S (lectures/écritures par seconde, profondeur de file d'attente, latence) et l'utilisation du processeur afin d'évaluer l'effet global.
Détails de la sauvegarde : sauvegarder et restaurer correctement les données « sparse »
Pour que les sauvegardes respectent le gain d'espace, je veille à ce que les outils prennent en charge les fichiers fragmentés. Lors de la copie de fichiers physiques, j'utilise les options appropriées pour éviter que les espaces vides ne soient „ comblés “ :
# Copie avec conservation des zones clairsemées
cp --sparse=always source.ibd dest.ibd
rsync -S --progress source.ibd dest.ibd
tar --sparse -cvf backup.tar /var/lib/mysql/datadir
# Vérification que la destination reste « sparse »
du -h dest.ibd
ls -ls dest.ibd
Dans le cas des sauvegardes de type « snapshot » (par exemple au niveau des périphériques blocs), les gains varient considérablement d'un fournisseur à l'autre. Pour les sauvegardes logiques (mysqldump, mariadb-dump), la taille de l'exportation ne change pratiquement pas, mais les temps de restauration sont réduits si la reconstruction qui suit réactive la compression des pages, ce qui réduit ainsi les volumes d'E/S lors de la reconstruction.
Réplication, haute disponibilité et déploiements en production
La compression des pages est transparente pour la réplication et les journaux binaires, car ce sont les modifications SQL qui sont répliquées, et non les pages compressées. Je préfère d'abord déployer les modifications DDL sur les réplicas et observer la latence et les E/S avant de modifier la configuration du serveur principal. Dans le cas de topologies multi-sources ou en cascade, je veille à ce qu’un algorithme approprié (innodb_compression_algorithm) soit défini partout, afin que des DDL identiques produisent le même comportement. Pour les déploiements sans temps d'arrêt, je combine la migration avec des plans de basculement et de reprise après sinistre.
Optimisation avancée : profils d'E/S et points de contrôle
Comme la compression modifie le nombre et la taille des blocs à écrire, j'ajuste les paramètres d'E/S d'InnoDB en fonction du nouveau profil. Une valeur réaliste pour innodb_io_capacity (et *_max) permet de générer des points de contrôle propres, sans pics soudains de vidage. Je vérifie si le tampon d’écriture double s’adapte aux nouvelles caractéristiques d’écriture et je surveille le rapport entre les pages sales et le taux de fsync. Sur les périphériques à haut degré de parallélisme (NVMe), je fais évoluer le nombre de threads d’écriture et la profondeur de file d’attente du périphérique bloc, afin que la réduction du volume de données se traduise par une réelle réduction de la latence.
Dépannage et difficultés courantes
- Pics d'utilisation du processeur après l'activation : Passer à l'algorithme lz4/lzo ou réduire modérément la valeur de PAGE_COMPRESSION_LEVEL, et augmenter la taille des hotsets dans le pool de tampons.
- Les E/S diminuent, mais la latence varie : Vérifier le checkpointing et le taux de pages sales ; des journaux de reprise trop petits entraînent des vidages fréquents.
- Un gain de place étonnamment faible : Vérifier la structure des données (nombreux champs binaires/aléatoires), forcer la reconstruction, analyser les modèles BLOB/TEXT, passer à zlib si nécessaire.
- Aucun impact sur la taille du fichier : Vérifier la prise en charge du „ hole punching “ par le système de fichiers, éviter les couches de conteneurs, ne pas « désparsifier » les copies clairsemées.
- Tableaux très commentés : Utiliser la compression de page de manière sélective ; envisager des alternatives (ne compresser que les tables d'archives et de journaux).
Exemples de configuration concrets
Pour partir du bon pied, je préfère que la configuration globale reste concise et facile à gérer :
[mysqld]
innodb_file_per_table=1
innodb_compression_algorithm=zlib # ou lz4/lzo selon le profil
# adapter les autres paramètres d'E/S en fonction de la plateforme
# innodb_io_capacity=...
# innodb_io_capacity_max=...
Je définis explicitement la compression pour chaque table afin d'éviter tout effet indésirable. Après des importations volumineuses ou de nombreuses mises à jour, j'utilise de manière ciblée la commande OPTIMIZE TABLE pour recalibrer les espaces vides et réduire la fragmentation accumulée au fil du temps.
En bref
La compression des pages InnoDB réduit sensiblement l'utilisation de la mémoire et allège la charge de E/S vers le processeur, sans modifier le pool de tampons. Des algorithmes bien choisis, tels que lz4 ou zlib, permettent de réaliser des gains de 30 à 60 % dans de nombreuses charges de travail, tout en maintenant la latence dans des limites acceptables. Il est essentiel de disposer d'un système de fichiers avec la fonctionnalité « hole-punching », d'activer innodb_file_per_table et de procéder à une activation correcte au niveau des tables. En effectuant des tests avec des données réelles, en intégrant un système de surveillance et en ajustant finement les niveaux ainsi que les algorithmes, on parvient à maintenir des coûts bas sur le long terme tout en garantissant une fiabilité Performance. Vous gagnez ainsi de la place, assurez la rapidité de vos systèmes et disposez de capacités supplémentaires pour accueillir des ensembles de données de plus en plus volumineux.
