2026年10月2日(金)掲載 4,789件/本日 27件
HN26176

さらば、ベクトルデータベース。その終焉が意味すること

RIP, vector database

razin・約21時間前

議論

11件
0:razinスレ主▲261約21時間前

最近のトレンドとして、専用のベクトルデータベースは本当に必要なのか?という議論が活発化しています。既存のデータベースやライブラリによるベクトル検索の実装が進化する中で、ベクトルDBという独立したカテゴリー自体が消え去ろうとしている現状について考察します。

1:gopalv約21時間前

「ライトアンプリフィケーション(書き込み増幅)が大きすぎて、インデックスのスループットを調整する努力が収穫逓減に達し始めている」

「ANNアドレスに依存しない」

これは、まさにturbopuffer v3が行っている変更だね。想像できる通り、簡単な変更じゃない。

これって、PostgresとMysqlがインデックスを構築する方法と完全に並行した話だよね。

設計の選択が、Postgresの設計パターンからMysqlのそれへと移行したってこと。違いはインデックス再構築コストとルックアップコストのバランスにあって、Postgresはルックアップに最適化されているのに対し、Mysqlは書き込み時のインデックス作成に最適化されている。もっと正確に言えば、PostgresはJOINを駆使した優れたスキーマ設計で強みを発揮し、Mysqlは正規化が不十分で同じテーブルに多数のインデックスが存在するような設計に最適化されていたんだ。

Postgresは、常にインデックスをPostgres内部の行ID(更新のたびに変わる任意の値)に向けている。

一方Mysqlは(ストレージエンジンがプラグ可能だと仮定すれば)、常にプライマリインデックスのエントリを指し示し、ルックアップに一段階間接参照を挟んでいる。

つまり、Mysqlのインデックスを不変なIDに向けているから、行のプライマリキーを更新しない限り、データに対して行った属性ルックアップのためにインデックスをすべて更新する必要はないってわけ。

最近はデータベースからは少し離れているけど、NIMBLEファイルフォーマットの設計には、この特定のアイデア(ワイドテーブル)に関連する癖がたくさんあるよ。

でも、インデックス増幅を防ぐためにPostgresからMysqlへ移行したという古いUberの記事[1]は、まさに今回の投稿の写し鏡だね。

[1] - https://www.uber.com/us/en/blog/postgres-to-mysql-migration/

2:drewlanenga約20時間前

マルチベクトル重複の件は納得。ベクトルごとに全属性をコピーするのは爆発的に増えるからね。で、新しいプライマリインデックスは何なの?

3:gk1約20時間前

ベクトルデータベースって、最初からベクトルやデータストレージというよりは、検索のためのものだったよね。でも、その言葉が定着しすぎて、企業もそれを手放すのに時間がかかりすぎた。残念だね :)

4:marekgalovic約20時間前

「ベクトルプライマリインデックスの問題点」

これについてはTopKで随分前に気づいていて、柔軟なサーバーレス検索エンジンをゼロから構築したよ。高密度/低密度ベクトル、レイトインタラクション、語彙検索、正規表現インデックス、フィルタリング、カスタムスコアリングを1つのクエリでサポートしてる。

5:Tsarp約20時間前

似たようなユースケースではlancedbがすごく気に入ってる。単にOSSだからというだけじゃなくて、LanceがANNを(turbopuffer v3のように)セカンダリインデックスとして扱っている点がいい。行はフラグメント内に保持されて、ベクトルインデックスがそれを移動させることはないからね。

6:tschellenbach約19時間前

AI関連の技術は、これまで見た中でも一番激しい浮き沈みを繰り返してるよね。

7:ironqcold約18時間前

同じスケールで1k+ QPSの時のp99レイテンシを見てみたい。

8:real_faxenoff約17時間前

ローカルの「コードグラフMCPツール」を開発中で(未公開)、似たような道をたどってきた。ただ、データベース内のベクトル数が少ない(5000万行のプロジェクトでも)から、もう少し先へ進めたかもしれない。

最初は人気のベクトルDBを全部試したけど、パフォーマンスにはがっかりした。結局、一番良くて速かったのは、SQLite上でマルチデータベースシステムを構築することだったよ。マルチクライアント処理に関連する部分をすべて削除してコンパイルして、排他モードだけを残した。すべて可能な限りバイナリに近付けてある。インデックスは完全に独立していて、事前学習済みのIVF(GPU上で構築、25万ベクトルを4秒で処理・保存)。今の最大の課題は頻繁なデータ変更で、再計算を減らすための最適化を実装する必要がある。

今のところ、正しい方向に進んでいるベクトルデータベースの実装には出会えていないな。Lancedbくらいは有望そうだけど、自分のニーズにはちょっと重すぎる。

9:croemer約15時間前

ダッシュボードが最後に更新されたのは9月7日で、開始は9月5日。バグ?それとも進捗なし?ブログ記事にリンクされてるから動くことを期待してるんだけど: https://turbopuffer.com/v3

10:DevKoala約13時間前

そのうちMarkdownを売るようになるんだろうな。