専用ベクトルDBにはない、TiDBに機能追加する意味とは
ベクトル検索を実現するためには、大きく2つの方法が考えられるだろう。1つは、専用のベクトルデータベースを用いる方法だ。Facebook AI Researchが開発した、大規模なベクトル検索に特化したライブラリの「Faiss」、大規模ベクトルデータの管理と検索に特化したオープンソースプラットフォームの「Milvus」、ベクトル検索に特化したクラウドサービスの「Pinecone」など、生成AIのブームも後押しして多様な製品・サービスが提供されている。
もう1つの方法が、既存のデータベース製品に追加された“ベクトル検索”機能を利用するものだ。たとえば、Oracle Database 23aiではVector Search機能を提供しており、PostgreSQLにはpgvectorがある。また、Amazon DocumentDBとDynamoDB、Azure Cosmos DB、Google BigQueryなど、今や多種多様なデータベースにベクトル検索機能が追加されている状況だ。
PingCAP CTO兼共同創業者 Ed Huang氏は、ベクトル検索はTiDBにとって「サイドカー」的であり、「専用のベクトルデータベースでは、大容量データをサポートすることが難しい製品もありますが、元々大きな拡張性を持つTiDBにベクトル検索機能を加えることで、その問題を解決します」と話す。そもそもベクトルデータベースを利用する際には、類似するベクトル情報がヒットすれば、その元となったデータを参照することになる。元のデータは既存のデータベースなどに別の形で管理されているため、それらを融合して利用することは簡単ではない。
一方、TiDBのようなリレーショナルデータベースに元のデータを入れておき、同じデータベースにベクトル値も格納しておけば、それらを一緒に活用することは容易だ。関連する別の情報などもSQLで“JOIN”して検索することも簡単にできる。1つのデータベースで管理できれば、AI機能開発におけるデベロッパーの工数を削減できるとHuang氏は主張する。
もう1つの利点は「拡張性」だ。もはや、すべてのビジネスデータを取り込んだLLMを独自に構築することは、コストや手間などからも現実的ではない。そのためRAGを用い、既存のLLMなどに最適な情報を与えることで、個社ごとのビジネス目的にあった精度の高い結果を得るようになっていくだろう。RAGは今後企業が生成AIを活用する上で主流の方法となり、その際にいかに関連性の高いデータを渡せるかが重要となる。その効率を良くするには、膨大なデータの中から類似性の高いものを確実に見つけられる必要があり、このときに分散型データベースかつ高い拡張性を持つTiDBが有効というわけだ。
先述のように、既存のデータベースにベクトル検索機能を追加する動きは多数見受けられる。とはいえ、たとえばPostgreSQLのpgvectorは現時点でシングルノードにしか対応しておらず、大規模なベクトルデータの要求には応えられないとHuang氏。また、Oracle Cloud Infrastructure（OCI）のクラウドサービスである、MySQL HeatWave Database Serviceにベクトル検索機能を追加するとのアナウンスはあるが、コミュニティ版にはまだベクトル検索機能が追加されるとの話になっていない。そのため、AWSやGoogle Cloudなど、マルチクラウドで利用できるTiDBにいち早く機能追加をすることで、市場での優位性も築けそうだ。
その上で、TiDB Serverlessにベクトル検索機能を追加することで、コスト面でもメリットを発揮できるとHuang氏は語る。TiDB Serverlessは、クラウドネイティブなアーキテクチャとAmazon S3などの安価なオブジェクトストレージを活用し、コスト削減に注力したサービス。これをベースに大量のベクトルデータを扱えるようにしたことで、コスト効率の良いベクトル検索機能が提供できるのだ。
