...

• 当用户创建大量的 sg 且写入少量数据时，可能导致产生大量的 raft 组，对集群的 CPU 资源产生浪费，这对存储引擎的线程模型提出了一定的挑战。
  • 可能的解决方案（可以都做）：
    • 方案 1：目前单机版推荐用户的存储组数 * VSG 个数 = 总核数，在新分布式架构中，可以为 sg 指定 vsg 的参数，默认为集群总核数/副本数。这样一方面方便单 sg 用户去充分利用集群所有的存算资源，也能给为多 sg 用户做细粒度的资源分配提出方案。
    • 方案 2：在存储上，此方案更便于做到 IO 的隔离。在计算上，参照 TiDB，CockroachDB 等数据库去做 multi-raft 的优化，包括但不限于心跳合并，线程池合并等。不论是单机还是分布式都应该尽可能将数据结构（LSM，Raft）和计算（线程资源）进行解耦。可以抽象出一些复用的线程池并对计算做一些管理。
    • 其实就跟操作系统对不同进程提供的保证一样，在我看来，没必要去限制进程个数不多于核数。尽管当进程过多时进程切换会带来一定的性能损耗，但其扩展性一定是更强的，而且聪明的程序员一定能从自己的应用场景寻找到避免频繁进程切换的解决方案。

调研

TDengine

tdengine 允许通过配置参数的方式去限制一个 database 中的最多 vnode 个数，其一个 vnode 只能管理一个 database 的数据。

Image Removed

Image Removed

Image Removed

TiDB

在 TiDB 的架构中，TiKV 可以被理解为一个无限大的有序 map，不同 database 的表会按照对应的编码规则组成 key 写入到 TiKV 中去。其每个一个 region 是一个 raft 组，其 region 个数既不与 database 个数有关，也不是静态不变（总核数 / 副本数）的，而是与数据的总大小有关，默认 128M 会组成一个 raft 组。

尽管 TiDB 不同 database 的数据在编码后理论上可能存在于一个 region 中，但大部分情况下同一个 region 的数据均是同一个 database 同一张表的数据。

Image Removed

Image Removed

总结

本文简单介绍了一个 VSG 共识组只能管理一个 sg 的设备组的优劣势并分别就原因和解决方案进行了讨论。由于作者水平有限，以上观点不一定绝对正确，欢迎大家补充修正。

...