Quickwit项目中的文档长度计量功能设计与实现

在分布式搜索引擎Quickwit的多租户场景中，资源使用计量是保障服务公平性和商业可持续性的关键需求。本文将深入解析Quickwit团队如何通过创新的文档长度计量功能，实现精确的租户级资源使用统计。

需求背景与挑战

现代搜索引擎服务通常采用多租户架构，不同租户的业务规模和数据特征差异显著。Quickwit用户需要按时间维度（特别是小时粒度）统计各租户的文档存储量，主要面临三大技术挑战：

1. 海量数据处理：系统需支持1000个数据分区和10万级租户规模
2. 实时性要求：计量数据需要准实时可用，延迟过高会影响计费准确性
3. 存储效率：计量系统本身不能占用过多存储资源

技术方案选型

经过多方案对比，Quickwit团队最终采用文档元数据增强方案：

核心设计：在文档映射层(docmapper)新增document_length配置项，启用后自动为每个文档添加_doc_length元字段。该字段记录原始JSON负载的字节长度，采用以下存储特性：

• 数据类型：64位无符号整数(u64)
• 存储形式：仅作为快速字段(fast field)存储
• 索引策略：不建立倒排索引，不存储原始值

方案优势：

1. 查询效率：快速字段支持高效范围聚合查询
2. 存储经济：每个文档仅增加约2字节开销
3. 实现透明：对现有查询逻辑完全无侵入

实现细节

在索引处理流水线中，该功能通过以下环节实现：

1. 文档解析阶段：在JSON反序列化后立即计算payload字节长度
2. 字段映射阶段：将长度值注入文档元数据字段
3. 索引构建阶段：将_doc_length作为特殊字段处理，跳过常规的索引和存储流程

查询时可通过聚合API实现租户维度的存储量统计：

{
  "query": "...",
  "aggs": {
    "tenant_usage": {
      "terms": {"field": "tenant_id"},
      "aggs": {
        "total_bytes": {"sum": {"field": "_doc_length"}}
      }
    }
  }
}

替代方案对比

团队曾考虑过其他两种方案：

1. 日志采集方案：通过索引器日志输出计量数据

   • 优点：实现简单
   • 缺点：数据一致性难保证，延迟高

2. 分片级聚合方案：在split元数据中记录统计值

   • 优点：查询效率极高
   • 缺点：无法支持灵活的时间粒度分析

最终文档长度方案在灵活性、准确性和性能之间取得了最佳平衡。

应用场景扩展

虽然当前设计主要面向计费场景，但该功能还可支持：

• 租户资源配额管理
• 异常流量检测
• 存储优化分析

未来可通过开放更多时间粒度参数和统计维度，进一步扩展其应用价值。该功能的实现体现了Quickwit在满足核心搜索能力的同时，对运维管理需求的深度考量。

注：本文基于Quickwit项目技术讨论整理，相关实现细节可能随版本演进调整。