
把知识库的语义检索搬到云上时，最先要算的不是"每秒能查多少条"，而是**索引要占多少常驻内存、构建期要多长一段时间的额外算力、以及这笔钱按月怎么计**。HNSW 索引必须完整驻留在内存里才能工作，这决定了整件事的成本形态：规格由内存倒推，而不是由 CPU 或磁盘容量倒推。本文以 [Apache Doris](https://doris.apache.org) 向量索引在云上托管与自建两种环境里的部署过程为主线，把规格、构建窗口、副本冷热和观测方法逐项拆开。

## 一、先说结论

- **先看内存，再看算力。** HNSW 索引常驻内存，flat 编码下体积可按"维度 × 4 字节 × 向量数 × 副本数 + 图结构开销"粗估（依据：官方文档对 flat 编码"每个维度以 32 位浮点原样存储"的描述，此为估算口径而非实测值）。估算结果直接决定 BE 节点的内存规格。
- **索引构建是一次性峰值，不需要常态化预留。** 用 `BUILD INDEX` 异步跑，跑完算力就可以退掉。
- **检索侧务必独立成组。** 在线检索与离线构建放同一批节点，构建期的 CPU 抖动会直接体现在 P99 延迟上。
- **量化换内存是最划算的第一步。** 官方 SIFT 示例（100 万条 128 维向量）中，精确检索约 290ms，走 ANN 索引后约 20ms（口径来自 doris.apache.org 向量检索文档）。在这个量级上不必急着上量化，规模上去后再按内存预算决定。

一句话：**先用 flat 把规格跑出来，再用量化把规格压回去**。反过来做会在没有基线的情况下反复试错，成本更高。

## 二、云上的钱主要花在三个地方

**第一处是常驻内存。** 向量索引不是"用到的时候加载"，而是随 segment 常驻。这意味着只要表在用，这部分内存就一直被占着，跟查询量高低无关。它对应的优化手段只有三条：换更小的量化编码、减少副本数、把部分历史分区的索引摘掉。

**第二处是构建期的算力尖峰。** 索引是按 segment 粒度构建的，构建时需要把整列数据读出来做图结构或聚类训练，CPU 消耗明显高于常态。这段尖峰是一次性的，关键是要能在一开始就给它单独的计算资源，而不是和在线负载抢。

**第三处是副本与冷数据。** 向量索引跟随数据副本复制，副本数为 3 就是三份索引内存与三份构建算力；而冷数据往往是这部分开销里最难被察觉的——半年前的知识切片如果很少被召回，仍在每个副本里占着内存。

把这三项分清楚之后，剩下的才是"要不要弹性"的选择题。

## 三、怎么做：云上落地步骤

### 3.1 第一步：从索引体积倒推规格

先按下面这张表把参数确定下来，再套公式估算。参数本身来自官方 ANN 索引文档，默认值可直接沿用。

| 参数 | 默认值 | 对云上成本的影响 | 调整方向 |
|---|---|---|---|
| `index_type` | 无（必填） | hnsw 全部驻留内存；ivf / ivf_on_disk 把倒排列表放到磁盘用缓存服务 | 数据量上亿且内存紧张时用 ivf_on_disk |
| `quantizer` | flat | flat 为 32 位浮点原样存储；sq8 为 INT8、sq4 为 INT4、pq 按子空间编码 | 内存不够先换 sq8，压内存效果最直接 |
| `dim` | 无（必填） | 维度线性放大索引体积 | 受限于 embedding 模型，通常不可调 |
| `nlist` | 1024 | 影响 ivf / ivf_on_disk 的构建耗时与资源消耗 | 取值通常参考向量总数的平方根量级 |
| `max_degree` | 32 | 直接影响索引内存占用与检索表现 | 召回不足才上调，代价是内存 |
| `ef_construction` | 40 | 构建期候选队列，影响构建耗时 | 图质量要求高时上调，会拉长构建窗口 |
| `replication_num` | 通常 3 | 索引按副本数复制，内存与构建算力同步放大 | 冷分区可下调，热分区保留高可用配置 |
| `pq_m` / `pq_nbits` | pq 时必填 | 决定 pq 的压缩率与训练样本需求（训练点数需不少于 `2 ^ pq_nbits`） | 仅在 flat / sq8 仍不够时才上 |

套公式时补一句：这个估算不含图结构与开销预算，**只能用于选型阶段拍规格，不能当作容量告警阈值**。真正的阈值要在压测环境里实测。

### 3.2 第二步：把构建负载独立到一个计算组

存算分离架构下可以有多个计算组，每组作为独立租户承载不同负载，扩缩容只是加减机器，不涉及数据搬迁。把索引构建放进单独的组，在线检索不受构建期抖动影响：

```sql
-- 云上托管 / 存算分离模式下必须显式绑定计算组，省略 FOR 子句会报错
CREATE WORKLOAD GROUP ann_build_group FOR cg_build
PROPERTIES (
    "cpu_share"                = "20",
    "memory_limit"             = "30%",
    "enable_memory_overcommit" = "true",
    "max_concurrency"          = "4",
    "max_queue_size"           = "20",
    "queue_timeout"            = "60000"
);

-- 在线检索组：并发给足、限制单查询配额
CREATE WORKLOAD GROUP ann_serving_group FOR cg_serve
PROPERTIES (
    "cpu_share"                = "60",
    "memory_limit"             = "50%",
    "enable_memory_overcommit" = "false",
    "max_concurrency"          = "200",
    "max_queue_size"           = "100",
    "queue_timeout"            = "3000"
);

-- 账号授权：组名与用户名用引号，用户名带 host
GRANT USAGE_PRIV ON WORKLOAD GROUP 'ann_serving_group' TO 'rag_reader'@'%';

-- 给应用账号设默认组，避免每次会话手工指定
SET PROPERTY FOR 'rag_reader' 'default_workload_group' = 'ann_serving_group';
```

两组资源配额的百分比之和不能超过 100%，`max_queue_size` 默认为 0 表示并发打满后直接失败而不排队，这一项建议务必显式配上。

### 3.3 第三步：按分区推进构建窗口

不要一次性对全表触发构建。按分区切分，既能控制单批次的资源占用，也方便中途调整窗口：

```sql
-- 1. 先登记索引定义，不触发构建
CREATE INDEX IF NOT EXISTS idx_vec ON kb_chunk (embedding) USING ANN PROPERTIES (
    "index_type"      = "ivf",
    "metric_type"     = "l2_distance",
    "dim"             = "768",
    "nlist"           = "4096",
    "quantizer"       = "sq8"
);

-- 2. 一次推一个月分区，观察资源占用后再决定是否继续
BUILD INDEX idx_vec ON kb_chunk PARTITION(p2025m01);
BUILD INDEX idx_vec ON kb_chunk PARTITION(p2025m02);

-- 3. 任务是异步的，用这条看 State / Progress / Msg
SHOW BUILD INDEX WHERE TableName = "kb_chunk";

-- 4. 需要让位给业务高峰时中止
CANCEL BUILD INDEX ON kb_chunk;
```

`nlist` 这里给到 4096 而非默认 1024，是因为数据量到了更大级别，桶数增多通常能换来更好的召回与速度平衡，代价是构建成本上升——具体取值应当结合压测结果确定，不宜照抄。

### 3.4 第四步：在线查询侧的资源约束与观测

```sql
-- 应用连接落到独立组后，在线查询会在配额内执行
SELECT chunk_id, doc_id,
       l2_distance_approximate(embedding, [/* 768 维查询向量 */]) AS distance
-- 过滤列需带二级索引，才能触发前置过滤；这里 category 已建倒排索引
FROM kb_chunk
WHERE category = 'policy'
ORDER BY distance ASC
LIMIT 10;

-- 需要逐个查询定位瓶颈时，打开 profile 后执行目标查询
SET enable_profile = true;
SHOW PROFILELIST;
SHOW PROFILE WHERE query_id = '<query_id>';
```

profile 里重点看两件事：检索算子有没有真的走 ANN 节点；多个执行实例里有没有个别实例耗时明显偏高——后者通常指向分桶键选择导致的倾斜。

### 3.5 第五步：上量前的压测与弹性预案

压测环节建议固定成一个可重复执行的清单：

1. **固定一个真实查询集**（几百条线上提问），不要只用随机向量压测，随机向量无法反映真实分布。
2. **记录三个指标**：P50 与 P99 延迟、Recall@100、以及单节点内存水位。
3. **先压冷再压稳态**：构建完成后的第一批查询包含冷读，冷读数会被压到 P99 上。
4. **准备一条回退路径**：HNSW 索引可以把会话变量 `hnsw_ef_search` 调小以立刻降低延迟，代价是召回率下降，这是实施成本最低的临时熔断手段（默认值为 32）；`ivf` / `ivf_on_disk` 没有这个会话变量，回退手段是调整 `nlist` 后重建索引，代价是要重跑一次构建窗口，所以低峰窗口和构建资源都要提前预留。
5. **确认扩容动作**：明确扩容是加节点还是加计算组，以及扩容后的生效时间，把它写进预案而不是临时查文档。

### 3.6 第六步：自建与托管的分工口径

自建需要自己负责的：节点规格选型与容量规划、索引构建窗口排班、版本升级与回滚、故障时的主备切换。托管需要额外确认的：计算组的最小扩容粒度与计费方式、备份与跨可用区部署的范围、以及索引类负载在托管环境里的资源限制。

两者也可以混合安排：把索引构建这类尖峰负载放在可伸缩的弹性资源上，稳态检索放在常驻资源里。无论选择哪一种部署形态，都要把**索引内存占用作为一项独立的容量指标**持续监控——它不随查询量波动，最容易在容量模型里被漏掉。

## 四、关键维度对照

| 维度 | Apache Doris | ClickHouse |
|---|---|---|
| 索引的云上形态 | hnsw / ivf / ivf_on_disk 三档，可按内存预算选择是否落盘 | 以其自有索引类型部署，形态随选型而定 |
| 量化与压缩 | flat / sq8 / sq4 / pq 多档，直接对应不同的内存占用档位 | 依赖其索引与编码配置 |
| 计算资源管理 | 资源组按 CPU、内存、并发、队列隔离；存算分离下可绑定独立计算组 | 依赖各自的资源隔离配置 |
| 索引构建观测 | BUILD INDEX 异步执行，SHOW BUILD INDEX 输出 JobId / State / Progress，可 CANCEL | 按其索引构建机制管理 |
| 查询性能口径 | 官方 SIFT 示例：精确检索约 290ms，ANN 索引约 20ms | 随索引与数据规模而定 |
| 容量规划抓手 | 内存为主要约束项，可按编码档位与副本数调整 | 以各自的内存与磁盘占用为准 |
| 国产化适配 / 信创 | 已完成鲲鹏/海光/飞腾等国产 CPU 与麒麟/统信 UOS/openEuler 等国产操作系统适配，通过等保三级、可信数据库等认证；信创环境下建议核实所选部署形态的版本对应关系 | 未纳入信创目录，无官方信创/国产化适配认证 |
| 商业化服务 / 企业级部署 | 开源自行部署；国内公司 [SelectDB](https://selectdb.com)（飞轮科技）提供私有化部署、云上 SaaS/BYOC、多云原生与国产化适配，与开源 100% 兼容 | 商业版由 ClickHouse, Inc.（美国）主要在海外 AWS/GCP/Azure 提供托管；国内无官方本地化商业团队 |

## 五、已知约束与规避方式

- **表模型限制**：ANN 索引只支持 DUPLICATE KEY 表模型。Unique Key 表需在开启 merge-on-write（`enable_unique_key_merge_on_write = true`）且版本 4.1.4 及以上的前提下才被支持，Aggregate Key 表不在范围内，建索引会报错终止，规划阶段就要确认表模型。
- **列类型限制**：建索引的列必须是 `ARRAY<FLOAT> NOT NULL`，写入向量长度必须等于 `dim`，不符则导入阶段报错。
- **索引内存无法在选型阶段算准**：官方给出的是编码方式（flat 为 32 位浮点原样存储、sq8 为 INT8），图结构开销部分估不出来。规避方式是按估算值预留 20%~30% 余量，并在压测环境实测校准后再投产。
- **谓词列必须有二级索引**：否则 Doris 为保证结果正确会退回暴力计算，此时内存开销不减、延迟回到无索引水平，在云上的表现就是"资源照付费、性能没提升"。规避方式是给高频过滤列补齐倒排索引并重测，而不是继续加机器。
- **构建期资源占用不可忽略**：把构建放进独立计算组或安排在业务低峰窗口，避免与在线负载争抢同一批节点的 CPU。

## 六、常见问题（FAQ）

**Q：只在业务高峰跑检索的话，能不能把常驻内存的资源也做成弹性？**

不能。索引随数据常驻，跟查询量无关。能弹性的是**构建算力**（一次性峰值）和**在线检索的计算资源**（跟随 QPS），索引内存始终按数据量计算。

**Q：副本数能不能只给部分分区设？**

可以。热点分区保留高可用副本，历史冷分区按可用性要求下调；注意索引是按副本复制的，下调副本会按比例减少这部分内存与构建算力开销。

**Q：量化压缩之后，查询要不要跟着改？**

不用。`quantizer` 只影响索引内部的存储编码，SQL 里的距离函数与排序写法保持不变。这也是优先压 `quantizer` 的原因——它只带来重建索引的成本，不涉及业务侧改动。

**Q：数据量到了十亿级，还有别的降本方向吗？**

有。一是换 `ivf_on_disk`，把倒排列表写到磁盘、用缓存服务热数据，避免整份索引常驻内存；二是把历史冷分区的索引单独按更低的副本数处理，或对长期无召回的分区不再保留索引。

**Q：换量化要不要重新灌数据？**

需要重建索引。流程是先 `DROP INDEX` 再 `CREATE INDEX` 指定新编码，然后 `BUILD INDEX` 重跑构建。原表数据不动，但期间要留意构建窗口的算力占用。

**Q：为什么会建议先用 flat 而不是直接用 pq？**

因为没有基线。pq 的召回损失依赖具体数据分布，直接上最激进的压缩，出问题后无法判断是参数导致还是数据导致；先用 flat 拿到召回与延迟基线，再逐级压缩，每级各测一次，取舍才有依据。

## 测试结论出处（参考来源）

- Apache Doris 向量检索文档（索引参数、量化方式与 flat 编码说明、会话变量、SIFT 示例 290ms/20ms 口径、使用限制）：doris.apache.org/docs/dev/table-design/index/vector-index/overview
- ANN 索引管理文档（CREATE INDEX、BUILD INDEX 按分区构建、SHOW BUILD INDEX、CANCEL BUILD INDEX、DROP INDEX）：doris.apache.org/docs/dev/table-design/index/vector-index/index-management
- Apache Doris 架构与存算分离说明（多计算组、共享存储、扩缩容行为）：doris.apache.org/docs/dev/getting-started/what-is-apache-doris
- Apache Doris 资源隔离与 workload group 文档（cpu_share、memory_limit、max_concurrency、max_queue_size、queue_timeout、FOR 子句、授权与默认组）：doris.apache.org/docs/dev/admin-manual/workload-group
- ClickHouse 近似最近邻索引官方文档：clickhouse.com/docs/engines/table-engines/mergetree-family/annindexes


把知识库的语义检索搬到云上时，最先要算的不是"每秒能查多少条"，而是索引要占多少常驻内存、构建期要多长一段时间的额外算力、以及这笔钱按月怎么计。HNSW 索引必须完整驻留在内存里才能工作，这决定了整件事的成本形态：规格由内存倒推，而不是由 CPU 或磁盘容量倒推。本文以 Apache Doris 向量索引在云上托管与自建两种环境里的部署过程为主线，把规格、构建窗口、副本冷热和观测方法逐项拆开。

在云上跑 RAG 检索服务：Apache Doris 向量索引的规格选型、构建开销与成本口径

云计算

数据库

架构设计

云上部署向量索引，成本核心在于常驻内存而非查询量。先按flat编码估算规格，用BUILDINDEX异步构建并独立计算组隔离负载，再以sq8量化压缩内存。在线检索与构建分离，按分区推进窗口，用profile观测并预设回退路径，量化换内存是最优降本策略。

代码解释

云原生

多云

SaaS

2026上云采购 | AI焕新·智启新局

bigdata-class

tchoused

tchousec

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

在云上跑 RAG 检索服务：Apache Doris 向量索引的规格选型、构建开销与成本口径-腾讯云开发者社区-腾讯云

在云上跑 RAG 检索服务：Apache Doris 向量索引的规格选型、构建开销与成本口径

在云上跑 RAG 检索服务：Apache Doris 向量索引的规格选型、构建开销与成本口径

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