Réplica en memoria
Este tema presenta el mecanismo de réplica en memoria en Milvus que permite múltiples réplicas de segmentos en la memoria de trabajo para mejorar el rendimiento y la disponibilidad.
Para obtener información sobre cómo configurar réplicas en memoria, consulte Configuraciones relacionadas con nodos de consulta.
Resumen
Disponibilidad_de_las_réplicas
Con réplicas en memoria, Milvus puede cargar el mismo segmento en múltiples nodos de consulta. Si un nodo de consulta ha fallado o está ocupado con una solicitud de búsqueda actual cuando llega otra, el sistema puede enviar nuevas solicitudes a un nodo de consulta inactivo que tenga una réplica del mismo segmento.
Rendimiento
Las réplicas en memoria permiten aprovechar recursos adicionales de CPU y memoria. Es muy útil si tiene un conjunto de datos relativamente pequeño pero desea aumentar el rendimiento de lectura con recursos de hardware adicionales. El QPS (consultas por segundo) y el rendimiento general pueden mejorar significativamente.
Disponibilidad
Las réplicas en memoria ayudan a Milvus a recuperarse más rápidamente si falla un nodo de consulta. Cuando falla un nodo de consulta, no es necesario volver a cargar el segmento en otro nodo de consulta. En su lugar, la solicitud de búsqueda puede reenviarse a un nuevo nodo de consulta inmediatamente sin tener que volver a cargar los datos. Con múltiples réplicas de segmentos mantenidas simultáneamente, el sistema es más resistente ante una conmutación por error.
Conceptos clave
Las réplicas en memoria se organizan como grupos de réplicas. Cada grupo de réplica contiene réplicas de fragmentos. Cada réplica de fragmento tiene una réplica de flujo y una réplica histórica que corresponden a los segmentos en crecimiento y sellados en el fragmento (es decir, el canal DML).
Ilustración del funcionamiento de las réplicas en memoria
Grupo de réplica
Un grupo de réplica consiste en múltiples nodos de consulta que son responsables de manejar los datos históricos y las réplicas.
Réplica de fragmentos
Una réplica de fragmento consta de una réplica de flujo y una réplica histórica, ambas pertenecientes al mismo fragmento. El número de réplicas de fragmentos de un grupo de réplicas viene determinado por el número de fragmentos de una colección específica.
Réplica de flujo
Una réplica de streaming contiene todos los segmentos crecientes del mismo canal DML. Técnicamente hablando, una réplica de streaming debe ser servida por un solo nodo de consulta en una réplica.
Réplica histórica
Una réplica histórica contiene todos los segmentos sellados del mismo canal DML. Los segmentos sellados de una réplica histórica pueden distribuirse en varios nodos de consulta dentro del mismo grupo de réplica.
Líder de fragmentos
Un líder de fragmento es el nodo de consulta que sirve la réplica de flujo en una réplica de fragmento.
Detalles de diseño
Equilibrio
Un nuevo segmento que deba cargarse se asignará a varios nodos de consulta diferentes. Una petición de búsqueda puede procesarse una vez que al menos una réplica se ha cargado correctamente.
Búsqueda
Caché
El proxy mantiene una caché que asigna segmentos a nodos de consulta y la actualiza periódicamente. Cuando el proxy recibe una petición, Milvus obtiene de la caché todos los segmentos sellados que necesitan ser buscados e intenta asignarlos a los nodos de consulta de manera uniforme.
Para los segmentos en crecimiento, el proxy también mantiene una caché de canal a nodo de consulta y envía solicitudes a los nodos de consulta correspondientes.
Conmutación por error
Las cachés del proxy no siempre están actualizadas. Algunos segmentos o canales pueden haberse movido a otros nodos de consulta cuando llega una petición. En este caso, el proxy recibirá una respuesta de error, actualizará la caché e intentará asignarlo a otro nodo de consulta.
Un segmento se ignorará si el proxy sigue sin encontrarlo tras actualizar la caché. Esto puede ocurrir si el segmento ha sido compactado.
Si la caché no es precisa, el proxy puede pasar por alto algunos segmentos. Los nodos de consulta con canales DML (segmentos crecientes) devuelven respuestas de búsqueda junto con una lista de segmentos fiables con los que el proxy puede comparar y actualizar la caché.
Mejora
El proxy no puede asignar las peticiones de búsqueda a los nodos de consulta de forma completamente equitativa y los nodos de consulta pueden tener diferentes recursos para servir las peticiones de búsqueda. Para evitar una distribución de recursos con colas largas, el proxy asignará segmentos activos en otros nodos de consulta a un nodo de consulta inactivo que también disponga de estos segmentos.
