InnoDB Plugin のデータベース圧縮機能

ファイルサイズが 1/10 になってアクセス速度も大幅改善か。実データでこれはすごいな *1。

I’ve tried to convert this table using COMPRESSED row format. This time conversion took 1,5 hours and results were really surprising:

• Only 5Gb data file (from 60Gb)
• ~5% I/O load according to iostat (from 99%)
• ~5% CPU load according to top (from 80-100% mostly waiting for I/O)
• 0.01 sec average lookup time by primary key (from 1-20 sec before the conversion)

Real-Life Use Case for "Barracuda" InnoDB File Format - Percona Database Performance Blog

というわけで、気になっていた点である、メモリ内における圧縮非圧縮状態の表現について確認。

To minimize i/o and to reduce the need to uncompress a page, at times the buffer pool will contain both the compressed and uncompressed form of a database page. However, to make room for other required database pages, InnoDB may “evict” from the buffer pool an uncompressed page, while leaving the compressed page in memory. Or, if a page has not been accessed in a while, the compressed form of the page may be written to disk, to free space for other data. Thus, at any given time, the buffer pool may not contain any copy of a given database page, may contain only the compressed form of the page, or may contain both the compressed and uncompressed forms of the page.

MySQL

なるほど、バッファプール内において、データは、

• 圧縮版
• 圧縮版と非圧縮版の両方

のいずれかの形式で存在しうる、ということか。そして、非圧縮版のみが存在するということは発生しない、と。

換言すると、InnoDB Plugin の圧縮機能は、HDD 格納サイズの減少ではなく、オンメモリに保持できるデータ量を増やすことで、速度向上を計ることを目標としている (そして成功してるっぽい) ってことかな。

うーん、試したくなってきた。

*1:いくらインデックスも圧縮されるとは言え zlib によるテキストデータの圧縮としては、そうとう元データが冗長なんじゃないかという気もする