Mongo on TerarkDB 性能评测

之前，我们发表过一篇 集成 TerichDB 的 MongoDB 性能测试，TerichDB 是 Terark 公司的第一个数据库产品，整个 DB 全部自主研发，因为使用 Terark 自己的引擎，所以功能非常丰富，性能也非常出色，但是与主流数据库不兼容。

现在，我们最新的 TerarkDB 完全兼容 RocksDB，我们通过实现 RocksDB 的 SSTable，将 Terark 的引擎 plugin 到 RocksDB 中，但是因为 RocksDB 本身的 SSTable 接口不支持两遍扫描，所以我们 fork 了 RocksDB，做了一些小的修改，以支持两遍扫描。更多内容，可以参考 TerarkDB 的 github

通过使用我们修改版的 MongoRocks，我们进一步把我们修改版的 RocksDB 集成到 MongoDB 中，并做了一些性能测试。本文主要描述这个性能测试结果。

以下内容来自 terark 官网的 blog：Mongo on TerarkDB 性能测试

---

目录

1.前言2.测试方式3.写性能4.读性能 4.1.数据远小于内存（内存64GB）4.2.数据略小于内存（内存8GB）4.3.数据略大于内存（内存4GB）4.4.数据远大于内存（内存2GB）

1.前言

我们将 TerarkDB 集成到了 MongoDB 社区版中，后续我们会逐步发布性能测试报告。 - Terark-Zip-Table 是我们替换了 RocksDB 的 SST (Static Sorted Table) 后的产品 - Mongo-Rocks 是 Facebook 官方适配 RocksDB 作为 MongoDB 存储引擎的产品 - Mongo-Terocks 指使用 TerarkDB 的 Mongo-Rocks - MongoDB 版本为该时间master最新版

2.测试方式

测试工具 YCSB(https://github.com/Terark/YCSB-mongo)测试数据 由于YCSB的数据都是纯随机字符串生成的，离用户的真实场景相差较大，我们采用了Amazon movie data (~8 million reviews)数据进行测试测试数据集尺寸 约为9.1GB约800万条数据平均每条数据大约1KB测试使用的引擎 MongoDB 默认存储引擎 WiredTigerFacebook 的 Mongo-RocksTerark 的 Mongo-Terocks读性能测试均是均匀分布与齐普夫(Zipf)分布测试这里测量了读95/99分位延迟数据

3.写性能

以下为写入速度与95/99分位延迟数据：

4.读性能

我们在开始读性能测试之前，首先批量的将所有数据写入数据库，然后重启服务器后开始测试。需要注意的是，除了数据远小于内存，其它的的读测试均是均匀分布与齐普夫分布测试。

内存受限情况，我们使用 cgroups 达成其中 RocksDB 开启 allow_mmap_reads 选项，BlockSize 为 4kWiredTiger 使用默认配置选项TerarkDB 使用默认配置选项RocksDB 与 TerocksDB 测试客户端均在本机启动WiredTiger 使用文件IO接口读取文件，cgroups 无法限制系统缓存，所以使用内核参数限制内存，此时测试客户端运行在内网其它服务器

4.1.数据远小于内存（内存64GB）

以下为数据压缩后大小与内存占用：由于压缩后数据库的尺寸(Storage Size)与读测试的内存限制无关，后面不再重复 Storage Size 图表 后续所有测试都使用同一份数据YCSB客户端全程占用 240% 以上CPU

4.2.数据略小于内存（内存8GB）

此种情况下内存比数据略大，设置数据库专用缓存(缓存解压后的数据) 4G （Wiredtiger 和 RocksDB 官方均推荐配置该缓存占物理内存一半）TerarkDB 需要的内存只有 2.84G，远小于8G，不影响性能读95/99分位延迟数据为均匀分布测试结果

4.3.数据略大于内存（内存4GB）

此种情况下内存比数据略大，设置缓存2GTerarkDB 需要的内存只有 2.84G，远小于4G，不影响性能读95/99分位延迟数据为均匀分布测试结果

4.4.数据大于内存（内存2GB）

此种情况下所有存储引擎都达不到需要的内存瓶颈在于文件IO，所有引擎的速度严重下降读95/99分位延迟数据为均匀分布测试结果