AI 摘要 · 由英文经 AI 翻译
MetaDB: Putting File-System Structure Back into Distributed Databases
Zebin Ren, Biao Cao, Kang Chen, Zhihui Yin, Qiushi Chen, Jielong Jian, Jiwei Xiong, Xinxing Wang, Yan Xing, Liguo Duan, Ran Zheng, Xianjun Meng, Zhenyu Hou
TL;DR
尽管分布式数据库已在生产存储系统中充当共享元数据层，通用数据库仍忽视了元数据工作负载的树形结构和差异化更新语义。MetaDB围绕元数据结构与语义协同设计分布式数据库；据报告，其吞吐量达到此前通用数据库的2.2×–4.1×，所需元数据机器数量减少一半。
问题
通用数据库忽视了元数据工作负载的结构与语义特性，尽管分布式数据库已在生产存储系统中充当共享元数据层。
出处：§1 · p. 1方法
MetaDB围绕文件系统结构、语义和工作负载动态特征，协同设计具备元数据感知能力的分布式数据库。
出处：§1 · p. 2结果
据报告，MetaDB的吞吐量达到此前通用数据库的2.2×–4.1×，所需元数据机器数量减少约50%。
出处：§1 · p. 2, §10 · p. 12启示与局限
结果表明，在数据库内部利用工作负载特有结构，是提升存储系统元数据管理性能与效率的一项设计原则。
出处：§10 · p. 12
Abstract
from arXiv · showhide
Storage systems in production increasingly rely on distributed databases for metadata management, yet our experience at Baidu shows that treating a general-purpose database as a black box leaves substantial performance and efficiency untapped. File-system metadata exhibits directory-tree locality, differentiated consistency requirements, and clustered deletions that general-purpose databases largely ignore. We thus propose MetaDB, a metadata-aware distributed transactional database that serves as the shared metadata layer for Baidu's large-scale storage systems. MetaDB addresses three key mismatches between general-purpose databases and metadata workloads: Data Model Mismatch, Transaction Model Mismatch, and Storage Implementation Mismatch. To bridge these gaps, MetaDB combines (1) tree-topology-induced sharding and execution, (2) semantic-aware off-critical-path processing, and (3) a lifecycle-aware storage engine with in-memory MVCC and locality-aware compaction. MetaDB achieves 2.2x-4.1x the throughput of our previous general-purpose database and halves the number of metadata machines. Deployed in production at Baidu for over five years, MetaDB unifies metadata management across the company's storage fleet and scales to over 1,000 metadata nodes, tens of trillions of metadata records, and exabyte-scale storage in a single cluster.
1 引言
百度的生产实践表明，通用数据库忽视文件系统元数据的结构、语义和动态特性，因而未能充分发挥性能。MetaDB 针对这类工作负载协同设计数据库技术，并实现了更高吞吐量、更少的元数据机器以及大规模生产部署。
1 引言
- 百度构建了统一的通用分布式数据库，作为各存储系统共享的元数据层；但生产实践表明，将其视为黑盒会导致性能瓶颈。MetaDB 围绕元数据特有的结构、语义和动态特性进行设计。出处：§1 · pp. 1–2
- 树拓扑驱动的分片使分片边界与目录边界对齐；将事务逻辑下推至存储节点，则可将多轮协调缩减为一次远程执行。基于策略或规模的分片可使单目录操作限制在一个分片内。出处：§1 · p. 2
- 语义感知的非关键路径处理会异步聚合热点父目录属性，并在无需严格时效保证的情况下更新辅助配额和索引。读路径上的协调可确保父目录属性保留最新可见状态。出处：§1 · p. 2
- 生命周期感知的存储引擎将内存 MVCC 与局部性感知的范围压实相结合，避免刷新生命周期短的墓碑，并及时清除局部集中的墓碑。该设计旨在保持较低的 listdir 延迟。出处：§1 · p. 2
- 据报告，MetaDB 的吞吐量是此前通用数据库的 2.2×–4.1×，元数据机器数量则减少约 50%。MetaDB 已部署超过五年；单个集群可扩展至 1,000 多台元数据机器、数十万亿条记录，并支持 EB 级存储。出处：§1 · p. 2
- MetaDB 通过三项相应设计，解决树拓扑、事务语义和操作动态特性方面的不匹配。论文在生产元数据工作负载上评估了这些设计，并报告了相较于通用数据库的性能提升和资源节省。出处：§1 · p. 2
2 背景与动机
百度的元数据服务支持扁平和层级命名空间，并从彼此独立的系统演进为统一的通用数据库。该数据库的生产实践暴露出数据库设计与元数据的树形局部性、一致性要求及删除模式之间的错配。
2.1 百度的元数据管理
- 对象存储提供扁平和层级命名空间服务，而 CFS 提供符合 POSIX 的层级命名空间；Mantle 和 CFS 都需要可扩展的目录树管理层。Mantle 的解耦设计会将每项元数据操作都发送到后端，而 CFS 客户端可以缓存目录元数据和物理布局信息。出处：§2.1 · p. 2
2.2 MetaDB 之前的元数据库
- 百度从采用静态分片的独立元数据系统，演进到统一的分布式事务数据库；该数据库在生产环境中的瓶颈促使我们开发 MetaDB。早期系统存在扩展不灵活、缺乏跨分片事务保障、管理开销大和热点风险等问题；统一数据库则增加了动态分片、复制和快照隔离。出处：§2.2 · pp. 2–3
2.3.1 数据模型错配：扁平分片与树形拓扑
- 超过 97% 的目录树修改操作仅涉及单个目录，但扁平分片可能将大型目录拆分到多个分片，使局部更新变成分布式事务。五位用户的目录大小分布表明，按目录边界划分分片是可行的；Figure 1 展示操作分布，Figure 2 展示目录大小分布。出处：§2.3.1 · p. 3, Figure 1 · p. 3, Figure 2 · p. 3
2.3.2 事务模型错配：僵化的 ACID 与宽松语义
- 对所有元数据字段都采用严格原子性，会造成父记录争用和多分片协调；然而，配额和索引更新可以容忍数分钟的延迟。对于同一目录下的创建操作，吞吐量会从无争用时的 ∼60K QPS 降至 ∼6K QPS；生产环境中的配额记录用于后付费计费和监控，按小时结算。出处：§2.3.2 · p. 3
- 批量删除期间，持久化的 MVCC 墓碑会不断累积并拖慢范围扫描；而传统的全分片压实速度过慢且资源消耗过大，无法及时清理局部删除产生的数据。删除期间，包含 1,000 个条目的 listdir 操作延迟会从 < 100 ms 升至 ∼6 秒；元数据事务的持续时间极短（< 10 ms）。出处：§2.3.2 · p. 4
3 MetaDB 设计
MetaDB 围绕目录树结构组织元数据，并针对元数据负载协同设计数据模型、集群架构和处理机制。其三项设计支柱分别针对数据模型、事务模型和存储实现方面的不匹配。
3.2 架构
- 代理通过 MetaCache 解析并路由请求，Manager 负责监控集群状态和动态分片；后端节点通过 Raft 复制数据，并使用内存 MVCC 和 RocksDB 持久化数据。缓存未命中时，MetaCache 会向 Manager 查询；后端节点在 Raft 共识达成后执行操作。出处：Figure 6 · p. 4, §3.2 · pp. 4–5
3.1 数据模型
- MetaTable 使用 (PID,name) 键和特殊的 _attr_ 条目将目录树展平，使每个目录的属性与其子项共置；QuotaTable 和 SecondaryIndexTable 存储辅助元数据。QuotaTable 跟踪每位用户的资源使用量，SecondaryIndexTable 则将数据面文件映射到元数据条目。出处：§3.1 · p. 4
3.3 解决不匹配
- MetaDB 通过树拓扑诱导的分片与执行、语义感知的非关键路径处理，以及生命周期感知的存储引擎，针对已识别的三项不匹配进行设计。存储设计将内存 MVCC 与局部性感知的范围压缩相结合。出处：§3.3 · p. 5
4 基于树拓扑的分片与执行
MetaDB 将分片边界与目录树结构对齐，并在后端节点执行单分片事务逻辑。这样既能让常见目录操作在本地完成、减少协调开销，也为规模特别大的目录提供了回退方案。
4 基于树拓扑的分片与执行
- 超过 96% 的目录项更新仅涉及单个目录，因此 MetaDB 将目录数据放在一起，并在本地执行这些操作。传统的基于大小的分片可能将父目录与其子目录分开，使此类更新变成分布式事务。出处：§4.1 · p. 5, §4 · p. 5
4.1 分片策略
- MetaDB 在 group_key 边界处分割分片，以父目录标识符为依据，将目录属性与其直接子项放在一起，从而避免单目录操作产生分布式事务。系统会监控超大分片，并可将其隔离到负载较低的节点上；如果某个分片仍超过单机容量，运维人员可以手动拆分，但这可能导致分布式事务。出处：§4.1 · p. 5
4.2 下推单分片事务逻辑
- 协调节点执行目录操作的读-改-写序列时，可能至少需要两次网络往返；MetaDB 则在后端节点本地完成整个序列。本地执行依赖分片策略将目录的条目与属性放在同一处。出处：§4.2 · p. 5
5 面向语义的非关键路径处理
MetaDB 将一致性需求不同的元数据更新移出事务关键路径。它异步处理辅助元数据并聚合父目录属性，同时在读取时合并尚未处理的属性变更。
5 面向语义的非关键路径处理
- MetaDB 将可聚合的目录属性和辅助元数据移出事务关键路径，以缓解锁竞争和不必要的多分片协调。对于一致性要求不同的字段，设计采用异步的非关键路径处理。出处：§5 · p. 6
5.1 解耦的异步辅助更新
- 配额和索引更新通常位于不同分片，因此与主要元数据一起原子更新需要多分片事务；MetaDB 则将这些辅助更新排队并异步批量处理。请求首先写入 Raft 日志，然后在主要更新后入队；时间戳和故障后重放可避免更新重复或丢失。出处：§5.1 · p. 6
5.2 无冲突的异步属性聚合
- 对目录的并发变更可能在其共享属性上产生竞争；MetaDB 聚合 num_children 的增量，并选取时间戳最大的已提交 modify_time。属性变更会记录并排队，由后台批量更新；读取时则将已持久化的值与待处理变更合并，以返回最新属性。出处：§5.2 · pp. 6–7
6 生命周期感知型存储引擎
MetaDB 针对元数据的短事务和成簇删除重新设计存储层。内存 MVCC 避免持久化冗余的 MVCC 墓碑；局部化 compaction 则针对删除密集的键范围进行处理。
6 生命周期感知型存储引擎
- MetaDB 将内存 MVCC 与感知局部性的 compaction 相结合，以应对连续删除导致的墓碑累积，并保障 listdir 范围扫描的延迟。该存储设计针对云对象存储负载中所描述的元数据生命周期量身定制。出处：§6 · p. 7
6.1 内存 MVCC
- MetaDB 在内存中保留已提交版本和 MVCC 墓碑，仅将最新已提交状态刷写到持久存储；删除操作会持久化一个 LSM-tree 墓碑，从而避免磁盘上累积 MVCC 墓碑。这避免了双重墓碑开销并降低读放大；内存表在超过 5 秒的事务超时后仍会保留一段时间再刷写；若节点在持久化前发生故障，则可利用 Raft 日志条目恢复。出处：§6.1 · p. 7
6.2 感知局部性的压缩
- 连续删除会产生 LSM-tree 墓碑，拖慢 listdir 扫描；MetaDB 会跟踪删除密集的键范围，并在超过阈值后仅对受影响区域主动执行 compaction。这种做法无需等待全局层级饱和，也不必压缩整个分片，即可清理墓碑并维持稳定的范围扫描延迟。出处：§6.2 · p. 7
7 评估
评估结合合成微基准测试和生产轨迹，检验 MetaDB 的设计机制与性能。生产集群测试显示，与通用数据库相比，MetaDB 吞吐量更高、延迟更低。
7.2 树拓扑诱导分片与执行的有效性
- 策略/大小感知分片将吞吐量维持在 6.0K QPS，而大小分片的吞吐量降至 0.4K QPS；在 256 个客户端下，推送执行使延迟降低 33.9%，吞吐量提高 28.8%。单客户端下，推送执行使延迟降低 25.3%，吞吐量提高 10.0%；每个客户端使用独立目录，以避免目录属性锁竞争。出处：Figure 10 · p. 8, §7.2 · p. 8, Figure 11 · p. 8
7.3 语义感知的非关键路径处理的有效性
- 在并发对同一目录执行 mkdir 时，相比基于锁的执行，异步属性聚合的吞吐量提高了 10.7×；在 16K QPS 下，待处理的配额更新意味着更新延迟小于 10 ms。在 120 秒内，队列中的待处理项峰值不到 100 个；配额和索引更新可容忍数分钟的延迟。出处：Figure 12 · p. 8, §7.3 · pp. 8–9, Figure 13 · p. 8
7.4 生命周期感知存储引擎的有效性
- 同时采用两项存储优化时，在持续批量删除期间，墓碑数量保持在 2M 以下，listdir 延迟峰值为 0.7 s。持续删除后，Baseline 和 MEM-MVCC 的 listdir 延迟在 5 s 左右波动；仅采用局部性感知压缩时，延迟保持在 1 s 到 3 s 之间。出处：Figure 14 · p. 9, §7.4 · p. 9, Figure 15 · p. 9
- 内存 MVCC 配置产生的 LSM-tree 写入量约减少 60%，其压缩读取量也低于 Baseline 和 Loc.Comp。Loc.Comp 的压缩读取量最高，因为压缩触发得更频繁。出处：Figure 16 · p. 9, §7.4 · p. 9, Figure 17 · p. 9
7.5 整体性能压力测试
- 在包含五种元数据操作的生产集群测试中，相比 GP-DB，吞吐量提高了 2.2×–4.1×，延迟降低了 23.1%–75.0%。测试使用了一个包含 10 个 BE 节点的集群、20 个各运行 50 个线程的客户端，以及 mdtest。出处：Figure 18 · p. 10, §7.5 · p. 10
7.6 MetaDB 生产部署
- 九个有代表性的部署涵盖 BOS、CFS 和 Mantle；BOS 最大集群约有 ∼500 个节点、1.3 to 1.8 trillion 条记录，峰值读 QPS 为 2M、写 QPS 为 0.7M。部署表汇总了九个有代表性的 MetaDB 部署。出处：Table 1 · p. 10, §7.6 · p. 10
- 四个 Mantle 和 CFS 集群中，涉及多个分片的目录修改事务占比从 100% 降至 0.79%–4.37%。Mantle 中剩余的多分片事务占比更高，因为路径解析会使用其他分片上的额外索引项；CFS 中的此类事务来自跨目录重命名。出处：Table 2 · p. 10, §7.6 · p. 10
- 在一个删除吞吐量较高的 BOS 节点上，墓碑数量峰值约为 ∼6M，且在 3M 左右波动；生产环境中的 listdir 延迟从约 8–18 ms 降至 0.5–4 ms。生产环境延迟观测覆盖两个 CFS 集群、共 21 天，并非旨在进行严格的性能比较。出处：Figure 19 · p. 10, §7.6 · pp. 10–11, Figure 20 · p. 11
8 经验与教训
MetaDB 的实践表明，应在受控范围内将目录语义与数据库能力集成，同时保持实现聚焦、管理可扩展。
解耦还是受控耦合？
- 通过内部表和原生事务集成目录索引，取代了跨系统两阶段提交，并复用了数据库的复制与恢复机制。此前的分离式架构还需要自行实现复制、故障检测和恢复；集成让一支十人团队节省了约六个月的工作。出处：§8 · p. 11
从头构建还是改造通用分布式数据库？
- MetaDB 基于 RocksDB 从头构建，而非深度改造大型通用数据库，最终代码库约有 ∼150K 行。这种取舍意味着需要自行实现通用数据库已有的一些功能；作者表示，由于元数据需求和访问模式变化不大，这项成本一直可控。出处：§8 · p. 11
SQL 接口还是专用 API？
- 轻量级直接执行框架将 ∼20 种固定 SQL 模式映射到存储路径，从而避免完整的通用 SQL 处理流程。保留 SQL 接口也简化了存储服务向 MetaDB 的迁移。出处：§8 · p. 11
单层管理器还是两层管理？中心服务：简单性还是可用性？
- 各自配备本地管理器的独立 Cell 将分片心跳和调度移出全局管理器；MetaCache 和混合逻辑时钟则用于应对中心服务风险。MetaCache 提供路由查询；时钟让各节点可在本地生成时间戳，无需依赖会阻塞写入的 TSO。出处：§8 · pp. 11–12
9 相关工作
相关工作涉及分布式文件系统元数据服务、数据库支撑的元数据系统，以及异步索引和 LSM-tree 删除技术。
分布式元数据管理
- 分布式元数据系统按子树或目录放置元数据、拆分大型目录、分离目录与文件元数据，或将父子元数据共置。示例包括 CephFS 、Lustre DNE 、IndexFS 、LocoFS 和 InfiniFS 。出处：§9 · p. 12
分布式元数据管理；分布式数据库；异步辅助元数据维护
- 数据库支撑的系统在事务和分片选择上各不相同；MetaDB 围绕元数据语义专门设计分片、事务处理和存储行为。HopsFS [31] 使用行锁和两阶段提交；Tectonic 不保证跨目录重命名的原子性。以往的异步索引工作 主要关注索引或可扩展性，不同于 MetaDB 对事务路径的重构。出处：§9 · p. 12
基于 LSM-tree 的 KV 存储删除
- 以往的删除方法采用延迟上限或保留窗口，而 MetaDB 按密度定位删除热点，以避免由时间驱动的压实开销。所引述的保留策略 需要对存储引擎进行侵入式修改，并导致较高的写放大； 讨论了标记删除对 LSM-tree 的影响。出处：§9 · p. 12
10 结论
MetaDB 围绕文件系统元数据特性共同设计分布式数据库，并报告了生产环境中的性能与效率提升。其结果表明，在数据库内部利用特定工作负载的结构有助于管理元数据。
10 结论
- MetaDB 的吞吐量达到此前通用数据库的 2.2×–4.1×，使生产环境中的元数据机器数量减半，并在持续批量删除期间维持稳定的低延迟范围扫描。论文将利用特定工作负载的结构视为提升存储系统元数据管理性能与效率的关键设计原则。出处：§10 · p. 12
与 TiDB 的性能比较
与 TiDB 相比，MetaDB 在带索引更新的 create 操作和同目录并发 mkdir 操作中吞吐量更高；连续批量删除期间，MetaDB 的 listdir 延迟更低。
与 TiDB 的性能比较
- 带索引更新的 create 操作在 256 个客户端下达到 85.6K QPS，吞吐量是 TiDB 的 2.2×；MetaDB 异步更新索引，而 TiDB 以原子方式更新索引。每个客户端发送四个并发请求。出处：A Performance Comparison with TiDB · p. 16
- 对于修改同一父目录行的并发 mkdir 操作，MetaDB 的峰值吞吐量达到 TiDB 的 36.2×。每个客户端在同一目录下发送四个并发请求。出处：A Performance Comparison with TiDB · p. 16
- 对象删除速率为 5K QPS 时，MetaDB 的 listdir 延迟保持在 0.7 s 以下；TiDB 峰值达到 2.5 s，累计 tombstone 30 分钟后仍处于 1 s 至 2.5 s 之间。出处：A Performance Comparison with TiDB · p. 16