db_bench: ToplingDB vs RocksDB

（一）背景ToplingDB，虽然 fork 自 RocksDB 并且兼容其 API，但实现了脱胎换骨的改进，最重要的就是实现了性能更高的 MemTable 和 SST，其次是对 RocksDB 本身进行了很多代码级优化，再通过 SidePlugin 将所有的组件和配置组织起来，应用代码只需要关心业务逻辑，和 RocksDB 复杂的配置说再见（TableFactory, BlockCache, DBOptions, ColumnFamilyOptions 等等）。读性能，写性能，内存用量，都得到了大幅改进。我们使用 db_bench 来进行一个基准测试，db_bench 是RocksDB 自带的性能测试工具，在 ToplingDB 中，为了适配对接，我们对 db_bench 进行了小幅修改。该对比测试是可重现的，rocksdb 版本具体到 git 提交（2023-06-23），toplingdb 具体到 git 提交（2023-06-28）。（二）场景设计2.1. key_sizekey_size 我们设置为 8，因为再长了前缀都是完全相同的。2.2. value 压缩db_bench 填充 value 时，可以设置预期的压缩比例，因为 ToplingZipTable 压缩算法的特殊性，按照 rocksdb 作者实现的 db_bench 的 value 填充算法，在默认 value_size=100 的情况下，压缩率太高，可能会让不明真相的人以为 ToplingDB 在作弊，同时 ToplingDB value 不压缩时可以使用 zero copy，测试结果太好，也有作弊嫌疑。所以我们设置 value_size=20，消除这两个影响。2.3. 不执行手动 compact填充完数据之后，不执行手动 compact，这更加贴近现实场景。（三）配置参数我们测试数据可以全部装入内存的场景，并且文件也存储在 /dev/shm 下，真正的全内存场景。该场景下，RocksDB 因为存在 BlockCache 和 page cache 双缓存，内存消耗更大，ToplingDB 只有 page cache，内存消耗更小，但该测试中我们暂不对比内存消耗，只对比性能。ToplingDB: MemTable=cspp，SST TableFactory fast & zip，使用 dispatch 或 dispatch_all_fast 。RocksDB: MemTable=SkipList，SST TableFactory 是 BlockBasedTable，使用 min_level_to_compress 参数控制仅 L0 不压缩，还是全部不压缩，压缩选项使用 db_bench 默认值。num=100000000, write_buffer_size=768M, target_file_size_base=32M, target_file_size_multiplier=2对于 RocksDB，设置 bloom_bits=10，ToplingDB 的 SST 搜索足够快，不需要 bloom filter（四）测试项目对于两种压缩配置（L0 不压缩，L1~L6 压缩；全部不压缩），我们分别测试各个项目。写数据我们使用 fillrandom, 分别测试 batch_size=1 和 batch_size=100读数据我们使用 readrandom，分别测试 threads=1 和 threads=10数据扫描，分别测试 readseq 和 readreverse（五）测试结果4.1. L0 不压缩，L1~L6 压缩

4.2. 都不压缩

（六）总结在内存不限的情况下，不管是随机写还是随机读，ToplingDB 比 RocksDB 都有显著优势。随机写的时候，只有每次写入多条数据（batch_size=100），ToplingDB 的优势才能体现出来，因为写路径上有很多个环节，只有每次写入多条数据，才能突出 ToplingDB CSPP MemTable 的优势，实际上 CSPP MemTable 本身相比 SkipList 有 6 倍的写性能，测试中的 3 倍是被其它环节拉低后的结果。随机读的时候，ToplingDB 比 RocksDB 有 5 倍的优势，双方都有随线程数近乎线性的加速比。数据扫描中，反向扫描（readreverse）比正向扫描更慢，这主要是因为在 DBIter 中，反向扫描时，对于相同的 UserKey，需要记忆上一个 value，而正向扫描不需要，其次是 RocksDB BlockBasedTable 反向扫描本身就比正向扫描慢。在 ToplingDB 中，我们对扫描的全链路都做了很多优化，并且 Topling 的 SST 扫描本身就更快并且正向反向一样快。值得注意的是，不管是 ToplingDB 还是 RocksDB，压缩对于读写性能的影响都不大，这是因为服务器的 CPU 和内存资源都是过剩的（32核64线程，256G 内存）。相比 ToplingDB，这种场景对 RocksDB 更加友好，但 ToplingDB 仍然以绝对优势胜出，实际上在资源受限（CPU 弱，内存小，IOPS低）的场景下，ToplingDB 的优势更大。