共计 2487 个字符，预计需要花费 7 分钟才能阅读完成。
（一）背景 ToplingDB，尽管 fork 自 RocksDB 并且兼容其 API，但实现了本性难移的改良，最重要的就是实现了性能更高的 MemTable 和 SST。咱们在 db_bench: ToplingDB vs RocksDB 测试中，看到了 cspp memtable 的单线程性能，本文中，咱们测试它的多线程性能。（二）配置参数 cspp memtable 的写性能太强，咱们必须配置多线程 flush 能力跟得上，而每个 memtable 又最多只能有 1 个线程来 flush，如此，又必须配置足够多的 memtable(write_buffer_num)，能力充分发挥多线程 flush 的作用。咱们测试的是小 KV，key_size=8，value_size=20，所以评估指标优先应用 OPS，即每秒操作数，也就是每秒钟向 DB 中写入多少条 KV。咱们这次只测试写性能，为了不便大家重现该测试，咱们应用阿里云的 ecs.g7.16xlarge 进行测试。CPU 核数 & 超线程数 32 核 64 超线程 CPU 型号 Intel(R) Xeon(R) Platinum 8369B CPU @ 2.70GHz 内存 256GToplingDB 和 RocksDB 雷同的参数：benchmarksfillrandomkey_size8value_size20num100000000threads40target_file_size_base33554432 (32M)target_file_size_multiplier2write_buffer_size1Gwrite_buffer_num17max_background_flushes16max_subcompations13max_background_compactions13enable_pipelined_writetrueToplingDB 和 RocksDB 不同的参数：ToplingDBRocksDBmemtable_factoryCSPP MemTableSkipListtable_factorydispatch_all_fast, no zipBlockBasedTable, no zipdb 目录放在 /dev/shm，全内存模式，打消 IO 带来的不确定性，其它参数均应用默认值，最初，设置不同的 batch_size 运行屡次。rocksdb 命令行：./db_bench -key_size=8 -value_size=20 -num=100000000 \
-db=/dev/shm/db_bench_rocksdb -bloom_bits=10 -write_buffer_size=1073741824 \
-target_file_size_base=33554432 -target_file_size_multiplier=2 \
-min_level_to_compress=10 -cache_size=34359738368 -enable_pipelined_write=true \
-max_write_buffer_number=17 -max_background_flushes=16 -subcompactions=13 \
-max_background_compactions=13 -disable_wal=true \
-benchmarks=fillrandom -threads=40 -batch_size=100ToplingDB 命令行（命令行中没有的参数在 db_bench_enterprise.yaml 中批改）：./db_bench -json=sideplugin/rockside/sample-conf/db_bench_enterprise.yaml \
-key_size=8 -value_size=20 -num=100000000 -disable_wal=true \
-benchmarks=fillrandom -threads=40 -batch_size=100（三）测试后果 3.1. fillrandom
结果显示，当 batch_size=500 时，应用 CSPP，DB 的写性能超过 2000 万 OPS，也就每秒钟能够向 DB 写入超过 2000 万 条 KV。能够看到，只有 batch_size 足够大时，CSPP MemTable 的性能稳固地超过 SkipList 3 倍，实际上，CSPP MemTable 自身相比 SkipList 有 6 倍的写性能，测试中的 3 倍是被其它环节拉低后的后果。3.2 readwhilewritingreadwhilewriting 测试的是：多个线程读（-threads=40），一个线程写（-batch_size=100）
可见，CSPP MemTable 不仅仅是写性能高，读性能更高，当然，读的时候除了搜寻 MemTable，还须要搜寻 SST，ToplingDB 的 SST，比 RocksDB 的 BlockBasedTable 更快。因为只有一个写线程，所以不会象 fillrandom 那样写得太快须要多线程 flush。（四）可期的改良：省略 MemTable Flush 很久以前，咱们就有个 ToplingDB 省略 L0 Flush 的改良打算，然而这将会是对 RocksDB 伤筋动骨的一个批改，所以始终未付诸行动。从这个测试中咱们能够看到，当应用 CSPP MemTable 时，Flush 是一个显著的瓶颈，咱们配置了 16 个线程来执行 Flush，理论运行中个别用到 8 个左右（通过 LOG 或 ToplingDB 的 WebView 能够看到），这些 Flush 实际上是以 Pipeline 的形式执行的，因为不同 Flush 线程操作的是不同工夫的 MemTable，相互之间有时间差，从而形成一个实际上的 Pipeline。如果省略了 MemTable Flush，而后 MemTable 会间接与 L1 的 SST 执行 Compact，就 fillrandom 测试来说，性能再进步 30% 是问题不大的。更进一步，在实在场景中，省去 MemTable Flush，还能大幅减小 IO，因为 L0 简直必定是不压缩的，Flush 对 IO 的耗费相当可观。
