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.
¿Se libera el espacio de almacenamiento inmediatamente después de la eliminación de datos en Milvus?
No, el espacio de almacenamiento no se libera inmediatamente cuando se borran datos en Milvus. Aunque la eliminación de datos marca las entidades como "eliminadas lógicamente", el espacio real puede no liberarse instantáneamente. He aquí por qué:
- Compactación: Milvus compacta automáticamente los datos en segundo plano. Este proceso fusiona segmentos de datos más pequeños en otros más grandes y elimina los datos eliminados lógicamente (entidades marcadas para su eliminación) o los datos que han superado su tiempo de vida (TTL). Sin embargo, la compactación crea nuevos segmentos mientras marca los antiguos como "Eliminados".
- Recogida de Basura: Un proceso independiente llamado Recogida de Basura (GC) elimina periódicamente estos segmentos "Arrojados", liberando el espacio de almacenamiento que ocupaban. Esto garantiza un uso eficiente del almacenamiento, pero puede introducir un ligero retraso entre la eliminación y la recuperación de espacio.
¿Puedo ver los datos insertados, borrados o subinsertados inmediatamente después de la operación sin esperar a que se produzca una descarga?
Sí, en Milvus, la visibilidad de los datos no está directamente ligada a las operaciones de vaciado debido a su arquitectura de desagregación almacenamiento-ordenador. Puede gestionar la legibilidad de los datos utilizando niveles de consistencia.
Al seleccionar un nivel de consistencia, tenga en cuenta las compensaciones entre consistencia y rendimiento. Para operaciones que requieran visibilidad inmediata, utilice un nivel de consistencia "Fuerte". Para escrituras más rápidas, priorice una consistencia más débil (los datos pueden no ser visibles inmediatamente). Para obtener más información, consulte Consistencia.
¿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.
