Redis Searchは、インメモリデータストアのRedisに全文検索とベクトル検索の機能を追加するモジュールで、Redis Stackや旧RediSearchとして提供されてきました。Redisが本来得意とする低レイテンシなキーバリュー操作と組み合わせ、ベクトル類似度検索とBM25検索を同じインスタンス内で扱えるのが大きな特徴です。本稿ではインデックス構造、クエリAPI、運用上の考え方を整理します。
この記事の目次
- Redis上のセカンダリインデックス
- ハイブリッドクエリと表現力
- メモリコストと永続化のバランス
- Redis Searchを採用する場面
- まとめ
Redis上のセカンダリインデックス
Redis SearchはFT.CREATEコマンドで、Redisに保存されているHashやJSONドキュメントに対してセカンダリインデックスを構築します。通常のRedisがキーバリュー単体での参照に閉じているのに対し、Redis Searchを使うと「住所が東京で、価格が10万円以下で、商品名にXを含む」といったセカンダリ条件付きクエリをサブミリ秒で実現できます。
ベクトル検索もこの仕組みの拡張として実装されており、VECTOR FLATまたはVECTOR HNSWの指定でベクトルカラムをインデックス化します。FLATはブルートフォース、HNSWは近似で、それぞれL2/IP/Cosineの距離指標を選べる構造です。Redisのインメモリ特性によりリアルタイム性が極めて高く、書き込みから検索結果へ反映されるまでの遅延が他の永続化前提のベクトルDBより圧倒的に短い点が際立ちます。
ハイブリッドクエリと表現力
Redis SearchのクエリDSLは独特で、FT.SEARCHに対して全文検索条件とフィルタ、そして=>[KNN k @vector $blob AS score]のような構文でベクトル検索を組み合わせて指定します。BM25でテキストを絞り込みつつ、その結果集合に対してベクトル類似度でリランキングをかけられるため、純粋なベクトルDBに比べてプリフィルタの表現力が高い構造です。
Redis 7.4以降はFT.AGGREGATEにもベクトル検索が組み合わさり、ベクトル類似度をスコアとした集計や、属性ごとのトップNの取得が一発で書けるようになりました。JSONドキュメントとの組み合わせを使えば、ネストされた構造化データを保ったままベクトル検索を行えるため、製品情報やユーザプロファイルのような複雑な検索に向きます。
メモリコストと永続化のバランス
Redisはオールインメモリ前提のため、ベクトル本体もメモリに乗せる必要があり、1ベクトルあたりのメモリ使用量はディスク主体のベクトルDBより大きくなります。Redis EnterpriseではAuto Tiering機能で、ベクトルやインデックスをNVMe SSDへ自動退避させ、メモリコストを抑える構成を組めるため、コスト要件次第で選択肢が分かれます。
永続化はRDBスナップショットとAOFログの二系統で従来通りに行えますが、ベクトルインデックスの再構築はAOFリプレイに比例して時間がかかるため、計画停止時のリスタート時間を見積もっておくことが運用上重要です。MilvusやpgvectorのようにディスクストレージにIVFやHNSWを残せる製品との「メモリ vs ディスク」のトレードオフを意識して採用判断を下すのが定石です。
Redis Searchを採用する場面
Redis Searchがもっとも光るのは、すでにRedisをセッションストアやキャッシュとして本番運用している組織が、追加のベクトルDBを立てずにRAGやレコメンドを実装したいときです。アプリケーションサーバから低レイテンシで埋め込みを引きたい場合や、リアルタイム性が要求される広告配信、不正検知のような用途にも適合します。
一方で10億ベクトル規模の純粋なベクトル検索基盤としては、メモリコスト面でMilvusやpgvectorscale、Qdrantに分が悪い場面もあり、「総合データ基盤としてのRedisにベクトル機能を足す」のか、「ベクトル専用DBを別立てするのか」を、ワークロードの性質から見極める姿勢が大切です。
まとめ
Redis Searchはインメモリの強みを保ったまま、全文検索とベクトル検索を統合したモジュールです。Redisを既に運用している環境でリアルタイム性の高いセマンティック検索を加えたい場合に、特に強い選択肢となります。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント