MariaDB-sidekomprimering: Spar plads med minimale tab af ydeevne

MariaDB-side Komprimering reducerer det fysiske lagerbehov ved at komprimere InnoDB-sider, før de skrives til lagringsmediet, hvilket mærkbart mindsker I/O-mængden. Jeg viser, hvordan du sparer lagerplads og holder latenstiden lav, hvilke forudsætninger der gælder, og hvilke indstillinger der har størst effekt i praksis.

Centrale punkter

Disse korte stikord giver en indføring i de vigtigste aspekter.

• Side for side Komprimering reducerer pladsbehovet og I/O.
• Ukomprimeret Buffer-poolen begrænser CPU-belastningen i RAM.
• Fleksibel Aktivering pr. tabel med PAGE_COMPRESSED.
• filsystem-Understøttelse af sparse/hole punching er obligatorisk.
• Valg af algoritme styrer hastighed, latenstid og CPU-forbrug.

Sådan fungerer InnoDB-sidekomprimering rent teknisk

Jeg komprimerer hver InnoDB-side, lige før den skrives til harddisken, så tablespace’et kun optager de faktisk reducerede bytes, og filsystemet markerer de ledige områder som »sparse«. I Bufferpool Jeg lader siderne forblive ukomprimerede, hvilket holder CPU-belastningen i arbejdsminnet lav og sikrer, at hyppige læseadgange forbliver hurtige. Som standard er InnoDB-sider 16K, men de gemte blokke bliver efter komprimeringen variabelt mindre, hvilket især sparer meget plads ved tekst- eller JSON-felter. Ved læsning udpakker jeg siden direkte efter indlæsning i RAM, altså præcis ved I/O-grænsen, hvor besparelsen ved overførslen tæller mest. På den måde flytter jeg belastningen fra I/O til CPU’en, men kun de steder, hvor det er rimeligt.

Sidekomprimering kontra klassisk InnoDB-tabelkomprimering

Den klassiske komprimering bygger på ROW_FORMAT=COMPRESSED plus KEY_BLOCK_SIZE, hvilket skaber et fast, komprimeret sideformat og medfører en ekstra beslutningsbyrde ved skrivning eller opdatering. Jeg foretrækker den Side Komprimering, fordi den forbliver fleksibel: Hvis en komprimering ikke lykkes, kan InnoDB gemme siden ukomprimeret uden at ændre hele filformatet. Bufferpoolen arbejder fortsat med ukomprimerede 16K-sider, hvilket gør cache-hits hurtige og holder CPU-stierne enkle. Ved typiske OLTP-arbejdsbelastninger med mange indsættelser og moderate opdateringer giver sidekomprimering en bedre balance mellem pladsbesparelse og latenstid. Resultatet er, at jeg ofte opnår en mærkbar I/O-fordel uden en stor overhead ved hver Opdatering til risiko.

Forudsætninger og grundkonfiguration

For Page Compression forudsætter jeg, at InnoDB er installeret, og aktiverer innodb_file_per_table, så hver tabel bruger sit eget tablespace. Det afgørende er filsystemet: Det skal understøtte sparsede filer og hole-punching, hvilket er tilfældet med ext4 og XFS og som regel findes i moderne cloud-volumener. Til valg af algoritme bruger jeg innodb_compression_algorithm, typisk zlib, lz4 eller lzo, afhængigt af den ønskede hastighed og CPU-profil. Den, der afvejer lagringslaget, drager fordel af en kompakt Sammenligning af filsystemer og tager samtidig højde for driver- og volumenindstillinger. På den måde opstår der en Konfiguration, der sparer plads, reducerer I/O og fungerer pålideligt.

Aktivering på tabelniveau

