Redis 10亿向量搜索实战：Redis 8 十亿级向量基准深度解析
随着 GenAI 应用进入生产阶段，企业对向量数据库的规模需求从百万级跃升至十亿级。Redis 官方博客《Searching 1 billion vectors with Redis 8》公开了十亿级规模的实测结果，本文按原文数据逐项拆解。
关于图表：原文的性能曲线是一张 Chart.js 交互图（canvas 动态渲染，静态抓取无法得到有效图片），因此本文不放置无源配图，改为把原文的全部关键指标整理为下方可溯源数据表。
基准测试配置
- 向量规模：10 亿（1B）条、768 维向量
- 数据来源：与 Intel® 合作准备的向量数据集，派生自 LAION-5B（用 Stable Diffusion 与 OpenClip 生成）
- 存储精度与距离度量：FLOAT16 + Euclidean（欧氏）距离
- 索引结构：HNSW，通过 M / EF_CONSTRUCTION / EF_RUNTIME 三个参数做精度—延迟取舍
- 查询负载：10K 条查询，每条带 100 个 ground truth（精确近邻）用于计算 recall
- 并发度：50 个并发搜索请求，取 Top-100 最近邻
- 版本：Redis 8 Community Edition
核心性能数据
1. 查询延迟（含 RTT）
| 精度目标（recall） | 中位延迟 | 说明 |
|---|---|---|
| 90% | ~200 ms | 十亿级规模下仍可视为实时可用 |
| 95% | ~1.3 s | 高精度检索场景，代价是明显更高的延迟 |
原文的取舍结论很直接：M 与 EF_CONSTRUCTION 越大，检索质量越高、延迟越大；精度与延迟是按用例调节的旋钮，而不是一个固定值。
2. 索引吞吐（实时写入）
| 索引配置 | 对应精度 | 插入吞吐 |
|---|---|---|
| M 16 / EF_CONSTRUCTION 32 | ≥ 95% | 66,000 向量/秒 |
| M 4 / EF_CONSTRUCTION 4 | 较低 | 160,000 向量/秒 |
- 66K 向量/秒意味着单节点每小时可写入约 2.4 亿条向量，且不需要停机重建索引（实时索引）。
- 原文明确指出：增加节点可进一步提升吞吐。
3. HNSW 三个参数的分工
| 参数 | 设定时机 | 含义 | 调大的影响 |
|---|---|---|---|
| M | 建索引时 | 每个节点允许的最大出边数（原文取 4 / 8 / 16 / 32） | 图更稠密，召回更高 |
| EF_CONSTRUCTION | 建索引时 | 建图阶段考察的候选出边数（原文取 4 / 8 / 16 / 32） | 索引质量更好，建索引更慢 |
| EF_RUNTIME | 查询时 | KNN 检索阶段保留的候选数 | 精度更高，查询更慢 |
一句话结论：用
M/EF_CONSTRUCTION换索引质量，用EF_RUNTIME换查询精度——三者共同决定最终的 recall 与延迟。
Redis 的独特价值：统一数据平台
与专用向量数据库不同，Redis 在同一平台内整合了多种数据操作能力（产品线能力，非本文基准数据）：
| 能力 | 传统方案 | Redis 方案 |
|---|---|---|
| 向量搜索 | 独立向量库 | Redis 8 内置向量索引（HNSW） |
| 语义缓存 / 缓存 | 独立缓存层 | Redis 原生缓存能力 |
| 会话存储 | 独立 Session 库 | 原生支持 |
| 实时数据 | 独立 Redis/Memcached | 统一管理 |
这种架构优势在以下场景尤为明显：
- Agent Memory：短期记忆（工作内存）与长期记忆（向量检索）可无缝流转；
- RAG + Caching：同一份向量数据既用于检索结果，又可直接作为 LLM 缓存层；
- 多租户场景：访问控制与数据分区统一在一套系统内完成。
行业应用（来源：redis.io 官网客户案例区）
Redis 官网的客户案例区可见 Superlinked、Sony LIV 等向量检索场景的落地案例；原文博客本身只发布基准数据，未给出这些案例的量化指标。
小夏点评
-
统一平台的价值常被低估：Redis 的竞争力不只在于十亿级向量下的延迟数字，更在于把向量检索、缓存、会话与实时数据放在同一套系统里。对需要快速拼装 AI 应用的团队，这种”少一个组件”的运维收益往往大于纯性能差异。
-
十亿级是”可运维”而非”极限”：原文的措辞是向量搜索”从百万级扩展到十亿级”仍能保持实时延迟，并明确指出加节点可继续提升吞吐。这说明当前的天花板更多在容量与成本规划，而不在单点技术。
-
国内团队选型建议：千万级以内的 RAG 场景，PostgreSQL + pgvector 依然成熟且成本可控；当规模进入亿级、需要向量数据与实时业务数据强耦合时，Redis 的统一平台优势才真正显现。建议在架构评估阶段就把”是否需要多类数据能力统一”作为决策项，而不是只比延迟数字。
