Page History

...

• 写入理论延时更低：原因在于逻辑分片的粒度更细。
  • 对于类似于 Ratis/Sofa-jraft 的共识算法库，其默认用一个异步 apply 线程去往状态机按序 apply 日志，然而在单机引擎内不同 sg 的写入原本可以并行。如果不做并行 apply 的优化，可以预见写入延时会很高；如果做并行 apply 的优化，则需要在 raft 库的 apply 线程中再进行一次异步调度，同时还需要支持 apply 返回异步 future 的 raft 库才方便做这样的优化，集成成本和维护成本会更高。
• 查询理论延时更低：原因在于逻辑分片的粒度更细。
  • 对于类似于 Ratis/Sofa-jraft 的共识算法库，其默认的读接口是线性一致性读，即需要等到 applyIndex 达到 leader 的 commitIndex 之后再去状态机读，这样的机制主要是为了防止出现脏读。当不同 sg 的数据存在于一个 raft 组中时，即使某一个 sg 没有写入，在查询该 sg 的数据时可能也要等待该共识组其他 sg 数据的并发写入被 apply 之后才可以去状态机读，这会进而增大查询延时。
• 做单机分区，多级存储和 做时间分区，多级存储和 TTL 时开发成本更低，效率更高：原因在于只有拥有相同属性的设备会被存在同一个 tsfile 中，便于以文件粒度进行处理。
  • 对于单机的时间分区和多级存储，当一个 对于时间分区和多级存储，当一个 VSG 共识组只能管理一个 sg 的数据时，其整体的流程基本都可以按照文件的粒度去生成和迁移，开发成本较低。
  • 对于 TTL，当一个 VSG 共识组只能管理一个 sg 的数据时， 一个 tsfile 所有设备的 ttl 均相同，过期删除实现方便，查询也不需要做额外的过滤。
• 做数据备份的开发成本更低，性能更好：原因在于只有拥有相同属性的设备会被存在同一个 tsfile 中，便于以文件粒度进行处理。
  • 对于做单 sg 的数据备份，显然此方案开发成本更低，性能（往往只需要硬链接，不需要重新去 build）都会更好。
• 调度灵活性更强：原因在于逻辑分片的个数更多。
  • 对于多 sg 场景，由于集群的总共识组个数相比另一种方案更多，对共识组的副本组做调度即成员变更时的成本会更低。
• 更容易做到资源隔离：
  • 对于多 sg 场景，此方案更容易支持不同 sg 的资源隔离（挂载不同磁盘，分配不同数量的线程资源），另一个方案写入一套 TSM 后就很难再去做资源隔离了。
• 与现有逻辑保持一致：
  • 在当前单机的 VSG 实现中，一个 tsfile 只会拥有单个 sg 的数据。目前还不确定在 tsfile 写入不同 sg 的数据时读写流程是否还需要改动。

...