Sello de tiempo
Este tema explica el concepto de marca de tiempo e introduce los cuatro parámetros principales relacionados con la marca de tiempo en la base de datos vectorial Milvus.
Visión general
Milvus es una base de datos vectorial que puede buscar y consultar vectores convertidos a partir de datos no estructurados. Al realizar una operación de lenguaje de manipulación de datos (DML), incluidas la inserción y la eliminación de datos, Milvus asigna marcas de tiempo a las entidades implicadas en la operación. Por lo tanto, todas las entidades en Milvus tienen un atributo de marca de tiempo. Y los lotes de entidades en la misma operación DML comparten el mismo valor de marca de tiempo.
Parámetros de marca de tiempo
Varios parámetros relacionados con la marca de tiempo intervienen cuando se realiza una búsqueda o consulta de similitud vectorial en Milvus.
Guarantee_timestampService_timestampGraceful_timeTravel_timestamp
Guarantee_timestamp
Guarantee_timestamp es un tipo de marca de tiempo que se utiliza para garantizar que todas las actualizaciones de datos realizadas por operaciones DML antes de Guarantee_timestamp sean visibles cuando se realiza una búsqueda o consulta de similitud vectorial. Por ejemplo, si ha insertado un lote de datos a las 15:00 horas, otro lote a las 17:00 horas, y el valor de Guarantee_timestamp se establece como 18:00 horas durante una búsqueda de similitud de vectores. Esto significa que los dos lotes de datos insertados a las 15:00 y a las 17:00, respectivamente, deben participar en la búsqueda.
Si no se configura Guarantee_timestamp, Milvus toma automáticamente el momento en que se realiza la solicitud de búsqueda. Por lo tanto, la búsqueda se realiza en una vista de datos con todas las actualizaciones de datos mediante operaciones DML antes de la búsqueda.
Para ahorrarle la molestia de entender el TSO dentro de Milvus, como usuario, no tiene que configurar directamente el parámetro Guarantee_timestamp. Sólo tiene que elegir el nivel de consistencia y Milvus gestionará automáticamente el parámetro Guarantee_timestamp por usted. Cada nivel de consistencia corresponde a un determinado valor de Guarantee_timestamp.
Guarantee_Timestamp.
Ejemplo
Como se muestra en la ilustración anterior, el valor de Guarantee_timestamp se establece como 2021-08-26T18:15:00 (para simplificar, la marca de tiempo en este ejemplo está representada por el tiempo físico). Al realizar una búsqueda o consulta, se buscan o consultan todos los datos anteriores a 2021-08-26T18:15:00.
Service_timestamp
Service_timestamp es un tipo de marca de tiempo generada y gestionada automáticamente por los nodos de consulta en Milvus. Se utiliza para indicar qué operaciones DML ejecutan los nodos de consulta.
Los datos gestionados por los nodos de consulta pueden clasificarse en dos tipos:
Datos históricos (o también llamados datos por lotes)
Datos incrementales (o también llamados datos de flujo).
En Milvus, es necesario cargar los datos antes de realizar una búsqueda o consulta. Por lo tanto, los datos por lotes de una colección son cargados por el nodo de consulta antes de que se realice una solicitud de búsqueda o consulta. Sin embargo, los datos de flujo se insertan o eliminan de Milvus sobre la marcha, lo que requiere que el nodo de consulta mantenga una línea de tiempo de las operaciones DML y las solicitudes de búsqueda o consulta. Como resultado, los nodos de consulta utilizan Service_timestamp para mantener dicha línea de tiempo. Service_timestamp puede verse como el punto de tiempo en el que ciertos datos son visibles, ya que los nodos de consulta pueden asegurarse de que todas las operaciones DML anteriores a Service_timestamp se han completado.
Cuando se recibe una solicitud de búsqueda o consulta, un nodo de consulta compara los valores de Service_timestamp y Guarantee_timestamp. Existen principalmente dos escenarios.
Service_Timestamp.
Escenario 1: Service_timestamp >= Guarantee_timestamp
Como se muestra en la figura 1, el valor de Guarantee_timestamp se establece como 2021-08-26T18:15:00. Cuando el valor de Service_timestamp crece hasta 2021-08-26T18:15:01, esto significa que todas las operaciones DML anteriores a este momento son ejecutadas y completadas por el nodo de consulta, incluyendo aquellas operaciones DML anteriores al momento indicado por Guarantee_timestamp. Como resultado, la petición de búsqueda o consulta puede ejecutarse inmediatamente.
Escenario 2: Service_timestamp < Guarantee_timestamp
Como se muestra en la figura 2, el valor de Guarantee_timestamp se establece como 2021-08-26T18:15:00, y el valor actual de Service_timestamp es sólo 2021-08-26T18:14:55. Esto significa que sólo las operaciones DML anteriores a 2021-08-26T18:14:55 se ejecutan y completan, dejando parte de las operaciones DML posteriores a este punto temporal pero anteriores a Guarantee_timestamp sin finalizar. Si la búsqueda o consulta se ejecuta en este punto, algunos de los datos requeridos son invisibles y no están disponibles todavía, afectando seriamente a la precisión de los resultados de la búsqueda o consulta. Por lo tanto, el nodo de consulta debe posponer la solicitud de búsqueda o consulta hasta que se completen las operaciones DML anteriores a guarantee_timestamp (es decir, cuando Service_timestamp >= Guarantee_timestamp).
Graceful_time
Técnicamente hablando, Graceful_time no es una marca de tiempo, sino más bien un período de tiempo (por ejemplo, 100 ms). Sin embargo, merece la pena mencionar Graceful_time porque está estrechamente relacionado con Guarantee_timestamp y Service_timestamp. Graceful_time es un parámetro configurable en el archivo de configuración de Milvus. Se utiliza para indicar el periodo de tiempo que se puede tolerar antes de que ciertos datos se hagan visibles. En resumen, se pueden tolerar operaciones DML no completadas durante Graceful_time.
Cuando hay una solicitud de búsqueda o consulta entrante, puede haber dos escenarios.
Graceful_Time.
Escenario 1: Service_timestamp + Graceful_time >= Guarantee_timestamp
Como se muestra en la figura 1, el valor de Guarantee_timestamp se establece como 2021-08-26T18:15:01, y Graceful_time como 2s. El valor de Service_timestamp se amplía a 2021-08-26T18:15:00. Aunque el valor de Service_timestamp sigue siendo menor que el de Guarantee_timestamp y no se completan todas las operaciones DML antes de 2021-08-26T18:15:01, se tolera un periodo de 2 segundos de invisibilidad de datos, como indica el valor de Graceful_time. Por lo tanto, la solicitud de búsqueda o consulta entrante puede ejecutarse inmediatamente.
Escenario 2: Service_timestamp + Graceful_time < Guarantee_timestamp
Como se muestra en la figura 2 , el valor de Guarantee_timestamp se establece como 2021-08-26T18:15:01, y Graceful_time como 2s. El valor actual de Service_timestamp es sólo 2021-08-26T18:14:54. Esto significa que las operaciones DML esperadas aún no se han completado e incluso teniendo en cuenta los 2 segundos de tiempo de gracia, la invisibilidad de los datos sigue siendo intolerable. Por lo tanto, el nodo de consulta debe aplazar la solicitud de búsqueda o consulta hasta que se completen determinadas solicitudes DML (es decir, cuando Service_timestamp + Graceful_time >= Guarantee_timestamp).
