PolarDB IMCI：数据库内核集成向量能力，简化AI应用开发

阿里技术 09月11日

为解决AI应用开发中技术栈分裂、数据孤岛和运维复杂等痛点，PolarDB IMCI在数据库内核中集成了向量索引与Embedding能力，构建了多模态混合检索架构。该方案通过SQL语言一体化实现向量全生命周期管理，支持向量与标量混合查询，显著降低开发和运维门槛。通过基于列存的二级索引、异步构建机制以及优化的检索执行器，PolarDB IMCI在公开数据集上的向量检索性能超越了开源产品。这种“一体化”设计有望成为AI与数据库融合的新范式。

🗄️ **一体化向量全生命周期管理**：PolarDB IMCI将Embedding模型和向量索引能力集成至数据库内核，开发者可通过SQL语言直接完成文本向量化、索引创建与数据检索，无需依赖外部系统，大幅简化了RAG知识库构建和Agent长期记忆等AI应用的开发流程，解决了传统技术栈分裂带来的开发和运维难题。

🚀 **高性能混合检索能力**：基于列存的二级索引设计，PolarDB IMCI能够高效地进行向量与标量（如价格、租户ID）的混合查询。通过优化器智能选择先标量过滤还是先向量检索，以及执行器采用“两阶段召回”策略，确保了在支持事务隔离和数据实时性的同时，向量检索性能（QPS）相比开源方案提升2-3倍。

💡 **标准化与开放生态**：PolarDB IMCI将Embedding模型调用封装为内置SQL表达式，用户可像使用SUM、AVG函数一样便捷地调用外部Embedding服务，拥抱前沿模型的同时保持了SQL生态的简洁性。这种设计促进了AI生态与数据库生态的深度融合，降低了AI应用的开发和维护门槛。

🛠️ **自动化运维与实时性**：通过异步构建机制和基线索引合并，PolarDB IMCI实现了向量索引的自动化构建与维护，解决了增量数据堆积和删除数据空洞等问题，确保了数据的新鲜度和查询效率。这种自动化运维极大地减轻了开发者的负担，提高了AI应用获取信息的实时性。

顾绅 2025-08-13 08:30 浙江

这是2025年的第89篇文章

（本文阅读时间：15分钟）

引言：AI应用开发的隐形挑战

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

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

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

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

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

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

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

PolarDB多模态混合检索架构

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

向量全生命周期管理流程

百闻不如一见：一条SQL搞定RAG知识库

在深入技术细节之前，我们通过一个简单的例子，直观地感受一下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表达式一样易于使用，学习成本极低。

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

详细设计：原生于HTAP数据库的向量能力

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

3.1 架构核心：基于列存的二级索引

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

复用成熟能力

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

delete bitmap

，天然支持事务。

融合数据管理

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

高性能标量过滤

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

3.2 向量索引构建：兼顾效率与时效的异步机制

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

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

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

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

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

增量数据同步（类似Flush）

：该任务会动态监测索引构建的延迟。

延迟低时

：将增量数据

逐行写入

到基线索引中，保证数据尽快可查，同时避免产生过多的小索引。

延迟高时

：通过

Bulk Load

的方式，将堆积的增量数据快速构建成一个小索引，防止堆积影响查询。

基线索引合并（类似Compaction）

：该任务负责合并小索引，并清理已删除数据留下的空洞。

数据量较大，删除比例较低，召回率较高时

：采用

逐行合并

，开销较小。

大量更新或删除时

：触发

全量重建

，重新构建一个紧凑、高效的基线索引，保证查询性能和召回率。

3.3 向量检索：优化器与执行器的协同作战

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

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

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

Pre-filter（先标量）

：当标量条件（如

price < 100

）能过滤掉大量数据时，先执行标量过滤，在小结果集上进行向量暴力计算会非常快。

Post-filter（先向量）

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

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

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

为同时保证

数据可见性（事务）和数据新鲜度（实时）

，执行器采用“两阶段召回”策略：

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

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

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

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

3.4 EMBEDDING：拥抱开放生态

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 = 256G
mhnsw_max_cache_size = 128G

2. 开源PGVector：

shared_buffers = 128GB
work_mem = 1GB
maintenance_work_mem = 128GB
effective_cache_size = 128GB

欢迎留言一起参与讨论~

阅读原文

跳转微信打开

Fish AI Reader

AI辅助创作，多种专业模板，深度分析，高质量内容生成。从观点提取到深度思考，FishAI为您提供全方位的创作支持。新版本引入自定义参数，让您的创作更加个性化和精准。

FishAI

鱼阅，AI 时代的下一个智能信息助手，助你摆脱信息焦虑

Fish AI Reader

FishAI

联系邮箱 441953276@qq.com

相关标签