Comment la compaction d’une base de données vectorielle récupère-t-elle de l’espace après la suppression d’un document ?
La compaction d’une base de données vectorielle récupère l’espace supprimé en réécrivant les enregistrements actifs dans des segments propres et en retirant les anciens fichiers de segments qui contiennent encore des vecteurs supprimés.
La suppression d’un document domestique d’une bibliothèque RAG locale peut le faire disparaître immédiatement des recherches, alors que l’utilisation du disque change à peine. Il ne s’agit pas nécessairement d’un échec de la suppression. De nombreuses bases de données vectorielles séparent la visibilité logique du nettoyage du stockage physique afin que les écritures au premier plan restent rapides et que les lecteurs puissent continuer à utiliser des segments immuables ou orientés ajout. La compaction constitue le processus de maintenance ultérieur qui transforme ces suppressions logiques en une représentation physique plus compacte.
Une suppression modifie généralement la visibilité avant de réécrire les octets stockés
Modifier physiquement un fichier d’index volumineux à chaque suppression créerait de coûteuses écritures aléatoires et une gestion complexe de la concurrence. De nombreux moteurs enregistrent plutôt un marqueur de suppression, un tombstone ou un journal des suppressions indiquant au moteur de recherche d’ignorer le vecteur.
Les tombstones HNSW permettent aux objets supprimés de devenir inéligibles à la recherche dans le graphe avant que la maintenance en arrière-plan ne supprime physiquement l’ensemble de leur état d’indexation.
Le résultat visible par l’utilisateur et le résultat au niveau du disque se produisent donc à des moments différents. L’enregistrement peut cesser d’apparaître dans les résultats de recherche des plus proches voisins tandis que ses anciens octets restent dans un segment existant.
Cette séparation permet également à la base de données de coordonner les requêtes concurrentes, les réplicas, les instantanés et les règles de conservation avant de détruire les structures de stockage historiques.
Les enregistrements supprimés s’accumulent dans les segments jusqu’à ce qu’un seuil de nettoyage soit atteint
Un segment peut contenir à la fois des vecteurs actifs et des enregistrements qui ne sont plus éligibles à la recherche. À mesure que les mises à jour et les suppressions s’accumulent, le ratio entre les données utiles et les données obsolètes diminue.
Un seuil de vecteurs supprimés peut retarder le nettoyage coûteux jusqu’à ce qu’un nombre suffisant de points obsolètes se soit accumulé pour qu’une réécriture du segment en vaille la peine.
Attendre un seuil permet d’amortir le travail de maintenance. Réécrire un segment pour récupérer un seul petit enregistrement supprimé coûterait plus d’E/S que l’espace récupéré. Sur un serveur domestique soumis à une réindexation fréquente, la quantité visible de stockage physique obsolète peut donc augmenter pendant un certain temps avant que l’optimiseur ne juge le nettoyage pertinent.
La compaction copie les données actives dans de nouveaux segments ou des segments fusionnés
Une fois la maintenance lancée, la base de données lit les segments source éligibles, ignore les enregistrements supprimés logiquement et écrit les vecteurs et les données utiles conservés dans une nouvelle représentation compacte.
La compaction par fusion de segments et nettoyage des suppressions réécrit les données conservées dans des segments plus propres, en omettant les enregistrements déjà supprimés logiquement ou arrivés à expiration.
Les petits segments peuvent être fusionnés en même temps, ce qui réduit le nombre de structures distinctes que le moteur de recherche doit consulter. Le nouveau segment représente l’état actif au lieu de conserver toutes les mutations historiques.
Cette réécriture peut nécessiter temporairement davantage d’espace libre, car les anciens et les nouveaux segments peuvent coexister jusqu’à ce que le remplacement soit vérifié et activé.
Les index sont reconstruits autour de l’ensemble des vecteurs conservés
La suppression des octets correspondant aux données vectorielles ne constitue qu’une partie du nettoyage. Les liens du graphe, les structures quantifiées, les filtres et les métadonnées des segments peuvent faire référence à des enregistrements qui n’appartiennent plus au segment actif.
Un processus de compaction qui reconstruit les index pendant l’optimisation garantit que les structures de recherche du graphe et les structures auxiliaires correspondent à l’ensemble des vecteurs conservés, au lieu de conserver des références vers des points supprimés.
Pour HNSW, cela peut modifier la topologie du graphe même lorsque les vecteurs restants n’ont pas changé. C’est pourquoi la compaction peut influencer le parcours de recherche des voisins approximatifs tout en préservant le même jeu de données logique. Le mécanisme décrit dans cet article concerne le cycle de vie du stockage : les enregistrements obsolètes sont exclus de l’index réécrit afin que leur empreinte physique puisse finalement disparaître.
Les anciens segments doivent être retirés avant que leur espace de stockage puisse être libéré
Une fois le segment compacté devenu la représentation active, les anciens segments sont marqués comme obsolètes ou supprimés. Les fichiers sous-jacents peuvent toutefois attendre une période de collecte des déchets ou de conservation avant que les blocs réellement occupés sur le disque ne soient libérés.
Lorsque la collecte des déchets suit la compaction, les fichiers de segments supprimés peuvent rester temporairement présents après l’activation du remplacement compacté. L’espace du système de fichiers peut donc être libéré plus tard que la visibilité dans les requêtes ne change.
Les instantanés, la conservation des sauvegardes, la réplication ou les lecteurs qui maintiennent des références peuvent prolonger ce délai dans les systèmes qui préservent les anciennes générations de segments.
La surveillance du disque doit donc distinguer le nombre logique d’entités, la taille des segments actifs, l’espace temporaire requis par la compaction, les segments supprimés et la capacité libre du système de fichiers.
La compaction est une maintenance en arrière-plan qui a son propre coût en ressources
La lecture des anciens segments, l’écriture des nouveaux, la reconstruction des index et la suppression des fichiers obsolètes consomment du processeur, de la bande passante disque, de la mémoire et parfois un espace de stockage temporaire en double.
Les métriques de nettoyage des tombstones rendent la réparation liée aux suppressions observable comme une charge de maintenance avec ses propres cycles, durées et besoins en ressources.
Éviter les enregistrements obsolètes dans l’index après les mises à jour de fichiers constitue une exigence en amont : une suppression de la source doit d’abord parvenir à la base de données vectorielle avant que la compaction puisse récupérer la représentation obsolète.
Produits recommandés
Centre Tech & IA
Plus à lire
Qu’est-ce que l’état de Plex et quelles parties doivent être persistantes ?
L’état persistant de Plex regroupe les informations qui préservent l’expérience du serveur après un redémarrage ou une reconstruction ; les données multimédias et les...
Comment Plex gère-t-il l’authentification entre les sessions locales et distantes ?
L’authentification Plex commence par l’identité du serveur et du compte, puis les chemins réseau locaux ou distants déterminent l’accessibilité et le fonctionnement de la...
Pourquoi la recherche dans Plex peut-elle ralentir à mesure que les données de la bibliothèque augmentent ?
La croissance de la bibliothèque n’est pas à elle seule la cause du problème. Testez la forme des requêtes, les index, l’état du cache,...
