Comment Milvus équilibre-t-il la charge des requêtes entre les nœuds ?

Image de couverture Binlog

Par Xi Ge.

Dans les articles de blog précédents, nous avons successivement présenté les fonctions de suppression, de jeu de bits et de compactage dans Milvus 2.0. Pour conclure cette série, nous aimerions partager la conception de l'équilibrage de charge, une fonction vitale dans le cluster distribué de Milvus.

Mise en œuvre

Si le nombre et la taille des segments mis en mémoire tampon dans les nœuds d'interrogation diffèrent, les performances de recherche entre les nœuds d'interrogation peuvent également varier. Le pire des cas pourrait se produire lorsque quelques nœuds d'interrogation sont épuisés par la recherche d'une grande quantité de données, mais que les nœuds d'interrogation nouvellement créés restent inactifs parce qu'aucun segment ne leur est distribué, ce qui entraîne un gaspillage massif des ressources de l'unité centrale et une baisse considérable des performances de recherche.

Pour éviter de telles circonstances, le coordinateur des requêtes (query coord) est programmé pour distribuer des segments de manière égale à chaque nœud de requête en fonction de l'utilisation de la mémoire vive des nœuds. Les ressources de l'unité centrale sont donc consommées de manière égale par tous les nœuds, ce qui améliore considérablement les performances de la recherche.

Déclencher l'équilibrage automatique de la charge

Selon la valeur par défaut de la configuration queryCoord.balanceIntervalSeconds, la coordination des requêtes vérifie l'utilisation de la mémoire vive (en pourcentage) de tous les nœuds de requête toutes les 60 secondes. Si l'une des conditions suivantes est remplie, la coordination des requêtes commence à équilibrer la charge des requêtes sur le nœud de requête :

1. L'utilisation de la RAM de n'importe quel nœud de requête dans le cluster est supérieure à queryCoord.overloadedMemoryThresholdPercentage (par défaut : 90) ;
2. ou la valeur absolue de la différence d'utilisation de la RAM entre deux nœuds de requête est supérieure à queryCoord.memoryUsageMaxDifferencePercentage (valeur par défaut : 30).

Une fois que les segments sont transférés du nœud de requête source au nœud de requête de destination, ils doivent également satisfaire aux deux conditions suivantes :

1. L'utilisation de la mémoire vive du nœud de destination n'est pas supérieure à queryCoord.overloadedMemoryThresholdPercentage (valeur par défaut : 90) ;
2. La valeur absolue de la différence d'utilisation de la RAM des nœuds de requête source et de destination après l'équilibrage de la charge est inférieure à celle avant l'équilibrage de la charge.

Lorsque les conditions ci-dessus sont remplies, la coordination des requêtes procède à l'équilibrage de la charge de la requête entre les nœuds.

Équilibrage de la charge

Lorsque l'équilibrage de la charge est déclenché, la coordinatrice des requêtes charge d'abord le(s) segment(s) cible(s) dans le nœud de destination. Les deux nœuds d'interrogation renvoient les résultats de recherche du ou des segments cibles à chaque demande de recherche à ce stade, afin de garantir l'exhaustivité du résultat.

Une fois que le nœud d'interrogation de destination a chargé avec succès le segment cible, le coordonnateur d'interrogation publie une adresse sealedSegmentChangeInfo sur le canal d'interrogation. Comme indiqué ci-dessous, onlineNodeID et onlineSegmentIDs indiquent respectivement le nœud de requête qui charge le segment et le segment chargé, et offlineNodeID et offlineSegmentIDs indiquent respectivement le nœud de requête qui doit libérer le segment et le segment à libérer.

sealedSegmentChangeInfo

Après avoir reçu l'information sealedSegmentChangeInfo, le nœud de requête source libère le segment cible.

Processus d'équilibrage de la charge

L'ensemble du processus aboutit lorsque le nœud de requête source libère le segment cible. La charge de la requête est alors équilibrée entre les nœuds de requête, ce qui signifie que l'utilisation de la mémoire vive de tous les nœuds de requête n'est pas supérieure à queryCoord.overloadedMemoryThresholdPercentage, et que la valeur absolue de la différence d'utilisation de la mémoire vive entre les nœuds de requête source et de destination après l'équilibrage de la charge est inférieure à celle observée avant l'équilibrage de la charge.

Quelles sont les prochaines étapes ?

Dans la série de blogs sur les nouvelles fonctionnalités de la version 2.0, nous expliquons la conception des nouvelles fonctionnalités. Plus d'informations dans cette série de blogs !

• Comment Milvus supprime les données en continu dans un cluster distribué
• Comment compacter les données dans Milvus ?
• Comment Milvus équilibre la charge des requêtes entre les nœuds ?
• Comment Bitset permet la polyvalence de la recherche par similarité vectorielle

Ceci est le dernier article de la série de blogs sur les nouvelles fonctionnalités de Milvus 2.0. Après cette série, nous prévoyons une nouvelle série de Milvus Deep Dive, qui présente l'architecture de base de Milvus 2.0. Restez à l'écoute.