一条SQL管理向量全生命周期，让AI应用开发更简单

在当前大模型驱动的AI浪潮中，无论是构建RAG知识库，还是实现Agent的长期记忆，向量都扮演着至关重要的角色。一个典型的向量数据流包含两个核心环节：

1. 写入：将文本等非结构化数据，通过Embedding模型转化为向量，并存入向量索引。

2. 检索：将用户问题同样转化为向量，在索引中进行检索，召回相关的信息。

然而，在实际的AI应用开发中，开发者常常面临一个分裂的技术栈。向量索引、Embedding模型和业务数据库往往是三个独立的系统，这种分离带来了诸多“隐形成本”：

1. 开发之痛：需要在不同的软件/云服务之间进行技术选型和集成，编写大量胶水代码，增加了开发复杂性。

2. 运维之痛：业务数据与向量数据需要手动或通过ETL工具同步，不仅增加了运维负担，还导致数据延迟，影响AI应用获取信息的实时性。

3. 使用之痛：各种向量数据库/服务接口各异，缺乏统一标准。当需要进行向量与标量（如商品价格、租户ID等）的混合查询时，能力往往受限，学习和使用成本高昂。

PolarDB多模态混合检索架构

为了解决这些难题，PolarDB IMCI（In-Memory Column Index，简称IMCI）提出了一套全新的解决方案——在数据库内核中集成向量索引与Embedding能力，构建了一个多模态混合检索架构，致力于为开发者提供一体化的向量全生命周期管理服务。

向量全生命周期管理流程

在深入技术细节之前，我们通过一个简单的例子，直观地感受一下PolarDB带来的改变。

假设我们要为PolarDB IMCI搭建一个技术问答机器人，知识库中有以下三条文档：

• "PolarDB IMCI支持通过Hybrid Plan在一条SQL中同时访问行存和列存"

• "HashMatch是PolarDB IMCI中的一种Join算子"

• "PolarDB IMCI提供内置的向量索引和embedding服务"

过去，这需要多个系统协作。现在，你只需要几行SQL。

第一步：创建并填充知识库

-- 创建一张表，其中vec列由doc列通过EMBEDDING表达式自动生成-- 同时，通过COMMENT语法声明一个HNSW向量索引CREATE TABLE t1(  doc TEXT,  vec VECTOR(1024) AS (EMBEDDING(doc, "text-embedding-v4", 1024)) STORED COMMENT 'imci_vector_index=HNSW(metric=cosine,max_degree=16,ef_construction=300)') COMMENT 'COLUMNAR=1';
-- 插入原始文本数据，向量生成和索引构建由数据库自动完成INSERT INTO t1(doc)VALUES("PolarDB IMCI支持通过Hybrid Plan在一条SQL中同时访问行存和列存"),("HashMatch是PolarDB IMCI中的一种Join算子"),("PolarDB IMCI提供内置的向量索引和embedding服务");

第二步：用一条SQL完成“提问-向量化-检索-拼接Prompt” 

当用户提问“HashMatch是什么”时，你可以这样从知识库中召回信息并生成Prompt：

SELECT CONCAT("请参考以下内容: ", GROUP_CONCAT(doc), ", 以合适的语气回答用户的问题: HashMatch是什么")FROM(SELECT doc FROM t1 ORDER BY DISTANCE(vec, EMBEDDING("HashMatch是什么", "text-embedding-v4", 1024), 'COSINE') LIMIT 1) AS t;

在这个例子中，PolarDB的优势体现得淋漓尽致：

1. 一体化：EMBEDDING表达式与向量索引无缝集成。通过物化虚拟列，文本向量化的过程无需应用层干预。

2. 自动化：只需在表定义中声明索引，数据库后台任务便会自动构建和维护向量索引，彻底告别了数据同步的烦恼。

3. 标准化：所有操作都在开发者最熟悉的SQL生态下完成。EMBEDDING和DISTANCE表达式就像普通的SQL表达式一样易于使用，学习成本极低。

接下来，我们将深入剖析其背后的技术设计。

我们将向量能力深度融合到PolarDB IMCI中，这一架构决策带来了独特的技术优势。我们没有“重复造轮子”，而是让向量索引“站在巨人的肩膀上”。

我们将HNSW向量索引实现为列式存储的一种二级索引。它存储的是从向量到数据行ID（RowID）的映射。这种设计的好处是：

• 复用成熟能力：向量索引本身通常不具备成熟的事务、备份恢复（Checkpoint/Recover）等企业级能力。通过与列存结合，这些能力被完美复用。例如，数据的可见性判断可以直接利用列存的delete bitmap，天然支持事务。

• 融合数据管理：向量索引只负责向量检索，而标量数据（如租户ID、时间戳、类别等）存储在列存中。查询时，通过RowID可以快速关联两者。

