MMap対応データストレージ
Milvusでは、メモリマップドファイルにより、ファイルの内容を直接メモリにマッピングすることができます。この機能により、特に利用可能なメモリが乏しく、完全なデータロードが不可能な状況において、メモリ効率が向上します。この最適化メカニズムにより、ある限度まではパフォーマンスを確保しながらデータ容量を増やすことができますが、データ量がメモリを超過しすぎた場合、検索やクエリのパフォーマンスが著しく低下する可能性がありますので、適宜この機能のON/OFFを選択してください。
メモリマッピングの設定
Milvus 2.4からは、デプロイ前に静的設定ファイルを調整してクラスタ全体のデフォルトのメモリマッピング設定を行う柔軟性があります。さらに、パラメータを動的に変更してクラスタとインデックスの両方のレベルでメモリマッピング設定を微調整するオプションもあります。将来のアップデートでは、メモリマッピング機能を拡張し、フィールドレベルの設定を含める予定です。
クラスタ展開前：グローバル設定
クラスタをデプロイする前に、クラスタレベルの設定でクラスタ全体にメモリマッピングを適用します。これにより、すべての新しいオブジェクトが自動的にこれらの設定に準拠するようになります。これらの設定を変更すると、有効にするにはクラスタを再起動する必要があることに注意してください。
クラスタのメモリマッピング設定を調整するには、configs/milvus.yaml ファイルを編集します。このファイルでは、デフォルトでメモリ・マッピングを有効にするかどうかを指定し、メモリ・マッピングされたファイルを格納するディレクトリ・パスを決定します。パス(mmapDirPath)を指定しないままにしておくと、システムのデフォルトでは、メモリ・マップされたファイルは{localStorage.path}/mmap に格納されます。詳細については、ローカル・ストレージ関連の構成を参照してください。
# This parameter was set in configs/milvus.yaml
...
queryNode:
mmap:
# Set memory mapping property for whole cluster
mmapEnabled: false | true
# Set memory-mapped directory path, if you leave mmapDirPath unspecified, the memory-mapped files will be stored in {localStorage.path}/ mmap by default.
mmapDirPath: any/valid/path
....
クラスタ動作中: 動的構成
クラスタ実行時に、コレクションレベルまたはインデックスレベルでメモリマッピング設定を動的に調整できます。
コレクションレベルでは、メモリマッピングは、プライマリキー、タイムスタンプ、および行IDを除く、コレクション内のインデックス付けされていないすべての未加工データに適用されます。このアプローチは、特に大規模なデータセットの包括的な管理に適している。
コレクション内のメモリマッピング設定を動的に調整するには、set_properties() メソッドを使用します。ここでは、mmap.enabled をTrue またはFalse の間で必要に応じて切り替えることができる。
# Get existing collection
collection = Collection("test_collection") # Replace with your collection name
# Set memory mapping property to True or Flase
collection.set_properties({'mmap.enabled': True})
インデックスレベルの設定では、他のデータ型に影響を与えることなく、メモリマッピングをベクトルインデックスに特別に適用することができます。この機能は、ベクトル検索に最適化されたパフォーマンスを必要とするコレクションにとって非常に貴重です。
コレクション内のインデックスのメモリマッピングを有効または無効にするには、index_name でターゲットインデックス名を指定し、mmap.enabled をTrue またはFalse に設定して、alter_index() メソッドを呼び出します。
collection.alter_index(
index_name="vector_index", # Replace with your vector index name
extra_params={"mmap.enabled": True} # Enable memory mapping for index
)
異なるデプロイメントでのストレージパスのカスタマイズ
メモリマップされたファイルのデフォルトは、localStorage.path 内の/mmap ディレクトリです。ここでは、さまざまなデプロイメント方法でこの設定をカスタマイズする方法を説明します：
- Helm Chartを使用してインストールされたMilvusの場合：
# new-values.yaml
extraConfigFiles:
user.yaml: |+
queryNode:
mmap:
mmapEnabled: true
mmapDirPath: any/valid/path
helm upgrade <milvus-release> --reuse-values -f new-values.yaml milvus/milvus
- Milvus Operatorを使用してインストールされたMilvusの場合：
# patch.yaml
spec:
config:
queryNode:
mmap:
mmapEnabled: true
mmapDirPath: any/valid/path
kubectl patch milvus <milvus-name> --patch-file patch.yaml
- Dockerを使用してインストールされたMilvusの場合：
# A new installation script is provided to enable mmap-related settings.
制限
メモリマッピングを有効にする前に、コレクションがリリースされていることを確認してください。
メモリマッピングはDiskANNまたはGPUクラスのインデックスには対応していません。
よくある質問
どのようなシナリオでメモリマッピングを有効にすることが推奨されますか？この機能を有効にした後のトレードオフは何ですか？
メモリー・マッピングは、メモリーが限られている場合やパフォーマンス要件が中程度の場合に推奨されます。この機能を有効にすると、データ・ロードの容量が増加します。例えば、2つのCPUと8GBのメモリの構成では、メモリマッピングを有効にすると、有効にしない場合に比べて最大4倍のデータをロードすることができます。パフォーマンスへの影響はさまざまです：
十分なメモリがあれば、期待される性能はメモリのみを使用した場合と同様です。
メモリが十分でない場合、期待されるパフォーマンスは低下する可能性があります。
コレクションレベル構成とインデックスレベル構成の関係は?
コレクション・レベルとインデックス・レベルは包括的な関係ではなく、コレクション・レベルは元のデータがmmap有効かどうかを制御し、インデックス・レベルはベクトル・インデックスのみを制御します。
メモリマッピングに推奨されるインデックスタイプはありますか？
はい、HNSWを推奨します。以前、HNSW、IVF_FLAT、IVF_PQ/SQ シリーズのインデックスをテストしたことがありますが、IVF シリーズのインデックスの性能は著しく低下しました。
メモリマッピングにはどのようなローカルストレージが必要ですか？
NVMeドライブが望ましい。
スカラーデータはメモリマッピングできますか？
メモリー・マッピングはスカラー・データに適用できますが、スカラー・フィールド上に構築されたインデックスには適用できません。
異なるレベルにまたがるメモリマッピング構成の優先順位はどのように決定されますか？
Milvusでは、メモリマッピング構成が複数のレベルにまたがって明示的に定義されている場合、インデックスレベルとコレクションレベルの構成が最も高い優先度を共有し、次にクラスタレベルの構成が続きます。
Milvus 2.3からアップグレードし、メモリマッピングディレクトリパスを設定した場合、どうなりますか?
Milvus 2.3 からアップグレードし、メモリマッピングディレクトリパス (
mmapDirPath) を設定した場合、設定は保持され、メモリマッピング有効 (mmapEnabled) のデフォルト設定はtrueになります。既存のメモリマッピングされたファイルの設定を同期するために、メタデータをマイグレートすることが重要です。詳細については、メタデータの移行を参照してください。
