InnoDB holepunch 实验

在阅读了 Mark Callaghan 的优秀博客（见下方链接）后，我决定花一些时间来实验 MariaDB 10.1 中使用 holepunch 功能时，不同的文件系统会有怎样的表现。首先，即使表是页面压缩的（MariaDB 中使用的术语），MariaDB 10.1 默认也不使用 holepunch。MariaDB 中的 holepunch 功能通过配置变量 innodb-use-trim=1 启用，并且自然需要文件系统支持带有 FALLOC_FL_PUNCH_HOLE 和 FALLOC_FL_KEEP_SIZE 参数的 fallocate 系统调用。在 cmake 构建阶段会检查对这些参数的支持。

我使用了 CentOS Linux release 7.1.1503 (Core) 系统，该系统运行 3.10.0-229.el7.x86_64 Linux 内核，并在 RAID-0 配置中使用了一些 SSD 硬盘（Intel X25-E Extreme SSDSA2SH032 G1GN 2.5 英寸 32GB SATA II SLC 固态硬盘 (SSD)）。在该系统中，我使用了 ext4, btrfs (v3.16.2), 和 xfs 作为文件系统。注意，设计该功能的 NVMFS 文件系统目前不能用作普通 SSD 的文件系统。

我使用 LinkBench 进行了测试，数据库大小为 2.5 倍，生成了 26G 的未压缩表和使用 zip 压缩的 16G holepunch 表。

显然，在 xfs 中删除 holepunch 压缩表所需的时间比未压缩表要长得多，这意味着如果工作负载需要删除大表，则 holepunch 功能在 xfs 上并不适用。在 ext4 中，基本没有区别；在 btrfs 中，差异是 10 倍。然而，问题可能在于数据库太小，因此我还使用 LinkBench 测试了 5 倍数据库大小的情况。

使用普通硬盘 (HD) 和 20 倍 LinkBench 仅使用 ext4 文件系统也进行了类似测试。首先，加载 holepunch 压缩表所需时间比未压缩数据库长得多。同样，删除数据库所需时间也显著不同

最后，使用 ioMemory SX300-1600 搭配 VSL driver 4.2.1 build 1137 和 NVMFS 1.1.1，并使用 20 倍 LinkBench 数据库进行了类似测试。在这种配置下，未发现显著差异。

结论

基于我的和其他实验，很明显，许多文件系统在处理大型稀疏文件时存在很大的开销。这一结论表明需要对 holepunch 进行替代设计，即可以在不进行 punch hole 操作的情况下使用此功能，从而产生比基于真正的页面压缩 (Page Compression) 架构所能达到的文件密度略高的文件。

链接

https://bugs.mysql.com/bug.php?id=78277
http://smalldatum.blogspot.com/2015/08/first-day-with-innodb-transparent-page.html
http://smalldatum.blogspot.com/2015/09/second-day-with-innodb-transparent-page.html
http://smalldatum.blogspot.com/2015/09/third-day-with-innodb-transparent-page.html
http://smalldatum.blogspot.com/2015/10/wanted-file-system-on-which-innodb.html
https://mariadb.com/kb/en/mariadb/compression/