首先，Todis(外存版 Redis) 的性能优势，主要来自底层的ToplingDB存储引擎，ToplingDBfork 自 RocksDB，增加了很多改进，修改了一些 bug，其中有很多修改也PR 给了上游 RocksDB。目前 Todis 仍在邀请内测中，可通过7分钟视频教程快速开始。
ToplingDB的性能优势，主要来自下面五点：
更好的 Compact 策略
Topling CSPP MemTabl
除了不支持用户自定义的 Comparator，Topling CSPP MemTable在各个方面都压倒性地优于RocksDB SkipList：单线程更快、多线程scale 更好、内存消耗更小。
Topling Fast SST
为了性能，Topling Fast SST不使用压缩，索引结构使用了 CSPP Trie，在 Todis 配置中，L0 和 L1 就使用了Topling Fast SST。
Topling Zip SST
Topling Zip SST使用了 Topling内存压缩算法，压缩率更高（相比 zstd），索引和数据在内存中的形态都是压缩的，搜索索引和提取数据都直接在压缩的数据上执行，可以精确提取每条数据。单线程可支持数十万甚至上百万的 QPS。
这种内存压缩算法压缩数据时需要的计算量较大，所以仅在 L2 及更低层使用，并且通过分布式 Compact转移到专用的计算集群。
这样，在 DB 结点上，充分发挥该算法读的优势，可以使用更低规格的硬件，实现更高的性能，达到 5 倍以上的性价比。
Topling 分布式 Compact
首先，分布式 Compact是基于共享存储的存算分离架构，进一步把计算分为前台计算和后台计算，DB 结点执行前台计算，Compact 计算集群执行后台计算，我们称之为前后分离。
在 DB 结点上，分布式 Compact相当于通过一个 RPC 远程调用，把相应的 Compact 任务，发送到计算集群中的结点上执行。
在这种架构之下，Topling Zip SST就是天选之子！但其实是Topling Zip SST催生了分布式 Compact——早在 2018 年，我就有了分布式 Compact 的想法，因为Topling Zip SST对它有迫切需求！
更好的 Compact 策略
RocksDB 通过 subcompact 把一个 Compact 任务划分成多个子任务，通过多线程并发执行，我们对此进行了一些改进：Level 1 Sub Compaction和GetRandomInteranlKeysAppend。
通过这两个改进，我们一方面减小了读放大和写放大，同时可以让分布式 Compact 更充分地并行化。
以下，是 Todis 与 阿里云 Tair 的测试对比，如需深入了解，可查看测试详情。