Jeg aktiverer sidekomprimering for hver enkelt tabel, efter at de globale variabler er indstillet korrekt, så jeg målrettet kan adressere netop de dataposter, der giver den størst mulige fordel. For nye tabeller angiver jeg indstillingerne direkte i DDL’en, mens en ALTER TABLE-sætning for eksisterende tabeller foretager omstillingen ved at omskrive dem. Komprimeringsniveauet definerer jeg med PAGE_COMPRESSION_LEVEL, og funktionen afhænger af den anvendte Algoritme . Da overgangen tager tid, planlægger jeg vedligeholdelsesvinduer og tjekker pladsbehovet med og uden komprimering ud fra reelle dataudsnit. På den måde kontrollerer jeg Udgifter og et resultat uden overraskelser.

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;

Pladsbesparelse i praksis

Jo mere ensartede og teksttunge dataene er, desto bedre virker Kompression; Log- og rapporteringstabeller giver som regel tydelige fordele. I typiske arbejdsbelastninger ser jeg ofte 40–60 % mindre brugt lagerplads med zlib, mens lz4 i mange tilfælde klarer sig med 30–50 % og dermed giver mere gennemstrømning til overs. Stærkt distribuerede binære data giver mindre gevinst, men også her reduceres I/O-mængder og omkostninger ofte mærkbart. Jeg tester altid med produktionssnapshots på staging for at opnå meningsfulde tal og identificere latenstops. Resultatet: færre data på lagringsmediet, kortere overførselstider, bedre Skalering.

Ydeevne: Korrekt vurdering af I/O kontra CPU

Jeg tjekker først, om flaskehalsen ligger på datamediet eller på CPU , da valget af komprimeringsmetode afhænger heraf. I I/O-begrænsede miljøer falder læse- og skrivemængderne markant, hvilket øger den effektive ydeevne – ofte med kun 5–10 % ekstra belastning i forhold til ukomprimerede tabeller ved brug af hurtige algoritmer. CPU-begrænsede systemer drager fordel af lz4 eller lzo, som fungerer meget hurtigt og kun opnår lidt lavere hastigheder. Derudover tager jeg højde for Doublewrite-buffer, fordi den påvirker skriveadfærden og sammen med sidekomprimering er med til at forme I/O-karakteristikken. Da bufferpuljen forbliver ukomprimeret, har hyppige cache-hits stort set ingen indflydelse på Forsinkelse fra.

Valg af algoritme og komprimeringsniveau

Jeg beslutter, at Algoritme-Jeg træffer beslutningen ud fra datamønstre, læse-/skrivehastighed og CPU-kapacitet i stedet for kun at basere mig på komprimeringsgraden. Zlib giver ofte den største pladsbesparelse ved moderat regnearbejde, mens lz4/lzo udmærker sig med lav latenstid. Jeg bruger primært LZMA eller bzip2 til arkiver eller tabeller, der sjældent ændres, da CPU-omkostningerne er højere. Komprimeringsniveauet (PAGE_COMPRESSION_LEVEL) regulerer forholdet mellem hastighed og ressourceforbrug, dog med aftagende grænsegevinst ud over de mellemste niveauer. En kort måleserie med det egentlige datasæt finder hurtigt det bedste Niveau.

Algoritme	Typisk sats	CPU-omkostninger	Egnethed	Noter
zlib	40–60 %	Medium	Mange OLTP-/rapporteringstabeller	God Balance ud fra hastighed/latens
lz4	30–50 %	Lav	Høje krav til gennemstrømning	Meget hurtig Dekompression
lzo	30–50 %	Lav	Skriveintensive arbejdsopgaver	Lav latenstid ved indsættelser
lzma	50–70 %	Høj	Arkiv/gamle data	For sjældne Ændringer
bzip2	50–70 %	Høj	Udvalgte historier	Langsomt, gode seertal

Hold øje med overvågning og nøgletal

Jeg måler gennemstrømning, latenstid, CPU-udnyttelse og Bufferpool-Hitrate, fordi kun det samlede billede viser den faktiske effekt. Et fald i I/O-mængderne ved uændret eller bedre latenstid indikerer, at konfigurationen har virket. Stiger CPU-udnyttelsen over et sundt niveau, tjekker jeg algoritmen og niveauet og skifter om nødvendigt til lz4. Derudover holder jeg øje med størrelsen på redo-loggen og checkpoint-adfærden, da begge dele er med til at præge skriveprofilen. På lang sigt kan jeg genkende tendenser og proaktivt reagere på ændrede Arbejdsbyrder reagere.

