MariaDB数据库引入原子写特性将提升30%性能

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数据集要慢些。数字： 小数据集(10G) 大数据集(100G) max ro tps 8000 3000 max rw tps 6000 1800 对大数据集，下面的配置将被比较： 双写入，InnoDB 页面校验 double write, InnoDB page checksum 原子写入，InnoDB 页面校验 原子写入，XtraDB 快速页面校验 原子写入，无页面校验 线程 双写入 　原子写入 原子写入+快速校验 原子写入+无校验 1 159.81 164.34 +2.8% 179.68 +12.4% 184.72 +15.6% 2 316.65 343.21 +8.4% 378.61 +19.6% 391.72 +23.7% 4 544.05 635.26 +16.8% 699.6 +28.6% 726.55 +33.5% 8 830.37 1062.8 +28.0% 1176.8 +41.7% 1214.7 +46.3% 16 1054.7 1421.2 +34.7% 1570.7 +48.9% 1610.1 +52.7% 32 1208.3 1615.1 +33.7% 1736.6 +43.7% 1767.4 +46.3% 64 1286.9 1673.2 +30.0% 1793.2 +39.3% 1833.7 +42.5% 128 1266.2 1653.1 +30.6% 1824.5 +44.1% 1875.6 +48.1% 256 1139.4 1505 +32.1% 1586.3 +39.2% 1618.3 +42.0%

结论：
启用原子写能立即带来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 重做日志.