百度将Mantle应用于对象存储路径解析

百度沧海·存储团队为解决对象存储「平坦 Namespace 下目录操作被放大为成百上千次底层对象操作、性能远弱于 HDFS」的问题，构建层级 Namespace：先评估并放弃子树划分路线（热点需动态分裂、工程复杂度高，且与基于 TafDB 的统一元数据架构冲突），改用「中心化索引 IndexNode + 水平扩展存储 MetaStore」双组件。 基于目录节点在海量元数据中占比不足 10%、目录修改操作占比低于 10% 的负载洞察，选择同步更新（2PC 强一致），从而把 readdir、DirectoryStat 等目录读操作卸载给底层可线性扩展的 TafDB。工程上进一步打破目录语义层与分布式 KV 的边界做跨层协同：把 IndexNode 下沉为 TafDB 内部的一个特殊分片，用协处理器把路径解析逻辑下推到存储节点，将任意深度路径解析由多次 RPC 压缩为一次 RPC，复用 TafDB 原生事务避免异构 2PC。 性能侧三项优化：一是全路径缓存加速——基于「98% 的目录重命名集中在路径倒数第二层、倒数第三层及以上目录项仅占 5%」的生产数据挖掘，用 TopDirPathCache 缓存稳定路径前缀实现 O(1) 前缀解析，并以 Invalidator（RemovalList + PrefixTree）无锁异步维护缓存一致性。 二是存储引擎专用化——把 Index 表从 RocksDB 切到 Hash 引擎，并基于元数据事务通常小于 10ms 的特征实现内存 MVCC（多版本仅保留 5 秒后刷写、持久化只保留最新版本）。三是 Follower read——只读 lookup 分发到 Follower/Learner 并先向 Leader 取 CommitIndex 保证强一致。 结果是 DirectStat 在 2048 线程下达 1894.5 Kop/s（约 189 万 QPS，论文 Figure 19）。并发侧：IndexNode 引入后 mkdir/rmdir 由 1PC 退化为跨分片 2PC，mdtest 全竞争场景下 mkdir 与 dirrename 吞吐分别下降 99.7% 与 99.4%。 先后尝试悲观并发控制（高争用 Key 阻塞式锁队列，仅数百 QPS）后，改用 Delta Record 机制把原地更新改为按「原始属性 Key + TS」写入独立增量记录、读取时合并、后台异步合并回主记录，使高争用场景下目录修改吞吐量提高超过 115 倍。文末致谢称该架构已转化为支撑核心业务的存储底座。