Planlæg sikkerhedskopiering og vedligeholdelse grundigt

Fuld og inkrementel filbackup drager fordel af den lavere datamængde, fordi der kopieres færre bytes, mens logiske dumps som regel bevarer deres størrelse. Jeg tester gendannelsestider med reelle data, så jeg kan afveje den opnåede pladsbesparelse mod den praktiske gendannelsestid. Jeg dokumenterer ændringer i algoritmen eller niveauet og kontrollerer backup-værktøjernes kompatibilitet med den anvendte MariaDB-version. Desuden validerer jeg integriteten efter store ALTER TABLE-operationer, især når mange tabeller er blevet omstillet til sidekomprimering. På den måde forbliver Tidspunkt for genstart forudsigelig og sikkerhedsstrategien pålidelig.

Forståelse af filsystemet og lagringsniveauet

For at sparse-filer skal fungere, skal filsystemet Udstansning af huller, som er tilgængeligt i ext4 og XFS og er meget udbredt i hosting-opsætninger. Jeg lægger vægt på mount-indstillinger og kødybde, da de har stor indflydelse på I/O-karakteristika. For ext4 tjekker jeg f.eks. commit-intervaller og journal-tilstande og tager højde for, hvordan garbage collection påvirker SSD/NVMe. Et kig på passende ext4-indstillinger hjælper med at tilpasse effekterne af sidekomprimering til filsystemets egenskaber. Sådan udnytter jeg den fysiske Opbevaring effektivt og forhindrer bivirkninger.

Praktisk guide til introduktion

Jeg starter med et testmiljø og kopierer repræsentative produktionsdata for at få de første måleværdier for kvote, latenstid og Gennemstrømning at opnå. Derefter aktiverer jeg først sidekomprimering for store tabeller eller arkiver, der hovedsageligt bruges til læsning og kun har få opdateringer. Jeg vurderer resultaterne ud fra klare nøgletal og sammenligner dem med udgangssituationen, inden jeg omlægger yderligere tabeller. Tidlig kommunikation med applikationsteams forhindrer overraskelser i vedligeholdelsesvinduer og sikrer klare forventninger. Efter hver udvidelse justerer jeg niveauet og Algoritme indtil lagerpladsbesparelsen og latenstiden ligger inden for målkorridoren.

Kombination med yderligere optimeringer

Gode indekser mindsker antallet af læste sider, derfor tjekker jeg Indeksdækning og kardinaliteter regelmæssigt. Velformulerede forespørgsler, passende sammenkoblinger og målrettet brug af EXPLAIN reducerer I/O og holder cache-hitraten høj. En tilstrækkelig stor bufferpool forhindrer unødvendige indlæsninger fra disken og gør komprimeringsoverheadet i hotsættet praktisk talt usynligt. På hardwaresiden betaler SSD’er og NVMe sig i form af høje IOPS og lav latenstid, hvilket forstærker fordelene ved sidekomprimering. Samlet set spiller komprimering sammen med forespørgselsdesign, indeksarbejde og Udvidelse af lagerkapaciteten sammen og danner dermed en strømlinet datavej.

Kompatibilitet, versioner og begrænsninger

Jeg holder øje med, hvilke miljøer der understøtter sidekomprimering, og hvor grænserne går. På udbredte Linux-filsystemer som ext4 og XFS fungerer »hole-punching« stabilt. ZFS opfører sig anderledes: Da »punching« ikke er tilgængeligt på samme måde der, foretrækker jeg på ZFS snarere indfødt Jeg aktiverer ZFS-komprimering og undgår sidekomprimering. I containeropsætninger med OverlayFS monterer jeg helst datakataloget som en bind-mount fra værten, så punching og spars-filer fungerer pålideligt. Desuden kombinerer jeg ikke sidekomprimering med InnoDB-tabellkryptering på filniveau: Kryptering gør dataene stort set tilfældige for komprimeringsalgoritmerne og blokerer til dels også punching. Hvis man har brug for begge dele, bør man anvende volumen-/filsystemkryptering under InnoDB.

