[venus-sector-manager] 扩展可用数据库类型

[dtynn]

模块 / Components

• venus-sector-manager
• venus-worker
• 工具链 / toolchains
• 文档 / docs

描述 / Description

• 基于其他类型数据库的组件实现
• 数据迁移工具

[remakeZK]

关于统一 wrapped store & 多类型 datastore 的对比

背景

目前 sector-manager 中对于不同类型的数据存放存在两种模式，它们分别是：

• wrapped store ： 通过对 Key 作前缀的包装，期望只注入一个 db 实例，包装由成多种 kv-store 供使用方调用。

• datastore ： 通过注入不同 db 实例，构造出不同的 kv-store，直接供使用方调用。

对比

db 层的比较：

• 使用不同的 db 实例在使用外部数据库时可能存在配置麻烦的情况，但这个可以通过同一个 db，不同的 table/collection 解决。

• 在性能上明显构造不同的 db 实例，将互相之间没有关系的数据分开存储对于 db 的增删改查更友好

• 将数据放在同一个 db 中，在人工需要查询数据的时候更友好？（存疑）

编码层的比较：

• 使用 wrapped store / 不同的 db 实例时 都需要进行代码的修改，wrapped store 需要添加新的 prefix。而不同的 db 则需要注入新的类型的 db，通过依赖注入系统帮助调用方构造 kvstore，需要改变的代码可见的会比使用 wrapped store 的多，且会改变依赖注入的代码

互相 migrate 的对比：

基于目前代码中存在两种混用的情况，统一化则需要进行 migrate

• 从 wrapped store=》不同实例： wrapped store 可以直接撤去，需要将现有的几类 store 进行修改，包裹成使用原生 key 不行的时候，使用 wrapped key 进行查询。（将 wrapped 这个概念下一层到 db 层作兼容）。

• 从 不同实例=》 wrapped store：目前几种 store 仍然需要注入（仍有可能会有查询落到这些 db 中），构造一个统一的实例，构造 wrapped store 中使用主 db 作为查询的第一层，目前几种 store 作为兼容。

• 直接使用工具进行 migrate，这种方式代码会比较干净，但是需要额外的运维人力来做这件事，另外需要额外的编写工具。

总结

统一成任何一种目前都存在一些问题，不过基于代码层都会进行改造，而数据库层面使用多个实例这种方式（外部数据库使用 table/collection），对于数据库的性能和可维护性都比较亲和，倾向于将目前的代码统一成使用多个实例这种方式。

[remakeZK]

@dtynn

[dtynn]

建议使用根据用途区分多实例的方式，同时保持 prefix wrapper 的使用逻辑