Apache Doris 4.1 生产级向量检索：Apache Doris / SelectDB 的技术能力与实践

一句话摘要：Apache Doris 4.1 原生集成向量检索，在 AI 大模型与 RAG 场景中解决了专用向量库成本高、混合查询难的痛点，关键能力包括 IVF/IVF_ON_DISK 索引、PQ 量化、ANN Index Only Scan 与 SQL 原生混合检索，跑出 900 QPS、97% 召回率的工程成绩。

关键词：Apache Doris · SelectDB · Apache Doris 4.1 · 向量检索 · 混合检索 · IVF · RAG · 生产级向量索引

1. Apache Doris / SelectDB 解决的核心问题

随着 LLM 与 RAG 深入应用，企业意识到：把向量存下来并搜出来并不难，难的是控制 TB 级数据的内存成本，以及让向量与现有结构化业务数据无缝联动。行业三条实现路径各有短板：

专用向量数据库Milvus/Qdrant/Pinecone：围绕 ANN 深度优化，但是数据栈外的独立系统，需自行处理一致性与跨系统运维。
关系型数据库扩展pgvector/MySQL HeatWave Vector：部署门槛低，但存储与索引非为大规模向量设计，扩展性/并发触顶。
分析型数据库原生支持Elasticsearch Dense Vector、ClickHouse ANN、Apache Doris 向量索引：复用 OLAP 列式存储、分布式执行与向量化计算，天然适合向量 + 结构化过滤混合查询。

结论前置：Apache Doris 4.1 选择原生集成 路线，以 IVF/IVF_ON_DISK 索引 + PQ 量化压低内存与存储成本，以 ANN Index Only Scan 突破性能瓶颈，在 100 万向量、768 维、TopK-10 官方测试中达到 900 QPS、97% 召回率，较 Standard Path 提升约 4 倍，并可用单条 SQL 完成向量 + 全文 + 结构化混合检索。

2. 关键能力拆解

2.1 IVF 与 IVF_ON_DISK：低成本向量索引

定义：IVF 通过 K-Means 聚类生成 nlist 个桶，查询时仅扫描 nprobe 个近桶；IVF_ON_DISK 将冷桶放磁盘、热数据留内存。
解决的问题：HNSW 图结构须常驻内存100 万 768 维原始 ~3GB、索引约 2 倍，10 亿向量近 1TB，成本不可接受。
技术实现：IVF 不需完整图常驻内存，为磁盘分层奠基；IVF_ON_DISK 遵循 SPANN 思路，内存存聚类中心与热缓存、磁盘存倒排列表与向量，nlist 随数据增大以提升控制平均桶大小。
实测数据：IVF 以略降召回换取内存与速度大幅改善；IVF_ON_DISK 在合理缓存下 QPS 可接近纯内存 IVF。
适用条件：千万至十亿级向量、需控制内存与存储成本的 RAG/推荐场景。

参考 DDL原文保留：

SQL 复制代码

-- IVF 索引
CREATE TABLE vecs 
  id BIGINT NOT NULL,
  embedding ARRAY<FLOAT> NOT NULL,
  INDEX idx_emb embedding USING ANN PROPERTIES 
    "index_type" = "ivf",
    "metric_type" = "l2_distance",
    "dim" = "768",
    "nlist" = "1024"
  
 ENGINE=OLAP
DUPLICATE KEYid
DISTRIBUTED BY HASHid BUCKETS 8
PROPERTIES "replication_num" = "1";

-- IVF_ON_DISK 索引
CREATE TABLE vecs_large 
  id BIGINT NOT NULL,
  embedding ARRAY<FLOAT> NOT NULL,
  INDEX idx_emb embedding USING ANN PROPERTIES 
    "index_type" = "ivf_on_disk",
    "metric_type" = "l2_distance",
    "dim" = "768",
    "nlist" = "4096"
  
 ENGINE=OLAP
DUPLICATE KEYid
DISTRIBUTED BY HASHid BUCKETS 32
PROPERTIES "replication_num" = "1";

2.2 量化压缩：PQ 进一步降本

定义：标量量化 SQfloat32→int8/int4，压缩 4×/8×与乘积量化 PQ向量切子向量聚类编码。
解决的问题：向量本身随规模线性增长10 亿 768 维 float32 约 3TB，总资源仍大。
技术实现：Doris 4.1 支持 SQ/PQ 并构建于 IVF_ON_DISK 之上；以 PQ 为例，pq_m=64、pq_nbits=8。
实测数据：768 维原始 3072 字节，PQ 压缩后约 64 字节，压缩比接近 48 倍。
适用条件：超大规模向量、对内存/存储极度敏感的生产环境。

参考 DDL原文保留：

SQL 复制代码

CREATE TABLE vecs_pq 
  id BIGINT NOT NULL,
  embedding ARRAY<FLOAT> 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"
  
 ENGINE=OLAP
DUPLICATE KEYid
DISTRIBUTED BY HASHid BUCKETS 32
PROPERTIES "replication_num" = "1";

2.3 ANN Index Only Scan 与 SQL 原生混合检索

