Gestión de recursos de archivo
Un recurso de archivo es una referencia registrada en el servidor a un archivo de diccionario externo que los analizadores de texto consumen en tiempo de ejecución. En Milvus 3.0, cuatro componentes analizadores pueden cargar sus diccionarios desde un recurso de archivo en lugar de desde una matriz en línea:
Componente analizador |
Parámetro que acepta un recurso de archivo |
|---|---|
|
|
|
|
|
|
|
Los recursos de archivo resuelven dos problemas prácticos de las matrices de diccionarios en línea:
Los diccionarios reales son grandes. Un vocabulario chino Jieba puede tener decenas de miles de líneas; las tablas de sinónimos suelen tener miles de reglas. Integrarlos en la configuración del analizador es poco práctico.
El mismo diccionario suele compartirse en todas las colecciones. Registrarlo una vez y luego referenciarlo por su nombre mantiene los esquemas pequeños y hace que las actualizaciones del diccionario sean una sola operación.
Tipos de recursos de archivo
Milvus admite dos tipos de recursos de archivo con diferentes responsabilidades de gestión:
Tipo |
Dónde vive el archivo |
Quién gestiona el archivo |
Ajustar |
|---|---|---|---|
Remoto |
En el almacén de objetos (MinIO / S3 / GCS / Azure) que su cluster Milvus ya está configurado para usar |
Milvus, a través de las API de cliente |
Recomendado para la mayoría de los despliegues. |
Local |
En la misma ruta absoluta en el sistema de archivos local de cada componente Milvus (DataNode, QueryNode, StreamingNode) |
Usted - monte el archivo usted mismo, por ejemplo a través de un volumen Kubernetes |
Escenarios de código abierto / autoalojados en los que prefiere gestionar los archivos de diccionario fuera de Milvus. |
El resto de esta página recorre ambos tipos, comenzando con el tipo remoto más común.
Requisitos previos
Para los recursos de archivos remotos, su implementación de Milvus debe estar configurada con un almacén de objetos. La mayoría de los despliegues ya lo están - compruebe la sección
minio:de sumilvus.yaml(o los valores equivalentes de la tabla Helm). Tenga en cuenta los valoresbucketNameyrootPath; los necesitará cuando registre los recursos de archivo.Para los recursos de archivos locales, debe ser capaz de colocar archivos en cada pod / contenedor Milvus en la misma ruta absoluta. La forma de hacerlo depende de su despliegue (montaje bind, volumen respaldado por ConfigMap, contenedor init, etc.).
Registrar un recurso de archivo remoto
Registrar un recurso de archivo remoto es un flujo de trabajo de tres pasos: cargue el archivo en el almacenamiento de objetos, regístrelo en Milvus con el nombre elegido y, a continuación, haga referencia a él desde cualquier analizador que lo necesite.
Primer paso Cargar el archivo del diccionario en el almacenamiento de objetos
Utilice sus propias herramientas (mc, aws s3 cp, boto3, o cualquier cliente compatible con S3) para colocar el archivo en el cubo que Milvus está configurado para utilizar.
Por ejemplo, si milvus.yaml contiene:
minio:
bucketName: milvus-bucket
rootPath: file
Cargar un archivo llamado chinese_terms.txt con rootPath como prefijo coloca el objeto en s3://milvus-bucket/file/chinese_terms.txt.
El argumento path que pasará a add_file_resource en el Paso 2 es la clave completa del objeto, incluyendo el prefijo rootPath - para el ejemplo anterior, path="file/chinese_terms.txt". Una ruta sin el prefijo (por ejemplo, sólo "chinese_terms.txt") se rechaza con el error file resource path not exist.
Paso 2. Registrar el archivo Registrar el archivo con 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 valida de forma sincrónica: la llamada vuelve sólo después de que Milvus haya confirmado que el objeto existe en path en el almacén de objetos configurado. Si falta el objeto, la llamada genera el error MilvusException(code=65535, "file resource path not exist") - cargue el archivo primero, luego vuelva a intentarlo.
La llamada es idempotente. Llamar a add_file_resource dos veces con los mismos name y path no crea duplicados.
Tercer paso. Hacer referencia al recurso de archivo desde un analizador
Siempre que un parámetro del analizador acepte una referencia de archivo (extra_dict_file, stop_words_file, word_list_file, synonyms_file), utilice la forma remota canónica:
{
"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
}
Los cuatro parámetros del analizador utilizan la misma forma; sólo difiere la clave del analizador que los rodea. Para ver ejemplos concretos por analizador, consulte Jieba tokenizer, Stop filter, Decompounder filter y Synonym filter.
Los nombres de los parámetros son resource_name y file_name - no name y file. El uso de name / file (o "type": "resource" en lugar de "type": "remote") genera MilvusException en el momento de creación del analizador con un mensaje como resource name of remote file ... must be set.
Lista de recursos de archivos
resources = client.list_file_resources()
for r in resources:
print(r.name, r.path)
# chinese_terms file/chinese_terms.txt
list_file_resources() devuelve una lista de objetos FileResourceInfo, cada uno con atributos .name y .path. La agrupación vacía devuelve []. No hay ningún get por recurso; list_file_resources es la única API de lectura.
Eliminar un recurso de archivo
client.remove_file_resource(name="chinese_terms")
remove_file_resource es idempotente: llamarlo para un nombre que no existe devuelve None sin levantar.
Antes de eliminar un recurso de archivo, elimine o modifique cualquier colección cuyas configuraciones de analizador hagan referencia a él. Mantener un recurso de archivo hasta que ninguna colección dependa de él evita el riesgo de que las búsquedas del analizador fallen después de que el recurso haya desaparecido.
Utilizar un recurso de archivo local
Un recurso de archivo local apunta directamente a una ruta en el sistema de archivos local de cada componente Milvus. No hay llamada a add_file_resource - Milvus no rastrea los recursos locales. Usted mismo coloca el fichero en la misma ruta absoluta en cada pod o contenedor relevante, y luego lo referencia por ruta:
{
"type": "local",
"path": "/var/lib/milvus/dicts/chinese_terms.txt",
}
Los recursos de archivos locales solo son válidos en despliegues donde usted controla los sistemas de archivos de DataNodes, QueryNodes y StreamingNodes - típicamente Milvus autoalojado en bare-metal o en un clúster Kubernetes donde puede añadir un montaje de volumen. El archivo debe existir exactamente en la misma ruta absoluta en cada componente; de lo contrario, algunos nodos fallan al cargar el analizador.
El archivo se abre cuando el analizador se crea por primera vez. Si la ruta no existe en ese momento, la creación del analizador falla con MilvusException(code=2000, "IOError: No such file or directory").
Consideraciones
La disponibilidad de todo el cluster no es instantánea. Tras el regreso de
add_file_resource, Milvus sincroniza el archivo con todos los componentes que lo necesitan. Durante esta breve ventana, puede fallar la creación de una colección que haga referencia al recurso en nodos que aún no se hayan sincronizado. La solución típica es reintentar la llamada de creación después de unos segundos.Eliminar sólo cuando ninguna colección dependa del recurso. Elimine o modifique cualquier colección cuya configuración del analizador haga referencia al recurso antes de llamar a
remove_file_resource, para evitar que las búsquedas del analizador no encuentren el archivo.Sólo metadatos.
list_file_resources()devuelvenameypath- no hay tamaño, suma de comprobación, tiempo de carga ni otros metadatos. Mantenga un registro de las versiones del diccionario con su propia convención de nomenclatura si lo necesita.