MySQL row_format compresso vs dinamico

Question

Ho modificato "innodb_file_format" da "Antelope" a "Barracuda" bcoz per i seguenti motivi.

1. Per evitare limite di dimensione fila
2. Per evitare limite di dimensione indice di colonna

Mentre si fa il cambio formato di file scelto i "row_format" come "dinamico". Funziona bene.

Ma, vorrei cambiare "row_format" da "dinamico" a "compresso" per la compressione dei dati. Qualcuno potrebbe dirmi

1. È che row_format ha relazione con COLUMN INDEXES e DATA INSERTS nelle tabelle? Se sì, quale è raccomandato e perché?
2. Il formato compresso comporta un peggioramento delle prestazioni?

Answer 1

L'utilizzo di DYNAMIC o COMPRESSED significa che InnoDB memorizza completamente fuori pagina i campi varchar/text/blob che non rientrano nella pagina. Ma a parte quelle colonne, che contano solo 20 byte per colonna, il limite della dimensione della riga InnoDB non è cambiato; è ancora limitato a circa 8000 byte per riga.

InnoDB supporta solo indici di 767 byte per colonna. È possibile aumentare questi 3072 byte impostando innodb_large_prefix=1 e utilizzando il formato di riga DYNAMIC o COMPRESSED.

L'utilizzo del formato di riga COMPRESSA non consente a InnoDB di supportare indici più lunghi.

Per quanto riguarda le prestazioni, questo è uno di quei casi in cui "dipende". La compressione è generalmente un compromesso tra le dimensioni dello spazio di archiviazione e il carico della CPU da comprimere e decomprimere. È vero che questo richiede un po 'più di CPU per lavorare con dati compressi, ma bisogna tenere a mente che i server di database in genere sono in attesa di I/O e hanno risorse CPU da risparmiare.

Ma non sempre: se si eseguono query complesse su dati presenti nel pool di buffer, è possibile che la CPU sia vincolata più di I/O. Quindi dipende da molti fattori, come il modo in cui i dati si adattano alla RAM, il tipo di query eseguite e quante query al secondo, nonché le specifiche hardware. Troppi fattori per cui chiunque può rispondere per la tua applicazione sul tuo server. Dovrai solo provarlo.

---

Re tuo commento:

Una possibilità è che l'indice non è giusto nel pool di buffer. Le prestazioni si riducono in modo significativo se una ricerca di indice deve caricare pagine e rimuovere pagine durante ogni query SELECT. Un'analisi EXPLAIN non può dire se l'indice si adatta al pool di buffer.

Non so quante colonne o quali tipi di dati delle colonne nel tuo indice, ma se stai indicizzando lunghe colonne varchar dovresti considerare l'uso di indici di prefissi (o diminuire la lunghezza delle colonne).

È inoltre possibile ottenere più RAM e aumentare la dimensione del pool di buffer.

Answer 2

COMPRESSED comprime i dati. Il testo verrà compresso davvero bene. Ho diverse tabelle e ho usato DYNAMIC prima, spostato in COMPRESSED.

Io uso MySQL 5,7

Tabella:

• id (int)
• some_other_id (int)
• testo (longtext) - utf8mb4_unicode_ci ~ 500KB/fila media
• updated_at (int)
• created_at (int)

Utilizza l'80% di spazio in meno con COMPRESSA rispetto a DINAMICO. Prima: 80 GB, dopo: 16 Gb Risparmio enorme, mentre non ho bisogno di quei dati così tanto.

Altri tavoli non erano così drammatici, ma è il salvato ~ 50% dove ci sono alcuni campi di testo. Per esempio. un altro da 6,4 Gb -> 3,1 Gb con 1,5 milioni di righe.

Non sono stato modificato in tabelle più piccole COMPRESSE che salva principalmente numeri interi/bit e simili. Queste tabelle sono già di piccole dimensioni, quindi non è necessario utilizzare più CPU per loro.