摘要针对大模型应用中专用向量库成本高、混合查询难的痛点本文深入拆解 Apache Doris 4.1 原生向量检索的工程实践。从 IVF 算法降本、存储分层到突破性能瓶颈的 ANN Index Only Scan系统化解决 AI 时代的海量数据存算难题。在大幅压低内存开销的同时跑出了 900 QPS 与 97% 召回率的亮眼成绩。随着大语言模型LLM应用与 RAG检索增强生成逐步深入开发者意识到把向量存下来并搜出来并不难难的是如何控制 TB 级数据的内存成本以及如何让向量与现有的结构化业务数据无缝联动。在这背景下 ANN 向量检索不再是新奇设计而是与过滤、连接、聚合一样成为数据系统的基础能力。那么向量索引应当被部署到哪里需要多少成本来实现当前行业里主要存在三条实现路径。本文将从这三条路径出发聊聊为什么 Apache Doris 及其商业化引擎 SelectDB 选择了原生集成这条路以及它在工程层面到底做了哪些事情。专用向量数据库Milvus、Qdrant、Pinecone从底层围绕 ANN 构建针对纯向量检索深度优化。代价是它会成为现有数据栈之外的独立系统应用层需要自行处理数据一致性、联合查询及跨系统运维。关系型数据库扩展 pgvector、MySQL HeatWave Vector嵌入事务数据库内部部署门槛低。但底层存储和索引并非为大规模向量负载设计扩展性与并发能力很快会触及天花板。分析型数据库原生支持Elasticsearch Dense Vector、ClickHouse ANN、Apache Doris 向量索引直接复用 OLAP 引擎已有的列式存储、分布式执行和向量化计算能力天然适合向量与结构化过滤相结合的混合查询。工程难点在于将 ANN 与执行引擎深度融合而非仅停留在功能可用的层面。本文重点讨论的正是 Apache Doris 4.1 在第三条路径上的工程实践。成本是第一工程问题IVF比 HNSW 更低内存占用、查询更快向量检索的内存消耗并非仅来自向量本身。以 100 万个 768 维float32向量为例原始数据约 3 GB1,000,000 × 768 × 4。而 ANN 索引还会额外占用大量内存。主流算法 HNSW分层可导航小世界采用分层图结构能在对数级复杂度下实现高召回率适合中小规模场景但它的图结构必须常驻内存。在常用参数M16efConstruction200下索引内存约为原始数据的 2 倍。若扩展到 10 亿向量内存占用将接近 1 TB。系统虽能运行但如此高的部署成本大多数团队难以接受。当 HNSW 的内存成本变得不可接受行业通常转向 IVFInverted File Index。IVF 的核心思想很直观构建阶段先对所有向量做 K-Means 聚类生成nlist个中心点每个向量归到最近的簇相当于把整个向量空间划分成很多桶查询阶段先找到最接近查询向量的几个桶由nprobe控制只在这些桶里计算距离从而避免全局扫描。代价是召回率会略有下降但查询速度和内存占用都能大幅改善。更关键的是IVF 不需要把完整的图结构常驻内存这为后续的磁盘分层打下了基础。Apache Doris 在 4.0 版本引入了 HNSW4.1 版本新增了 IVF用于支撑更大规模的数据集。DDL 如下CREATE TABLE vecs ( id BIGINT NOT NULL, embedding ARRAYFLOAT NOT NULL, INDEX idx_emb (embedding) USING ANN PROPERTIES ( index_type ivf, metric_type l2_distance, dim 768, nlist 1024 ) ) ENGINEOLAP DUPLICATE KEY(id) DISTRIBUTED BY HASH(id) BUCKETS 8 PROPERTIES (replication_num 1);其中nlist是聚类桶数量nprobe是查询时扫描的桶数且nprobe可以动态调整同一套索引就能在召回率和延迟之间实时平衡。IVF_ON_DISK冷热分层存储降低成本即使 IVF 大幅降低了索引开销向量数据本身的体积仍然会线性增长。10 亿个 768 维 float32 向量约 3TB仅向量数据就已经是 TB 级。行业对此的标准答案是存储分层热桶放内存、冷桶放磁盘、内存只保留导航结构。微软的 DiskANNNeurIPS 2019和 SPANNNeurIPS 2021都是这一方向的代表性工作。Doris 4.1 的IVF_ON_DISK基本遵循 SPANN 的设计思路。内存中保存聚类中心和热数据缓存磁盘中保存倒排列表和向量数据。查询时热数据直接命中缓存冷数据按需从 SSD 读取从而在普通商用机器上支持十亿级向量检索。DDL 本质上与普通 IVF 相同只是索引类型不同。其中nlist通常会随着数据集的增大而增大以控制平均桶的大小。CREATE TABLE vecs_large ( id BIGINT NOT NULL, embedding ARRAYFLOAT NOT NULL, INDEX idx_emb (embedding) USING ANN PROPERTIES ( index_type ivf_on_disk, metric_type l2_distance, dim 768, nlist 4096 ) ) ENGINEOLAP DUPLICATE KEY(id) DISTRIBUTED BY HASH(id) BUCKETS 32 PROPERTIES (replication_num 1);听起来磁盘索引似乎要比内存索引慢得多。实则并非如此向量查询具有明显的局部性相邻查询往往命中相同的簇热点数据的缓存命中率很高实际 I/O 远低于全量扫描。在合理的缓存策略下IVF_ON_DISK的 QPS 可以非常接近纯内存 IVF。量化手段压缩向量本身进一步降低成本存储分层核心是以磁盘容量换取内存预算总资源使用有效减少但向量本身依旧很大。因此需要通过向量量化进一步压缩向量本身。常见的做法有两种标量量化 SQScalar Quantization把 float32 转成 int8 或 int4压缩率分别约 4 倍和 8 倍实现简单乘积量化 PQProduct Quantization将向量切成多个子向量分别聚类编码最终只存编码 ID压缩率非常高且可调节这也是 PQ 常见于大模型向量检索系统中的主要原因。Doris 4.1 支持以上所有类型并允许将他们构建于IVF_ON_DISK之上 。本文主要展示 PQ配置示例如下CREATE TABLE vecs_pq ( id BIGINT NOT NULL, embedding ARRAYFLOAT NOT NULL, INDEX idx_emb (embedding) USING ANN PROPERTIES ( index_type ivf_on_disk, metric_type l2_distance, dim 768, nlist 4096, quantizer pq, pq_m 64, pq_nbits 8 ) ) ENGINEOLAP DUPLICATE KEY(id) DISTRIBUTED BY HASH(id) BUCKETS 32 PROPERTIES (replication_num 1);对于 768 维向量原始大小 3072 字节PQ 压缩后约 64 字节压缩比接近 48 倍。查询性能更不可忽视存储分层和量化技术解决了空间与成本问题但在实际生产环境中查询性能往往更不可忽视。在实现了低成本存储之后如何进一步优化检索速度、提升系统吞吐是另一个需要攻克的瓶颈。ANN Index Only Scan900 QPS、97% 召回率ANN 查询真正的性能瓶颈往往不在选桶和排序而在于读取原始向量列。在列式数据库中这本质上是随机 I/O。Doris 4.1 对此的优化思路类似关系数据库的覆盖索引如果查询只需要 ID 和距离值就不必回表读取原始向量直接利用索引中的向量或量化向量完成距离计算即可。这就是 Doris 4.1 引入的 ANN Index Only Scan。在官方测试中100 万向量、768 维、TopK-10 近邻查询这一优化最终达到 900 QPS、97% 召回率整体性能相比 Standard Path 提升约 4 倍。混合检索向量检索与其他检索结合解决了底层存储和单列检索的成本与性能问题后应用层面临的最大挑战往往是复杂的真实查询场景。纯向量检索在实际生产中很少单独出现。大多数场景会在向量相似度之上叠加其他检索维度主要有两种模式结构化过滤联合查询。向量相似度与类别、价格、时间、权限等布尔或范围条件结合使用。典型场景包括电商的相似商品推荐、内容平台的关联推荐以及 RAG 中按租户或时间窗口切片检索。多路召回融合排序。向量召回与 BM25 文本搜索、行为召回、规则召回等通道联合排序。典型场景包括搜索引擎的混合检索以及 RAG 管道中的检索质量优化。结构化过滤联合查询专用向量数据库在处理这类查询时通常有两种做法但都不理想后过滤先向量召回再过滤可能导致过滤后结果数量不够如果过滤器通过率为 30%实际返回的只有K × 30%行前过滤先过滤再向量检索会让 ANN 索引结构失效退化为暴力扫描延迟也会随候选集大小线性增长。这正是 Apache Doris 原生向量索引的价值所在。查询优化器能够根据谓词选择性、索引可用性和代价估算自动在预过滤与后过滤之间做出决策应用层无需提前选择策略。以一个商品表为例表中同时存储商品元数据和视觉 Embedding。查询目标在运动鞋类别中找到 20 个有库存、价格在 50~200 元之间、且与参考商品视觉最相似的商品。SELECT id, name, price, l2_distance(embedding, [0.12, 0.08, ..., 0.31]) AS distance FROM products WHERE category sneakers AND in_stock TRUE AND price BETWEEN 50 AND 200 ORDER BY l2_distance(embedding, [0.12, 0.08, ..., 0.31]) LIMIT 20;执行时优化器根据选择性自动选择路径若结构化条件过滤后候选集远小于nprobe × 平均桶大小则先过滤再在子集上计算精确距离若过滤选择性低则先走向量索引再对结果施加过滤。整个流程封装在一条 SQL 中应用层既不需要硬编码预/后过滤策略也不需要维护跨系统的数据同步。多路召回融合排序多路召回融合面临的问题与过滤不同核心难点不在于逻辑放在哪里而在于如何合并度量单位完全不同的分数。最典型的场景是文本搜索与向量检索的融合。用户输入查询时系统既要返回关键词匹配结果倒排索引 BM25也要返回语义相关但可能不含关键词的结果向量索引 距离。两个通道的分数尺度完全不同BM25 与 L2 距离之间不存在可直接加权的基础。业界常用的方案是 RRFReciprocal Rank Fusion。RRF 不对原始分数做归一化而是只取每个结果在各通道中的排名将倒数1 / (k rank)求和作为最终得分。无需分数归一化、对离群值鲁棒、且易于扩展新的召回源因此在近年的混合检索实践中被广泛采用。在 Apache Doris 中整个融合流程可以用一条 SQL 完成。以下示例在 HackerNews 数据集上用 RRF 融合 BM25 文本搜索与 ANN 向量检索WITH text_raw AS ( SELECT id, score() AS bm25 FROM hackernews WHERE (text MATCH_PHRASE hybrid search OR title MATCH_PHRASE hybrid search) AND dead 0 AND deleted 0 ORDER BY score() DESC LIMIT 1000 ), vec_raw AS ( SELECT id, l2_distance_approximate(vector, [0.12, 0.08, ...]) AS dist FROM hackernews ORDER BY dist ASC LIMIT 1000 ), text_rank AS ( SELECT id, ROW_NUMBER() OVER (ORDER BY bm25 DESC) AS r_text FROM text_raw ), vec_rank AS ( SELECT id, ROW_NUMBER() OVER (ORDER BY dist ASC) AS r_vec FROM vec_raw ), fused AS ( SELECT id, SUM(1.0 / (60 rank)) AS rrf_score FROM ( SELECT id, r_text AS rank FROM text_rank UNION ALL SELECT id, r_vec AS rank FROM vec_rank ) t GROUP BY id ORDER BY rrf_score DESC LIMIT 20 ) SELECT f.id, h.title, h.text, f.rrf_score FROM fused f JOIN hackernews h ON h.id f.id ORDER BY f.rrf_score DESC;执行路径分为四步倒排索引与 ANN 索引并行执行 BM25 和 L2 距离召回各取 Top-N对两组结果按原始分数局部排序并分配排名将每个候选在各通道的排名贡献1 / (k rank)求和得出最终得分仅对最终 Top-K 结果回表读取展示字段避免中间步骤扫描宽列。将融合放在 SQL 层的价值不在算法本身RF 在任何地方都能实现。真正的收益在于两个检索通道共享同一份数据、同一套事务可见性和同一套生命周期管理。需要扩展第三路召回按类别、时间或用户画像加权时只需新增一个 CTE无需引入额外系统。公开基准与选型参考根据 VectorDBBench100 万 × 768 维2026 年 1 月的公开测试数据主流向量检索系统的表现如下按 QPS 排序。注各系统的硬件规格并不统一。OpenSearch 运行在 16c128gpgvector 运行在 2c8gWeaviate Cloud 和 S3Vectors 为托管服务、由平台选定规格。行与行之间的对比需考虑这一差异。对比总结加载时长索引构建 Doris 4.1397 秒在本表中最快比 Milvus HNSW581.8 秒快约 30%比 pgvector10250 秒快一个数量级以上。这一指标对批量冷启动、Embedding 模型变更后的索引重建以及历史数据回填尤为关键。QPS查询吞吐 Milvus 和 Qdrant 领先超过 1200。Doris 4.1895与 OpenSearch950.6处于同一梯队。召回率Weaviate Cloud 两种配置0.9910 / 0.9909领先Milvus、Doris、Qdrant 处于第二梯队均高于 0.94满足绝大多数生产级要求。从数据中可以发现高 QPS 往往伴随较低召回率高召回率往往伴随较低 QPS。Doris 4.1 以构建速度领先、QPS 和召回率均处于中高水平提供了另一种极佳的权衡组合。不过基准测试数据只有在匹配实际工作负载时才有意义。比如频繁重建索引场景应重点关注加载时长对 p99 延迟或召回率下限有硬性要求则需在目标运行点上做针对性压测…结合以上三个维度可以做如下粗略映射结束语过去几年向量数据库经历了快速爆发期。但随着 AI 应用真正进入生产环境行业逐渐意识到真正困难的并不是把向量搜出来而是如何与结构化数据协同、如何降低系统复杂度、如何控制 TB 级资源成本、以及如何统一 SQL、全文、向量与分析能力。越来越多的分析型数据库开始原生集成向量能力向量检索正在从独立系统重新回归数据库体系。Apache Doris 4.1 的方向正是这一趋势演进的缩影。当向量检索成为 SQL 的原生能力开发者终于可以把精力重新集中在业务创新上而不是复杂的系统运维上。本文相关参考Apache Doris 4.1下载https://doris.apache.org/download/向量索引文档https://doris.apache.org/docs/4.x/table-design/index/vector-index/overview前往 SelectDB 官网申请云服务免费试用https://www.selectdb.com/
97% 召回率、900 QPS：Apache Doris 4.1 生产级向量检索的工程实践
摘要针对大模型应用中专用向量库成本高、混合查询难的痛点本文深入拆解 Apache Doris 4.1 原生向量检索的工程实践。从 IVF 算法降本、存储分层到突破性能瓶颈的 ANN Index Only Scan系统化解决 AI 时代的海量数据存算难题。在大幅压低内存开销的同时跑出了 900 QPS 与 97% 召回率的亮眼成绩。随着大语言模型LLM应用与 RAG检索增强生成逐步深入开发者意识到把向量存下来并搜出来并不难难的是如何控制 TB 级数据的内存成本以及如何让向量与现有的结构化业务数据无缝联动。在这背景下 ANN 向量检索不再是新奇设计而是与过滤、连接、聚合一样成为数据系统的基础能力。那么向量索引应当被部署到哪里需要多少成本来实现当前行业里主要存在三条实现路径。本文将从这三条路径出发聊聊为什么 Apache Doris 及其商业化引擎 SelectDB 选择了原生集成这条路以及它在工程层面到底做了哪些事情。专用向量数据库Milvus、Qdrant、Pinecone从底层围绕 ANN 构建针对纯向量检索深度优化。代价是它会成为现有数据栈之外的独立系统应用层需要自行处理数据一致性、联合查询及跨系统运维。关系型数据库扩展 pgvector、MySQL HeatWave Vector嵌入事务数据库内部部署门槛低。但底层存储和索引并非为大规模向量负载设计扩展性与并发能力很快会触及天花板。分析型数据库原生支持Elasticsearch Dense Vector、ClickHouse ANN、Apache Doris 向量索引直接复用 OLAP 引擎已有的列式存储、分布式执行和向量化计算能力天然适合向量与结构化过滤相结合的混合查询。工程难点在于将 ANN 与执行引擎深度融合而非仅停留在功能可用的层面。本文重点讨论的正是 Apache Doris 4.1 在第三条路径上的工程实践。成本是第一工程问题IVF比 HNSW 更低内存占用、查询更快向量检索的内存消耗并非仅来自向量本身。以 100 万个 768 维float32向量为例原始数据约 3 GB1,000,000 × 768 × 4。而 ANN 索引还会额外占用大量内存。主流算法 HNSW分层可导航小世界采用分层图结构能在对数级复杂度下实现高召回率适合中小规模场景但它的图结构必须常驻内存。在常用参数M16efConstruction200下索引内存约为原始数据的 2 倍。若扩展到 10 亿向量内存占用将接近 1 TB。系统虽能运行但如此高的部署成本大多数团队难以接受。当 HNSW 的内存成本变得不可接受行业通常转向 IVFInverted File Index。IVF 的核心思想很直观构建阶段先对所有向量做 K-Means 聚类生成nlist个中心点每个向量归到最近的簇相当于把整个向量空间划分成很多桶查询阶段先找到最接近查询向量的几个桶由nprobe控制只在这些桶里计算距离从而避免全局扫描。代价是召回率会略有下降但查询速度和内存占用都能大幅改善。更关键的是IVF 不需要把完整的图结构常驻内存这为后续的磁盘分层打下了基础。Apache Doris 在 4.0 版本引入了 HNSW4.1 版本新增了 IVF用于支撑更大规模的数据集。DDL 如下CREATE TABLE vecs ( id BIGINT NOT NULL, embedding ARRAYFLOAT NOT NULL, INDEX idx_emb (embedding) USING ANN PROPERTIES ( index_type ivf, metric_type l2_distance, dim 768, nlist 1024 ) ) ENGINEOLAP DUPLICATE KEY(id) DISTRIBUTED BY HASH(id) BUCKETS 8 PROPERTIES (replication_num 1);其中nlist是聚类桶数量nprobe是查询时扫描的桶数且nprobe可以动态调整同一套索引就能在召回率和延迟之间实时平衡。IVF_ON_DISK冷热分层存储降低成本即使 IVF 大幅降低了索引开销向量数据本身的体积仍然会线性增长。10 亿个 768 维 float32 向量约 3TB仅向量数据就已经是 TB 级。行业对此的标准答案是存储分层热桶放内存、冷桶放磁盘、内存只保留导航结构。微软的 DiskANNNeurIPS 2019和 SPANNNeurIPS 2021都是这一方向的代表性工作。Doris 4.1 的IVF_ON_DISK基本遵循 SPANN 的设计思路。内存中保存聚类中心和热数据缓存磁盘中保存倒排列表和向量数据。查询时热数据直接命中缓存冷数据按需从 SSD 读取从而在普通商用机器上支持十亿级向量检索。DDL 本质上与普通 IVF 相同只是索引类型不同。其中nlist通常会随着数据集的增大而增大以控制平均桶的大小。CREATE TABLE vecs_large ( id BIGINT NOT NULL, embedding ARRAYFLOAT NOT NULL, INDEX idx_emb (embedding) USING ANN PROPERTIES ( index_type ivf_on_disk, metric_type l2_distance, dim 768, nlist 4096 ) ) ENGINEOLAP DUPLICATE KEY(id) DISTRIBUTED BY HASH(id) BUCKETS 32 PROPERTIES (replication_num 1);听起来磁盘索引似乎要比内存索引慢得多。实则并非如此向量查询具有明显的局部性相邻查询往往命中相同的簇热点数据的缓存命中率很高实际 I/O 远低于全量扫描。在合理的缓存策略下IVF_ON_DISK的 QPS 可以非常接近纯内存 IVF。量化手段压缩向量本身进一步降低成本存储分层核心是以磁盘容量换取内存预算总资源使用有效减少但向量本身依旧很大。因此需要通过向量量化进一步压缩向量本身。常见的做法有两种标量量化 SQScalar Quantization把 float32 转成 int8 或 int4压缩率分别约 4 倍和 8 倍实现简单乘积量化 PQProduct Quantization将向量切成多个子向量分别聚类编码最终只存编码 ID压缩率非常高且可调节这也是 PQ 常见于大模型向量检索系统中的主要原因。Doris 4.1 支持以上所有类型并允许将他们构建于IVF_ON_DISK之上 。本文主要展示 PQ配置示例如下CREATE TABLE vecs_pq ( id BIGINT NOT NULL, embedding ARRAYFLOAT NOT NULL, INDEX idx_emb (embedding) USING ANN PROPERTIES ( index_type ivf_on_disk, metric_type l2_distance, dim 768, nlist 4096, quantizer pq, pq_m 64, pq_nbits 8 ) ) ENGINEOLAP DUPLICATE KEY(id) DISTRIBUTED BY HASH(id) BUCKETS 32 PROPERTIES (replication_num 1);对于 768 维向量原始大小 3072 字节PQ 压缩后约 64 字节压缩比接近 48 倍。查询性能更不可忽视存储分层和量化技术解决了空间与成本问题但在实际生产环境中查询性能往往更不可忽视。在实现了低成本存储之后如何进一步优化检索速度、提升系统吞吐是另一个需要攻克的瓶颈。ANN Index Only Scan900 QPS、97% 召回率ANN 查询真正的性能瓶颈往往不在选桶和排序而在于读取原始向量列。在列式数据库中这本质上是随机 I/O。Doris 4.1 对此的优化思路类似关系数据库的覆盖索引如果查询只需要 ID 和距离值就不必回表读取原始向量直接利用索引中的向量或量化向量完成距离计算即可。这就是 Doris 4.1 引入的 ANN Index Only Scan。在官方测试中100 万向量、768 维、TopK-10 近邻查询这一优化最终达到 900 QPS、97% 召回率整体性能相比 Standard Path 提升约 4 倍。混合检索向量检索与其他检索结合解决了底层存储和单列检索的成本与性能问题后应用层面临的最大挑战往往是复杂的真实查询场景。纯向量检索在实际生产中很少单独出现。大多数场景会在向量相似度之上叠加其他检索维度主要有两种模式结构化过滤联合查询。向量相似度与类别、价格、时间、权限等布尔或范围条件结合使用。典型场景包括电商的相似商品推荐、内容平台的关联推荐以及 RAG 中按租户或时间窗口切片检索。多路召回融合排序。向量召回与 BM25 文本搜索、行为召回、规则召回等通道联合排序。典型场景包括搜索引擎的混合检索以及 RAG 管道中的检索质量优化。结构化过滤联合查询专用向量数据库在处理这类查询时通常有两种做法但都不理想后过滤先向量召回再过滤可能导致过滤后结果数量不够如果过滤器通过率为 30%实际返回的只有K × 30%行前过滤先过滤再向量检索会让 ANN 索引结构失效退化为暴力扫描延迟也会随候选集大小线性增长。这正是 Apache Doris 原生向量索引的价值所在。查询优化器能够根据谓词选择性、索引可用性和代价估算自动在预过滤与后过滤之间做出决策应用层无需提前选择策略。以一个商品表为例表中同时存储商品元数据和视觉 Embedding。查询目标在运动鞋类别中找到 20 个有库存、价格在 50~200 元之间、且与参考商品视觉最相似的商品。SELECT id, name, price, l2_distance(embedding, [0.12, 0.08, ..., 0.31]) AS distance FROM products WHERE category sneakers AND in_stock TRUE AND price BETWEEN 50 AND 200 ORDER BY l2_distance(embedding, [0.12, 0.08, ..., 0.31]) LIMIT 20;执行时优化器根据选择性自动选择路径若结构化条件过滤后候选集远小于nprobe × 平均桶大小则先过滤再在子集上计算精确距离若过滤选择性低则先走向量索引再对结果施加过滤。整个流程封装在一条 SQL 中应用层既不需要硬编码预/后过滤策略也不需要维护跨系统的数据同步。多路召回融合排序多路召回融合面临的问题与过滤不同核心难点不在于逻辑放在哪里而在于如何合并度量单位完全不同的分数。最典型的场景是文本搜索与向量检索的融合。用户输入查询时系统既要返回关键词匹配结果倒排索引 BM25也要返回语义相关但可能不含关键词的结果向量索引 距离。两个通道的分数尺度完全不同BM25 与 L2 距离之间不存在可直接加权的基础。业界常用的方案是 RRFReciprocal Rank Fusion。RRF 不对原始分数做归一化而是只取每个结果在各通道中的排名将倒数1 / (k rank)求和作为最终得分。无需分数归一化、对离群值鲁棒、且易于扩展新的召回源因此在近年的混合检索实践中被广泛采用。在 Apache Doris 中整个融合流程可以用一条 SQL 完成。以下示例在 HackerNews 数据集上用 RRF 融合 BM25 文本搜索与 ANN 向量检索WITH text_raw AS ( SELECT id, score() AS bm25 FROM hackernews WHERE (text MATCH_PHRASE hybrid search OR title MATCH_PHRASE hybrid search) AND dead 0 AND deleted 0 ORDER BY score() DESC LIMIT 1000 ), vec_raw AS ( SELECT id, l2_distance_approximate(vector, [0.12, 0.08, ...]) AS dist FROM hackernews ORDER BY dist ASC LIMIT 1000 ), text_rank AS ( SELECT id, ROW_NUMBER() OVER (ORDER BY bm25 DESC) AS r_text FROM text_raw ), vec_rank AS ( SELECT id, ROW_NUMBER() OVER (ORDER BY dist ASC) AS r_vec FROM vec_raw ), fused AS ( SELECT id, SUM(1.0 / (60 rank)) AS rrf_score FROM ( SELECT id, r_text AS rank FROM text_rank UNION ALL SELECT id, r_vec AS rank FROM vec_rank ) t GROUP BY id ORDER BY rrf_score DESC LIMIT 20 ) SELECT f.id, h.title, h.text, f.rrf_score FROM fused f JOIN hackernews h ON h.id f.id ORDER BY f.rrf_score DESC;执行路径分为四步倒排索引与 ANN 索引并行执行 BM25 和 L2 距离召回各取 Top-N对两组结果按原始分数局部排序并分配排名将每个候选在各通道的排名贡献1 / (k rank)求和得出最终得分仅对最终 Top-K 结果回表读取展示字段避免中间步骤扫描宽列。将融合放在 SQL 层的价值不在算法本身RF 在任何地方都能实现。真正的收益在于两个检索通道共享同一份数据、同一套事务可见性和同一套生命周期管理。需要扩展第三路召回按类别、时间或用户画像加权时只需新增一个 CTE无需引入额外系统。公开基准与选型参考根据 VectorDBBench100 万 × 768 维2026 年 1 月的公开测试数据主流向量检索系统的表现如下按 QPS 排序。注各系统的硬件规格并不统一。OpenSearch 运行在 16c128gpgvector 运行在 2c8gWeaviate Cloud 和 S3Vectors 为托管服务、由平台选定规格。行与行之间的对比需考虑这一差异。对比总结加载时长索引构建 Doris 4.1397 秒在本表中最快比 Milvus HNSW581.8 秒快约 30%比 pgvector10250 秒快一个数量级以上。这一指标对批量冷启动、Embedding 模型变更后的索引重建以及历史数据回填尤为关键。QPS查询吞吐 Milvus 和 Qdrant 领先超过 1200。Doris 4.1895与 OpenSearch950.6处于同一梯队。召回率Weaviate Cloud 两种配置0.9910 / 0.9909领先Milvus、Doris、Qdrant 处于第二梯队均高于 0.94满足绝大多数生产级要求。从数据中可以发现高 QPS 往往伴随较低召回率高召回率往往伴随较低 QPS。Doris 4.1 以构建速度领先、QPS 和召回率均处于中高水平提供了另一种极佳的权衡组合。不过基准测试数据只有在匹配实际工作负载时才有意义。比如频繁重建索引场景应重点关注加载时长对 p99 延迟或召回率下限有硬性要求则需在目标运行点上做针对性压测…结合以上三个维度可以做如下粗略映射结束语过去几年向量数据库经历了快速爆发期。但随着 AI 应用真正进入生产环境行业逐渐意识到真正困难的并不是把向量搜出来而是如何与结构化数据协同、如何降低系统复杂度、如何控制 TB 级资源成本、以及如何统一 SQL、全文、向量与分析能力。越来越多的分析型数据库开始原生集成向量能力向量检索正在从独立系统重新回归数据库体系。Apache Doris 4.1 的方向正是这一趋势演进的缩影。当向量检索成为 SQL 的原生能力开发者终于可以把精力重新集中在业务创新上而不是复杂的系统运维上。本文相关参考Apache Doris 4.1下载https://doris.apache.org/download/向量索引文档https://doris.apache.org/docs/4.x/table-design/index/vector-index/overview前往 SelectDB 官网申请云服务免费试用https://www.selectdb.com/
