Redis，这个备受欢迎的内存数据库，对其查询引擎进行了重大升级，以支持日益增长的检索增强生成 (RAG) 应用需求，尤其是在向量数据库重要性日益凸显的背景下。
此次升级的核心在于引入了
多线程查询执行
，在保持低延迟（平均查询延迟低于 10 毫秒）的同时，显著提升了查询吞吐量。
通过允许多个查询并发访问索引，Redis 实现了
垂直扩展
，有效提升了 Redis 操作和查询的吞吐量，尤其是在数据量达到数亿文档级别时，避免了复杂查询成为性能瓶颈。
垂直扩展示意图
传统的 Redis 单线程架构在处理长时间运行的查询，特别是使用倒排索引进行数据搜索时，容易造成拥塞，降低整体吞吐量。搜索操作本身并非 O(1) 复杂度，通常需要结合多个 O(log(n)) 复杂度的索引扫描来满足多个查询条件，其中 n 是索引映射的数据点数量。
Redis 的多线程架构有效解决了这一挑战。新的架构允许多个查询在独立的线程上并发执行，同时保持主线程对其他 Redis 操作的响应能力。
具体来说，查询执行分为三个步骤：
-
主线程准备查询上下文（规划），并将其放入共享队列。
-
多个工作线程从队列中取出任务，并并发执行查询管道。
这使得多个查询可以并行处理，大大提高了吞吐量。
-
查询完成后，结果返回给主线程。
主线程负责整合结果并返回给客户端。
这种设计既提升了复杂查询（例如向量相似性搜索）的吞吐量，又保证了 Redis 核心操作的高性能。Redis 指出，高效扩展搜索需要结合
水平扩展（分布式数据负载）和垂直扩展（多线程索引访问）
，以应对不断增长的数据量和查询需求。
为了验证新查询引擎的性能，Redis 进行了广泛的基准测试，并与三类向量数据库提供商进行了比较：
-
-
-
完全托管的内存 Redis 云服务提供商 (CSP)
结果显示，Redis 在速度和可扩展性方面优于纯向量数据库，并在整体性能上显著超过了通用数据库和托管 Redis CSP。
基准测试使用了多个数据集 (gist-960-euclidean, glove-100-angular, deep-image-96-angular, dbpedia-openai-1M-angular) 和行业标准工具 (例如 Qdrant 的 vector-db-benchmark)，涵盖了数据摄取（使用 HNSW 算法和 ANN 搜索）和 k-NN 搜索等工作负载，确保了测试的全面性和可靠性。
Redis 的此次升级正值向量数据库市场蓬勃发展之际。然而，市场上向量数据库选项日益饱和，正如 Reddit 首席工程师 Doug Turnbull 指出的，选择过多反而让用户无所适从。
真正的挑战在于构建完整的检索解决方案，而不仅仅是获取向量。Vectera 的 Ofer Mendelevitch 和 RisingWave Labs 创始人吴英骏也表达了类似的观点，强调向量数据库只是 AI 应用技术栈的一部分，并且更倾向于在现有数据库上增强向量引擎。Redis 的做法与这一理念相符，通过增强现有基础设施为开发者提供更集成高效的解决方案。
新 Redis 查询引擎的查询吞吐量提升了 16 倍，尤其适用于对实时性要求很高的 RAG 应用，例如需要快速检索向量数据库的聊天机器人。
Gmail 创始人 Paul Buchheit 提出的 “100 毫秒规则” 强调了用户体验的重要性。在 RAG 架构中，网络往返、LLM 处理、应用操作和向量数据库查询等多个环节会导致延迟，平均端到端响应时间远超 100 毫秒。
Redis 的改进有助于开发者构建更接近 “100 毫秒规则” 的实时生成式 AI 应用，提供更流畅的用户体验。
