Utilisation de la base de données vectorielles Milvus pour des requêtes en temps réel

Image de couverture

Cet article a été rédigé par Xi Ge et transcrit par Angela Ni.

Dans l'article précédent, nous avons parlé de l'insertion et de la persistance des données dans Milvus. Dans cet article, nous allons continuer à expliquer comment les différents composants de Milvus interagissent les uns avec les autres pour réaliser des requêtes de données en temps réel.

Vous trouverez ci-dessous quelques ressources utiles avant de commencer. Nous recommandons de les lire d'abord pour mieux comprendre le sujet de cet article.

• Plongée dans l'architecture de Milvus
• Modèle de données Milvus
• Le rôle et la fonction de chaque composant Milvus
• Traitement des données dans Milvus
• Insertion et persistance des données dans Milvus

Chargement des données dans le nœud d'interrogation

Avant l'exécution d'une requête, les données doivent d'abord être chargées dans les nœuds de requête.

Deux types de données sont chargés dans le nœud d'interrogation : les données en continu provenant du courtier de journaux et les données historiques provenant du stockage d'objets (également appelé stockage persistant ci-dessous).

Organigramme

La coordination des données est chargée de traiter les données en continu qui sont insérées en permanence dans Milvus. Lorsqu'un utilisateur de Milvus appelle collection.load() pour charger une collection, la coordination des requêtes interroge la coordination des données pour savoir quels segments ont été conservés dans le stockage et quels sont les points de contrôle correspondants. Un point de contrôle est une marque indiquant que les segments conservés avant les points de contrôle sont consommés alors que ceux après le point de contrôle ne le sont pas.

Ensuite, la coordonnatrice des requêtes produit une stratégie d'allocation basée sur les informations fournies par la coordonnatrice des données : soit par segment, soit par canal. L'allocateur de segments est chargé d'allouer des segments dans le stockage permanent (données de lot) à différents nœuds de requête. Par exemple, dans l'image ci-dessus, l'allocateur de segments attribue les segments 1 et 3 (S1, S3) au nœud d'interrogation 1, et les segments 2 et 4 (S2, S4) au nœud d'interrogation 2. L'allocateur de canaux attribue différents nœuds d'interrogation pour surveiller plusieurs canaux de manipulation de données (DMChannels) dans le courtier d'enregistrement. Par exemple, dans l'image ci-dessus, l'allocateur de canaux affecte le nœud de requête 1 à la surveillance du canal 1 (Ch1) et le nœud de requête 2 à la surveillance du canal 2 (Ch2).

Grâce à la stratégie d'attribution, chaque nœud d'interrogation charge des données de segment et surveille les canaux en conséquence. Dans le nœud d'interrogation 1 de l'image, les données historiques (données de lot) sont chargées via S1 et S3 à partir du stockage permanent. Dans le même temps, le nœud de requête 1 charge des données incrémentielles (données en continu) en s'abonnant au canal 1 du log broker.

Gestion des données dans le nœud d'interrogation

Un nœud d'interrogation doit gérer à la fois les données historiques et les données incrémentielles. Les données historiques sont stockées dans des segments scellés, tandis que les données incrémentielles sont stockées dans des segments croissants.

Gestion des données historiques

Il y a principalement deux considérations à prendre en compte pour la gestion des données historiques : l'équilibre de la charge et le basculement du nœud d'interrogation.

Équilibre de la charge

Par exemple, comme le montre l'illustration, le nœud de requête 4 s'est vu attribuer plus de segments scellés que le reste des nœuds de requête. Il est très probable que cela fasse du nœud d'interrogation 4 le goulot d'étranglement qui ralentit l'ensemble du processus d'interrogation. Pour résoudre ce problème, le système doit attribuer plusieurs segments du nœud d'interrogation 4 à d'autres nœuds d'interrogation. C'est ce qu'on appelle l'équilibrage de la charge.

Basculement d'un nœud de requête

Une autre situation possible est illustrée dans l'image ci-dessus. L'un des nœuds, le nœud d'interrogation 4, est soudainement hors service. Dans ce cas, la charge (segments alloués au nœud d'interrogation 4) doit être transférée à d'autres nœuds d'interrogation fonctionnels afin de garantir l'exactitude des résultats de l'interrogation.

Gestion incrémentale des données

Le nœud d'interrogation surveille les DMChannels pour recevoir des données incrémentielles. Un diagramme de flux est introduit dans ce processus. Il filtre d'abord tous les messages d'insertion de données. Cela permet de s'assurer que seules les données d'une partition donnée sont chargées. Chaque collection dans Milvus a un canal correspondant, qui est partagé par toutes les partitions de cette collection. Par conséquent, un organigramme est nécessaire pour filtrer les données insérées si un utilisateur de Milvus ne doit charger que les données d'une certaine partition. Dans le cas contraire, les données de toutes les partitions de la collection seront chargées dans le nœud d'interrogation.

Après avoir été filtrées, les données incrémentielles sont insérées dans des segments croissants, puis transmises aux nœuds de temps du serveur.

