共计 2048 个字符，预计需要花费 6 分钟才能阅读完成。
（一）背景 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 的劣势更大。