Synchronisation temporelle

Cette rubrique présente le mécanisme de synchronisation temporelle dans Milvus.

Vue d'ensemble

Les événements dans Milvus peuvent généralement être classés en deux catégories :

• Les événements du langage de définition des données (DDL) : créer/supprimer une collection, créer/supprimer une partition, etc.

• Événements du langage de manipulation des données (DML) : insertion, recherche, etc.

Tout événement, qu'il s'agisse d'un événement DDL ou DML, est marqué d'un horodatage qui peut indiquer le moment où il s'est produit.

Supposons que deux utilisateurs lancent une série d'événements DML et DDL dans Milvus dans l'ordre chronologique indiqué dans le tableau suivant.

Idéalement, l'utilisateur 2 devrait être en mesure de voir :

• Une collection vide C0 à t2.

• Les données A1 à t7.

• Les données A1 et A2 sur t12.

• Seulement les données A2 à t17 (car les données A1 ont été supprimées de la collection avant ce point).

Ce scénario idéal peut être facilement réalisé lorsqu'il n'y a qu'un seul nœud. Cependant, Milvus est une base de données vectorielle distribuée et, pour garantir que toutes les opérations DML et DDL dans les différents nœuds sont maintenues en ordre, Milvus doit résoudre les deux problèmes suivants :

1. L'horloge est différente pour les deux utilisateurs de l'exemple ci-dessus s'ils se trouvent sur des nœuds différents. Par exemple, si l'utilisateur 2 a 24 heures de retard sur l'utilisateur 1, toutes les opérations de l'utilisateur 1 ne sont pas visibles pour l'utilisateur 2 avant le lendemain.

2. Il peut y avoir une latence du réseau. Si l'utilisateur 2 effectue une recherche sur la collection C0 à l'adresse t17, Milvus doit pouvoir garantir que toutes les opérations avant t17 sont traitées et terminées avec succès. Si l'opération de suppression à t15 est retardée en raison de la latence du réseau, il est très probable que l'utilisateur 2 puisse encore voir les données prétendument supprimées A1 lorsqu'il effectue une recherche à t17.

Milvus adopte donc un système de synchronisation temporelle (timetick) pour résoudre ces problèmes.

Oracle d'horodatage (TSO)

Pour résoudre le premier problème mentionné dans la section précédente, Milvus, comme d'autres systèmes distribués, fournit un service d'oracle d'horodatage (TSO). Cela signifie que tous les événements de Milvus doivent être affectés d'un horodatage provenant de TSO plutôt que de l'horloge locale.

Le service TSO est fourni par le coordinateur racine de Milvus. Les clients peuvent attribuer un ou plusieurs horodatages dans une seule demande d'attribution d'horodatage.

Un horodatage TSO est un type de valeur uint64 qui se compose d'une partie physique et d'une partie logique. La figure ci-dessous illustre le format d'un horodatage.

TSO_Timestamp.

Comme illustré, les 46 bits du début constituent la partie physique, à savoir le temps UTC en millisecondes. Les 18 derniers bits constituent la partie logique.

Système de synchronisation temporelle (timetick)

Cette section utilise l'exemple d'une opération d'insertion de données pour expliquer le mécanisme de synchronisation temporelle dans Milvus.

Lorsque le proxy reçoit une demande d'insertion de données du SDK, il divise les messages d'insertion en différents flux de messages (MsgStream) en fonction de la valeur de hachage des clés primaires.

Chaque message d'insertion (InsertMsg) se voit attribuer un horodatage avant d'être envoyé à MsgStream.

timesync_proxy_insert_msg

Un principe général est que dans MsgStream, les horodatages deInsertMsgs provenant du même proxy doivent être incrémentaux. Cependant, il n'existe pas de règle de ce type pour les InsertMsgs provenant de mandataires différents.

La figure suivante est un exemple de InsertMsgs dans un MsgStream. Le snippet contient cinq InsertMsgs, dont trois proviennent de Proxy1 et le reste de Proxy2.

msgstream

Les horodatages des trois InsertMsgs provenant de Proxy1 sont incrémentaux, de même que les deux InsertMsgs provenant de Proxy2. Cependant, il n'y a pas d'ordre particulier entre Proxy1 et Proxy2 InsertMsgs .

Un scénario possible est que, lors de la lecture d'un message portant l'horodatage 110 à partir de Proxy2, Milvus constate que le message portant l'horodatage 80 à partir de Proxy1 est toujours dans MsgStream. Par conséquent, Milvus introduit un système de synchronisation temporelle, timetick, pour garantir que, lors de la lecture d'un message à partir de MsgStream, tous les messages avec des valeurs d'horodatage plus petites doivent être consommés.

synchronisation_temporelle

Comme le montre la figure ci-dessus,

• Chaque proxy signale périodiquement (toutes les 200 ms par défaut) la plus grande valeur d'horodatage du dernier InsertMsg dans le MsgStreamà la coordonnée racine.

• Le coordonnateur racine identifie la valeur minimale de l'horodatage sur ce site Msgstream, quel que soit le proxy auquel appartient le site InsertMsgs. Ensuite, le coordonnateur racine insère cet horodatage minimum dans le site Msgstream. Cet horodatage est également appelé "timetick".

• Lorsque les composants consommateurs lisent le timetick inséré par le coordonnateur racine, ils comprennent que tous les messages d'insertion avec des valeurs d'horodatage inférieures ont été consommés. Par conséquent, les demandes pertinentes peuvent être exécutées en toute sécurité sans interrompre l'ordre.

La figure suivante est un exemple du site Msgstream avec l'insertion d'un timetick.

timetick

MsgStream traite les messages par lots en fonction du time tick afin de s'assurer que les messages de sortie répondent aux exigences de l'horodatage.

Prochaines étapes

• Découvrez le concept d'horodatage.
• Découvrir le flux de traitement des données dans Milvus.