Linera协议中AdminKeyValueStore的root_key机制解析与改进

背景与现状

在Linera协议的核心存储组件AdminKeyValueStore中，目前采用了root_key的设计模式。这种设计本质上类似于数据库中的分区键(partition key)概念，用于在键值存储中实现数据隔离和分区管理。当前实现允许通过clone_with_root_key方法创建具有不同根键的子存储实例，但缺乏获取所有根键的能力。

现有问题分析

现有架构存在两个主要使用场景无法满足：

1. 验证器链列表访问：验证器需要获取其管理的所有区块链列表
2. 数据迁移需求：在不同存储系统间迁移数据时需要枚举所有分区

当前实现存在以下技术限制：

• DynamoDB/ScyllaDB：这类分布式数据库原生支持分区键查询，理论上可以轻松获取所有根键
• RocksDB：由于设计选择将键简单拼接为root_key + key的形式，没有内置的分区概念
  • 当初选择这种设计是为了避免为每个根键创建独立RocksDB实例导致文件描述符耗尽
  • 缺乏有效机制追踪已创建的根键

技术方案设计

新增接口设计

建议增加以下核心方法：

fn get_root_keys(&self) -> Result<Vec<Vec<u8>>, Self::Error>

RocksDB实现方案

针对RocksDB的特殊情况，提出以下改进方案：

1. 根键追踪机制：

   • 在clone_with_root_key操作时，异步写入一个特殊标记记录
   • 这些标记记录将用于后续枚举所有根键
   • 虽然会使clone_with_root_key变为异步操作，但在可接受范围内

2. 存储结构优化：

   • 使用专门的键前缀(如__root_keys__)存储根键列表
   • 维护一个内存中的根键缓存，定期与持久化存储同步

分布式存储适配

对于DynamoDB和ScyllaDB：

1. 利用原生分区键查询功能
2. 可能需要添加二级索引以提高查询效率
3. 考虑分区键的分布式特性带来的性能影响

技术挑战与考量

1. 一致性保证：

   • 在分布式环境下确保根键列表的强一致性
   • 处理节点故障时的数据恢复

2. 性能优化：

   • 对于大规模根键集合的分页查询支持
   • 缓存策略的设计与失效机制

3. 存储服务适配：

   • 现有存储服务层需要相应扩展
   • 可能需要版本化API以保持向后兼容

应用场景扩展

该改进不仅解决当前需求，还为以下场景奠定基础：

1. 存储监控：实时监控各分区的存储使用情况
2. 数据治理：实现基于分区的数据生命周期管理
3. 多租户隔离：为未来的多租户支持提供基础设施

总结

Linera协议的存储层改进通过引入get_root_keys接口，不仅解决了验证器链管理和数据迁移的现实需求，还为系统未来的可扩展性奠定了基础。针对不同底层存储引擎的特性差异，需要采用差异化的实现策略，在保证功能完整性的同时兼顾性能与可靠性。这一改进将显著提升Linera协议在复杂部署场景下的管理能力和运维便利性。