Horodatage

Cette rubrique explique le concept d'horodatage et présente les quatre principaux paramètres liés à l'horodatage dans la base de données vectorielles Milvus.

Vue d'ensemble

Milvus est une base de données vectorielle qui permet de rechercher et d'interroger des vecteurs convertis à partir de données non structurées. Lors de l'exécution d'une opération en langage de manipulation de données (DML), y compris l'insertion et la suppression de données, Milvus attribue des horodatages aux entités impliquées dans l'opération. Par conséquent, toutes les entités de Milvus possèdent un attribut d'horodatage. Et les lots d'entités dans la même opération DML partagent la même valeur d'horodatage.

Paramètres d'horodatage

Plusieurs paramètres liés à l'horodatage interviennent lorsque vous effectuez une recherche ou une requête de similarité vectorielle dans Milvus.

• Guarantee_timestamp

• Service_timestamp

• Graceful_time

• Travel_timestamp

Guarantee_timestamp

Guarantee_timestamp est un type d'horodatage utilisé pour garantir que toutes les données mises à jour par des opérations DML avant Guarantee_timestamp sont visibles lors d'une recherche ou d'une requête de similarité vectorielle. Par exemple, si vous insérez un lot de données à 15 heures, un autre lot à 17 heures, et que la valeur de Guarantee_timestamp est fixée à 18 heures lors d'une recherche de similarité vectorielle. Cela signifie que les deux lots de données insérés respectivement à 15 heures et à 17 heures doivent être impliqués dans la recherche.

Si Guarantee_timestamp n'est pas configuré, Milvus prend automatiquement le moment où la demande de recherche est faite. Par conséquent, la recherche est effectuée sur une vue de données avec toutes les mises à jour de données par des opérations DML avant la recherche.

Pour vous éviter d'avoir à comprendre le TSO dans Milvus, en tant qu'utilisateur, vous n'avez pas à configurer directement le paramètre Guarantee_timestamp. Il suffit de choisir le niveau de cohérence et Milvus gère automatiquement le paramètre Guarantee_timestamp pour vous. Chaque niveau de cohérence correspond à une certaine valeur de Guarantee_timestamp.

Guarantee_Timestamp.

Exemple

Comme le montre l'illustration ci-dessus, la valeur de Guarantee_timestamp est définie comme 2021-08-26T18:15:00 (pour des raisons de simplicité, l'horodatage dans cet exemple est représenté par le temps physique). Lorsque vous effectuez une recherche ou une requête, toutes les données antérieures à 2021-08-26T18:15:00 sont recherchées ou interrogées.

Service_timestamp

Service_timestamp est un type d'horodatage généré et géré automatiquement par les nœuds de requête dans Milvus. Il est utilisé pour indiquer quelles opérations DML sont exécutées par les nœuds de requête.

Les données gérées par les nœuds de requête peuvent être classées en deux catégories :

• les données historiques (également appelées données par lots)

• les données incrémentielles (également appelées données en continu).

Dans Milvus, vous devez charger les données avant d'effectuer une recherche ou une requête. Par conséquent, les données par lots d'une collection sont chargées par le nœud de requête avant qu'une recherche ou une requête ne soit effectuée. Toutefois, les données en continu sont insérées dans Milvus ou supprimées à la volée, ce qui oblige le nœud de requête à conserver une chronologie des opérations DML et des requêtes de recherche ou d'interrogation. Par conséquent, les nœuds de requête utilisent Service_timestamp pour conserver cette chronologie. Service_timestamp peut être considéré comme le moment où certaines données sont visibles, car les nœuds de requête peuvent s'assurer que toutes les opérations DML antérieures à Service_timestamp sont terminées.

Lorsqu'il reçoit une demande de recherche ou d'interrogation, un nœud d'interrogation compare les valeurs de Service_timestamp et de Guarantee_timestamp. Il existe principalement deux scénarios.

Service_Timestamp.

Scénario 1 : Service_timestamp >= Guarantee_timestamp

Comme le montre la figure 1, la valeur de Guarantee_timestamp est fixée à 2021-08-26T18:15:00. Lorsque la valeur de Service_timestamp est augmentée à 2021-08-26T18:15:01, cela signifie que toutes les opérations DML antérieures à ce point dans le temps sont exécutées et terminées par le nœud de requête, y compris les opérations DML antérieures à l'heure indiquée par Guarantee_timestamp. Par conséquent, la demande de recherche ou d'interrogation peut être exécutée immédiatement.

Scénario 2 : Service_timestamp < Guarantee_timestamp

Comme le montre la figure 2, la valeur de Guarantee_timestamp est définie comme 2021-08-26T18:15:00, et la valeur actuelle de Service_timestamp est seulement 2021-08-26T18:14:55. Cela signifie que seules les opérations DML avant 2021-08-26T18:14:55 sont exécutées et terminées, laissant une partie des opérations DML après ce point temporel mais avant Guarantee_timestamp inachevées. Si la recherche ou la requête est exécutée à ce stade, certaines des données requises sont encore invisibles et indisponibles, ce qui affecte sérieusement la précision des résultats de la recherche ou de la requête. Par conséquent, le nœud d'interrogation doit reporter la demande de recherche ou d'interrogation jusqu'à ce que les opérations DML avant guarantee_timestamp soient terminées (c'est-à-dire lorsque Service_timestamp >= Guarantee_timestamp).

Graceful_time

Techniquement parlant, Graceful_time n'est pas un horodatage, mais plutôt une période de temps (par exemple 100 ms). Toutefois, Graceful_time mérite d'être mentionné car il est étroitement lié à Guarantee_timestamp et Service_timestamp. Graceful_time est un paramètre configurable dans le fichier de configuration de Milvus. Il est utilisé pour indiquer la période de temps qui peut être tolérée avant que certaines données ne deviennent visibles. En bref, les opérations DML non terminées pendant Graceful_time peuvent être tolérées.

En cas de recherche ou de requête entrante, il peut y avoir deux scénarios.

Graceful_Time.

Scénario 1 : Service_timestamp + Graceful_time >= Guarantee_timestamp

Comme le montre la figure 1, la valeur de Guarantee_timestamp est fixée à 2021-08-26T18:15:01, et celle de Graceful_time à 2s. La valeur de Service_timestamp est augmentée à 2021-08-26T18:15:00. Bien que la valeur de Service_timestamp soit toujours inférieure à celle de Guarantee_timestamp et que toutes les opérations DML avant 2021-08-26T18:15:01 ne soient pas terminées, une période de 2 secondes d'invisibilité des données est tolérée, comme l'indique la valeur de Graceful_time. Par conséquent, la recherche entrante ou la demande de requête peut être exécutée immédiatement.

Scénario 2 : Service_timestamp + Graceful_time < Guarantee_timestamp

Comme le montre la figure 2 , la valeur de Guarantee_timestamp est définie comme 2021-08-26T18:15:01, et Graceful_time comme 2s. La valeur actuelle de Service_timestamp n'est que 2021-08-26T18:14:54, ce qui signifie que les opérations DML attendues ne sont pas encore terminées et que, même avec un délai de grâce de 2 secondes, l'invisibilité des données reste intolérable. Par conséquent, le nœud de requête doit reporter la recherche ou la requête jusqu'à ce que certaines requêtes DML soient terminées (c'est-à-dire lorsque Service_timestamp + Graceful_time >= Guarantee_timestamp).

Prochaines étapes

• Découvrez comment l'horodatage garanti permet une cohérence réglable dans Milvus.