火山引擎、RDS MySQL に高性能ベクトルインデックス機能を追加
本文の状態
日本語全文を表示中
詳細モードで約8分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
ByteDance Engineering
火山引擎は RDS MySQL に高性能ベクトル索引を実装し、RAG アーキテクチャの構築に必要な追加データベースの不要化と、既存の MySQL ユーザーへの低コストなベクトル検索機能提供を実現した。
AI深層分析を開く2026年8月6日 21:43
AI深層分析
キーポイント
単一 DB での RAG 実装の実現
火山引擎は RDS MySQL に高性能ベクトル索引を追加し、ユーザーが追加のベクトルデータベースをデプロイすることなく、1 つの MySQL 表で業務データとベクトル検索を同時に実行可能にした。
他社製品との機能比較優位性
Oracle の MySQL 9.0 はベクトル索引を未サポートだが、火山引擎は MySQL 8.0 および 8.4 でネイティブに高性能ベクトル索引をサポートし、HeatWave などの追加コンポーネント購入不要で標準機能として提供している。
インデックス構築速度の劇的向上
火山引擎は自研の並列構築エンジンにより、百万件規模のデータでも索引構築を大幅に短縮し、MariaDB や pgvector と比較して最大 6 倍の高速化を実現した。
ストレージ効率の最適化
SQ16 および SQ8 の標量量化技術を採用することで、pgvector の Float32 保存と比較し、インデックスサイズを最大で 4 分の 1 に削減し、ディスク使用量を大幅に抑制した。
SQ16/SQ8 量化によるストレージコスト削減
SQ16 量化で索引サイズが半分に、SQ8 量化では 4 分の 1 に縮小され、ディスク使用量とコストを大幅に削減できる。
重要な引用
火山引擎 RDS MySQL 正式推出了高性能向量索引，用户不用再单独部署向量数据库
火山引擎依靠自研的高性能并行构建引擎，打破了向量索引构建的瓶颈
开启 SQ16 量化后索引大小可缩减至 1/2，SQ8 量化后进一步缩减至 1/4
火山引擎 RDS MySQL 向量检索吞吐（QPS）约为 MariaDB 的 1.6 倍、pgvector 的 2.3 倍
編集コメントを表示
編集コメント
ベクトル検索機能のデータベース統合は、AI アプリケーション開発の障壁を下げ、運用コストを削減する実用的な進展である。特に大規模データ処理における並列構築と圧縮技術の成果は、実環境での導入判断において重要な指標となる。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
原创 火山引擎数据库 2026-08-06 18:00 北京
点击阅读原文获取火山引擎 RDS MySQL 向量索引
一、火山引擎 RDS MySQL の高性能ベクトルインデックス機能
ここ数年で AI が急速に進化し、AI モデルや AI アシスタントなどの製品が急増しました。これらの AI 製品のほとんどは、RAG（検索強化生成）アーキテクチャを採用しています。
ベクトルデータベースの重要性も高まり、業務に不可欠なデータベースとなっています。しかし、MySQL データベースユーザーの多くは、自社の業務データをすべて MySQL に格納しています。もしベクトル検索が必要になれば、別途ベクトルデータベースをデプロイする必要が生じます。これにより、データクエリのパスが長くなり、応答時間が遅延するだけでなく、追加でデータベースを運用するコストや、データ同期にかかる負荷、そして新たなデータベースの管理コストも増大します。
この課題を解決するため、火山引擎 RDS MySQL はついに高性能ベクトルインデックス機能を正式にリリースしました。これにより、ユーザーは別途ベクトルデータベースを構築する必要がなくなります。単一の MySQL テーブル内で、通常の業務クエリとベクトル検索の両方を実行可能となり、MySQL データベースのみで RAG 機能の完全な実現が可能になります。
二、主要データベースのベクトル機能比較
Oracle は MySQL 9.0 で VECTOR ベクトルフィールド型や変換関数を追加しましたが、ベクトルインデックスには対応していません。高性能な近似最近傍（ANN）ベクトル検索を行うには、全表スキャンを実行するか、有料の HeatWave コンポーネントを追加購入する必要があります。
一方、火山引擎はより軽量で優位性のある検索ソリューションを提供します：
- MySQL 8.0 および 8.4 の両バージョンで高性能ベクトルインデックスをサポートしており、MySQL 9.x へのアップグレードや、追加の有料 HeatWave コンポーネント購入は不要です。
- MySQL 9.x の標準的な VECTOR ベクトルフィールド定義およびベクトル変換構文を完全に準拠しているため、業務コードの変更が不要で、保守コストも低く抑えられます。
各データベースのネイティブベクトル機能における差異を下表にまとめました：
三、RDS MySQL と MariaDB、pgvector のベクトルインデックス性能比較
市販の主要データベースにおけるベクトルインデックスには、一般的に以下の課題があります。
- インデックス構築に時間がかかる
- ベクトル検索の実行に時間がかかる
- インデックスが大量のディスク領域を占有する
火山引擎 RDS MySQL はこれらの課題に対し、カーネルレベルでの深い最適化を行いました。同時に、インデックス構築速度、インデックスサイズ、クエリ性能の 3 つの観点から、MariaDB 13.1（MySQL エコシステムに属す）および pgvector 0.8.2（PostgreSQL エコシステムで最も人気のあるベクトルインデックス拡張）との性能を横断的に比較しました。
索引構築速度：4〜6 倍の高速化
MariaDB のベクトルインデックスはすべて順次（シリアル）に構築されるため、大量のベクトルデータを扱うと構築に非常に時間がかかります。これに対し、火山引擎（Volcengine）は独自開発した高性能な並列構築エンジンを採用し、ベクトルインデックス構築のボトルネックを解消しました。百万件規模のベクトルデータであっても、迅速にインデックスを構築することが可能です。
今回のテストでは、HNSW インデックスの設定として m=16、ef_construction=128 を使用し、異なるベクトル次元を持つ 2 つのデータセットを用意して、ベクトルデータのロードからインデックス構築完了までの全体所要時間を計測しました。
棒グラフの比較データから、以下の結論が導き出されます。
- 1536 次元・5 万件のベクトルデータ：MariaDB は構築に 126 秒を要しましたが、pgvector は 27.76 秒、火山引擎 RDS MySQL はわずか 22 秒でした。火山引擎 RDS MySQL の構築速度は MariaDB と比較して約 6 倍の向上です。
- 768 次元・100 万件のベクトルデータ：MariaDB は 2524.5 秒、pgvector は 378.5 秒、火山引擎 RDS MySQL は 645.6 秒でした。火山引擎 RDS MySQL の構築速度は MariaDB と比較して約 4 倍の向上です。
ベクトルデータセットが大きいほど、並列構築による効率化の恩恵は顕著になります。百万件規模のインデックス構築シーンでは、所要時間が 42 分から 11 分以内へと大幅に短縮されました。
インデックスサイズ：2〜4 倍の削減
ネイティブな pgvector は Float32 ベクトルストレージのみをサポートしており、構築されるインデックスがディスク領域を多く占有します。一方、火山引擎 RDS MySQL では SQ16 や SQ8 というスカラー量子化（Scalar Quantization）に対応し、よりコンパクトな形式でベクトルインデックスを保存できます。
上記の棒グラフ比較データに基づき、以下の結論が得られます。
- 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 でした。
SQ16 量化を有効にすれば、pgvector と比較してインデックスサイズが半分になり、SQ8 量化ではさらに 4 分の 1 に縮小できます。これにより、ベクトルインデックスが消費するディスク容量を大幅に減らし、ストレージコストの削減を実現します。
- インデックスの検索性能：高再現率で QPS が 2〜3 倍上回る
今回の性能テストでは、業界標準のベンチマークツール「VectorDBBench」を使用し、実務で重視される高再現率の範囲を基準に、各データベースのベクトル検索スループット（QPS）を計測しました。
上記の棒グラフを比較すると、以下の結論が得られます。
1536 次元・5 万件のベクトルデータで再現率 97% の場合：MariaDB のベクトル検索スループット（QPS）は 5326、pgvector は 3600 に対し、火山引擎 RDS MySQL は 8334 を記録しました。比較すると、火山引擎 RDS MySQL のスループットは MariaDB の約 1.6 倍、pgvector の約 2.3 倍です。
768 次元・100 万件のベクトルデータで再現率 95% の場合：MariaDB は QPS 3703、pgvector は 2100 に対し、火山引擎 RDS MySQL は 4838 を達成しました。これにより、火山引擎 RDS MySQL のスループットは MariaDB の約 1.3 倍、pgvector の約 2.3 倍となります。
四、オープンソースフレームワークとの連携：RDS MySQL がそのままベクトルデータベースに
高性能なベクトルインデックスを提供するだけでなく、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 にベクトルデータの保存と高性能なベクトル検索機能を追加することで、AI シナリオにおける MySQL エコシステムの弱点を補完しました。MySQL 8.0 と MySQL 8.4 の 2 つのバージョンをサポートし、MySQL 9.x で定義される標準的な VECTOR ベクトルフィールドやベクトル変換構文と完全に互換性があります。そのため、ビジネスコードの変更は不要です。さらに、高性能なインデックス構築と検索能力を備え、LangChain や LlamaIndex の開発フレームワークにも対応しています。
AI アプリケーション向けにベクトルデータベースの選定を検討中で、追加でベクトルデータベースを導入するコストを抑えたい場合は、火山引擎 RDS MySQL が最適です。こちらから詳細を確認し、企業向けの RAG（検索拡張生成）業務をワンストップで実現できます。
[続きを読む]
WeChat で開く
原文を表示
原创 火山引擎数据库 2026-08-06 18:00 北京
image
点击阅读原文获取火山引擎 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 组件。而火山引擎提供了轻量化、更有优势的检索方案：
在 MySQL 8.0 和 MySQL 8.4 版本上都支持高性能向量索引，不需要升级到 MySQL 9.x 版本，也不需要购买额外的付费 HeatWave 组件。
完全兼容 MySQL 9.x 的标准 VECTOR 向量字段定义和向量转换语法，不用改造业务代码，维护成本低。
下表列举了各数据库的原生向量能力的功能差异：
三、RDS MySQL 与 MariaDB 、pgvector的向量索引性能对比
市面上主流数据库的向量索引存在索引构建耗时长、向量检索耗时长和向量索引占用大量磁盘存储空间这几个痛点。火山引擎 RDS MySQL 针对上述痛点，进行了深度的内核优化，同时从索引构建速度、索引的大小、索引查询性能三个方面，横向对比了与MariaDB 13.1 （同属 MySQL 生态）和 pgvector 0.8.2 （PostgreSQL 生态中最受欢迎的向量索引扩展）的差异。
1、索引的构建速度：提升 4~6 倍
MariaDB 的向量索引都是采用串行索引构建的，这就导致了构建大量向量索引的耗时极长。而火山引擎依靠自研的高性能并行构建引擎，打破了向量索引构建的瓶颈，即使是百万级向量数据，也可以快速构建向量索引。
本次测试使用参数 m=16、ef_construction=128 的 HNSW 索引配置，选取两组不同向量维度的数据集，统计了从向量数据载入至索引构建的整体耗时。
根据柱状图的对比数据，可以得出以下结论：
1536 维、5 万条向量数据： MariaDB 构建索引耗时 126 秒，pgvector 构建索引耗时 27.76 秒，火山引擎 RDS MySQL 构建索引耗时 22 秒。火山引擎 RDS MySQL 构建索引的速度相比 MariaDB 提升约 6 倍。
768 维、100 万条向量数据： MariaDB 构建索引耗时 2524.5 秒，pgvector 构建索引耗时 378.5 秒，火山引擎 RDS MySQL 构建索引耗时 645.6 秒。火山引擎 RDS MySQL 构建索引的速度相比 MariaDB 提升约 4 倍。
向量数据集越大，并行构建向量索引的效率提升越明显，在百万级向量索引构建场景下，索引的构建时间从 42 分钟缩短到至 11 分钟以内。
2、索引的大小：减少2~4倍
原生 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 业务。
阅读原文
跳转微信打开
関連記事
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み