优秀的软件系统，都是采用“分层”架构的，kv store，就是数据库系统中最关键的一个层级。
上层是 ，底层用 kv store，是数据库系统一个自然的演化结果。在 kv store 这个层级，RocksDB 现在是无可争议的事实标准，所以大家可以看到，RocksDB 几乎无处不在，于是就有人惊呼： RocksDB Is Eating the Database World。
我是 ToplingDB 的作者，ToplingDB fork 自 rocksdb，核心是两个 github 仓库：
| github 仓库 | 内容 |
|---|---|
| ToplingDB | fork 自 RocksDB，仅对 RocksDB 进行最少的必要的修改，从而可以对 RocksDB 保持 100% 的 |
| rockside | SidePlugin 插件体系，是 ToplingDB 的 |
对 RocksDB 做了很多改进：
- 修复了 RocksDB 的很多 Bug，其中有几十个修复已经
- 可以通过 json/yaml 设定 DB 的各种配置参数，用户代码只需要关注自己的业务逻辑，不需要操心任何配置相关的事情
- SidePlugin 内置了对 RocksDB 自身所有组件的支持（例如各种 TableFactory, Cache, RateLimiter, WriteBufferManager 等等）
- 通过 SidePlugin 框架，内嵌了一个 Http Web Server，可以展示 DB 的各种内部状态（例如展示当前生效的配置参数，展示 LSM 树形态等等），还可以将 DB 的各种内部指标 实现监控
- 通过内嵌的 Http Web Server，不用重启进程，
- 将 Compact 转移到专有的 ，并且这也是通过 json/yaml 配置来实现的，用户代码不需要为此进行任何修改！
- 完美支持 带状态的 CompactionFilter, MergeOperator, EventHandler 等等，当然，这需要用户自己实现 状态的 /反序列化
- Topling 性能组件： ， ， ，这些也是通过 json/ 来配置的，不需要修改用户代码
相比 RocksDB，ToplingDB 是全方位的超越者：
- 解决了 DB 入口的 随机写性能
- 解决了 Compact 中 执行压缩计算时算力不足的问题
- 通过让不同 DB 实例共享 Compact 计算集群，大幅提高(至少3倍)了计算资源的利用率
- 并且 Compact 计算集群还可以使用“ ”，在公有云上，“空闲算力”的价格可以低至一折！在私有部署中，“空闲算力”几乎是零成本的，因为数据中心最大的问题不是 不足，而是算力无法有效利用，只需要简单思考一下：公有云厂商对计算资源的利用率要远高于普通的私有数据中心，他们都肯用一折的价格售卖“空闲算力”，普通私有数据中心对算力的利用率就可想而知了。
- 既然算力不是问题了，那么我们就可以 尽情地使用 Topling 的可检索内存压缩算法，来把数据压缩成 更利于随机读的形式。
- 可检索 ，可以在相同的内存中装入好几倍数据，同时提供更好的 随机读性能，甚至于，ToplingDB 不需要 Filter 过程（BloomFilter，RibbonFilter，SurF Filter……），也可以在任何情况下提供更好的 性能