Ga naar de inhoud 
MariaDB-pagina Compressie vermindert de fysieke opslagbehoefte door InnoDB-pagina’s te comprimeren voordat ze naar de schijf worden geschreven, waardoor de I/O-volumes merkbaar afnemen. Ik laat zien hoe u opslagruimte kunt besparen en de latentie laag kunt houden, welke voorwaarden van toepassing zijn en welke instellingen in de praktijk het meeste effect hebben.
Centrale punten
Deze beknopte punten geven een inleiding op de belangrijkste aspecten.
- Pagina voor pagina Compressie vermindert de benodigde opslagruimte en de I/O.
- Niet-gecomprimeerd De bufferpool beperkt de CPU-belasting in het RAM-geheugen.
- Flexibel Activering per tabel met PAGE_COMPRESSED.
- bestandssysteem-Ondersteuning voor sparse/hole punching is verplicht.
- Algoritmekeuze regelt de snelheid, de latentie en het CPU-verbruik.
Hoe InnoDB-paginacompressie technisch werkt
Ik comprimeer elke InnoDB-pagina vlak voordat deze naar de schijf wordt geschreven, zodat de tabelruimte slechts de daadwerkelijk gecomprimeerde bytes in beslag neemt en het bestandssysteem de vrije gebieden als ‘sparse’ markeert. In de Bufferpool Ik houd pagina’s nog steeds ongecomprimeerd, waardoor de CPU-belasting in het werkgeheugen laag blijft en frequente leesbewerkingen snel blijven. Standaard zijn InnoDB-pagina's 16K groot, maar de opgeslagen blokken worden na compressie variabel kleiner, wat vooral bij tekst- of JSON-velden veel ruimte bespaart. Bij het lezen pak ik de pagina direct na het laden in het RAM uit, dus precies op de I/O-grens, waar de besparing bij de overdracht het meest telt. Zo verplaats ik de belasting van I/O naar de CPU, maar alleen op die plaatsen waar dat redelijk is.
Paginacompressie versus klassieke InnoDB-tabelcompressie
Bij klassieke compressie wordt gebruikgemaakt van ROW_FORMAT=COMPRESSED in combinatie met KEY_BLOCK_SIZE, wat een vast gecomprimeerd paginaformaat oplevert en bij het schrijven of bijwerken extra beslissingsbelasting met zich meebrengt. Ik geef de voorkeur aan de Pagina Compressie, omdat het flexibel blijft: als compressie niet lukt, kan InnoDB de pagina ongecomprimeerd opslaan zonder het volledige bestandsformaat te wijzigen. De bufferpool blijft werken met ongecomprimeerde 16K-pagina’s, wat cache-hits versnelt en de CPU-paden eenvoudig houdt. Bij typische OLTP-workloads met veel invoegingen en een matig aantal updates biedt paginacompressie een betere balans tussen ruimtebesparing en latentie. Het resultaat is dat ik vaak een merkbaar I/O-voordeel krijg, zonder dat dit bij elke Update risico.
Vereisten en basisconfiguratie
Voor paginacompressie ga ik ervan uit dat InnoDB is geïnstalleerd en schakel ik het volgende in innodb_file_per_table, zodat elke tabel zijn eigen tabelruimte gebruikt. Het bestandssysteem is hierbij doorslaggevend: het moet sparse-bestanden en hole-punching ondersteunen, wat het geval is bij ext4 en XFS en doorgaans ook aanwezig is in moderne cloudvolumes. Voor de keuze van het algoritme stel ik innodb_compression_algorithm in, doorgaans zlib, lz4 of lzo, afhankelijk van de gewenste snelheid en het CPU-profiel. Wie de opslaglaag zorgvuldig afweegt, profiteert van een compacte Vergelijking van bestandssystemen en houdt daarbij ook rekening met stuurprogramma- en volumekeuzes. Zo ontstaat een Configuratie, die ruimte bespaart, de I/O vermindert en betrouwbaar werkt.
Activering op tabelniveau
Ik schakel paginacompressie per tabel in, nadat de globale variabelen correct zijn ingesteld, zodat ik gericht precies die gegevensrecords kan selecteren die het grootste voordeel opleveren. Voor nieuwe tabellen stel ik de opties direct in de DDL in; bij bestaande tabellen zorgt een ALTER TABLE-opdracht voor de omschakeling door de gegevens opnieuw te schrijven. Het compressieniveau definieer ik met PAGE_COMPRESSION_LEVEL; het gedrag hangt af van de gebruikte Algoritme omdat. Omdat de omschakeling tijd kost, plan ik onderhoudsvensters in en controleer ik de benodigde opslagruimte met en zonder compressie aan de hand van echte gegevensfragmenten. Zo controleer ik Uitgaven en een resultaat zonder verrassingen.
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;
Besparing op opslagruimte in de praktijk
Hoe homogener en hoe meer tekst de gegevens bevatten, hoe beter de Compressie; Log- en rapportagetabellen leveren meestal aanzienlijke voordelen op. Bij typische workloads zie ik vaak 40–60 % minder geheugengebruik met zlib, terwijl lz4 in veel gevallen volstaat met 30–50 % en daardoor meer doorvoercapaciteit overlaat. Sterk gedistribueerde binaire gegevens leveren minder voordeel op, maar ook daar nemen de I/O-volumes en kosten vaak merkbaar af. Ik test altijd met productiesnapshots op de staging-omgeving om betrouwbare statistieken te verkrijgen en pieken in de latentie te herkennen. Het resultaat: minder gegevens op de opslagmedia, kortere overdrachtstijden, betere Schalen.
Prestaties: I/O versus CPU correct beoordelen
Ik controleer eerst of het knelpunt zich op de gegevensdrager of op de CPU ligt, want daarvan hangt de keuze van de compressiemethode af. In I/O-beperkte omgevingen nemen de lees- en schrijfvolumes aanzienlijk af, waardoor de effectieve prestaties toenemen, vaak met slechts 5–10 % extra belasting ten opzichte van ongecomprimeerde tabellen bij snelle algoritmen. CPU-beperkte systemen profiteren van lz4 of lzo, die zeer snel werken en slechts iets lagere compressieverhoudingen behalen. Daarnaast houd ik rekening met de Doublewrite-buffer, omdat deze het schrijfgedrag beïnvloedt en samen met paginacompressie de I/O-karakteristiek bepaalt. Aangezien de bufferpool ongecomprimeerd blijft, hebben frequente cache-hits nauwelijks invloed op de Latency van.
Algoritmekeuze en compressieniveau
Ik besluit de Algoritme-Ik maak mijn keuze op basis van gegevenspatronen, lees-/schrijfsnelheid en CPU-capaciteit, in plaats van me alleen te richten op de compressieverhouding. Zlib levert vaak de grootste ruimtebesparing bij een matige rekenbelasting, terwijl lz4/lzo uitblinken door hun lage latentie. LZMA of bzip2 gebruik ik vooral voor archieven of tabellen die zelden worden gewijzigd, omdat de CPU-kosten hoger zijn. Het compressieniveau (PAGE_COMPRESSION_LEVEL) bepaalt de verhouding tussen snelheid en rekeninspanning, maar het randvoordeel neemt af bij niveaus boven het gemiddelde. Een korte reeks metingen met de echte dataset brengt snel de beste optie aan het licht. Niveau.
| Algoritme | Typische tarieven | CPU-kosten | Geschiktheid | Opmerkingen |
|---|---|---|---|---|
| zlib | 40–60 % | Medium | Veel OLTP-/rapportagetabellen | Goed Saldo uit snelheid/latentie |
| lz4 | 30–50 % | Laag | Hoge eisen aan de doorvoercapaciteit | Zeer snel Decompressie |
| lzo | 30–50 % | Laag | Schrijfintensieve taken | Lage latentie bij inserts |
| lzma | 50–70 % | Hoog | Archief/oude gegevens | Voor zeldzame Veranderingen |
| bzip2 | 50–70 % | Hoog | Selectieve geschiedenissen | Langzaam, goede kijkcijfers |
Monitoring en statistieken in de gaten houden
Ik meet de doorvoer, de latentie, het CPU-gebruik en Bufferpool-Hitrate, omdat alleen het totaalbeeld het werkelijke effect laat zien. Een daling van de I/O-volumes bij een gelijkblijvende of betere latentie duidt erop dat de configuratie goed werkt. Als de CPU-belasting boven een gezond niveau stijgt, controleer ik het algoritme en het niveau en schakel ik indien nodig over naar lz4. Daarnaast let ik op de grootte van het redo-log en het checkpoint-gedrag, aangezien beide het schrijfprofiel mede bepalen. Op de lange termijn herken ik trends en kan ik proactief reageren op gewijzigde Werklasten reageren.
Back-ups en onderhoud goed plannen
Volledige en incrementele back-ups profiteren van de lagere hoeveelheid gegevens, omdat er minder bytes worden gekopieerd, terwijl logische dumps meestal hun omvang behouden. Ik test de hersteltijden met echte gegevens, zodat ik de gewonnen ruimtebesparing kan afwegen tegen de praktische hersteltijd. Wijzigingen in het algoritme of het niveau documenteer ik en ik controleer de compatibiliteit van de back-uptools met de gebruikte MariaDB-versie. Daarnaast valideer ik de integriteit na grote ALTER TABLE-bewerkingen, vooral wanneer veel tabellen zijn omgezet naar paginacompressie. Zo blijft de Herstarttijd voorspelbaar en de beveiligingsstrategie betrouwbaar.
Het bestandssysteem en het opslagniveau begrijpen
Om sparse-bestanden te kunnen gebruiken, heeft het bestandssysteem Gatenponsen, wat beschikbaar is bij ext4 en XFS en veel wordt gebruikt in hostingomgevingen. Ik let op mount-opties en de wachtrijdiepte, omdat deze de I/O-karakteristieken sterk beïnvloeden. Voor ext4 controleer ik bijvoorbeeld commit-intervallen en journal-modi en houd ik rekening met het effect van garbage collection op SSD/NVMe. Een blik op geschikte ext4-opties helpt om de effecten van paginacompressie af te stemmen op de eigenschappen van het bestandssysteem. Zo maak ik gebruik van de fysieke Opslag efficiënt en voorkom bijwerkingen.
Praktische handleiding voor de introductie
Ik begin met een testomgeving en kopieer representatieve productiegegevens om de eerste meetwaarden voor quota, latentie en Doorvoer te verkrijgen. Vervolgens schakel ik ‘Page Compression’ in eerste instantie in voor grote tabellen of archieven die voornamelijk worden gelezen en waarin weinig updates plaatsvinden. Ik evalueer de resultaten aan de hand van duidelijke kengetallen en vergelijk ze met de uitgangssituatie, voordat ik andere tabellen aanpas. Tijdige communicatie met applicatieteams voorkomt verrassingen tijdens onderhoudsvensters en zorgt voor duidelijke verwachtingen. Na elke uitbreiding pas ik het niveau en Algoritme totdat de geheugenbesparing en de latentie binnen de streefbandbreedte liggen.
Combinatie met verdere optimalisaties
Goede indexen zorgen ervoor dat het aantal gelezen pagina’s afneemt, daarom controleer ik Indexdekking en cardinaliteiten regelmatig. Nauwkeurig geformuleerde query's, passende joins en het doelgericht gebruik van EXPLAIN verlagen de I/O en houden het cache-hitpercentage hoog. Een voldoende grote bufferpool voorkomt onnodige laadprocessen vanaf de schijf en maakt de compressie-overhead in de hotset praktisch onzichtbaar. Wat de hardware betreft, leveren SSD’s en NVMe voordelen op door hoge IOPS en lage latentie, wat de voordelen van paginacompressie versterkt. Al met al speelt compressie een rol bij het ontwerpen van query’s, indexering en Uitbreiding van de opslagcapaciteit wordt samengevoegd en vormt zo een gestroomlijnd gegevenspad.
Compatibiliteit, versies en beperkingen
Ik houd in de gaten in welke omgevingen paginacompressie wordt ondersteund en waar de grenzen liggen. Op veelgebruikte Linux-bestandssystemen zoals ext4 en XFS werkt ‘hole-punching’ stabiel. ZFS gedraagt zich anders: aangezien ‘punching’ daar niet op dezelfde manier beschikbaar is, geef ik bij ZFS de voorkeur aan de native Schakel ZFS-compressie in en laat Page Compression achterwege. In containeropstellingen met OverlayFS koppel ik de gegevensmap bij voorkeur als bind-mount vanaf de host, zodat punching en sparse-bestanden betrouwbaar werken. Bovendien combineer ik paginacompressie niet met InnoDB-tabelversleuteling op bestandsniveau: versleuteling maakt de gegevens grotendeels willekeurig voor compressiealgoritmen en blokkeert deels ook het punching. Wie beide nodig heeft, kiest voor volume-/bestandssysteemversleuteling onder InnoDB.
Wat betreft de InnoDB-paginagrootte (innodb_page_size) houd ik meestal vast aan 16K. Kleinere paginagroottes kunnen de compressie bemoeilijken en de beheerskosten verhogen. Tijdelijke tabellen of MEMORY-/werktabellen worden niet beïnvloed door paginacompressie – het voordeel doet zich alleen voor in de betreffende .ibd-tablespace.
Activeren, deactiveren en opnieuw opbouwen zonder verrassingen
Het aanpassen via ALTER TABLE leidt altijd tot een herbouw van de tabel. Daarom ben ik van plan om:
- Onderhoudsvenster met duidelijke SLA’s en voldoende opslagruimte voor de tijdelijke kopie.
- Voorafgaande controle met EXPLAIN voor ALTER, om te zien wat de verwachte werkwijze is (INPLACE/COPY, LOCK-niveau).
- Optionele batchstrategie: eerst grote tabellen die zelden worden gewijzigd, daarna middelgrote tabellen en tot slot de ‘hot tables’ – indien van toepassing.
Om dit uit te schakelen, ga ik symmetrisch te werk en stel ik PAGE_COMPRESSED=0 in. Vervolgens voer ik een OPTIMIZE TABLE of opnieuw een ALTER-Rebuild uit, zodat de tablespace weer zonder gaten wordt geschreven en het fysieke ruimtegebruik realistisch wordt weergegeven.
Bulk-laadbewerkingen, hot-updates en defragmentatie
Voor grote hoeveelheden gegevens laad ik deze ofwel direct gecomprimeerd, als er weinig I/O-capaciteit beschikbaar is, ofwel versnel ik het importeren door ze ongecomprimeerd te laden en daarna met ALTER TABLE over te schakelen naar PAGE_COMPRESSED. Vervolgens zorgt de rebuild voor de optimale lay-out met een maximaal 'loch-punching'-effect. Bij tabellen met zeer veel in-place-updates plan ik regelmatige herschrijvingen (OPTIMIZE TABLE of partitie-rollovers), omdat de compressievoordelen na verloop van tijd door herhaalde wijzigingen kunnen afnemen. Voor BLOB/TEXT-kolommen kies ik voor een modern regelformaat (bijv. DYNAMIC), zodat grote off-page-gegevens efficiënt worden verwerkt en de paginaburen niet onnodig toenemen.
De doeltreffendheid controleren en aantonen
Of paginacompressie werkt, controleer ik met eenvoudige systeemopdrachten en MariaDB-weergaven:
# Schijnbare grootte vergelijken met bezette blokken
ls -ls --block-size=1 *.ibd
du -h --apparent-size *.ibd
du -h *.ibd
# Omvang van de fragmentatie (punching) per bestand controleren
filefrag -v your_table.ibd | tail -n +1
# In MariaDB: tabellestatus en DDL-opties controleren
SHOW TABLE STATUS LIKE 'log_entries'\G
SHOW CREATE TABLE log_entries\G
De schijnbare grootte (ls) blijft gelijk aan het logische gegevensvolume, terwijl je de daadwerkelijk bezette blokken weergeeft. Een merkbaar verschil duidt erop dat het ‘hole-punching’ goed werkt. Ik breng deze meting in verband met I/O-statistieken (lees-/schrijfbewerkingen per seconde, wachtrijdiepte, latentie) en het CPU-gebruik om het totale effect te beoordelen.
Back-upgegevens: Sparse-bestanden correct back-uppen en herstellen
Om ervoor te zorgen dat back-ups rekening houden met de ruimtebesparing, let ik op of de tools sparse-bestanden ondersteunen. Bij het kopiëren van fysieke bestanden gebruik ik de juiste opties, zodat gaten niet worden „opgevuld“:
# Kopiëren met behoud van sparse-gebieden
cp --sparse=always source.ibd dest.ibd
rsync -S --progress source.ibd dest.ibd
tar --sparse -cvf backup.tar /var/lib/mysql/datadir
# Controleren of het doelbestand nog steeds sparse is
du -h dest.ibd
ls -ls dest.ibd
Bij snapshot-back-ups (bijvoorbeeld op blokapparaatniveau) varieert de mate van besparing per aanbieder. Bij logische dumps (mysqldump, mariadb-dump) verandert de exportgrootte nauwelijks, maar de hersteltijden nemen wel af als bij de daaropvolgende rebuild de paginacompressie weer wordt ingeschakeld, waardoor de I/O-volumes tijdens het opnieuw opbouwen worden verminderd.
Replicatie, HA en implementaties in de productieomgeving
Paginacompressie werkt transparant voor replicatie en binlogs, omdat SQL-wijzigingen worden gerepliceerd, niet de gecomprimeerde pagina’s. Ik rol DDL-wijzigingen bij voorkeur eerst uit op de replica’s en houd de latentie en I/O in de gaten voordat ik de primaire server aanpas. Bij multi-source- of cascadetopologieën zorg ik ervoor dat overal een geschikt algoritme (innodb_compression_algorithm) is ingesteld, zodat identieke DDL hetzelfde gedrag oplevert. Voor implementaties zonder downtime combineer ik de omschakeling met switchover-/failover-plannen.
Geavanceerdere afstemming: I/O-profielen en checkpoints
Omdat compressie het aantal en de grootte van de te schrijven blokken beïnvloedt, stem ik de I/O-parameters van InnoDB af op het nieuwe profiel. Een realistische innodb_io_capacity (en *_max) helpt bij het genereren van schone checkpoints zonder plotselinge flush-pieken. Ik controleer of de doublewrite-buffer goed aansluit bij de nieuwe schrijfkarakteristiek en houd de verhouding tussen dirty pages en fsync-snelheid in de gaten. Op apparaten met een hoge mate van parallelliteit (NVMe) schaal ik de schrijfthreads en de wachtrijdiepte van het blokapparaat, zodat de lagere gegevenshoeveelheid daadwerkelijk leidt tot een vermindering van de latentie.
Probleemoplossing en veelvoorkomende valkuilen
- CPU-pieken na activering: Schakel over naar het lz4/lzo-algoritme of verlaag PAGE_COMPRESSION_LEVEL enigszins, vergroot de hotsets in de bufferpool.
- De I/O neemt af, maar de latentie schommelt: Controleer de checkpointing en het percentage ‘dirty pages’; te kleine redo-logs leiden tot frequente flushes.
- Onverwacht geringe ruimtebesparing: De gegevensstructuur controleren (veel binaire/willekeurige velden), een rebuild afdwingen, BLOB/TEXT-patronen analyseren en indien nodig overschakelen naar zlib.
- Geen invloed op de bestandsgrootte: Controleer of het bestandssysteem „hole-punching“ ondersteunt, vermijd containerlagen, en maak geen ‘sparse-kopieën’ on-sparse.
- Veelbesproken tabellen: Gebruik paginacompressie op selectieve basis; bekijk alternatieven (alleen archief- en logtabellen comprimeren).
Praktijkgerichte configuratievoorbeelden
Om een frisse start te maken, houd ik de algemene configuratie beknopt en overzichtelijk:
[mysqld]
innodb_file_per_table=1
innodb_compression_algorithm=zlib # of lz4/lzo, afhankelijk van het profiel
# pas de overige I/O-parameters aan het platform aan
# innodb_io_capacity=...
# innodb_io_capacity_max=...
Per tabel definieer ik de compressie expliciet, om ongewenste neveneffecten te voorkomen. Na grote imports of veel updates pas ik doelgericht OPTIMIZE TABLE toe om gaten opnieuw te kalibreren en de fragmentatie die in de loop van de tijd is ontstaan te verminderen.
Kort samengevat
InnoDB Page Compression vermindert het geheugengebruik aanzienlijk en verlicht de belasting van I/O naar de CPU, zonder de bufferpool te wijzigen. Goed gekozen algoritmen zoals lz4 of zlib leveren bij veel workloads een besparing van 30–60 % op en blijven qua latentie binnen de normale grenzen. Cruciaal zijn een bestandssysteem met ‘hole-punching’, `innodb_file_per_table` en een correcte activering op tabelniveau. Wie tests met echte gegevens uitvoert, monitoring integreert en het niveau en het algoritme nauwkeurig afstemt, bereikt blijvend lage kosten bij betrouwbare Prestaties. Zo bespaart u ruimte, houdt u uw systemen snel en creëert u ruimte voor groeiende datasets.
