新しいデータにご不満ですか？ベクターデータベースがお手伝いします
ビッグデータの時代、どのようなデータベース技術やアプリケーションが脚光を浴びるのか？次のゲームチェンジャーは何だろうか？
非構造化データが保存データ全体の約80～90％を占める中、私たちは増え続けるデータレイクをどう扱えばいいのだろうか？従来の分析手法を使おうと思うかもしれないが、有益な情報を引き出せない。この疑問に答えるため、Zillizの研究開発チームの "三銃士 "である郭廉東博士、阮暁帆氏、李暁孟博士は、汎用ベクトルデータベースシステムを構築する際に直面する設計と課題について論じた論文を共著で発表した。
この論文は、中国最大のソフトウェア開発者コミュニティであるCSDNが作成した雑誌Programmerに掲載されました。今回のProgrammerには、2020年チューリング賞受賞者のジェフリー・ウルマン氏、2018年チューリング賞受賞者のヤン・ルクン氏、MongoDB CTOのマーク・ポーター氏、OceanBase創業者の楊振勲氏、PingCAP創業者の黄東秀氏などの記事も掲載されています。
以下、記事全文を紹介する：
AI指向の汎用ベクトルデータベースシステムの設計と実践
はじめに
現代のデータアプリケーションは、今日のデータの約20％を占める構造化データを容易に扱うことができる。そのツールボックスには、リレーショナルデータベースやNoSQLデータベースなどのシステムがある。対照的に、全データの約80％を占める非構造化データには、信頼できるシステムが存在しない。この問題を解決するために、この記事では、従来のデータ分析が非構造化データに対して抱えるペインポイントについて説明し、さらに独自の汎用ベクトルデータベースシステムを構築する際に直面したアーキテクチャと課題について説明する。
AI時代のデータ革命
5GとIoT技術の急速な発展により、産業界はデータ収集のチャネルを増やし、現実世界をデジタル空間にさらに投影しようとしている。それはいくつかの途方もない課題をもたらしたが、同時に成長する業界に多大な利益ももたらした。これらの困難な課題の1つは、この新しい受信データをどのように深く洞察するかということである。
IDCの統計によると、2020年だけでも世界中で4万エクサバイト以上の新しいデータが生成されるという。このうち、構造化データ（高度に秩序化され、数値計算や関係代数によって整理・分析が容易なデータ）はわずか20％に過ぎない。一方、残りの80％を占める非構造化データは、データ型のバリエーションが極めて豊富で、従来のデータ分析手法では深い意味合いを明らかにすることが難しい。
幸いなことに、私たちは非構造化データとAIの同時進行的な急速な進化を経験しており、図1に示すように、AIによって様々なタイプのニューラルネットワークを通じてデータをより深く理解できるようになっている。
図1：埋め込みプロセス](https://assets.zilliz.com/newdata1_d5c34497d0.jpeg)
エンベッディング技術は、Word2vecの登場後、急速に普及し、「すべてをエンベッディングする」という考え方は、機械学習のあらゆる分野に及んでいる。その結果、生データ層とベクトルデータ層という2つの主要なデータ層が出現した。生データ層は、非構造化データとある種の構造化データで構成され、ベクトル層は、生レイヤーから機械学習モデルを通過した、分析しやすい埋め込みデータのコレクションである。
生データと比較した場合、ベクトル化データには以下のような利点がある：
- 埋め込みベクトルは抽象的なデータ型であり、非構造化データの複雑さを軽減するための統一的な代数システムを構築できる。
- 埋め込みベクトルは高密度の浮動小数点ベクトルで表現されるため、アプリケーションはSIMDを利用できる。SIMDはGPUとほぼすべての最新CPUでサポートされているため、ベクトル間の計算は比較的低コストで高い性能を達成することができます。
- 機械学習モデルによってエンコードされたベクトル・データは、元の非構造化データよりも少ないストレージ容量で済むため、より高いスループットを実現できる。
- 算術演算も埋め込みベクトル間で実行できる。図2は、クロスモーダル意味近似マッチングの例を示している。図に示された写真は、単語の埋め込みと画像の埋め込みをマッチングした結果である。
図2：クロスモーダル神経言語モデルに基づく意味埋め込みの可視化](https://assets.zilliz.com/newdata2_14e0554305.png)
図3に示すように、画像と単語のセマンティクスを組み合わせることは、対応する埋め込みをまたがる単純なベクトルの加算と減算で行うことができる。
図3：クロスモーダル神経言語モデルに基づく統一的な視覚化意味埋め込み](https://assets.zilliz.com/newdata3_3c71fc56b9.png)
上記の特徴とは別に、これらの演算子は、実用的なシナリオにおいて、より複雑なクエリ文をサポートする。コンテンツ推薦がよく知られた例である。一般的に、システムはコンテンツとユーザーの視聴嗜好の両方を埋め込む。次に、システムは埋め込まれたユーザーの嗜好と、意味的類似性分析によって最も類似した埋め込まれたコンテンツをマッチングさせ、ユーザーの嗜好に類似した新しいコンテンツを生成する。このベクトルデータレイヤーは、レコメンダーシステムに限らず、電子商取引、マルウェア分析、データ分析、生体認証、化学式分析、金融、保険などのユースケースも含まれる。
非構造化データは完全な基本ソフトウェア・スタックを必要とする
システム・ソフトウェアは全てのデータ指向アプリケーションの基礎に位置するが、データベース、データ分析エンジンなど、過去数十年にわたって構築されたデータ・システム・ソフトウェアは、構造化データを扱うためのものである。現代のデータ・アプリケーションは、ほとんど非構造化データのみに依存しており、従来のデータベース管理システムの恩恵を受けていない。
この問題に取り組むため、我々はAI指向の汎用ベクトルデータベースシステムMilvusを開発し、オープンソース化した（文献No.1~2）。従来のデータベースシステムと比較した場合、Milvusはデータのレイヤーが異なります。リレーショナル・データベース、KVデータベース、テキスト・データベース、画像・映像データベースなど、従来のデータベースは生データ層で動作するが、Milvusはベクトル・データ層で動作する。
以下の章では、Milvusを構築する際に直面した斬新な機能、アーキテクチャ設計、技術的な課題について説明する。
ベクターデータベースの主な属性
ベクトルデータベースは、ベクトルを保存、検索、解析するデータベースであり、他のデータベースと同様に、CRUD操作のための標準的なインターフェースを提供します。これらの "標準的な "機能に加えて、以下に挙げる属性もベクトルデータベースにとって重要な資質です：
- 高効率ベクトル演算子のサポート**。
分析エンジンにおけるベクトル演算子のサポートは、2つのレベルに焦点を当てています。第一に、ベクトル・データベースは、例えば前述の意味的類似性マッチングや意味的演算など、さまざまなタイプの演算子をサポートすべきである。これに加えて、類似度計算の基礎となる様々な類似度メトリックをサポートする必要がある。このような類似性は通常、ベクトル間の空間的距離として定量化され、一般的なメトリックスはユークリッド距離、余弦距離、内積距離である。
- ベクトル・インデックスのサポート**。
従来のデータベースにおけるB-treeやLSM-treeベースのインデックスに比べ、高次元ベクトルインデックスは通常、より多くのコンピューティングリソースを消費します。クラスタリングとグラフインデックスアルゴリズムを使用し、行列とベクトル演算を優先し、前述のハードウェアベクトル演算アクセラレーション能力をフルに活用することを推奨します。
- 異なる導入環境においても一貫したユーザーエクスペリエンスを提供します。
ベクターデータベースは通常、異なる環境で開発・導入されます。予備段階では、データサイエンティストやアルゴリズムエンジニアは、検証効率や反復速度に注意を払うため、ラップトップやワークステーションで作業することがほとんどです。検証が完了すると、プライベートクラスタやクラウド上にフルサイズのデータベースをデプロイする。したがって、適格なベクトルデータベースシステムは、さまざまな展開環境において一貫したパフォーマンスとユーザーエクスペリエンスを提供する必要がある。
- ハイブリッド検索**のサポート
ベクターデータベースがユビキタスになるにつれ、新しいアプリケーションが出現しています。これらの要求の中で最も頻繁に言及されるのは、ベクトルと他のタイプのデータに対するハイブリッド検索です。スカラーフィルタリング後の近似最近傍検索（ANNS）、全文検索とベクトル検索からのマルチチャネルリコール、時空間データとベクトルデータのハイブリッド検索などがその例である。このような課題には、ベクトル検索エンジンをKV、テキスト、その他の検索エンジンと効果的に融合させるための、弾力的なスケーラビリティとクエリの最適化が要求される。
- クラウドネイティブアーキテクチャ
ベクトルデータの量は、データ収集の指数関数的な増加とともに増加します。兆スケールの高次元ベクトルデータは数千TBのストレージに相当し、単一ノードの限界をはるかに超えている。その結果、水平方向の拡張性はベクトルデータベースにとって重要な能力であり、伸縮性と展開の俊敏性に対するユーザーの要求を満たす必要がある。さらに、クラウドインフラストラクチャの支援により、観測可能性を向上させながら、システムの運用と保守の複雑さを軽減する必要がある。このようなニーズには、マルチテナント分離、データのスナップショットやバックアップ、データの暗号化、データの可視化など、従来のデータベースで一般的なものもある。
ベクターデータベースシステムアーキテクチャ
Milvus 2.0は、「データとしてのログ」、「バッチ処理とストリーム処理の統合」、「ステートレス」、「マイクロサービス」という設計原則に従っている。図4はMilvus 2.0の全体的なアーキテクチャを示している。
図4：Milvus 2.0の全体アーキテクチャ](https://assets.zilliz.com/newdata4_b7f3ab6969.png)
**データとしてのログMilvus 2.0は物理テーブルを保持しません。その代わりに、ログの永続化とログのスナップショットによってデータの信頼性を確保する。ログブローカー（システムのバックボーン）はログを保存し、ログ公開-サブスクリプション（pub-sub）メカニズムを通じてコンポーネントとサービスを分離します。図5に示すように、ログブローカは「ログシーケンス」と「ログサブスクライバ」で構成される。ログシーケンスは、コレクション（リレーショナルデータベースのテーブルに相当）の状態を変更するすべての操作を記録し、ログサブスクライバーは、ローカルデータを更新し、読み取り専用コピーの形でサービスを提供するためにログシーケンスをサブスクライブする。pub-subメカニズムは、変更データキャプチャ(CDC)とグローバルに分散された展開という点で、システムを拡張する余地もある。
図5：ログストレージの単純化モデル](https://assets.zilliz.com/newdata5_853dd38bc3.png)
バッチ処理とストリーム処理の統合：ログストリーミングにより、Milvusはリアルタイムにデータを更新し、リアルタイムな配信性を確保します。さらに、データバッチをログスナップショットに変換し、スナップショット上にインデックスを構築することで、Milvusはより高いクエリ効率を実現することができます。クエリ中、Milvusは増分データと履歴データの両方からクエリ結果をマージし、返されるデータの統合性を保証する。このような設計により、リアルタイムのパフォーマンスと効率のバランスがより良くなり、従来のLambdaアーキテクチャと比較して、オンラインとオフラインの両方のシステムのメンテナンス負担が軽減される。
ステートレス：クラウドインフラストラクチャとオープンソースのストレージコンポーネントにより、Milvusは自身のコンポーネント内でのデータの永続化から解放されます。Milvus 2.0は、メタデータストレージ、ログストレージ、オブジェクトストレージの3種類のストレージでデータを永続化する。メタデータ・ストレージはメタデータを保存するだけでなく、サービス・ディスカバリーとノード管理も行う。ログストレージは、インクリメンタルなデータ永続化とデータ公開-サブスクリプションを実行する。オブジェクト・ストレージは、ログのスナップショット、インデックス、およびいくつかの中間計算結果を格納する。
**マイクロサービスMilvusはデータプレーンとコントロールプレーンの分離、リード／ライトの分離、オンライン／オフラインのタスク分離の原則に従っている。アクセス・レイヤー、コーディネータ・レイヤー、ワーカー・レイヤー、ストレージ・レイヤーの4つのレイヤーから構成される。これらのレイヤーは、スケーリングとディザスタリカバリに関しては相互に独立している。フロント・レイヤーおよびユーザー・エンドポイントとして、アクセス・レイヤーはクライアント接続を処理し、クライアント・リクエストを検証し、クエリー結果を結合する。システムの "頭脳 "として、コーディネータ・レイヤーはクラスタ・トポロジーの管理、負荷分散、データ宣言、データ管理などのタスクを引き受けます。ワーカー層はシステムの "手足 "であり、データ更新、クエリー、インデックス構築作業を実行する。最後に、ストレージ層がデータの永続化とレプリケーションを担当する。全体として、このマイクロサービスベースの設計は、各コンポーネントがそれぞれ対応する機能に責任を持ち、制御可能なシステムの複雑性を保証する。Milvusは、明確に定義されたインターフェースを通じてサービスの境界を明確にし、より細かい粒度に基づいてサービスを切り離すことで、弾力的なスケーラビリティとリソースの分散をさらに最適化している。
ベクターデータベースが直面する技術的課題
ベクトルデータベースに関する初期の研究は、主に高効率なインデックス構造とクエリ手法の設計に集中しており、その結果、様々なベクトル検索アルゴリズムライブラリが生み出された（参考文献3～5）。ここ数年の間に、ベクトル検索の問題をシステム設計の観点から捉え直し、体系的な解決策を提案する学術チームや技術チームが増加している。既存の研究やユーザーの要望をまとめると、ベクトルデータベースの主な技術的課題は以下のように分類される：
- 負荷に対するコスト・パフォーマンス比の最適化**。
従来のデータ型と比較して、ベクトルデータの解析は、その高次元のため、より多くのストレージとコンピューティングリソースを必要とする。さらに、ユーザーは、ベクトル検索ソリューションの負荷特性やコスト・パフォーマンスの最適化について、多様な好みを示している。例えば、極めて大規模なデータセット（数百億から数千億のベクトル）を扱うユーザーは、データ保存コストが低く、検索レイテンシにばらつきのないソリューションを好むだろうし、一方で、より高い検索性能とばらつきのない平均レイテンシを求めるユーザーもいるだろう。このような多様な嗜好を満足させるためには、ベクトルデータベースのコアインデックスコンポーネントは、異なるタイプのストレージとコンピューティングハードウェアでインデックス構造と検索アルゴリズムをサポートできなければなりません。
例えば、より安価なストレージ媒体（NVMやSSDなど）にベクトルデータと対応するインデックスデータを格納することは、ストレージコストを下げる際に考慮されるべきである。しかし、既存のベクトル検索アルゴリズムのほとんどは、メモリから直接読み込んだデータで動作する。ディスクドライブの使用による性能低下を避けるため、ベクトルデータベースは、ベクトルデータとインデックス構造のストレージソリューションに適応できることに加え、検索アルゴリズムと組み合わせたデータアクセスの局所性を利用できる必要がある（参考文献6～8）。性能向上のため、GPU、NPU、FPGAなどのハードウェアアクセラレーション技術が研究されている（参考文献9）。しかし、アクセラレーションに特化したハードウェアやチップのアーキテクチャ設計は様々であり、異なるハードウェアアクセラレータ間で最も効率的に実行する問題はまだ解決されていない。
- システム構成とチューニングの自動化**。
ベクトル探索アルゴリズムに関する既存の研究のほとんどは、ストレージコスト、計算性能、探索精度の柔軟なバランスを追求している。一般的に、アルゴリズムのパラメータとデータの特徴の両方が、アルゴリズムの実際の性能に影響を与える。ユーザーの要求はコストとパフォーマンスにおいて異なるため、ユーザーのニーズとデータの特徴に合ったベクトルクエリ手法を選択することは重要な課題となる。
とはいえ、データ分布が検索アルゴリズムに与える影響を手動で分析する方法は、ベクトルデータの高次元のため有効ではない。この問題を解決するために、学界と産業界は機械学習に基づくアルゴリズム推薦ソリューションを模索している（参考文献No.10）。
また、MLを利用したインテリジェントなベクトル検索アルゴリズムの設計も研究のホットスポットである。一般に、既存のベクトル探索アルゴリズムは、様々な次元や分布パターンを持つベクトルデータに対して汎用的に開発されている。そのため、データの特徴に応じた特定のインデックス構造をサポートしておらず、最適化の余地が少ない。今後の研究では、データの特徴に応じたインデックス構造を実現する効果的な機械学習技術も検討する必要がある（参考文献No.11-12）。
- 高度なクエリーセマンティクスのサポート**。
現代のアプリケーションは、ベクトル間のより高度なクエリに依存することが多い。従来の最近傍検索セマンティクスは、ベクトルデータ検索にはもはや適用できない。さらに、複数のベクターデータベースにまたがる検索や、ベクターデータと非ベクターデータを組み合わせた検索に対する要求も出てきている（参考文献 No.13）。
具体的には、ベクトル類似度の距離メトリクスのバリエーションが急速に増えている。ユークリッド距離、内積距離、余弦距離といった従来の類似度スコアでは、すべてのアプリケーションの要求を満たすことはできない。人工知能技術の普及に伴い、多くの業界では、谷本距離、マハラノビス距離、超構造、部分構造など、各分野に特化した独自のベクトル類似度評価基準を開発している。これらの評価指標を既存の検索アルゴリズムに統合することと、これらの評価指標を利用した新しいアルゴリズムを設計することは、いずれも困難な研究課題である。
ユーザーサービスの複雑さが増すにつれ、アプリケーションはベクトルデータと非ベクトルデータの両方を検索する必要が出てくる。例えば、コンテンツ・レコメンダーは、ユーザーの嗜好や社会的関係を分析し、現在のホットな話題とマッチングさせて、適切なコンテンツをユーザーに提供する。このような検索は、通常、複数のデータタイプに対するクエリや、複数のデータ処理システムにまたがるクエリを含む。このようなハイブリッド検索を効率的かつ柔軟にサポートすることも、システム設計の課題である。
##著者
Dr. Rentong Guo (Ph.D. of Computer Software and Theory, Huazhong University of Science and Technology) Zillizのパートナー兼研究開発ディレクター。中国コンピュータ連盟分散コンピューティング・処理技術委員会（CCF TCDCP）メンバー。データベース、分散システム、キャッシュシステム、ヘテロジニアスコンピューティングの研究に従事。研究成果は、Usenix ATC、ICS、DATE、TPDSなどの一流会議や学術誌に掲載されている。Milvusのアーキテクトとして、高度にスケーラブルでコスト効率に優れたAIベースのデータ分析システムを開発するソリューションを模索している。
Xiaofan Luan、Zillizのパートナー兼エンジニアリング・ディレクター、LF AI & Data Foundationの技術諮問委員会メンバー。オラクル米国本社、Software Defined Storageの新興企業Hedvigを経て、アリババクラウドデータベースチームに参加。Alibaba Cloud Databaseチームに参加し、NoSQLデータベースHBaseとLindormの開発を担当。コーネル大学で電子コンピューター工学の修士号を取得。
Dr. Xiaomeng Yi (Ph.D. of Computer Architecture, Huazhong University of Science and Technology) Zillizのシニアリサーチャー兼リサーチチームリーダー。高次元データ管理、大規模情報検索、分散システムにおけるリソース割り当ての研究に従事。李博士の研究成果は、IEEE Network Magazine、IEEE/ACM TON、ACM SIGMOD、IEEE ICDCS、ACM TOMPECSなどの主要ジャーナルや国際会議で発表されている。
ZillizのデータエンジニアであるFilip Haltmayerは、カリフォルニア大学サンタクルーズ校を卒業し、コンピューターサイエンスの理学士号を取得した。Zilliz入社後は、クラウドのデプロイメント、クライアントとのやり取り、技術的な講演、AIアプリケーションの開発などに時間を費やしている。
参考文献
1.Milvusプロジェクト: https://github.com/milvus-io/milvus 2.Milvus: 目的別ベクトルデータ管理システム、SIGMOD'21 3.Faissプロジェクト: https://github.com/facebookresearch/faiss 4.Annoyプロジェクト: https://github.com/spotify/annoy 5.SPTAGプロジェクト：https://github.com/microsoft/SPTAG 6.GRIP: ベクトル検索エンジンのためのマルチストア容量最適化高性能最近傍探索, CIKM'19 7.DiskANN: シングルノードにおける高速高精度10億点最近傍探索, NIPS'19 8.HM-ANN: 効率的なヘテロジニアスメモリ上の10億点最近傍探索, NIPS'20 9.SONG: GPU上での近似最近傍探索, ICDE'20 10.データベース管理システムの自動チューニングサービス「ottertune」のデモ, VLDB'18 11.学習型インデックス構造の事例, SIGMOD'18 12.学習型適応的早期終了による近似最近傍探索の改善, SIGMOD'20 13.AnalyticDB-V：構造化データと非構造化データのクエリ融合に向けたハイブリッド分析エンジン, VLDB'20
オープンソースコミュニティに参加しよう：
GitHub](https://bit.ly/3qgRq3z)でMilvusを検索したり、貢献することができます。
フォーラム](https://bit.ly/31HKWRd) でコミュニティと交流する。
Twitter](https://bit.ly/304zfD9)で私たちとつながりましょう。
読み続けて
Zilliz Cloud Just Landed in Claude Code
The Zilliz Cloud Plugin brings the full power of Zilliz Cloud directly into your Claude Code terminal as natural-language conversations.
Demystifying the Milvus Sizing Tool
Explore how to use the Sizing Tool to select the optimal configuration for your Milvus deployment.
1 Table = 1000 Words? Foundation Models for Tabular Data
TableGPT2 automates tabular data insights, overcoming schema variability, while Milvus accelerates vector search for efficient, scalable decision-making.