Pagina MariaDB La compressione riduce lo spazio fisico occupato in memoria, poiché le pagine InnoDB vengono compresse prima di essere scritte sul supporto di archiviazione, riducendo così in modo tangibile i volumi di I/O. Vi mostrerò come risparmiare spazio in memoria e mantenere bassa la latenza, quali sono i prerequisiti e quali impostazioni risultano più efficaci nella pratica.
Punti centrali
Questi brevi punti chiave offrono una panoramica degli aspetti più importanti.
- Pagina per pagina La compressione riduce l'ingombro e le operazioni di I/O.
- Non compresso Il buffer pool limita il carico della CPU nella RAM.
- Flessibile Attivazione per ogni tabella con PAGE_COMPRESSED.
- sistema di file- Il supporto per Sparse/Hole Punching è obbligatorio.
- Scelta dell'algoritmo controlla la frequenza, la latenza e il carico della CPU.
Come funziona tecnicamente la compressione delle pagine di InnoDB
Comprimo ogni pagina InnoDB poco prima che venga scritta sul disco, in modo che lo spazio tabella occupi solo i byte effettivamente ridotti e il file system contrassegni le aree libere come “sparse”. Nel Pool di buffer Continuo a mantenere le pagine non compresse, il che riduce il carico sulla CPU nella memoria di lavoro e garantisce che gli accessi in lettura frequenti rimangano veloci. Per impostazione predefinita, le pagine InnoDB hanno una dimensione di 16K, ma dopo la compressione i blocchi memorizzati risultano di dimensioni variabili, il che consente di risparmiare molto spazio, soprattutto nei campi di testo o JSON. In fase di lettura, decomprimo la pagina direttamente dopo averla caricata nella RAM, ovvero proprio al confine I/O, dove il risparmio in termini di trasferimento è maggiore. In questo modo sposto il carico da I/O riguardo alla CPU, ma solo nei punti in cui è giustificabile.
Compressione delle pagine vs. compressione classica delle tabelle InnoDB
La compressione classica si basa su ROW_FORMAT=COMPRESSED più KEY_BLOCK_SIZE, il che genera un formato di pagina compresso fisso e comporta un carico decisionale aggiuntivo in fase di scrittura o aggiornamento. Io preferisco la Pagina La compressione, perché rimane flessibile: se la compressione non va a buon fine, InnoDB può memorizzare la pagina senza comprimerla, senza modificare l’intero formato del file. Il buffer pool continua a lavorare con pagine da 16K non compresse, il che rende veloci gli accessi alla cache e mantiene semplici i percorsi della CPU. Nei tipici carichi di lavoro OLTP con molti inserimenti e aggiornamenti moderati, la compressione delle pagine offre un miglior equilibrio tra risparmio di spazio e latenza. Di conseguenza, spesso ottengo un vantaggio tangibile in termini di I/O senza un elevato overhead ad ogni Aggiorna al rischio.
Requisiti e configurazione di base
Per la compressione delle pagine, è necessario che sia installato InnoDB e che sia attivato innodb_file_per_table, in modo che ogni tabella utilizzi il proprio tablespace. Il fattore determinante è il filesystem: deve supportare i file sparsi e l’hole-punching, caratteristiche presenti in ext4 e XFS e solitamente disponibili nei moderni volumi cloud. Per la scelta dell’algoritmo, imposto innodb_compression_algorithm, tipicamente zlib, lz4 o lzo, a seconda della velocità desiderata e del profilo della CPU. Chi valuta attentamente il livello di archiviazione, beneficia di un formato compatto Confronto tra file system tenendo conto anche delle opzioni relative ai driver e ai volumi. In questo modo si ottiene una Configurazione, che consente di risparmiare spazio, riduce gli I/O e garantisce un funzionamento affidabile.
Attivazione a livello di tabella
Attivo la compressione a pagina per ogni singola tabella, dopo aver verificato che le variabili globali siano corrette, in modo da indirizzare in modo mirato proprio quei record che offrono il massimo beneficio possibile. Per le nuove tabelle imposto le opzioni direttamente nel DDL, mentre per quelle esistenti un comando ALTER TABLE esegue la conversione tramite riscrittura. Definisco il livello di compressione con PAGE_COMPRESSION_LEVEL; il comportamento dipende dal Algoritmo . Poiché la migrazione richiede tempo, pianifico delle finestre di manutenzione e verifico lo spazio necessario con e senza compressione sulla base di estratti di dati reali. In questo modo controllo Spese e un risultato senza sorprese.
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;
Risparmio di spazio di archiviazione nella pratica
Più i dati sono omogenei e ricchi di testo, migliore è l'effetto della Compressione; Le tabelle di log e di reporting producono solitamente effetti significativi. In carichi di lavoro tipici, con zlib osservo spesso una riduzione dello spazio di memoria occupato pari a 40–60 %, mentre lz4 gestisce molti casi con 30–50 %, lasciando a disposizione una maggiore larghezza di banda. I dati binari fortemente distribuiti offrono vantaggi minori, ma anche in questo caso i volumi di I/O e i costi si riducono spesso in modo tangibile. Effettuo sempre i test utilizzando snapshot di produzione in ambiente di staging, per ottenere metriche significative e individuare i picchi di latenza. Il risultato: meno dati sul supporto di memorizzazione, tempi di trasferimento più brevi, migliori Scala.
Prestazioni: valutare correttamente l'I/O rispetto alla CPU
Per prima cosa verifico se il collo di bottiglia si trova sul supporto dati o sul CPU , poiché da questo dipende la scelta del metodo di compressione. In ambienti limitati dall’I/O, i volumi di lettura e scrittura diminuiscono notevolmente, con un conseguente aumento delle prestazioni effettive, spesso con un carico aggiuntivo di soli 5–10 % rispetto alle tabelle non compresse quando si utilizzano algoritmi veloci. I sistemi limitati dalla CPU traggono vantaggio da lz4 o lzo, che funzionano molto velocemente e raggiungono velocità solo leggermente inferiori. Inoltre, tengo conto del Buffer di scrittura doppia, poiché influenza il comportamento di scrittura e, insieme alla compressione delle pagine, determina le caratteristiche di I/O. Poiché il buffer pool rimane non compresso, i frequenti accessi alla cache hanno un impatto minimo sulla Latenza da.
Scelta dell'algoritmo e livello di compressione
Decido io il Algoritmo-Valuto in base a modelli di dati, velocità di lettura/scrittura e margine di CPU, invece di basarmi esclusivamente sul rapporto di compressione. Zlib offre spesso il massimo risparmio di spazio con un carico di calcolo moderato, mentre lz4/lzo si distinguono per la bassa latenza. Utilizzo LZMA o bzip2 soprattutto per archivi o tabelle che vengono modificate raramente, poiché il carico sulla CPU è maggiore. Il livello di compressione (PAGE_COMPRESSION_LEVEL) regola il rapporto tra velocità e sforzo, ma con un utilità marginale decrescente oltre i livelli medi. Una breve serie di misurazioni con il set di dati reale individua rapidamente la soluzione migliore Livello.
| Algoritmo | Tasso tipico | Costi della CPU | Idoneità | Note |
|---|---|---|---|---|
| zlib | 40–60 % | Medio | Numerose tabelle OLTP/di reporting | Buono Equilibrio da frequenza/latenza |
| lz4 | 30–50 % | Basso | Elevati requisiti di produttività | Molto veloce Decompressione |
| lzo | 30–50 % | Basso | Carichi di lavoro che richiedono un uso intensivo della scrittura | Bassa latenza negli inserti |
| lzma | 50–70 % | Alto | Archivio/dati inattivi | Per le malattie rare Cambiamenti |
| bzip2 | 50–70 % | Alto | Storie selettive | Lento, buona quota |
Tenere sotto controllo il monitoraggio e le metriche
Misuro la velocità di trasmissione, la latenza, l'utilizzo della CPU e Pool di buffer-Tasso di successo, perché solo una visione d'insieme mostra l'effetto reale. Una diminuzione dei volumi di I/O a parità di latenza o con una latenza migliore indica che la configurazione è corretta. Se il carico della CPU supera un livello accettabile, controllo l'algoritmo e il livello e, se necessario, passo a lz4. Inoltre, tengo d’occhio la dimensione del redo log e il comportamento dei checkpoint, poiché entrambi influenzano il profilo di scrittura. A lungo termine, individuo le tendenze e posso reagire in modo proattivo ai cambiamenti Carichi di lavoro reagire.
Pianificare con cura i backup e la manutenzione
I backup completi e incrementali dei file traggono vantaggio dalla minore quantità di dati, poiché vengono copiati meno byte, mentre i dump logici mantengono solitamente le loro dimensioni. Testo i tempi di ripristino con dati reali, in modo da poter valutare il risparmio di spazio ottenuto rispetto alla durata effettiva del ripristino. Documento le modifiche apportate all’algoritmo o al livello e verifico la compatibilità degli strumenti di backup con la versione di MariaDB utilizzata. Inoltre, valido l’integrità dopo operazioni ALTER TABLE di grandi dimensioni, soprattutto quando molte tabelle sono state convertite alla compressione delle pagine. In questo modo si mantiene la Tempo di riavvio prevedibile e la strategia di copertura affidabile.
Comprendere il sistema di file e il livello di archiviazione
Affinché i file sparse funzionino, il file system richiede Punzonatura, che è disponibile su ext4 e XFS ed è ampiamente utilizzato nelle configurazioni di hosting. Presto attenzione alle opzioni di mount e alla profondità della coda, poiché influenzano notevolmente le caratteristiche di I/O. Per ext4, ad esempio, verifico gli intervalli di commit e le modalità di journaling e valuto l’effetto della garbage collection su SSD/NVMe. Uno sguardo alle opzioni appropriate Opzioni ext4 aiuta ad adeguare gli effetti della compressione delle pagine alle caratteristiche del filesystem. Ecco come utilizzo lo spazio fisico Immagazzinamento è efficace e previene gli effetti collaterali.
Guida pratica per l'introduzione
Inizio con un ambiente di test e copio dati di produzione rappresentativi per ottenere i primi valori di misurazione relativi a quota, latenza e Produttività da ottenere. Successivamente, attivo la compressione delle pagine innanzitutto per le tabelle di grandi dimensioni, utilizzate prevalentemente in lettura, o per gli archivi con pochi aggiornamenti. Valuto i risultati sulla base di indicatori chiari e li confronto con la situazione iniziale, prima di estendere la modifica ad altre tabelle. Una comunicazione tempestiva con i team applicativi evita sorprese durante le finestre di manutenzione e garantisce aspettative chiare. Dopo ogni estensione, adeguo il livello e Algoritmo finché il risparmio di memoria e la latenza rientrano nell'intervallo target.
Combinazione con ulteriori ottimizzazioni
Gli indici ben fatti riducono il numero di pagine da leggere, quindi controllo Copertura dell'indice e le cardinalità con regolarità. Query formulate correttamente, join adeguati e l'uso mirato di EXPLAIN riducono l'I/O e mantengono alta la percentuale di hit della cache. Una dimensione sufficientemente ampia del buffer pool impedisce inutili operazioni di lettura dal disco e rende praticamente impercettibile l'overhead della compressione nell'hotset. Dal punto di vista hardware, gli SSD e gli NVMe si rivelano vantaggiosi grazie agli elevati valori di IOPS e alla bassa latenza, il che potenzia i vantaggi della compressione delle pagine. In sintesi, la compressione interagisce con la progettazione delle query, la gestione degli indici e Ampliamento della memoria insieme, creando così un percorso dati snello.
Compatibilità, versioni e limiti
Tengo d’occhio quali ambienti supportano la compressione delle pagine e quali sono i limiti. Sui sistemi di file Linux più diffusi, come ext4 e XFS, l’hole punching funziona in modo stabile. ZFS si comporta diversamente: poiché in questo caso l’hole punching non è disponibile in modo equivalente, su ZFS preferisco utilizzare piuttosto il nativo Attivo la compressione ZFS e rinuncio alla compressione delle pagine. Nelle configurazioni con container che utilizzano OverlayFS, preferisco montare la directory dei dati dall’host tramite un mount bind, in modo che il punching e i file sparse funzionino in modo affidabile. Inoltre, non combino la compressione delle pagine con la crittografia delle tabelle InnoDB a livello di file: la crittografia rende i dati in gran parte casuali per gli algoritmi di compressione e, in alcuni casi, blocca anche il punching. Chi necessita di entrambe le funzionalità, dovrebbe optare per la crittografia del volume o del filesystem a un livello inferiore rispetto a InnoDB.
Per quanto riguarda la dimensione della pagina InnoDB (innodb_page_size), di solito mantengo il valore a 16K. Dimensioni di pagina inferiori possono rendere più complessa la compressione e aumentare i costi di gestione. Le tabelle temporanee o le tabelle MEMORY/di lavoro non subiscono modifiche a seguito della compressione delle pagine: il vantaggio si ottiene solo nel rispettivo tablespace .ibd.
Attivazione, disattivazione e ricostruzioni senza sorprese
La modifica tramite ALTER TABLE comporta sempre una ricostruzione della tabella. Ho quindi intenzione di procedere come segue:
- Finestra di manutenzione con SLA chiari e spazio di archiviazione sufficiente per la copia temporanea.
- Verifica preliminare con EXPLAIN per ALTER, per vedere la procedura prevista (INPLACE/COPY, livello di LOCK).
- Strategia di elaborazione in batch opzionale: prima le tabelle di grandi dimensioni che vengono modificate raramente, poi quelle di medie dimensioni e, infine, le tabelle più attive – se del caso.
Per disattivare questa opzione, procedo in modo simmetrico e imposto PAGE_COMPRESSED=0. Successivamente, eseguo un OPTIMIZE TABLE o un nuovo ALTER-Rebuild, in modo che il tablespace venga nuovamente scritto senza spazi vuoti e lo spazio fisico occupato sia rappresentato in modo realistico.
Caricamenti in blocco, aggiornamenti a sistema acceso e deframmentazione
Per i dati di grandi dimensioni, li carico direttamente in formato compresso se le risorse I/O sono limitate, oppure accelero l'importazione caricandoli in formato non compresso e poi impostando PAGE_COMPRESSED con ALTER TABLE. Successivamente, la ricostruzione impone il layout ottimale con il massimo effetto di "hole punching". Per le tabelle con un numero molto elevato di aggiornamenti in loco, pianifico riscritture regolari (OPTIMIZE TABLE o rollover delle partizioni), poiché le modifiche ripetute possono ridurre nel tempo i vantaggi della compressione. Per le colonne BLOB/TEXT, opto per un formato di riga moderno (ad es. DYNAMIC), in modo che i dati off-page di grandi dimensioni vengano gestiti in modo efficiente e la vicinanza delle pagine non aumenti inutilmente.
Verificare e dimostrare l’efficacia
Per verificare se la compressione delle pagine è attiva, utilizzo semplici comandi di sistema e le viste di MariaDB:
# Confronta la dimensione apparente con i blocchi occupati
ls -ls --block-size=1 *.ibd
du -h --apparent-size *.ibd
du -h *.ibd
# Verifica dell'entità della frammentazione (punching) per ogni file
filefrag -v your_table.ibd | tail -n +1
# In MariaDB: verificare lo stato delle tabelle e le opzioni DDL
SHOW TABLE STATUS LIKE 'log_entries'\G
SHOW CREATE TABLE log_entries\G
La dimensione apparente (ls) rimane pari al volume logico dei dati, mentre mostra i blocchi effettivamente occupati. Una differenza percepibile indica che la funzione "hole-punching" funziona correttamente. Metto in correlazione questa misurazione con le metriche di I/O (letture/scritture al secondo, profondità della coda, latenza) e il carico della CPU per valutare l'effetto complessivo.
Dettagli del backup: come eseguire correttamente il backup e il ripristino dei file sparse
Affinché i backup rispettino il risparmio di spazio, mi assicuro che gli strumenti supportino la tecnologia „sparse“. Quando copio file fisici, utilizzo i parametri appropriati per evitare che gli spazi vuoti vengano "riempiti":
# Copia con conservazione delle aree sparse
cp --sparse=always source.ibd dest.ibd
rsync -S --progress source.ibd dest.ibd
tar --sparse -cvf backup.tar /var/lib/mysql/datadir
# Verifica che la destinazione sia ancora sparse
du -h dest.ibd
ls -ls dest.ibd
Nel caso dei backup snapshot (ad esempio a livello di dispositivo a blocchi), il risparmio varia in misura diversa a seconda del fornitore. Per i dump logici (mysqldump, mariadb-dump), la dimensione dell’esportazione rimane pressoché invariata, ma i tempi di ripristino si riducono se la successiva ricostruzione riattiva la compressione delle pagine, riducendo così i volumi di I/O durante la ricostruzione.
Replica, alta disponibilità e implementazioni in produzione
La compressione delle pagine è trasparente per la replica e i binlog, poiché vengono replicate le modifiche SQL, non le pagine compresse. Preferisco applicare le modifiche DDL prima sulle repliche e monitorare la latenza e l’I/O prima di modificare le impostazioni del server primario. Nelle topologie multi-sorgente o a cascata, mi assicuro che ovunque sia impostato un algoritmo appropriato (innodb_compression_algorithm), in modo che lo stesso DDL produca lo stesso comportamento. Per implementazioni a tempo zero, combino la migrazione con piani di switchover/failover.
Ottimizzazione avanzata: profili I/O e checkpoint
Poiché la compressione modifica il numero e la dimensione dei blocchi da scrivere, adeguo i parametri I/O di InnoDB al nuovo profilo. Un valore realistico di innodb_io_capacity (e *_max) aiuta a generare checkpoint puliti, senza picchi improvvisi di flush. Verifico che il buffer di doppia scrittura sia in sintonia con le nuove caratteristiche di scrittura e monitoro il rapporto tra pagine sporche e frequenza di fsync. Su dispositivi ad alto parallelismo (NVMe), scalo i thread di scrittura e la profondità della coda del dispositivo a blocchi, in modo che la minore quantità di dati si traduca in una reale riduzione della latenza.
Risoluzione dei problemi e difficoltà tipiche
- Picchi della CPU dopo l'attivazione: Passare all'algoritmo lz4/lzo oppure ridurre moderatamente il valore di PAGE_COMPRESSION_LEVEL, aumentare le dimensioni degli hot set nel buffer pool.
- L'I/O diminuisce, ma la latenza oscilla: Verificare il checkpointing e la quota di pagine sporche; i log di redo troppo piccoli causano flush frequenti.
- Risparmio di spazio inaspettatamente esiguo: Verificare la struttura dei dati (numero elevato di campi binari/casuali), forzare la ricostruzione, analizzare i modelli BLOB/TEXT e, se necessario, passare a zlib.
- Nessun effetto sulle dimensioni del file: Verificare il supporto della funzione „hole-punching“ da parte del filesystem, evitare i livelli container, non "desparsificare" le copie sparse.
- Tabelle molto discusse: Utilizzare la compressione delle pagine in modo selettivo; valutare alternative (comprimere solo le tabelle di archivio/log).
Esempi pratici di configurazione
Per partire con il piede giusto, ritengo che la configurazione globale debba essere essenziale e gestibile:
[mysqld]
innodb_file_per_table=1
innodb_compression_algorithm=zlib # oppure lz4/lzo a seconda del profilo
# Adattare gli altri parametri I/O in base alla piattaforma
# innodb_io_capacity=...
# innodb_io_capacity_max=...
Per ogni tabella definisco esplicitamente la compressione, in modo da evitare effetti collaterali indesiderati. Dopo importazioni di grandi dimensioni o numerosi aggiornamenti, utilizzo in modo mirato il comando OPTIMIZE TABLE per ricalibrare gli spazi vuoti e ridurre la frammentazione accumulata nel tempo.
Riassumendo brevemente
La compressione delle pagine InnoDB riduce sensibilmente il consumo di memoria e alleggerisce il carico su I/O alla CPU, senza modificare il buffer pool. Algoritmi ben scelti come lz4 o zlib garantiscono in molti carichi di lavoro un risparmio di 30–60 %, mantenendo la latenza entro limiti accettabili. Sono fondamentali un file system con hole-punching, innodb_file_per_table e un’attivazione corretta a livello di tabella. Chi esegue test con dati reali, integra il monitoraggio e ottimizza il livello e l’algoritmo, ottiene costi costantemente bassi con prestazioni affidabili Prestazioni. In questo modo risparmierete spazio, manterrete i vostri sistemi veloci e disporrete di risorse aggiuntive per i set di dati in crescita.
