ベクトルDB / ストレージ

ClickHouse可観測性

追記が中心で値の種類が多いデータ——モデル呼び出しごとに1行を記録し、後からモデル名やコスト、エラーで絞り込む——に向いた列指向エンジンです。Langfuseは2024年12月にトレースの保存先をPostgreSQLからClickHouseへ移し、2026年1月にはClickHouseがLangfuseを買収したため、セルフホストの可観測性基盤を組むと下層にこれが入る構成が増えています。一方でトランザクション処理には向かず、更新や削除は行の書き換えではなく列パート単位の再作成になるため、アプリケーションの状態を書き込む先ではなく、エージェントの実行記録が着地する場所として扱ってください。

MilvusベクトルDB

ストレージと計算を分離し、インデックス構築とクエリを独立にスケールさせる設計です。数十億ベクトル規模で必要になるアーキテクチャがここにあります。その能力は運用負荷と引き換えであり、数百万ベクトル未満の規模ではより単純な選択肢のほうが適しています。

QdrantベクトルDB

Rust製で、メタデータによる絞り込みを検索後ではなく検索中に適用する設計です。大規模なコレクションのうち狭い範囲だけをエージェントが検索する場面で、結果の正しさを保てるかどうかがこの違いに現れます。ローカル開発用の単一コンテナから分散クラスタまで、同じ構成で拡張できます。

ChromaベクトルDB

検索を動かすまでの摩擦が最も少ない選択肢です。サーバーの構築もクラスタのサイジングも不要です。そのためプロトタイプや小規模な本番負荷には非常に適しています。一方で、どの規模で手狭になるかは、遭遇してから慌てるのではなく事前に計画しておくべき論点です。