Per quanto riguarda "Dynamic" , il formato non compresso di Barracuda, molto poco è cambiato da compatto, principalmente su come vengono memorizzati i BLOB (e tutti i campi molto dinamici) . Non ho mai avuto problemi con compact vs dynamic, quindi posso tranquillamente raccomandare la dinamica di Barracuda. Ricorda che Barracuda supporta anche i vecchi formati di riga ridondanti e compatti .
L'articolo che stai citando è probabilmente troppo vecchio (5.1) e, come Peter Z., CEO di Percona, menziona i commenti, potrebbe essere un po 'fuorviante. Ciò non significa che la compressione non possa essere un guadagno enorme a seconda dei carichi di lavoro. Tuttavia, ti consiglio di provarlo su versioni> = 5.6, poiché sia Facebook che Oracle hanno apportato molti miglioramenti al riguardo.
Come materiale di riferimento più recente, ti consiglierei:
In particolare, mi piacciono i materiali di Facebook in quanto sono di terze parti (non è necessario un programma) e hanno una delle più grandi distribuzioni MySQL al mondo. Come puoi vedere, hanno avuto configurazioni di grande successo combinando la tecnologia SSD con la compressione.
Ti gioverà? Ciò dipenderà dal carico di lavoro, dal set di lavoro e dall'impostazione (IOPS, memoria) . A seconda se si è associati a IO, CPU o memoria, la compressione può influire negativamente in alcuni casi, aggiungendo CPU aggiuntiva, requisiti di memoria (le pagine compresse e non compresse vengono archiviate nel pool buffer InnoDB) o generando troppi errori di compressione, aumentando la latenza. Dipende anche dal tipo di dati: la compressione può aiutare molto con grandi BLOB di testo, ma può essere inutile con dati già compressi.
Nella mia esperienza, in pratica, ci sono persone per le quali la compressione era il santo graal delle prestazioni e ne sono molto contenta, ma in altri casi abbiamo dovuto ripristinare i dati non compressi poiché non è stato ottenuto alcun guadagno. Mentre un carico di lavoro di scrittura molto pesante può sembrare un brutto ambiente per la compressione, se nel tuo caso particolare non sei vincolato alla CPU e alla memoria, ma associato a iops, potrebbe non essere utile.
In generale, è molto difficile prevedere i risultati, di solito è necessario impostare un ambiente di test per il benchmarking e quindi scoprire perché si ottengono risultati migliori o peggiori (e in questo modo è possibile giocare con blocchi di dimensioni diverse, ecc.). Barracuda è completamente sicuro. La compressione può o no essere per te. E puoi sempre sperimentare altri metodi di compressione come la compressione dei BLOB sul lato client (ad esempio, se finisci con il collegamento con la CPU) o altri motori di terze parti come RocksDB e TokuDB , in cui la compressione è una grande priorità, poiché è focalizzata in termini di prestazioni per set di dati più grandi di quelli che InnoDB è in grado di gestire.
In breve: i motivi principali per utilizzare Barracuda sono la gestione BLOB, la innodb_large_prefixcompatibilità (indici di grandi dimensioni) e la compressione. Dinamico, su MySQL 8.0 è ora il formato file predefinito.