Quickwit元数据存储中Split主键优化方案探讨

在分布式搜索引擎Quickwit的元数据存储设计中，splits表当前使用split_id作为主键(PKEY)。本文深入分析将其修改为复合主键(index_uid, split_id)的技术价值与实现考量。

现有架构分析

当前split_id作为单一主键的设计存在以下特点：

1. 功能完整性：能够保证每个split的唯一性标识
2. 查询模式：实际业务中所有涉及split的操作都同时携带index_uid参数
3. 索引结构：目前依赖indexes表的B-tree索引来加速排序查询

优化方案优势

采用复合主键(index_uid, split_id)将带来多方面提升：

查询性能优化

• 天然支持最常见的查询模式（按index过滤+split操作）
• 消除跨表索引依赖，查询路径更短
• 复合索引可同时满足等值查询和范围查询需求

存储架构演进

• 为未来按index_uid分区(partitioning)奠定基础
• 分区后可以更好地支持超大规模元数据存储
• 符合"数据局部性"原则，相关数据物理相邻

设计一致性

• 与文件式元数据存储的行为保持一致（不强制全局唯一split_id）
• 更贴近实际业务场景的数据访问模式

技术实现考量

迁移安全性

• 数据库层面属于无损变更（满足唯一性约束）
• 不影响现有业务逻辑的正确性
• 兼容现有文件存储的实现方式

性能影响

• 索引体积略微增大（增加index_uid字段）
• 写入性能影响可忽略（仍为单索引维护）
• 读取性能在典型场景会有提升

架构演进展望

该优化为系统扩展性打下重要基础：

1. 分区支持：未来可按index_uid进行水平分片
2. 查询优化：为复杂查询提供更好的索引支持
3. 规模扩展：适应海量索引和split的管理需求

这个改动体现了从"能用"到"好用"的设计演进，是Quickwit元数据存储向生产级系统迈进的重要一步。