Amazon Aurora PostgreSQL with pgvector：pgvectorプラグインでベクター類似性検索が可能だが、フルテキスト検索とのハイブリッド検索はアプリケーション側での追加実装が必要。1,000万件規模ではクラスターインスタンスの手動スケールアップが必要でインフラ管理負担が増大する
Aurora PostgreSQL with pgvectorはベクター検索に対応しますが、フルテキスト検索との組み合わせには独自実装が必要です。1,000万件規模では手動でのクラスタースケールアップが必要となり、小規模な運用チームへのインフラ管理負担が増大します。
C
Amazon RDS PostgreSQL with pgvector：pgvectorプラグインによるセマンティック検索が可能だが、サーバーレスでなく容量計画と手動スケーリングが必要。1,000万件のP99 200ms要件を安定的に満たすには大型インスタンスの常時稼働が必要となりコスト効率が低い
RDS PostgreSQL with pgvectorは非サーバーレスのため容量計画と手動スケーリングが必要です。1,000万件規模でP99 200msを安定的に維持するには大型インスタンスの常時稼働が必要となり、コスト効率も低くなります。ハイブリッド検索も追加実装が必要です。
D
Amazon MemoryDB for Redis：インメモリ処理による低レイテンシーを実現できるが、フルテキスト検索（BM25等）のサポートが限定的でハイブリッド検索の実装が複雑。1,000万件規模のベクターデータをメモリに保持するコストはストレージベースのソリューションと比較して大幅に高い
MemoryDB for Redisはインメモリ処理で低レイテンシーを実現できますが、1,000万件のベクターデータをメモリに保持するコストは莫大になります。またBM25等のフルテキスト検索サポートが不十分で、ハイブリッド検索の実装がOpenSearchと比較して複雑になります。
解説
Amazon OpenSearch Serverless は Bedrock Knowledge Bases のベクターストアとして、このシナリオのすべての要件を満たします。k-NN（近傍探索）によるセマンティック検索と BM25 によるフルテキスト検索をネイティブにサポートしており、ハイブリッド検索クエリで両者を組み合わせることができます。「MI」と「心筋梗塞」のような概念的類似性はセマンティック検索で、完全一致が必要な医学用語はキーワード検索でカバーできます。サーバーレスアーキテクチャのため自動スケーリングが行われ、1,000万件規模への拡張もインフラ変更なしに対応可能です。
選択肢BのAmazon Aurora PostgreSQL with pgvectorはベクター検索に対応しますが、フルテキスト検索とのハイブリッド検索はアプリケーション側での独自実装が必要です。1,000万件規模ではデータベースクラスターの手動スケーリングが必要となり、運用負担が増大します。
選択肢CのAmazon RDS PostgreSQL with pgvectorも同様に、ハイブリッド検索には追加実装が必要です。非サーバーレスのため容量計画が必要で、1,000万件でのP99 200msレイテンシーを保証するには大型インスタンスの常時稼働が求められます。
選択肢DのAmazon MemoryDB for Redisはインメモリ処理でレイテンシーは低いですが、1,000万件のベクターデータ（1536次元float32等）をメモリに保持するコストは非常に高くなります。また、BM25等のフルテキスト検索サポートが不十分でハイブリッド検索の実装が複雑です。