MariaDB 引入原子写特性 已翻译 100%

Sysbench OLTP，每秒处理事务数

在使用高性能低延迟的存储设备（如SSD）时，我们可能会遇到意想不到的瓶颈。本文讲述的就是遭遇和处理这样的一个瓶颈的故事。

InnoDB 有一个独特的特性叫“双写缓存”（Double Write Buffer）。这个特性用于恢复那些未完整写入的页（Page），如果电源出现故障时 InnoDB 正在往硬盘上写一个页（1页=16KB=32磁道），那么就可能导致该页未完整写入。下次读取这个页的时候，InnoDB 会发现其校验码（checksum）不匹配并判定其是损坏的。为了将这个损坏的页恢复，我们需要这个页的原始备份。

“双写缓存”就提供了这样的备份。当 InnoDB 将一个页写入硬盘时，该页的内容首先被写入双写缓存中。仅当该缓存被安全的写入到硬盘后，该页的内容才会被写到硬盘的最终位置。当要恢复的时候，InnoDB 会扫描双写缓存，对缓存中每个正确的页，同样检查其在数据文件中的内容是否正确。

在这个机制中，校验码的生成和两次写入的过程都是要消耗时间的，由此会带来页数据写入的性能下降。只有当使用快速存储设备，并执行大量写操作的时候，其影响才会变得明显。在测试的时候你可以禁用这些特性，但我强烈建议不要在生产环境中这么做。

目前想要使用“原子写”特性的话，需要采用 DirectFS 文件系统，该文件系统是 FusionIO SDK 的一部分。来自 Monty Program AB 的 Wlad Vaintroub 与 FusionIO 的开发人员一道，为InnoDB/XtraDB 使用该特性作了必要的修改。如果数据库中所有的表空间都驻于 DirectFS/FusionIO 上，并由此支持“原子写”特性的话，那么可以用新的变量 innodb_use_atomic_writes=1 来将“双写缓存”切换成“原子写”。该补丁已经包含到 MariaDB-10.0.2，并也将包含到 MariaDB 5.5.31。该特性的使用说明文档在这里。

来看看数据吧！初步的测试结果表明，原子写特性对于小数据集（同 RAM 大小相匹配的数据集）来说，带来的好处很小甚至没有。但是在使用快速的 SSD 时，由于读写速度大幅改善，数据库可以经受（同 RAM 相比）大得多的数据集。

下面是 Sysbench 的 OLTP 基准数字，使用100GB数据（16表,400亿行），但 InnoDB 缓冲池的 RAM 只能有16GB。性能当然比通常的10GB数据集要慢些。数字：

对大数据集，下面的配置将被比较：

• 双写入，InnoDB 页面校验 double write, InnoDB page checksum
• 原子写入，InnoDB 页面校验
• 原子写入，XtraDB 快速页面校验
• 原子写入，无页面校验

结论：

• 启用原子写能立即带来30%左右的写性能改善；
• 使用 XtraDB 的快速校验（fast checksum）能将性能改善提高至接近50%；
• 完全禁用校验只会带来很少的性能改善。

测试细节：

MariaDB-5.5.30 (lp trunk). Sysbench-0.5 (Lua 启用). Complex OLTP 测试. 400 mio rows in 16 tables. 16GB InnoDB 缓冲池, 4G 重做日志.

本次测试的脚本和结果，一如既往的向大家公开。