こんにちは。
アプリケーションサービス部、DevOps担当の兼安です。
今回はベクトルデータベースの内容です。
はじめに
2026年現在ベクトルデータベースは、生成AIの回答精度向上に用いられます。
AWSにおいてはAmazon Bedrockとセットで語られることが多いと思いますが、AIの部分をAWS以外で動かすことも多いと思うので今回はベクトルデータベースだけにフォーカスしようと思います。
AWSにおいて、ベクトルデータベースを構築する手段は複数あります。
今回はその中でもコストを意識したサーバーレス構成として、Amazon Aurora Serverless v2＋pgvector、Amazon OpenSearch Serverless、Amazon S3 Vectorsを選定して10万件のデータを投入・検索し、その処理時間を検証してみました。
10万件のデータというのはベクトルデータベースとしてはデータ量がとても少ないと思いますが、最初の一歩としてどれを選ぶかという観点で少量のデータで検証してみたとお考えください。
また、データはランダム値を投入しています。
ランダム値だとデータの塊（クラスタ）ができませんが、サービスとそのアーキテクチャごとのオーバーヘッドや投入・検索の『処理時間』の比較にフォーカスしているためあえて目を瞑っているとお考えください。
本記事では各データベースを以下のように記載します。
- Amazon Aurora Serverless v2＋pgvector：Aurora
- Amazon OpenSearch Serverless：OpenSearch
- Amazon S3 Vectors：S3 Vectors
本記事のターゲット
本記事は一般的な関係データベースに触れたことがある上で、これからベクトルデータベースについて学ぶ人を想定した内容になっています。
検証にあたっての準備知識
検証に入る前に、検証の手順と結果を読んでいただくにあたり、私の方で必要と思う基礎的な知識を書かせていただきます。
ベクトルデータベースの検索アルゴリズムとインデックスアルゴリズム
最初にベクトルデータベースの検索アルゴリズムとインデックスアルゴリズムについて触れておきます。
ベクトルデータベースには2つのアルゴリズム要素があります。
それが検索アルゴリズムとインデックスアルゴリズムです。
ベクトルデータベースにおける検索手法は、
大きく分けて以下のKNN（K-Nearest Neighbor / K最近傍探索）とANN（Approximate Nearest Neighbor / 近似最近傍探索）の2種類があります。
私が知る限り、ANNの方がよく使われており、ANNを実現するためのインデックスアルゴリズムには複数の種類があります。
代表的なものとしてHNSW（Hierarchical Navigable Small World）とIVF（Inverted File Index）があります。
これも私が知る限り、HNSWの方がよく使われる印象です。
本記事の検証では、AuroraとOpenSearchについてはANNの検索手法とHNSWインデックスを使用してデータ投入と検索を行います。
S3 Vectorsについては、ANNによる近似検索をサポートしていますがインデックスアルゴリズムは公表されていないため、そこは問わずにデータ投入と検索を行います。
ベクトル次元数とtop_k
ベクトル次元数とは、各データを表現するベクトルの要素数のことです。
たとえば次元数が1536の場合、1つのデータは1536個の数値の配列として格納されます。
次元数は使用する埋め込みモデル（Embedding Model）によって決まり、次元数が大きいほどデータの意味をより細かく表現できますが、その分ストレージと計算コストが増加します。
top_kとは、検索時に返す類似度上位の件数を指すパラメータです。
たとえばtop_k=10の場合、クエリベクトルに最も近い上位10件の結果が返されます。
RAG（Retrieval-Augmented Generation）においては、このtop_kで取得した結果をLLMのコンテキストとして渡すのが一般的です。
Amazon OpenSearch Serverlessのストレージ
OpenSearchをServerlessで組んだ場合、ベクトルデータとベクトルインデックスはAmazon S3に格納することになります。
Amazon S3 をインデックスのプライマリデータストレージとして使用します。
キャパシティ管理の単位：ACUとOCU
Amazon Aurora Serverlessのキャパシティ（容量）はACUという単位で管理します。
最小・最大ACUを設定すると負荷に応じてその範囲でACUは増減します。
Amazon OpenSearch Serverlessの場合はOCUという単位でキャパシティを管理します。
OCUはインデックス用と検索用で分かれており、本記事執筆時点ではデフォルトがそれぞれ最大10で設定されています。
OCUは最小の設定はなく、AWS側で最小値が設定されています。
Amazon OpenSearch Serverless でのキャパシティ制限の管理 - Amazon OpenSearch Service
アカウントで利用可能な最小キャパシティは、インデックス作成用に 1 OCU [0.5 OCU x 2]、検索用に 1 OCU [0.5 OCU x 2] です。
ベクトルデータベースの効率的なデータ投入方法
Auroraについては、関係データベースにおける一般的な大量データ投入手法が転用できます。
いわゆるバルクインサートと、投入前の一時的なインデックス削除と投入後の一括インデックス作成が有効です。
OpenSearchとS3 Vectorsについてはインデックスは自動管理のため、一時的なインデックス削除は有効ではありません。
バルクインサートのAPIを用いることになります。
OpenSearchのドキュメントにバルクインサートしたい場合はAPIを使う旨が記載されています。
（厳密にはAmazon OpenSearch ServerlessはOpenSearchは2.17系ですので、こちらのリンクは参考情報として読んでください）
Bulk - OpenSearch Documentation
S3 Vectorsの場合は、PutVectorsAPIを使用します。
PutVectors - Amazon Simple Storage Service
検証方法
Aurora・OpenSearch・S3 Vectorsのそれぞれにデータ投入した後、少し間を開けてから検索を行います。
構成図
今回はデータ投入にAmazon ECSによるコンテナを用います。
検索処理にはAWS Lambdaを用います。
プログラムはPythonを用いて、各データベースの操作には以下のライブラリを使用します。
- Aurora（pgvector）:
psycopg2 - OpenSearch:
opensearch-py+requests-aws4auth - S3 Vectors:
boto3
構成図は以下の通りです。
Auroraはプライベートサブネットに配置、ECS・LambdaをVPCに入れてアクセスします。
VPC内のECS・LambdaからのOpenSearchとS3 Vectorsへの接続はVPCエンドポイントを経由させます。
データ投入手順
- 投入前のデータ件数確認
- インデックス削除（Auroraのみ）
- データ投入
- インデックス作成（Auroraのみ）
- 投入後のデータ件数確認
投入するベクトルデータベースの内容は以下の通りです。
| 項目 | 値 |
|---|---|
| ベクトル次元数 | 1536 |
| 投入データ件数 | 100,000 |
| 検索クエリ数 | 100 |
| top_k | 10 |
投入データはECS Fargateタスク内のランダムベクトル生成ロジックを使用し、シード値から決定論的に1536次元のベクトルを生成して10万件のデータを投入します。
Auroraのキャパシティ設定は以下の通りです。
| 項目 | 値 |
|---|---|
| Aurora Min ACU | 0.5 |
| Aurora Max ACU | 10 |
OpenSearchのキャパシティ設定は以下の通りです。
OpenSearch Standby Replicasは冗長化に関する設定値です。
今回は冗長化なしとしていますが、これは処理速度低下には繋がらない認識です。
| 項目 | 値 |
|---|---|
| OpenSearch Max インデックスOCU | 10 |
| OpenSearch Max 検索OCU | 10 |
| OpenSearch Standby Replicas | DISABLED（＝冗長化なし） |
検証結果
データ投入の処理時間
各データベースにAmazon ECSを用いて、10万件のランダムデータの生成と投入を行いました。
Auroraについては投入前後のインデックスの削除と作成もECSで行なっています。
| DB | 投入時間 | インデックス作成時間 | 合計時間 | 備考 |
|---|---|---|---|---|
| Aurora | 560秒（約9.3分） | 714秒（約11.9分） | 約21.2分 | HNSW インデックス作成含む |
| OpenSearch | 527秒（約8.8分） | - | 約8.8分 | インデックス自動管理 |
| S3 Vectors | 559秒（約9.3分） | - | 約9.3分 | インデックス自動管理 |
単純処理時間でいうとOpenSearchが一番早く、Auroraが一番長いという結果になりました。
Auroraはデータ投入とインデックス作成の2段階にしていますが、これを同時にやるともっと長いかもしれません。
OpenSearchとS3 Vectorsについてはインデックス作成が非同期処理のようで、私が試した際はデータ投入が終わっても投入件数とプログラムから認識できる件数が一致するまで十数分の遅延がありました。
少なくともデータ投入直後は件数が合わないことは発生し得ると思われるので、実運用においても注意が必要と思います。
ACU・OCUの推移（CloudWatch、5分間隔 Maximum）
イメージ通り、データ投入中はACU/OCUともに上昇しています。
ACU/OCUともにMAX値に触れる動きをしていないので、性能上限によるボトルネックは発生していないと言えます。
OCUはデータ投入時においてはインデックスOCUのみ上昇するようです。
検索の処理時間
各データベースにAWS Lambdaを用いて、100回検索を行いました。
AuroraのACUはコールドスタートを回避するため、ベンチマーク実行前に最小ACUを0.5に変更しています。
| DB | 平均値 (ミリ秒) | 中央値 (ミリ秒) | P95 (ミリ秒) | P99 (ミリ秒) | スループット (クエリ数/秒) |
|---|---|---|---|---|---|
| Aurora | 13.3 | 12.5 | 18.7 | 24.1 | 75.0 |
| OpenSearch | 86.8 | 82.4 | 120.3 | 145.2 | 11.5 |
| S3 Vectors | 76.3 | 72.1 | 105.8 | 128.4 | 13.1 |
いずれのDBも十分に早いのですが、今回検証したデータ量においてはAuroraが一番速いという結果になりました。
データ量がもっと増えればOpenSearchが有利になると思われますが、この件数ではOpenSearch Serverlessはその構成の複雑さによるオーバーヘッドにより他に劣ってしまうのだと考えます。
OpenSearch Serverlessのオーバーヘッドについては通信方式がAuroraより複雑なのと、ストレージがS3であることが関係していると思います。
なお、Auroraは最小をゼロACUにした状態でもテストしています。
ゼロACUの場合、コールドスタートが発生するのでAuroraがダントツで遅いという結果でした。
OpenSearch Serverlessは最小OCUが利用者が設定できないので良くも悪くもコールドスタートは発生し得ないようです。
ACU・OCUの推移（CloudWatch、5分間隔 Maximum）
今回の範疇においてはAuroraは検索に伴いACUが上昇していますが、OCUに動きは見られませんでした。
データ投入時と同様に、ACU/OCUともにMAX値に触れる動きをしていないので、性能上限によるボトルネックは発生していないと言えます。
まとめ
今回検証した範囲においては10万件のデータならば、Auroraが一番検索が早いという結果になりました。
ベクトルデータベースは件数だけで重さが決まるものではないのですが、少量のベクトルデータならばAuroraが有利と考えます。
S3 Vectorsと比べると運用手順が少々煩雑ですが、一般的な関係データベースの運用の知識が転用できるので、個人的にはむしろS3 Vectorsより手軽と感じます。
OpenSearchとS3 Vectorsについては、バルクインサートにそれ用のAPIがあること、データ登録直後だと件数が合わないことがあるなど、関係データベースに慣れていると少々癖を感じる仕様なので、触れる場合は本記事を参考にしていただけると幸いです。
補足
「VPC内のECS・LambdaからのOpenSearchとS3 Vectorsへの接続はVPCエンドポイントを経由させます。 」とさらりと書きましたが、実は少々試行錯誤しました。
ハマりやすいポイントだと思うので、ここについては別の機会に改めて記事にします。
検証ソースコード
今回検証に使用したソースコードはこちらにアップしています。
兼安 聡(執筆記事の一覧)
アプリケーションサービス部 DS3課所属
2025 Japan AWS Top Engineers (AI/ML Data Engineer)
2025 Japan AWS All Certifications Engineers
2025 AWS Community Builders
Certified ScrumMaster
PMP
広島在住です。今日も明日も修行中です。
X(旧Twitter)
