SmithDB中的全文搜索：为对象存储设计倒排索引

SmithDB支持对代理追踪进行全文搜索和JSON过滤，中位延迟仅为400毫秒，尽管其底层数据是存储在对象存储中的大型嵌套JSON文档。这一性能得益于为对象存储量身定制的倒排索引设计。

代理追踪数据具有独特特征：每个事件的输入和输出字段占绝大多数字节，常见payload大小超过1MB，甚至达到数百MB。此外，随着LLM上下文窗口增大和代理运行时间延长，payload持续增长。这导致传统搜索索引的经济性被颠覆——文档极大，索引与源数据比例高达1:1.9。同时，词频遵循Zipfian分布，少数高频词出现频率极高，而长尾词仅出现一两次。查询模式包括路径存在（json_key）、键值搜索（json_key_search）和全文搜索（search），每种模式对索引有不同的要求。

对象存储的约束使得索引设计必须最小化请求次数。传统搜索引擎如Tantivy基于mmap，假设随机I/O廉价，不适合对象存储约100ms的往返延迟。SmithDB的搜索引擎集成在基于Vortex的列式引擎中，要求doc ID与Vortex行索引对齐。

第一个版本的索引直接使用Vortex默认编码，将术语和值存储为两列，但遇到了问题：没有按术语的编码控制，导致高频词迫使整个列使用更宽的位宽；行组基于固定术语数量，导致大小严重不均；合并时需要解压并重组位置列表，成本高昂。

第二个版本改变了组织单元：从“每个行组N个术语”变为按字节预算划分行组，并自定义每列的字节布局。每个行组占用相近的字节数，由术语频率决定，而非术语数量。位置列表采用紧凑的位编码，并为高频词保留额外空间。合并时只需连接段切片，无需重新计算偏移量。这显著减少了对象存储请求和合并成本。

目前，SmithDB的倒排索引在生产环境中处理数百万文档，P50延迟维持400ms。未来计划包括支持更复杂的短语查询和进一步优化压缩。