THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
- 写入理论延时更低:原因在于逻辑分片的粒度更细。
- 对于类似于 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 的数据时读写流程是否还需要改动。
...