OpenData Vector: MIT ライセンスのオブジェクトストレージ上のベクトル検索

生成的 AI と大規模言語モデル（LLM）の台頭により、従来のベクトルデータベースと同様のコスト負担なしに線形にスケールできるベクトルデータベースの概念が必要となりました。OpenData Vector はベクトル検索への新しいアプローチを導入し、オブジェクトストレージを主要なストレージ層として活用し、コンピュートとストレージを実質的に分離して、スケーラブルで MIT ライセンスのプロプライエタリなベクトル検索エンジンの代替手段を提供します。

OpenData Vector のアーキテクチャ

OpenData Vector の根本的な目的は、ベクトルデータベースの主要なボトルネックである高性能ストレージのコストとスケール問題を解決することです。AWS S3、Google Cloud Storage、Azure Blob Storage などのオブジェクトストレージを利用することで、システムは高性能検索に通常必要とされる高価な SSD バックエンドインフラを使用せずに、埋め込みの大規模データセットを維持できるようにします。

コンピュートとストレージの分離により、独立したスケーリングが可能になります。検索量が増加した場合、クエリ負荷に対応するためにコンピュートノードを追加でき、複数の高価なディスクにデータセット全体を複製する必要がありません。逆にデータ量が増えても、オブジェクトストレージは高性能ブロックストレージに比べてはるかに安価であるため、ストレージコストは低く抑えられます。

パフォーマンスと実装の詳細

オブジェクトストレージはローカル SSD に比べて本質的に遅いですが、OpenData Vector はレイテンシを軽減するための戦略を実装しています。アーキテクチャはインデックスとデータを分離するパターンに従い、インデックスはキャッシュされたり、より高速な層に保存されたりして、クエリ結果が迅速に返されるようにします。

このアプローチは Turbopuffer のような他の高性能ベクトル検索エンジンで見られるアーキテクチャパターンに似ています。目標は、効率的なインデックス作成とメモリ管理を通じて検索結果の精度を保ちつつ、高いクエリスループットを実現することです。

コミュニティディスカッションと重要な考慮点

リリース後、コミュニティはパフォーマンスのトレードオフやプロジェクトの成熟度に関していくつかの重要な質問を提起しています。

パフォーマンスギャップ

主要な懸念の一つは、OpenData Vector が高度に最適化されたハードウェアアクセラレートシステムとどのように比較されるかです。コミュニティメンバー @oliverio が指摘するように、いくつかのプロプライエタリシステムではハードウェアおよびファームウェア層で大きな最適化が行われており、パフォーマンスギャップを生む可能性があります。OpenData Vector の課題は、オブジェクトストレージの汎用性を保ちつつ、これらの最適化をオープンソースプロジェクトに実際に取り込むことです。

オブジェクトストレージの QPS コスト

もう一つの議論点はリクエストレートのコストです。GET や PUT 操作に伴うリクエストコストのため、クエリ毎秒（QPS）が非常に高くなるとオブジェクトストレージが高価になるという一般的な認識があります。

"QPS が高くなると、オブジェクトストレージは「普通」の SSD と比べて非常に高価だと考えていました。"

これに対処するため、オブジェクトストレージベースのシステムは通常、積極的なキャッシュ層を導入したり、データがストレージ層にコミットされる前に DB サーバーで大幅な前処理を行ったりします。オブジェクトストアへの直接呼び出し回数を減らすことで、ストレージのコスト効率とローカルディスクのパフォーマンスの両方を維持できます。

結論

OpenData Vector は、ベンダーロックインを回避し、埋め込みデータの管理権を保持したいユーザーに対し、魅力的な MIT ライセンスの代替手段を提供します。ベクトル検索エンジンをオブジェクトストレージに移行することで、従来の高価で高性能なストレージ要件というモデルに挑戦し、開発者や MIT ライセンスのソフトウェアプロジェクトにとって大規模ベクトル検索をより利用しやすくします。