Diagramme de flux

Lors de l'insertion des données, un horodatage est attribué à chaque message d'insertion. Dans le canal DMC illustré dans l'image ci-dessus, les données sont insérées dans l'ordre, de gauche à droite. L'horodatage du premier message d'insertion est 1, celui du deuxième, 2, et celui du troisième, 6. Le quatrième message marqué en rouge n'est pas un message d'insertion, mais un message d'horodatage. Il indique que les données insérées dont l'horodatage est inférieur à ce timetick se trouvent déjà dans le log broker. En d'autres termes, les données insérées après ce message de timetick devraient toutes avoir des horodatages dont les valeurs sont supérieures à ce timetick. Par exemple, dans l'image ci-dessus, lorsque le nœud de requête perçoit que l'heure actuelle est 5, cela signifie que tous les messages d'insertion dont la valeur de l'horodatage est inférieure à 5 sont tous chargés dans le nœud de requête.

Le nœud de temps du serveur fournit une valeur tsafe mise à jour chaque fois qu'il reçoit un timetick du nœud d'insertion. tsafe signifie le temps de sécurité, et toutes les données insérées avant ce point dans le temps peuvent être interrogées. Par exemple, si tsafe = 9, les données insérées dont l'horodatage est inférieur à 9 peuvent toutes être interrogées.

Requête en temps réel dans Milvus

L'interrogation en temps réel dans Milvus est activée par des messages d'interrogation. Les messages de requête sont insérés dans le log broker par proxy. Les nœuds d'interrogation obtiennent ensuite les messages d'interrogation en surveillant le canal d'interrogation dans le courtier d'enregistrement.

Message de requête

Message de requête

Un message de requête comprend les informations cruciales suivantes concernant une requête :

• msgID: L'ID du message, l'ID du message d'interrogation attribué par le système.
• collectionID: L'ID de la collection à interroger (si spécifié par l'utilisateur).
• execPlan: Le plan d'exécution est principalement utilisé pour le filtrage des attributs dans une requête.
• service_ts: L'horodatage du service sera mis à jour en même temps que tsafe mentionné ci-dessus. L'horodatage du service indique à quel moment le service a été mis en place. Toutes les données insérées avant service_ts sont disponibles pour la requête.
• travel_ts: L'horodatage du voyage spécifie une plage de temps dans le passé. L'interrogation portera sur les données existant dans la période spécifiée par travel_ts.
• guarantee_ts: L'horodatage de garantie spécifie une période de temps après laquelle la requête doit être effectuée. La requête ne sera effectuée que si service_ts > guarantee_ts.

Requête en temps réel

Processus d'interrogation

Lorsqu'un message d'interrogation est reçu, Milvus juge d'abord si l'heure de service actuelle, service_ts, est supérieure à l'horodatage de garantie, guarantee_ts, dans le message d'interrogation. Dans l'affirmative, la requête est exécutée. La requête sera effectuée en parallèle sur les données historiques et les données incrémentielles. Étant donné qu'il peut y avoir un chevauchement de données entre les données en continu et les données par lots, une action appelée "réduction locale" est nécessaire pour filtrer les résultats redondants de la requête.

Toutefois, si le temps de service actuel est inférieur à l'horodatage de garantie dans un message de requête nouvellement inséré, le message de requête deviendra un message non résolu et attendra d'être traité jusqu'à ce que le temps de service devienne supérieur à l'horodatage de garantie.

Les résultats de la requête sont finalement transmis au canal de résultats. Le mandataire obtient les résultats de la requête à partir de ce canal. De même, le mandataire effectuera une "réduction globale" car il reçoit des résultats de plusieurs nœuds de requête et les résultats de la requête peuvent être répétitifs.

Pour s'assurer que le mandataire a reçu tous les résultats de la requête avant de les renvoyer au SDK, le message de résultat conservera également un enregistrement des informations, notamment les segments scellés recherchés, les DMChannels recherchés et les segments scellés globaux (tous les segments sur tous les nœuds de requête). Le système peut conclure que le mandataire a reçu tous les résultats de la requête uniquement si les deux conditions suivantes sont remplies :

• L'union de tous les segments scellés recherchés enregistrés dans tous les messages de résultats est supérieure aux segments scellés globaux,
• Tous les canaux DMC de la collection sont interrogés.

Enfin, le proxy renvoie les résultats finaux après "réduction globale" au SDK Milvus.

À propos de la série Deep Dive

Avec l'annonce officielle de la disponibilité générale de Milvus 2.0, nous avons orchestré cette série de blogs Milvus Deep Dive afin de fournir une interprétation approfondie de l'architecture et du code source de Milvus. Les sujets abordés dans cette série de blogs sont les suivants

• Vue d'ensemble de l'architecture Milvus
• API et SDK Python
• Traitement des données
• Gestion des données
• Requête en temps réel
• Moteur d'exécution scalaire
• Système d'assurance qualité
• Moteur d'exécution vectoriel