Distributed Compaction In MyTopling
MyTopling 基于 ToplingDB，而 分布式 Compact 是 ToplingDB 的一个杀手级特性，于是 MyTopling 就天然地获得了分布式 Compact 所有的收益。
MyTopling 使用 ToplingZipTable 与 分布式 Compact 黄金组合，把 Compact 任务转移到专用的计算结点上，移除了 Compact 对 DB 结点 CPU 的消耗，于是 DB 结点对 ToplingZipTable 就只有读操作，而 ToplingZipTable 读操作的开销极低，这就进一步降低了 DB 结点的 CPU 消耗。
相比 RocksDB BlockBasedTable，ToplingZipTable 使用了可检索内存压缩算法，直接在压缩的数据上执行搜索和访问，内存占用更低，读操作的 CPU 开销也更低。相应的代价是创建 ToplingZipTable 的开销较高，大约是 BlockBasedTable + zstd 的 2 倍，通过分布式 Compact，ToplingZipTable 的创建就在 Compact 结点上执行，不需要消耗 DB 结点的算力。
按照传统方式，在 DB 结点上，既服务读写请求，又执行 Compact，而这两种计算的需求特征完全不同：
- 服务读写请求，是在线计算，评价的指标是每个请求的延时
- 执行 Compact，是离线计算，评价的指标是所有 Compact 的总吞吐
这两种计算并发执行时，会互相争抢资源，即便在线计算的优先级更高，但终归还是会被离线计算拖累，所以，在实际应用中，大家都不敢把系统负载跑太高，比如有些业务在规划时就要求在线服务的负载不应高于 30%，实际上可能常年在 10% 左右。
另一方面，在 RocksDB 这种 LSM 引擎中，写操作本身消耗的算力不超过 10%，而写操作引发的 后台线程(Flush & Compact)消耗的算力才是大头，这样综合起来，算力的浪费极大，这实际上就是对金钱的浪费！分布式 Compact 用来优化算力的调度与利用率，提高效益，减少浪费：
- 多个 DB 结点可以共享相同的 Compact 服务器，这样，因为不同 DB 的流量峰值和低谷在时间上的交错，在 Compact 服务器上，对来自不同 DB 结点的 Compact 请求，自然而然地起到平峰错谷的效果，其结果就是提升了资源的利用率
- Compact 服务器上只运行 Compact，而 Compact 作为离线计算，对延时并不敏感，所以，我们就可以把机器的负载打到很高（例如 90%，对比前面的 30%），从而用另一种方式提升了资源的利用率
- Compact 计算，可以使用空闲算力，在公有云上（例如阿里云的抢占式实例，AWS Spot Instance），空闲算力的价格非常便宜，最低可以低至 1折！ 从用户的视角，这是降低了计算资源的成本，从公有云厂商的视角，提高了他们的资源利用率，创造了利润！
基于 MySQL 传统主从方案，DB 数据一般保存在 NVMe SSD 上，NVMe 提供了极高的带宽与 IOPS，从而 IO 作为系统瓶颈已经成为过去时，软件层的失配与 CPU 成了新的瓶颈。
很早以前 innodb 使用异步的 libaio 来改善 IO 性能，在过去的岁月里这为 MySQL 的性能提供了极大的改善，但是在硬件的 NVMe 和软件的 io uring 已经普及的今天，MySQL 使用的 aio 就显得有点力不从心了。软件层的开销既大，硬件性能又无法充分发挥。
基于 LSM 的 ToplingDB 存储引擎，其 IO Pattern 与 innodb 有极大的差异：只有顺序追加写，无随机写。这种 IO Pattern 对 Flash 存储非常友好，但是在 NVMe 上，瓶颈仍主要体现在 CPU 上：Compact 对 CPU 的消耗。所以我们使用分布式 Compact。
在部署方式上，DB 结点把自己的数据目录通过 NFS 暴露给 compact worker 结点，从而 DB 结点需要付出额外的 NFS 服务开销及相应的网络带宽。好在 NFS 服务的开销很低，并且数据中心的网络带宽也属于比较富裕的资源（例如一般云厂商 8c32g 的云服务器都有高达 10Gb 的网络带宽，16c64g 的网络带宽甚至高达 25Gb）。
这么高的网络带宽仅作为 MySQL 服务根本用不满，白白地浪费掉，就是金钱的损失。
MyTopling 支持基于共享存储的主从方案，在这种方案中，底层共享存储的可靠性，决定了整个副本集的可靠性，所以这个存储本身必须是可靠的，多副本的（纠删码对 DB 存储不适用）。
在公有云上，最可靠的，广泛可用的，并且适用于 DB 存储的，是性能优先的 NAS，例如阿里云的性能型 NAS 产品。但是相比 NVMe SSD，NAS 不论是延迟，还是带宽，都远远不如。
但是 NAS 有三个巨大的优势：
- 秒级拉起新的只读结点（因为数据存储是共享的）
- 逻辑上数据只有一份（物理上是多副本），只需要一次 Compact
- 在共有云上，NAS 容量和 IO 可以弹性伸缩，并按实际用量付费
| 维度 | 本地 NVMe SSD | NAS 共享存储 | 理想的分布式共享存储 |
|---|---|---|---|
| IOPS | 高(数十万) | 中(数万) | 极高（数千万） |
| IO 带宽 | 高(数GB) | 1 低(<1GB) | 极高（数百GB） |
| IO 延迟 | 低(<100us) | 高(~1ms) | 中(数百us) |
| 持久性 | 低(硬件损坏) | 高(11个9) | 高(11个9) |
| 可用性 | 中 | 中 | 高 |
| 容量扩展性 | 无 | 高 | 极高 |
| 快速拉起新结点 | 不支持 | 支持 | 支持 |
| Compact 计算消耗 | 同副本数 | 仅 1 次 | 仅 1 次 |
1 注：云厂商 NAS 的 IO 带宽一般是 基础带宽 + 增量带宽，增量带宽随 NAS 的实际数据存储量线性增加。例如阿里云性能型 NAS 基础带宽是 600MB/s，增量带宽是 0.6MB/GB，即每增加 1GB 数据量，带宽增加 0.6MB/s；其它云厂商 NAS 的基础带宽一般 100~150 MB/s。
本地 NVMe SSD 最大的优势就是 低延迟 ，在没有理想的分布式共享存储时，这个优势是 NAS 方案完全无法比拟的。然而，相比共享存储方案，这个 低延迟 是用更多的 CPU（分布式 Compact 计算量）换来的，好在 分布式 Compact 可以使用 空闲算力 来执行，大大缓解了这个劣势带来的成本增加。
分布式 Compact 要正常工作，dcompact worker 服务就不能中断，从而就必须至少有一个 dcompact worker 结点，即便我们只有一个 DB 结点，这个 dcompact worker 结点也必不可少。在这种情况下，分布式 Compact 并不能提供应有的经济效益。
所以，作为云原生的 DB 服务，我们让多个用户，多个 DB 实例共享同一组 dcompact worker 结点，通过 Serverless 方案，dcompact worker 集群甚至可以自动弹性伸缩，既提供足够的算力，又不浪费资源，以最低的成本实现最高的效益。
对于有一定规模的私有部署集群（数十个结点即可体现出可观的效益），不管是基于本地 NVMe 的 MySQL 传统主从方案，还是基于共享存储的新式主从方案，都可以直接应用共享分布式 Compact：
