ベクトルの保存先をNeo4jにまとめ、Milvusを外せるか。その判断材料として、Beekleの自社システムで検索性能と実装上の課題を検証しました。今回は、その途中結果と構成ごとの利点・課題を紹介します。
測定条件
- Neo4j 5.20.0／Milvus 2.4.17。GitHub Actions上で実行。
- 合成ベクトル2,000件、上位80件取得、同時実行1、10秒間・1回の暫定測定。
- ホストは2 vCPU・約8.3GB RAM。メモリ上限はNeo4j 2GiB、Milvus 3GiB。CPU制限なし。
- MilvusはIVF_FLAT、Neo4jの近似検索はHNSW系ANN。実文書や最新バージョン同士の比較ではありません。
検索単体ではMilvusが速かった
検索方式 | 中央値 p50 | p95 | スループット |
|---|---|---|---|
Milvus | 2.10ms | 2.67ms | 460回/秒 |
Neo4j ANN（近似検索） | 32.93ms | 47.57ms | 29.1回/秒 |
Neo4j exact（全件比較） | 82.06ms | 102.17ms | 11.7回/秒 |
検索時間の中央値は、Neo4j ANNがMilvusの約15.7倍、exactが約39.1倍でした。この条件では、Milvusの検索性能が際立っています。
ただし、短時間の測定で、同じ構成の再測定でも中央値は25〜35%変動しています。資源配分や索引方式も異なるため、製品一般の性能差や本番の処理能力を示す数字ではありません。
検索品質と実装で分かったこと
合成データの10クエリを厳密解と比較したRecall@10は、MilvusとNeo4j exactが1.00。Neo4j ANNは再起動前0.99、再起動後0.92でした。再起動後の変化の原因は未確定で、追加測定が必要です。この再現率は、実文書に対する検索品質を意味しません。
自社システムの実装では、ベクトルの実体を見ずに整備率100%を返す監視と、削除に失敗しても再試行しない処理が見つかりました。保存先をNeo4jに変えるだけでは直らず、実体の照合やトランザクション境界の見直しが必要です。
併用とNeo4j統合のメリット・デメリット
今回の実測と実装調査を踏まえた整理です。統合による運用負担の軽減や、負荷への影響は、まだ実証されていません。
構成 | メリット | デメリット・必要な対応 |
|---|---|---|
Milvus＋Neo4jの併用 | 今回速かったMilvusの検索を活かし、Neo4jで関係性を扱える。 | 2つのDBの運用と同期が必要。更新・削除の再試行や、欠損の監視が欠かせない。 |
Neo4jへの統合 | 保存先を集約でき、同一トランザクションや関係性による候補の絞り込みを設計しやすい。 | 今回の検索単体は遅かった。通常のグラフ操作への影響、ANNの品質、整合性を得るための実装変更を確認する必要がある。 |
併用で削除済みの検索候補を正本との照合時に落とすと、その分だけ有効な結果件数が減ります。Neo4j統合も、ANN検索の後で除外するだけなら同じ問題が残るため、候補を絞るタイミングまで設計する必要があります。
今回の実験からの示唆
- Milvusを残す価値はある。今回の検索単体では大きな差があり、「Neo4jでも検索できる」だけを理由に専用DBを外すのは早い。検索はMilvus、関係性はNeo4jという役割分担は有力です。
- 統合の効果は実装次第。保存先を一つにしても、削除処理や欠損検知の穴は自動では直りません。併用なら同期と復旧、統合なら同一トランザクションでの更新・削除まで設計する必要があります。
- 倍率だけで構成を決めない。Neo4j exactの中央値82msで十分な用途もあります。検索負荷が通常操作に与える影響と、同期・障害対応を含む運用負担まで並べて判断したいところです。
なお、Neo4jへの統合には、今回見つかった実装上の課題を解消する条件が残っています。混合負荷の本測定は今回の検証時点で実行中で、実文書の検索品質も未検証。併用・統合の最終判断には、追加の測定が必要です。
出典：Beekle自社検証（2026年9月）