ファイルリソースの管理
ファイル・リソースとは、テキスト解析ツールが実行時に利用する外部辞書ファイルへの参照をサーバーに登録したものです。Milvus3.0では、4つのアナライザーコンポーネントがインライン配列からではなく、ファイルリソースから辞書をロードすることができます：
アナライザコンポーネント |
ファイルリソースを受け取るパラメータ |
|---|---|
|
|
|
|
|
|
|
ファイル・リソースは、インライン辞書配列の2つの実用的な問題を解決する：
実際の辞書は大きい。実際の辞書は大きい。中国語の Jieba 語彙は数万行になることがあり、類義語テーブルは通常数千ルールになる。同義語テーブルは通常、数千のルールである。これらを解析器構成にインライン化することは非現実的である。
同じ辞書は通常、コレクション間で共有されます。辞書を一度登録してから名前で参照することで、スキーマを小さく保ち、辞書の更新を1回の操作で済ませることができます。
ファイル・リソース・タイプ
Milvusは管理責任の異なる2つのファイルリソースタイプをサポートしています：
タイプ |
ファイルの保存場所 |
ファイルの管理者 |
フィット |
|---|---|---|---|
リモート |
Milvusクラスタが既に使用するように設定されているオブジェクトストア(MinIO / S3 / GCS / Azure)内 |
Milvus, |
ほとんどのデプロイメントに推奨 |
ローカル |
各Milvusコンポーネント（DataNode、QueryNode、StreamingNode）のローカルファイルシステム上の同じ絶対パス。 |
お客様 - Kubernetesボリュームを経由するなどして、お客様自身でファイルをマウントしてください。 |
オープンソース/セルフホストシナリオでは、Milvusの外部で辞書ファイルを管理します。 |
このページの残りの部分では、両方のタイプについて、より一般的なリモートタイプから説明します。
前提条件
リモートファイル リソースの場合、Milvus デプロイメントにオブジェクト ストアが設定されている必要があります。ほとんどのデプロイメントではすでに設定されています。
milvus.yaml(または同等の Helm チャート値) のminio:セクションを確認してください。bucketNameとrootPathの値に注意してください。ファイルリソースを登録するときに必要になります。ローカルファイルリソースの場合、すべてのMilvusポッド/コンテナに同じ絶対パスでファイルを配置できる必要があります。その方法は、デプロイメントによって異なります（バインドマウント、ConfigMap バックアップボリューム、init コンテナなど）。
リモートファイルリソースの登録
リモートファイルリソースの登録は、オブジェクトストレージにファイルをアップロードし、任意の名前でMilvusに登録し、そのファイルを必要とするアナライザから参照するという3ステップのワークフローです。
ステップ 1.辞書ファイルをオブジェクト・ストレージにアップロードする。
独自のツール(mc,aws s3 cp,boto3, または任意のS3互換クライアント)を使用して、Milvusが使用するように設定されているバケットにファイルを置く。
例えば、milvus.yaml に
minio:
bucketName: milvus-bucket
rootPath: file
rootPath をプレフィックスとしてchinese_terms.txt という名前のファイルをアップロードすると、オブジェクトはs3://milvus-bucket/file/chinese_terms.txt に置かれます。
ステップ 2 でadd_file_resource に渡すpath 引数は、rootPath 接頭辞を含む完全なオブジェクトキーで、上記の例ではpath="file/chinese_terms.txt" です。プレフィックスを含まないパス（たとえば、"chinese_terms.txt" だけ）は、エラーfile resource path not exist で拒否されます。
ステップ 2.でファイルを登録する。add_file_resource
from pymilvus import MilvusClient
client = MilvusClient(uri="http://localhost:19530")
client.add_file_resource(
name="chinese_terms", # short, unique name you'll reference later
path="file/chinese_terms.txt", # full S3 object key, including the rootPath prefix
)
add_file_resource Milvusが設定されたオブジェクトストアのpath にオブジェクトが存在することを確認した後にのみ、呼び出しが返されます。オブジェクトが見つからない場合、呼び出しはMilvusException(code=65535, "file resource path not exist") を発生させる - まずファイルをアップロードし、その後再試行する。
この呼び出しは冪等です。同じname とpath でadd_file_resource を2回呼び出しても、重複は作成されない。
ステップ3.アナライザーからファイルリソースを参照する
アナライザー・パラメーターがファイル参照を受け付ける場合 (extra_dict_file,stop_words_file,word_list_file,synonyms_file)、正規のリモート形式を使用します：
{
"type": "remote",
"resource_name": "chinese_terms", # must match the name in add_file_resource
"file_name": "chinese_terms.txt", # filename only — Milvus uses this to identify the file inside the resource
}
4つのアナライザー・パラメーターはすべて同じ形を使用します。解析器ごとの具体的な例としては、Jieba tokenizer、Stop filter、Decompounder filter、Synonym filterを参照のこと。
パラメータ名はresource_name とfile_name であり、name とfile ではない。name /file (または"type": "remote" の代わりに"type": "resource" ) を使用すると、分析器作成時にresource name of remote file ... must be set のようなメッセージとともにMilvusException が発生します。
ファイル・リソースのリスト
resources = client.list_file_resources()
for r in resources:
print(r.name, r.path)
# chinese_terms file/chinese_terms.txt
list_file_resources() は、.name と.path 属性を持つFileResourceInfo オブジェクトのリストを返します。空のクラスタは[] を返します。リソースごとのget はありません。list_file_resources が唯一の読み取りAPIです。
ファイル・リソースの削除
client.remove_file_resource(name="chinese_terms")
remove_file_resource はべき等です。存在しない名前で呼び出すと、None がそのまま返されます。
ファイル・リソースを削除する前に、アナライザ・コンフィギュレーションがそれを参照しているコレクションをすべて削除または変更してください。コレクションがファイル・リソースに依存しなくなるまでファイル・リソースを保持することで、リソースがなくなった後にアナライザ・ルックアップが失敗するリスクを回避できます。
ローカルファイルリソースの使用
ローカルファイルリソースは、Milvusコンポーネントのローカルファイルシステム上のパスを直接指定します。Milvusはローカルリソースを追跡しませんので、add_file_resource 。関連するすべてのポッドまたはコンテナ上の同じ絶対パスにファイルを配置し、パスで参照します：
{
"type": "local",
"path": "/var/lib/milvus/dicts/chinese_terms.txt",
}
ローカルファイルリソースは、DataNodes、QueryNodes、StreamingNodesのファイルシステムをコントロールするデプロイでのみ有効です。通常は、ベアメタル上のセルフホストMilvus、またはボリュームマウントを追加できるKubernetesクラスタ上です。ファイルは各コンポーネント上で完全に同じ絶対パスに存在する必要があります。
このファイルは、アナライザーが最初に作成されたときに開かれます。その時点でパスが存在しない場合、アナライザーの作成はMilvusException(code=2000, "IOError: No such file or directory") で失敗します。
考慮事項
クラスタ全体の可用性は即時ではありません。
add_file_resource、Milvusはファイルを必要とするすべてのコンポーネントにファイルを同期します。この短いウィンドウの間に、まだ同期していないノードでリソースを参照するコレクションが作成に失敗することがあります。典型的な修正は、数秒後にcreateコールを再試行することです。リソースに依存するコレクションがない場合にのみ削除します。
remove_file_resourceを呼び出す前に、アナライザ構成がリソースを参照しているコ レクションを削除または変更することで、ファイルが見つからないアナライザ ルックアップを回避できる。メタデータのみ。
list_file_resources()は、nameとpathを返します。サイズ、チェックサム、アップロード時間、その他のメタデータはありません。必要であれば、独自の命名規則で辞書のバージョンを追跡してください。