Hvad angår InnoDB-sidestørrelsen (innodb_page_size), holder jeg som regel fast ved 16K. Mindre sidestørrelser kan gøre komprimeringen vanskeligere og øge administrationsomkostningerne. Midlertidige tabeller eller MEMORY-/arbejdstabeller påvirkes ikke af sidekomprimering – gevinsten opnås kun i det pågældende .ibd-tablespace.

Aktivering, deaktivering og genopbygning uden uventede overraskelser

En ændring via ALTER TABLE medfører altid en genopbygning af tabellen. Derfor planlægger jeg følgende:

• Vedligeholdelsesvindue med klare SLA’er og tilstrækkelig lagerplads til den midlertidige kopi.
• Forudgående kontrol med EXPLAIN for ALTER for at se den forventede fremgangsmåde (INPLACE/COPY, LOCK-niveau).
• Valgfri batch-strategi: først store tabeller, der sjældent ændres, derefter mellemstore, og til sidst de hyppigt anvendte tabeller – hvis overhovedet.

For at deaktivere funktionen går jeg symmetrisk til værks og sætter PAGE_COMPRESSED=0. Derefter udfører jeg en OPTIMIZE TABLE eller en ny ALTER-Rebuild, så tablespace’et igen skrives uden huller, og det fysiske pladsforbrug afspejles realistisk.

Bulk-indlæsninger, hot-opdateringer og defragmentering

Når det drejer sig om store datamængder, indlæser jeg enten direkte i komprimeret form, hvis I/O-kapaciteten er begrænset, eller også fremskynder jeg importen ved at indlæse i ukomprimeret form og derefter skifte til PAGE_COMPRESSED med ALTER TABLE. Derefter sikrer genopbygningen det optimale layout med maksimal »hole-punching«-effekt. For tabeller med meget mange in-place-opdateringer planlægger jeg regelmæssige omskrivninger (OPTIMIZE TABLE eller partitionsrollovers), da komprimeringsfordelene med tiden kan mindskes på grund af gentagne ændringer. For BLOB/TEXT-kolonner anvender jeg et moderne linjeformat (f.eks. DYNAMIC), så store off-page-data håndteres effektivt, og side-naboskabet ikke vokser unødigt.

Undersøge og dokumentere effektiviteten

Jeg kontrollerer, om sidekomprimering fungerer, ved hjælp af enkle systemkommandoer og MariaDB-visninger:

# Sammenlign tilsyneladende størrelse med optagede blokke
ls -ls --block-size=1 *.ibd
du -h --apparent-size *.ibd
du -h *.ibd

# Kontroller omfanget af fragmentering (punching) pr. fil
filefrag -v your_table.ibd | tail -n +1

# I MariaDB: Kontroller tabelstatus og DDL-indstillinger
SHOW TABLE STATUS LIKE 'log_entries'\G
SHOW CREATE TABLE log_entries\G

Den tilsyneladende størrelse (ls) forbliver den samme som den logiske datamængde, mens du viser de faktisk optagede blokke. En mærkbar forskel er tegn på, at »hole-punching« fungerer. Jeg sammenholder denne måling med I/O-metrikker (læsninger/skrivninger pr. sekund, kødybde, latenstid) og CPU-udnyttelsen for at vurdere den samlede effekt.

Detaljer om sikkerhedskopiering: Korrekt sikkerhedskopiering og gendannelse af sparsedata

For at sikkerhedskopierne skal tage højde for pladsbesparelsen, sørger jeg for, at værktøjerne understøtter sparse-filer. Når jeg kopierer fysiske filer, bruger jeg de relevante indstillinger, så hullerne ikke bliver „udfyldt“:

# Kopiering med bevarelse af sparsomme områder
cp --sparse=always source.ibd dest.ibd
rsync -S --progress source.ibd dest.ibd
tar --sparse -cvf backup.tar /var/lib/mysql/datadir

# Kontrol af, om målet stadig er spars
du -h dest.ibd
ls -ls dest.ibd

