TEngineDB-V: An OLAP-Native Vector Search System for Large-$k$ Workloads at Tencent
Xufei Wu, Pengcheng Zhang, Yitong Song, Xiaobo Zhang, Anqi Liang, Kai Wang, Jijun Du, Yidi Xiong, Guangxu Cheng, Zhe Chen, Peng Chen, Guoliang Li, Xuanhe Zhou, Fan Wu
cs.DB
2026-08-01
腾讯把大规模向量检索(k 取 10 的 3 到 5 次方)重写成 OLAP 关系算子,在百亿图片的生产库里把取 10 万条的查询做到 5 秒内,比 StarRocks 最快快 145 倍。
向量检索不只是「找最像的 10 条」了。在腾讯,文生图/视觉模型团队要从 100 亿张图片里一次捞 1 万到 10 万张去拼微调数据集,广告团队要按相似度圈一批图再做聚合统计。这种 k 取 10 的 3 次方到 5 次方的大规模检索,延迟要求比 RAG 宽松,但后面通常还要接过滤、聚合、join,是分析型负载。
现有系统两头不讨好。专用向量库(Milvus、PGVector、ElasticSearch)为了压住尾延迟,普遍把 k 上限卡在 1 万到 1.6 万,分析能力也弱。OLAP 库(StarRocks、Doris)把向量索引当黑盒子按数据段(segment)各建一份,查询要广播到所有段、各自算局部 top-k 再全局归并,这就是 scatter-gather。表被切成 N 段,每段至少取 k 条,结果体量膨胀到 N 乘 k(k=10 万、N=2000 时就是 2 亿条),磁盘 IO、网络、归并开销全部跟着炸。
TEngineDB-V 的核心选择是把向量检索变成 OLAP 引擎里的一等公民算子,分三层重构。
存储层走「段解耦」的全局索引。不再每个段各建一份本地索引,而是用 Spark 给全量数据建一个跨段的全局 IVFPQ 索引,再把它拆成三张关系表:IVF 质心表(按簇 ID 分片)、PQ 码本表(不分片)、量化向量表(按簇 ID 分片)。查询只去探相关的几个簇,成本只跟探簇数挂钩,彻底干掉了 scatter-gather。索引异步刷新、原子切换,容忍最终一致(刷新窗口内删掉的 ID 可能还在,新插入要等下次重建),这正合几天才更新一次的分析负载。
计算层把 IVFPQ 检索拆成一串关系算子:IVF Prune(扫质心表选出最近的 N 个簇)、LUT Compute(扫码本表造距离查表)、Distance Estimate(把查表广播给候选向量累加距离,再 TopK)。拆开之后,延迟物化、join 运行时过滤、列式 FastScan、算子融合这些 OLAP 老本事都能直接用。他们还做了 DPPQ 量化:传统 PQ 最小化欧氏重建误差,而近邻排序其实对方向更敏感,所以 DPPQ 改成最小化角度偏差,再用多层残差逐轮细化。同等比特预算下召回比 PQ 和 RaBitQ 都高,关键是把细化融进了算子里,省掉了大 k 下最贵的原始向量重排阶段(传统做法要重排 2k 到 3k 个候选,大 k 时直接吃掉全部延迟)。
控制层把索引语义喂给基于 Cascades 的优化器。带标量过滤的 FANNS 查询,枚举出 8 个候选执行计划(先过滤还是后过滤、join 的 build/probe 谁来当、广播还是 shuffle),再用一个联合建模 CPU/内存/网络的代价模型选最优,权重设成 0.5、2.0、1.5。
| 设置 | 指标 | TEngineDB-V | 对照 |
| Wikipedia,k=2 万,召回 0.86 | 延迟 | 332ms | 比 Milvus/StarRocks/PGVector/DiskANN 快 2.7/8.9/7.7/50 倍 |
| SIFT1B,召回 0.88 | 延迟 | 208ms | 比 StarRocks/PGVector/DiskANN 快 137/13/105 倍(Milvus 内存溢出跑不了) |
| SIFT1B,k=1 万 | 延迟 | 189ms | 比 StarRocks 快 145.5 倍 |
| 生产 Tencent-Image,100 亿,召回 0.88 | 延迟 | 14.2s | 旧系统 200s、StarRocks 333s、Milvus 56s |
| 生产 Tencent-Image,召回 0.8 | 相对旧系统 | 快 52 倍 | StarRocks 65 倍、Milvus 26 倍 |
DPPQ 在 SIFT1M 上 400 比特/向量时,召回比 PQ 高 4.1 个百分点、比 RaBitQ 高 3.2 个。列式 FastScan 只比行式 FastScan 慢约 5%,比不开 FastScan 快 4 到 5 倍。最大生产集群 30 多个节点、100TB 数据、约 100 亿图向量,top-10 万检索稳定在 5 秒内。
大 k 向量检索正在变成真需求:LLM 数据治理、多模态分析、广告选品都要一次捞一大把再加工。这篇给出的结论是,不必非得外挂一个独立向量库,把向量检索折叠进 OLAP 引擎、写成关系算子,就能和 join、过滤、运行时过滤一起联合优化,还能扩到百亿规模。对任何要搭分析型向量流水线的工程团队,这是一份可直接参考的工业系统设计。要泼一盆冷水:它是为低频更新、最终一致的分析场景设计的,不是实时事务库。
最终一致意味着索引会滞后于底表,删掉的 ID 在窗口期内可能仍被检索到,新插入要等下次重建才可见,对实时性要求高的场景不适用。
实验召回只评到 0.8 到 0.9,因为他们的链路里向量检索只负责粗筛候选,不是最终答案。需要高召回的用法下,优势可能会缩。
代价模型那三个权重(0.5/2.0/1.5)是按自家硬件手调的,换集群不一定照搬。
DPPQ 每个细化轮次每个子空间要多存一个 FP32 缩放因子,细化轮数越多存储涨得越多,论文没给存储开销的完整账。