点击阅读原文获取火山引擎 RDS MySQL 向量索引
一、火山引擎 RDS MySQL 的高性能向量索引能力
随着近两年 AI 的快速发展，像 AI 模型、 AI 助手等 AI 产品越来越多，这些 AI 产品几乎都用到了 RAG （检索增强生成）架构。向量数据库也逐渐重要，变成了业务不可缺少的数据库，但对于绝大多数的 MySQL 数据库用户来说，业务数据全部存储在 MySQL 中，如果需要向量检索就需要额外再部署一个向量数据库，不仅会导致数据查询链路变长，增加查询耗时，多部署一个数据库，数据同步的成本和对该数据库的运维成本也会增加。
为了解决 MySQL 用户的这个问题，火山引擎 RDS MySQL 正式推出了高性能向量索引，用户不用再单独部署向量数据库，可以让您在一张 MySQL 表里同时执行常规业务查询和向量检索，仅依赖 MySQL 数据库即可完整实现 RAG 业务能力。
Oracle 在 MySQL 9.0 中新增了 VECTOR 向量字段类型和一些转换函数，但是没有支持向量索引。如果用户想要做高性能近似最近邻 （ANN） 向量检索，要么需要扫描全表的数据，要么就是去额外购买付费的 HeatWave 组件。而火山引擎提供了轻量化、更有优势的检索方案：
下表列举了各数据库的原生向量能力的功能差异：
三、RDS MySQL 与 MariaDB 、pgvector的向量索引性能对比
市面上主流数据库的向量索引存在索引构建耗时长、向量检索耗时长和向量索引占用大量磁盘存储空间这几个痛点。火山引擎 RDS MySQL 针对上述痛点，进行了深度的内核优化，同时从索引构建速度、索引的大小、索引查询性能三个方面，横向对比了与MariaDB 13.1 （同属 MySQL 生态）和 pgvector 0.8.2 （PostgreSQL 生态中最受欢迎的向量索引扩展）的差异。
MariaDB 的向量索引都是采用串行索引构建的，这就导致了构建大量向量索引的耗时极长。而火山引擎依靠自研的高性能并行构建引擎，打破了向量索引构建的瓶颈，即使是百万级向量数据，也可以快速构建向量索引。
本次测试使用参数 m=16、ef_construction=128 的 HNSW 索引配置，选取两组不同向量维度的数据集，统计了从向量数据载入至索引构建的整体耗时。
根据柱状图的对比数据，可以得出以下结论：
向量数据集越大，并行构建向量索引的效率提升越明显，在百万级向量索引构建场景下，索引的构建时间从 42 分钟缩短到至 11 分钟以内。
原生 pgvector 仅支持 Float32 向量存储，构建的索引占用的磁盘空间较大。而火山引擎 RDS MySQL 提供 SQ16、SQ8 两种标量量化，用更紧凑的方式存储向量索引。
结合上述柱状图对比数据，可以得出以下结论：
1536 维、5 万条向量数据： MariaDB 构建的索引大小为 218.1 MB，pgvector 构建的索引大小为 391 MB，火山引擎 RDS MySQL 构建的索引大小为 220.4 MB。
768 维、100 万条向量数据： MariaDB 构建的索引大小为 2.135 GB，pgvector 构建的索引大小为 3.906 GB，火山引擎 RDS MySQL 构建的索引大小为 2.219 GB。
相比 pgvector，开启 SQ16 量化后索引大小可缩减至 1/2，SQ8 量化后进一步缩减至 1/4，可以有效减少向量索引占用的磁盘空间，降低存储成本。
3、索引的查询性能：高召回下查询吞吐领先 2~3 倍
本次性能测试使用行业公认基准工具 VectorDBBench 执行，基于高召回率的实用业务区间，统计各数据库向量检索吞吐（QPS）指标。
结合上述柱状图对比数据，可以得出以下结论：
1536 维 5 万条向量数据、97% 召回率： MariaDB 向量检索吞吐（QPS）为 5326，pgvector 向量检索吞吐（QPS）为 3600，火山引擎 RDS MySQL 向量检索吞吐（QPS）为 8334。相比之下，火山引擎 RDS MySQL的向量吞吐（QPS） 约为 MariaDB 的 1.6 倍、pgvector 的 2.3 倍。
768 维 100 万条向量数据、95% 召回率： MariaDB 向量检索吞吐（QPS）为 3703，pgvector 向量检索吞吐（QPS）为 2100，火山引擎 RDS MySQL 向量检索吞吐（QPS）为 4838。相比之下，火山引擎 RDS MySQL的向量吞吐（QPS） 约为 MariaDB 的 1.3 倍、 pgvector 的 2.3 倍。
四、对接开源框架，RDS MySQL 就是 RAG 向量库
除了具备高性能向量索引的能力外，是否能低成本、快速便捷地接入 AI 应用也很重要。火山引擎 RDS MySQL 官方适配 LangChain、LlamaIndex 两大主流 RAG 开发框架，将底层的向量操作 SQL 封装成标准的 vector_store 接口，仅调用框架标准 API 即可完成向量表和向量索引的都贱、向量的增删改查、相似度检索等操作。开发者不用再手写 SQL，即可将 RDS MySQL 作为 RAG 框架原生向量存储后端。
综上所述，您的 MySQL 实例可以直接作为向量数据库去使用，无需再额外部署 Milvus、Pinecone 或 Weaviate 等向量引擎数据库了；并且业务数据和向量数据存储在同一张表中，也保证了业务数据与向量数据的一致性。
from langchain_community.vectorstores import MySQLVectorStore
vectorstore = MySQLVectorStore( connection_string="mysql+pymysql://user:pass@rds-endpoint:3306/mydb", embedding_function=embeddings,
table_name="documents")
results = vectorstore.similarity_search("如何配置数据库备份？", k=5)
火山引擎 RDS MySQL 为标准的 MySQL 补齐了向量数据存储与高性能向量索引能力，填补了 MySQL 生态在 AI 场景的短板。它支持 MySQL 8.0 和 MySQL 8.4 两个版本，完全兼容 MySQL 9.x 的标准 VECTOR 向量字段定义和向量转换语法，不用改造业务代码，同时也具备高性能索引构建与检索能力，并适配 LangChain、LlamaIndex 开发框架。
如果您正在为 AI 应用选择向量数据库，又想减少额外部署向量数据库的成本，可以选择火山引擎的 RDS MySQL（点击阅读原文获取），即可一站式落地企业 RAG 业务。
