Tombstones do Índice Vetorial: Como os Ficheiros Eliminados Permanecem Pesquisáveis até à Compactação

Os ficheiros eliminados podem continuar a ser detetáveis quando um índice regista um tombstone lógico, mas segmentos mais antigos, réplicas, caches ou blocos derivados continuam a responder às pesquisas.

Remover um PDF de um NAS doméstico não remove necessariamente a respetiva incorporação, o texto da miniatura, o resultado do OCR ou o resultado de recuperação em cache. Muitos motores de armazenamento marcam primeiro os registos como eliminados e só mais tarde recuperam o espaço durante a compactação. Os caminhos de consulta corretos devem respeitar imediatamente o marcador, mas uma propagação incompleta ou um filtro ignorado pode permitir que evidências obsoletas sejam apresentadas.

Um Tombstone Separa a Eliminação Lógica da Recuperação Física

No armazenamento orientado para anexação, reescrever um segmento grande a cada eliminação seria dispendioso. Um tombstone regista que um identificador já não está ativo. As consultas consultam este estado, enquanto a compactação em segundo plano combina posteriormente os segmentos e elimina tanto o registo obsoleto como o respetivo marcador quando tal for seguro.

Uma explicação sobre tombstones lógicos de bases de dados observa que os tombstones impedem que as linhas eliminadas sejam devolvidas antes de a compactação remover os respetivos dados físicos. O mesmo princípio é importante para os sistemas vetoriais, mesmo quando as respetivas implementações de segmentos e mapas de eliminação são diferentes.

Esta distinção explica por que razão a utilização do disco pode não diminuir após uma eliminação. Por si só, não explica um resultado de pesquisa visível: uma consulta atual correta tem de excluir o vetor marcado com um tombstone, mesmo enquanto os respetivos bytes permanecem no disco.

Um Ficheiro Eliminado Pode Deixar Vários Derivados Independentes

Um ficheiro de origem pode produzir blocos, incorporações, índices de palavras-chave, resumos, texto OCR, miniaturas e entradas de cache de respostas. Eliminar apenas os IDs dos vetores deixa intactos outros caminhos de recuperação. A reingestão com um novo identificador também pode criar duplicados que a lista de eliminação original não abrange.

A documentação de bases de dados sobre a limpeza durante a compactação explica que a recuperação ocorre durante a compactação, porque reescrever continuamente os dados é dispendioso. Até a limpeza coordenada estar concluída, o armazenamento físico e a visibilidade lógica devem ser tratados como estados separados. Esta distinção altera a decisão doméstica resultante.

Um registo de eliminações fiável associa, por isso, a identidade da origem a todos os derivados e namespaces. Regista também a geração que está a ser removida, impedindo que um evento de eliminação atrasado oculte acidentalmente uma substituição mais recente com o mesmo nome de ficheiro.

Onde as Réplicas Obsoletas e os Caches Quebram a Semântica da Eliminação

A pesquisa distribuída ou multiprocesso acrescenta um atraso de propagação. Um trabalhador pode respeitar o tombstone enquanto outro disponibiliza um segmento mais antigo; um cache de respostas pode devolver uma resposta composta anteriormente sem consultar o índice. As cópias de segurança podem posteriormente restaurar o derivado eliminado, caso as regras de retenção não o incluam.

A DataStax descreve os tombstones de réplicas como marcadores propagados entre réplicas antes da remoção final. O período de tolerância protege contra o ressurgimento em armazenamento distribuído, mas também demonstra por que razão a limpeza prematura e as réplicas inconsistentes exigem uma coordenação cuidadosa. Este limite continua visível durante a análise posterior das evidências.

O limite da falha é a visibilidade da consulta, não os bytes ocupados. Se qualquer rota de pesquisa suportada ainda puder devolver as evidências eliminadas após o período de eliminação prometido, o sistema não concluiu a eliminação, mesmo que um painel indique sucesso.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Comprove a Eliminação em Todos os Caminhos de Pesquisa

Antes da eliminação, registe o ID da origem, os IDs dos blocos derivados, uma frase única e uma pergunta em cache. Elimine o ficheiro e, em seguida, faça consultas pela frase, por uma paráfrase semântica, por um filtro de metadados, pelo ID da origem e pela pergunta em cache, antes e depois da compactação.

Utilize a mesma disciplina de ficheiros atuais descrita no estado da indexação incremental: o teste deve distinguir a visibilidade lógica, o armazenamento físico e a retenção histórica. Inspecione todas as réplicas ou trabalhadores configurados, em vez de confiar numa única consulta bem-sucedida. A dependência deve, por isso, ser medida separadamente na prática.

Considere o processo aprovado apenas quando nenhuma rota do modo atual devolver a origem ou os respetivos derivados, os caches forem invalidados e a compactação recuperar posteriormente o armazenamento esperado. Se a recuperação histórica for intencional, isole-a atrás de uma autorização separada e torne-a indisponível para consultas RAG normais.