ベクトル・データベースの一貫性モデルを理解する
ベクトル検索アプリケーションのための分散システムは、スケーラビリティやフォールトトレランスから、強化されたパフォーマンスやグローバルなアクセシビリティに至るまで、不可欠なものとなりつつあります。分散システムをレジリエントで高性能なアプリケーションのバックボーンにする基本原則は、一貫性、可用性、およびレイテンシのトレードオフを考慮する必要があります。
例えば、分散アプリケーションでベクトル検索を使用する場合、一貫性が重要です。そこにあるはずのデータがなかったらどうでしょう？分散システムにあるすべてのレプリカでデータが一貫していなければ、そうなります。表面的には単純に聞こえる。もちろん、データをそこに置き、複数のノードにレプリケートした後、私のデータはそこにあるべきです。しかし、いつそこにあるべきなのか？どうやってそれを保証するのか？
一貫性の問題に対応するため、完全分散型Milvusベクトル・データベースはTunable Consistencyを提供している。Milvusはユニークなアーキテクチャを持っており、余計なツールを使うことなく、データの記述方法をスケールアウトし、一貫性を確保することができます。分散インフラストラクチャを活用したMilvusは、疎結合のpub-subシステムであり、タイムスタンプによって整合性を容易に管理・調整することができます。
この記事では
一貫性とは何か？
- ベクターデータベースの一貫性要件
一貫性、可用性、パーティション
Milvusはどのレベルの一貫性を提供するか？
最終的な一貫性
セッションの一貫性
セッションの一貫性
強い一貫性
ベクトルデータベースの一貫性を理解するためのまとめ
一貫性とは何か？
一貫性の定義の1つは、"時間の経過とともに品質が大きく変化しない性能レベルを達成すること "です。分散データベースの一貫性については、あなたが求める最も正確で最新のデータを提供します。そのため、Milvusでは、アクセスしたいデータがどの程度最新である必要があるかに基づいて一貫性を「調整」する機能を提供しています。
データベースの種類によって、さらに一貫性の要件があります。例えば、非リレーショナルデータベースでは、ACID (原子性、一貫性、分離性、耐久性) の要件が「偶発的」または緩和されていることがよくあります。NoSQLデータベースを使用する場合、部分的に更新されたデータを取得する可能性があります。
一方、PostgresのようなACID準拠のSQLデータベースには、異なる一貫性要件があります。これらのデータベースは、変更レベルで一貫性を強制することにより、部分的に更新されたデータが戻ってこないことを保証します。そのため、クエリを実行すると、その変更からデータを取得するために、変更全体が行われるまで待たなければなりません。
ベクター・データベースの一貫性要件
一方、ベクトル・データベースには、リレーショナル・データベースや非リレーショナル・データベースとは異なる一貫性要件があります。バッチ変更が完全に行われる前であっても、有効なデータを持つことができます。しかし、部分的に更新されたデータを持つことはできない。ベクトル・データベースはPACELCの定理に基づいて動作する。これはまさにMilvusがpub-subセットアップを通して行っていることである。各行は書き込みパイプラインを通して "publish "され、必要なノードによって "subscribe "される。このセットアップにより、Milvusを検索したり問い合わせたりして、タイムスタンプの差に基づいた結果を得ることができる。
一貫性、可用性、パーティション (CAP)
CAP定理とはコンピュータサイエンスの概念で、一貫性、可用性、パーティション耐性の間にはトレードオフの関係があるというものです。この3つのうち、2つしか選べません。ネットワーク・パーティションがある場合、可用性と一貫性のどちらかを選択しなければならない。高いデータ可用性が要求されるシステムではレプリカが必要となり、一貫性が難しくなる。
PACELCの定理はCAPの定理を拡張したものである。CAP定理＋else＋レイテンシ＋一貫性である。これは、ネットワーク・パーティションのないシステムでは、可用性と一貫性のトレードオフを心配する必要はないとしている。しかし、データの同期を待つ必要があるため、レイテンシーと一貫性のどちらかを選択しなければならない。
Milvusはどのレベルの一貫性を提供していますか？
Milvusには4つの異なる一貫性レベルがあります。一貫性の低いものから高いものへと順に並べると、以下のようになります：Eventual、Session、Bounded、Strong`です。偶発的な一貫性とは、「...いつ」発生しても構わないということです。強力な一貫性とは、クエリを送信した瞬間にすべてのデータを含めることを意味します。セッションとバウンデッドはその中間です。もう少し詳しく見てみましょう。
どの絵文字がどのレベルを表しているかわかりますか？
最終的な一貫性
最終的な（あるいは "Eventually"）一貫性とは、最終的にすべてのレプリカでデータが一貫することを意味します。最新データや繰り返し可能なクエリを持つことよりも、アプリケーションの速度を重視する場合に、最終的な一貫性を使用します。Milvusの場合、このタイプの一貫性は、読み込み時のタイムスタンプのチェックをスキップすることで一貫性の要件を実装することを意味します。
このタイプの一貫性レベルの使用例としては、商品レビューを取得する場合が考えられます。ほとんどのユーザーは、商品に関するすべてのレビューを読むわけではないので、最新のレビューを取得することの重要性は高くありません。このレベルの一貫性を持つコレクションを作成したい場合、以下のコードはMilvusで "Eventually "レベルの一貫性を持つコレクションを作成する方法を示しています。重要なのは、consistency_levelがキーワード "Eventually "を探していることである。
セッションの一貫性
セッションの一貫性とは、各セッションがそれ自身の書き込みに基づいて少なくとも最新であることを意味する。セッションは複数のレプリカを持つかもしれないので、これが最初のレイテンシと一貫性のトレードオフである。セッションごとに一度だけ状態を保存する必要がある場合に、セッション一貫性を使用します。Milvusは、必要なタイムスタンプを最後の書き込み時刻に設定することで、この種の一貫性を実装しています。
実際には、各クライアントとサーバーのインスタンスにデータの一貫性が必要な場合に、セッション一貫性を使うことができます。例えば、ビデオゲームサーバーです。プレイヤーに無限大のグリッチをさせたくないので、各インスタンスやセッションの内部で一貫性を確保する必要があります。以下のコードは、一貫性レベルを "Session" にしてベクトル検索を行う方法を示しています。
境界の一貫性
バウンデッド・コンシステンシー（またはバウンデッド・スタルネス）は、セッション・コンシステンシーよりも一段階「一貫性が高い」。セッション "レベルの一貫性では、他のインスタンス（セッション）は最終的に一貫性があるものとして扱われます。Bounded stalenessでは、各インスタンスとレプリカは一定期間内に同期するよう強制されます。
境界付き一貫性の例としては、動画レコメンデーションエンジンがある。ユーザーは最新の動画をすぐに必要としないが、すぐに見ることができるはずである。また、ユーザーの変更はセッションの外部に速やかに拡散する必要がある。以下のコードでは、Milvusの検索に境界付き一貫性を要求する方法を示しています。
強力な一貫性
強力な一貫性は、データを挿入した瞬間に利用可能にする。もちろん、この一貫性には待ち時間というトレードオフが伴います。実際には、Milvusは、必要な読み取りタイムスタンプをシステムの最新の更新に設定することで、この一貫性を実装しています。これにより、検索レイテンシは最低でも200msになります。
強力な一貫性の例としては、詐欺検出が考えられます。誰かがあなたの銀行口座を不正に使用した場合、あなたはそれを知り、すぐに止めなければなりません。リード・アフター・ライト・タイプのセットアップが必要なアプリケーションには、強力な一貫性が必要です。以下のコードは、強い一貫性が要求されるコレクションへのクエリー（ベクトルなしのフィルター検索）の方法を示しています。
ベクターデータベースの一貫性を理解するためのまとめ
データの一貫性は、分散アプリケーションを構築する際に考慮すべき最も重要なことの1つです。すべてのアプリケーションにはデータが必要であり、すべてのデータには一貫性の要件が必要です。ベクトルデータに関しては、行ベースの一貫性要件に関するデータの一貫性を評価しなければなりません。
これらの要件に合わせて、Milvusはデータのタイムスタンプに基づく4段階の一貫性を提供しています。これは行ベースの一貫性でのみ可能であり、SQLやNoSQLデータベースでは実装されていないことに注意してください。一貫性の4つのレベルは、最も一貫性の低いものから順に、strong、bound、session、enduallyである。
強力な一貫性は、システム全体で（ほぼ）すぐに利用可能なすべての最新データを保証します。このレベルの一貫性は、タイムスタンプを最新の挿入タイムスタンプに更新することで達成され、リクエスト時刻までに挿入されたすべてのデータを照会できることを保証する。
バウンデッド一貫性は、一定期間内にシステム全体のすべての最新データがあることを保証します。Bounded consistencyは、リクエストから一定期間内にチェックするタイムスタンプを設定します。こうすることで、制限された期間内にすべてのデータが揃う。Bounded consistencyはMilvusのデフォルト設定です。
セッションの一貫性により、現在作業しているセッションの最新データをすべて取得することができます。Milvusでは、各インスタンスのタイムスタンプをそのインスタンスが最後にデータを挿入した時刻に設定することで、このレベルの一貫性を実現しています。こうすることで、（少なくとも）使用しているインスタンスに挿入されたすべてのデータを持つことができます。
最後に、最終的な一貫性（キーワードは "Eventually"）は、最終的にシステム全体のデータがすべて一貫性を持つことを保証します。データは増殖する可能性があり、意味のある速度でレプリカに同期されます。データの一貫性と引き換えに、可用性とパフォーマンスが向上する。実際には、このレベルの一貫性にはそれほど時間はかからない。Milvusでは、タイムスタンプのチェックをスキップし、検索やクエリを即座に実行することで、最終的な一貫性を実現している。
読み続けて
Stop Building AI Data Infra for the Wrong Stage
Learn how AI data infrastructure should evolve from prototype to enterprise scale, and when Vector Lakebase becomes the right architecture for AI apps.
Zilliz Cloud Enterprise Vector Search Powers High-Performance AI on AWS
Zilliz Cloud on AWS powers secure, scalable, ultra-fast vector search for enterprise AI apps, with BYOC, sub-10ms latency, and zero-DevOps simplicity.
Optimizing Embedding Model Selection with TDA Clustering: A Strategic Guide for Vector Databases
Discover how Topological Data Analysis (TDA) reveals hidden embedding model weaknesses and helps optimize vector database performance.