• 高性能标量过滤：在进行“向量+标量”的混合检索时，可以充分利用列存引擎强大的IO裁剪（只读需要的列）和向量化执行器，实现高效的标量过滤。

向量索引的构建开销较大，为了不影响列式存储的物理复制，我们采用异步构建。但这带来了新的挑战：

1. 前台写入流量较大时，增量数据可能无法及时被写入向量索引，产生堆积。堆积的数据无法借助向量索引加速，只能通过暴力扫描进行检索，影响性能。

2. 列式存储采用标记删除，基线向量索引中将产生空洞，带来空间开销的同时还会影响性能。

3. 使用quantization时，预训练的codebook质量将随写入下降，影响recall。

为此，我们参考LSM-Tree的设计思想，将异步构建后台任务分解为两个子任务：

• 增量数据同步（类似Flush）：该任务会动态监测索引构建的延迟。

• 延迟低时：将增量数据逐行写入到基线索引中，保证数据尽快可查，同时避免产生过多的小索引。

• 延迟高时：通过Bulk Load的方式，将堆积的增量数据快速构建成一个小索引，防止堆积影响查询。

• 基线索引合并（类似Compaction）：该任务负责合并小索引，并清理已删除数据留下的空洞。

• 数据量较大，删除比例较低，召回率较高时：采用逐行合并，开销较小。

• 大量更新或删除时：触发全量重建，重新构建一个紧凑、高效的基线索引，保证查询性能和召回率。

PolarDB IMCI支持精确检索和近似检索。精确检索通过暴力扫描实现，较为简单，重点在于高性能的近似检索。

• 优化器：智能决策混合检索路径
  

  在混合检索场景中，过滤标量和检索向量的先后顺序，对性能影响巨大。

• Pre-filter（先标量）：当标量条件（如 price < 100）能过滤掉大量数据时，先执行标量过滤，在小结果集上进行向量暴力计算会非常快。

• Post-filter（先向量）：当标量条件选择性差时，先通过向量索引召回K个近邻，再用标量条件进行过滤更为高效。

PolarDB优化器会基于统计信息，动态选择Pre-filter或Post-filter的执行计划。未来我们还将引入执行反馈和自适应执行，让决策更加智能。

• 执行器：实现事务级的实时检索
  

  为同时保证数据可见性（事务）和数据新鲜度（实时），执行器采用“两阶段召回”策略：

• 基线索引召回：从向量索引中检索数据。利用列存的delete bitmap进行可见性判断，天然支持事务隔离。

• 增量数据召回：扫描尚未写入索引的最新数据，进行暴力计算。

• 结果合并：最后，由上层算子将两路召回的结果进行归并排序，得到最终的Top-K结果。

此外，通过Sideway Information Passing，如果上层Filter算子过滤掉了部分向量召回结果，执行器可以动态地从向量索引中召回更多候选集，以保证最终结果的数量和质量。

Embedding模型技术日新月异。我们认为，数据库的核心是数据管理与计算，而非模型本身。因此，PolarDB IMCI选择了一种更开放、灵活的方式：

• 将外部Embedding服务（如阿里云百炼等）的API调用封装为内置SQL表达式。

• 用户可以在SQL中直接调用EMBEDDING表达式，就像调用SUM、AVG一样简单。

这种设计既让用户能随时用上最前沿（SOTA）的模型，又兼容了简洁的SQL生态，实现了AI生态与数据库生态的完美结合。

我们在公开的GIST-960数据集上，将PolarDB IMCI与开源PGVector及MariaDB进行了性能对比。在同等硬件规格下（见附录），测试结果显示：在不同的召回率下，PolarDB IMCI的向量检索性能（QPS）是其他两款产品的2-3倍。

PolarDB IMCI通过将向量检索与Embedding能力集成到数据库内核中，从根本上解决了传统AI应用开发中技术栈分裂、数据孤岛和运维复杂等痛点。它不仅提供了一个高性能、支持事务、实时可见的向量数据库，更重要的是，它将这一切都统一在开发者最熟悉的SQL语言之下，极大地降低了AI应用的开发和维护门槛。

我们相信，这种“一体化”的设计将成为AI与数据库融合的新范式，为广大开发者构建下一代智能应用提供坚实、高效的数据底座。

测试使用的CPU规格为Intel(R) Xeon(R) Platinum 8357C CPU @ 2.70GHz，PolarDB为128G规格，开源PGVector和MariaDB的相关参数如下：

1. MariaDB：

innodb_buffer_pool_size = 256Gmhnsw_max_cache_size = 128G

2. 开源PGVector：

shared_buffers = 128GBwork_mem = 1GBmaintenance_work_mem = 128GBeffective_cache_size = 128GB