Ved snapshot-backups (f.eks. på blok-enhedsniveau) varierer besparelsen alt efter udbyder. For logiske dumps (mysqldump, mariadb-dump) ændrer eksportstørrelsen sig næsten ikke, men gendannelsestiderne falder, hvis den efterfølgende genopbygning igen aktiverer sidekomprimering og dermed reducerer I/O-mængderne under genopbygningen.

Replikering, HA og udrulninger i drift

Sidekomprimering fungerer transparent i forhold til replikering og binlogs, da det er SQL-ændringerne, der replikeres, ikke de komprimerede sider. Jeg foretrækker at udrulle DDL-ændringer først på replikerne og overvåge latenstid og I/O, før jeg ændrer indstillingerne på primærserveren. I multi-source- eller kaskadetopologier sørger jeg for, at der overalt er indstillet en passende algoritme (innodb_compression_algorithm), så identiske DDL-kommandoer giver samme adfærd. Ved udrulninger uden nedetid kombinerer jeg ændringen med switchover-/failover-planer.

Avanceret tuning: I/O-profiler og checkpoints

Da komprimering ændrer antallet og størrelsen af de blokke, der skal skrives, tilpasser jeg InnoDB’s I/O-parametre til den nye profil. En realistisk innodb_io_capacity (og *_max) hjælper med at generere rene checkpoints uden pludselige flush-spidser. Jeg kontrollerer, om doublewrite-bufferen harmonerer med de nye skrivekarakteristika, og overvåger forholdet mellem dirty pages og fsync-frekvensen. På enheder med høj parallelitet (NVMe) skalerer jeg skrivetrådene og kødybden for blokenheden, så den lavere datamængde resulterer i en reel reduktion af latenstiden.

Fejlfinding og typiske udfordringer

• CPU-spidsbelastninger efter aktivering: Skift algoritme til lz4/lzo eller sænk PAGE_COMPRESSION_LEVEL moderat, og udvid hotsets i bufferpoolen.
• I/O falder, men latenstiden svinger: Kontroller checkpointing og andelen af beskidte sider; for små redo-logfiler medfører hyppige flushes.
• Uventet lille pladsbesparelse: Kontroller datastrukturen (mange binære/tilfældige felter), tving en genopbygning, analyser BLOB/TEXT-mønstre, skift eventuelt til zlib.
• Ingen indvirkning på filstørrelsen: Kontroller, om filsystemet understøtter „hole-punching“, undgå containerlag, og undlad at »dekomprimere« spars-kopier.
• Tabeller, der er meget omtalte: Anvend sidekomprimering selektivt; undersøg alternativer (komprimer kun arkiv-/logtabeller).

Praktiske konfigurationseksempler

For at komme godt i gang foretrækker jeg, at den globale konfiguration er kortfattet og overskuelig:

[mysqld]
innodb_file_per_table=1
innodb_compression_algorithm=zlib   # eller lz4/lzo afhængigt af profilen
# Tilpas yderligere I/O-parametre efter platformen
# innodb_io_capacity=...
# innodb_io_capacity_max=...

For hver tabel definerer jeg komprimeringen eksplicit for at undgå uønskede bivirkninger. Efter store importoperationer eller mange opdateringer bruger jeg målrettet OPTIMIZE TABLE for at omkalibrere hullerne og reducere den fragmentering, der er opstået over tid.

Kort opsummeret

InnoDB-sidekomprimering reducerer hukommelsesforbruget mærkbart og aflaster I/O til CPU’en uden at ændre bufferpoolen. Velvalgte algoritmer som lz4 eller zlib giver i mange arbejdsbelastninger en besparelse på 30–60 % og holder latenstiden inden for det acceptable interval. Afgørende er et filsystem med hole-punching, innodb_file_per_table og en korrekt aktivering på tabelniveau. Den, der udfører tests med reelle data, integrerer overvågning og finjusterer niveauet samt algoritmen, opnår vedvarende lave omkostninger med pålidelig Ydelse. På den måde sparer du plads, holder dine systemer hurtige og skaber plads til voksende datasæt.