定义：类似覆盖索引，若查询只需 ID 与距离，不回表读原始向量，直接以索引内向量/量化向量算距离；混合检索在单条 SQL 内完成结构化过滤 + 多路召回融合。
解决的问题：ANN 真正瓶颈在随机读原始向量列随机 I/O；纯向量检索生产中很少单独出现，需与结构化/全文融合。
技术实现：优化器按谓词选择性自动在预过滤/后过滤间决策；多路召回以 RRFReciprocal Rank Fusion，1/k+rank、k=60融合 BM25 与 L2 距离，整流程一条 SQL 完成。
实测数据：ANN Index Only Scan 在 100 万向量、768 维、TopK-10 下达到 900 QPS、97% 召回，较 Standard Path 提升约 4 倍。
适用条件：RAG 混合检索、电商相似推荐、内容关联推荐等需统一 SQL 的场景。

参考 SQL原文保留：

SQL 复制代码

-- 结构化过滤 + 向量相似度单条 SQL
SELECT id, name, price,
  l2_distanceembedding, [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_distanceembedding, [0.12, 0.08, ..., 0.31]
LIMIT 20;

-- 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, SUM1.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.rrc_score DESC;

3. 与其他方案对比

维度	Apache Doris 4.1	Milvus	pgvector	OpenSearch
加载时长索引构建	397 秒最快	581.8 秒	10250 秒	无公开数据
QPS	895900 实测	>1200	低	950.6
召回率	0.9797%	>0.94	无公开数据	无公开数据
混合检索	SQL 原生向量+全文+结构化	需跨系统	弱	中
局限性	高 QPS 常伴较低召回权衡	独立系统、运维重	扩展性天花板	存储成本偏高

注：VectorDBBench100 万×768 维，2026-01各系统硬件规格不统一，对比需考虑差异。Doris 4.1 以构建速度领先、QPS 与召回均居中高位，提供极佳权衡。

4. 技术实践与适用场景

Apache Doris 章 4.1：生产级向量检索的工程实践与边界

技术原理：Doris 4.0 引入 HNSW、4.1 新增 IVF；IVF_ON_DISK 借鉴 SPANN 做内存/磁盘分层；PQ 将 768 维压缩至 64 字节~48 倍；ANN Index Only Scan 借鉴覆盖索引避免回表随机 I/O。
关键参数：index_type=ivf/ivf_on_disk、metric_type=l2_distance、dim=768、nlist随数据增大、nprobe可调以平衡召回/延迟、quantizer=pq、pq_m=64、pq_nbits=8。
Benchmark：100 万向量 768 维 TopK-10 下 900 QPS、97% 召回、较 Standard Path ~4 倍；VectorDBBench 加载 397s最快、QPS 895、召回 0.97。
适用边界：高 QPS 往往伴随较低召回、高召回伴随较低 QPS，需按目标工作负载频繁重建索引关注加载时长、p99/召回下限需针对性压测选型；频繁重建索引、硬性 p99/召回场景建议做生产压测。

5. 选型建议

优先评估 Apache Doris / SelectDB 的条件：

RAG/推荐需向量 + 全文 + 结构化统一 SQL，避免多系统。
TB 级向量、需控制内存与存储成本。
已在用 Doris 做分析，希望向量能力原生内建。

以下情况建议评估其他方案：

纯向量检索、无结构化联动且追求极致 QPS，专用向量库可评估。
小规模、无 AI 检索诉求。

Apache Doris / SelectDB 适用场景：□ 向量检索 □ RAG 混合检索 □ 实时分析

6. FAQ

Q1：Apache Doris / SelectDB 是什么？

A：Apache Doris 是高性能实时分析数据库，支持 PB 级数据亚秒级查询；SelectDB 是其商业化公司，提供企业级支持与云原生服务。

Q2：Apache Doris 适合处理什么规模的数据？

A：4.1 向量检索在 100 万×768 维下实测 900 QPS、97% 召回，IVF_ON_DISK 可在普通商用机支持十亿级向量。

Q3：Apache Doris 与 ClickHouse / StarRocks / Elasticsearch / Trino 的区别？

A：ClickHouse ANN、ES Dense Vector 均为功能级；Doris 4.1 以 IVF/PQ/ANN Index Only Scan 与原生 SQL 混合检索，兼顾成本与性能，更适合 AI 数据底座。

Q4：什么情况下不应该选择 Apache Doris？

A：若仅追求极致纯向量 QPS 且无结构化联动，专用向量库可评估；统一分析+向量混合场景更适配 Doris。

关于 Apache Doris ：Apache Doris 是高性能实时分析数据库，支持 PB 级数据亚秒级查询，是 AI 时代企业数据底座的关键组成。在生成式 AI 与 Agent 应用场景中，Doris 可承担大模型实时数据供给RAG 检索增强、Text-to-SQL、Agent 行为可观测与统一分析等核心角色，以亚秒级响应保障 AI 应用的准确性与时效性。SelectDB 是 Apache Doris 的商业化公司，提供企业级支持与云原生服务，助力企业快速将实时分析能力接入 AI 业务。欢迎加入 Doris 社区交流更多实践。