Mengenai "Dynamic" , format Barracuda-only yang tidak dikompresi, sangat sedikit yang berubah dari compact, terutama tentang bagaimana blob (dan bidang yang sangat dinamis) disimpan . Saya tidak pernah memiliki masalah dengan compact vs dynamic, jadi saya dapat dengan aman merekomendasikan dinamis Barracuda. Ingat bahwa Barracuda juga mendukung format baris yang redundan dan ringkas .
Artikel yang Anda sebutkan mungkin terlalu tua (5.1) dan, seperti yang dikatakan Peter Z., CEO Percona, menyebutkan komentar-komentar itu mungkin agak menyesatkan. Itu tidak berarti bahwa kompresi tidak bisa menjadi keuntungan besar tergantung pada beban kerjanya. Namun, saya akan merekomendasikan Anda untuk mencobanya pada versi> = 5.6, karena Facebook dan Oracle telah melakukan banyak perbaikan tentang hal itu.
Sebagai bahan referensi yang lebih baru, saya akan merekomendasikan Anda:
Secara khusus, saya suka materi Facebook karena mereka adalah pihak ketiga (tidak perlu agenda) dan mereka memiliki salah satu penyebaran MySQL terbesar di dunia. Seperti yang Anda lihat, mereka memiliki setup yang sangat sukses menggabungkan teknologi SSD dengan kompresi.
Apakah ini akan menguntungkan Anda? Itu akan tergantung pada beban kerja, set dan pengaturan kerja Anda (IOPS, memori) . Bergantung jika Anda terikat IO, CPU terikat atau memori terikat, kompresi dapat mempengaruhi negatif dalam beberapa kasus, dengan menambahkan CPU tambahan, persyaratan memori (halaman terkompresi dan tidak terkompresi disimpan di pool buffer InnoDB) atau menghasilkan terlalu banyak kegagalan kompresi, menambah latensi. Ini juga tergantung pada jenis data: kompresi dapat banyak membantu dengan gumpalan teks besar, tetapi mungkin tidak berguna dengan data yang sudah dikompresi.
Dalam pengalaman saya, dalam prakteknya, ada orang-orang yang kompresi adalah cawan suci kinerja dan sangat senang dengan itu, tetapi pada kasus lain, kami harus kembali ke data yang tidak terkompresi karena tidak ada perolehan yang diperoleh. Sementara beban kerja penulisan yang sangat berat mungkin tampak seperti lingkungan yang buruk untuk kompresi, jika dalam kasus khusus Anda, Anda tidak terikat cpu dan terikat memori, tetapi terikat dengan iops mungkin tidak kurang membantu.
Secara umum, sangat sulit untuk memprediksi hasil, biasanya Anda harus menyiapkan lingkungan pengujian untuk pembandingan dan kemudian menemukan mengapa Anda mendapatkan hasil yang lebih baik atau lebih buruk (dan dengan cara itu Anda bisa bermain dengan ukuran blok yang berbeda, dll.). Barracuda sepenuhnya aman. Kompresi mungkin atau tidak untuk Anda. Dan Anda selalu dapat bereksperimen dengan metode kompresi lain seperti kompresi gumpalan sisi klien (misalnya, jika Anda berakhir dengan terikat CPU) atau mesin pihak ke - 3 lainnya seperti RocksDB dan TokuDB , di mana kompresi merupakan prioritas besar, karena difokuskan dalam kinerja untuk dataset yang lebih besar daripada yang bisa ditangani InnoDB.
Singkatnya: Alasan utama untuk menggunakan Barracuda adalah penanganan BLOB, innodb_large_prefixkompatibilitas (indeks besar) dan kompresi. Dinamis, pada MySQL 8.0 sekarang merupakan format file default.