Preguntas más frecuentes
¿Cómo configurar nlist y nprobe para los índices FIV?
La configuración de nlist depende del escenario. Como regla general, el valor recomendado de nlist es 4 × sqrt(n), donde n es el número total de entidades en un segmento.
El tamaño de cada segmento viene determinado por el parámetro datacoord.segment.maxSize, cuyo valor predeterminado es 512 MB. El número total de entidades en un segmento n puede estimarse dividiendo datacoord.segment.maxSize por el tamaño de cada entidad.
El ajuste de nprobe es específico del conjunto de datos y del escenario, e implica un compromiso entre la precisión y el rendimiento de la consulta. Recomendamos encontrar el valor ideal mediante la experimentación repetida.
Los siguientes gráficos son los resultados de una prueba realizada con el conjunto de datos sift50m y el índice IVF_SQ8, que compara la recuperación y el rendimiento de consulta de diferentes pares nlist/nprobe.
Prueba de precisión 
Prueba de rendimiento
¿Por qué a veces las consultas tardan más en conjuntos de datos más pequeños?
Las operaciones de consulta se realizan en segmentos. Los índices reducen el tiempo necesario para consultar un segmento. Si un segmento no ha sido indexado, Milvus recurre a la búsqueda de fuerza bruta en los datos brutos, lo que aumenta drásticamente el tiempo de consulta.
Por lo tanto, normalmente se tarda más en consultar un conjunto de datos pequeño (colección) porque no se ha creado un índice. Esto se debe a que los tamaños de sus segmentos no han alcanzado el umbral de creación de índices establecido por rootCoord.minSegmentSizeToEnableindex. Llame a create_index() para forzar a Milvus a indexar los segmentos que han alcanzado el umbral pero que aún no han sido indexados automáticamente, mejorando significativamente el rendimiento de la consulta.
¿Qué factores afectan al uso de la CPU?
El uso de la CPU aumenta cuando Milvus construye índices o ejecuta consultas. En general, la creación de índices requiere un uso intensivo de la CPU, excepto cuando se utiliza Annoy, que se ejecuta en un único subproceso.
Cuando se ejecutan consultas, el uso de la CPU se ve afectado por nq y nprobe. Cuando nq y nprobe son pequeños, la concurrencia es baja y el uso de la CPU se mantiene bajo.
¿Insertar datos y realizar búsquedas simultáneamente afecta al rendimiento de las consultas?
Las operaciones de inserción no requieren un uso intensivo de la CPU. Sin embargo, como los nuevos segmentos pueden no haber alcanzado el umbral para la creación de índices, Milvus recurre a la búsqueda de fuerza bruta, lo que afecta significativamente al rendimiento de la consulta.
El parámetro rootcoord.minSegmentSizeToEnableIndex determina el umbral de creación de índices para un segmento, y está fijado en 1024 filas por defecto. Consulte Configuración del sistema para obtener más información.
¿Puede la indexación de un campo VARCHAR mejorar la velocidad de borrado?
La indexación de un campo VARCHAR puede acelerar las operaciones de "Borrado por expresión", pero sólo en determinadas condiciones:
- Índice INVERTIDO: Este índice ayuda para expresiones
INo==en campos VARCHAR de clave no primaria. - Índice Trie: Este índice ayuda para consultas de prefijo (por ejemplo,
LIKE prefix%) en campos VARCHAR no primarios.
Sin embargo, indexar un campo VARCHAR no acelera:
- Borrado por IDs: Cuando el campo VARCHAR es la clave primaria.
- Expresiones no relacionadas: Cuando el campo VARCHAR no forma parte de la expresión de borrado.
¿Todavía tiene preguntas?
Usted puede:
- Eche un vistazo a Milvus en GitHub. Siéntase libre de hacer preguntas, compartir ideas y ayudar a otros.
- Únase a nuestro canal Slack para encontrar apoyo y participar con nuestra comunidad de código abierto.
