Tombstones in vectorindexen: hoe verwijderde bestanden doorzoekbaar blijven tot het compacteren

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

Verwijderde bestanden kunnen vindbaar blijven wanneer een index een logisch tombstone registreert, maar oudere segmenten, replica's, caches of afgeleide chunks nog steeds zoekopdrachten bedienen.

Een pdf verwijderen van een thuis-NAS verwijdert niet noodzakelijk de embedding, tekst uit de miniatuur, OCR-uitvoer of het gecachte zoekresultaat. Veel opslagsystemen markeren records eerst als verwijderd en maken hun bytes later vrij tijdens compaction. Correcte querypaden moeten de markering onmiddellijk respecteren, maar onvolledige verspreiding of een omzeild filter kan ervoor zorgen dat verouderd bewijsmateriaal toch zichtbaar wordt.

Een tombstone scheidt logische verwijdering van fysieke vrijgave

Bij opslag die uitsluitend toevoegingen uitvoert, zou het herschrijven van een groot segment voor elke verwijdering duur zijn. Een tombstone registreert dat een identifier niet langer actief is. Queries raadplegen deze status, terwijl achtergrondcompaction de segmenten later samenvoegt en zowel het verouderde record als de markering verwijdert zodra dat veilig is.

Een uitleg van logische tombstones in databases merkt op dat tombstones voorkomen dat verwijderde rijen worden teruggegeven voordat compaction hun fysieke gegevens verwijdert. Ditzelfde principe is van belang voor vectorsystemen, ook wanneer hun implementaties van segmenten en verwijderingskaarten verschillen.

Dit onderscheid verklaart waarom het schijfgebruik na verwijdering mogelijk niet daalt. Het verklaart op zichzelf niet waarom een zichtbaar zoekresultaat verschijnt: een correcte actuele query moet de vector met tombstone uitsluiten, ook zolang de bytes ervan nog op schijf staan.

Een verwijderd bestand kan verschillende onafhankelijke afgeleiden achterlaten

Eén bronbestand kan chunks, embeddings, trefwoordindexen, samenvattingen, OCR-tekst, miniaturen en vermeldingen in de antwoordcache opleveren. Alleen de vector-ID's verwijderen laat andere zoekpaden intact. Opnieuw opnemen onder een nieuwe identifier kan ook duplicaten creëren die niet in de oorspronkelijke verwijderingslijst staan.

Databasehandleidingen over compaction voor het opruimen leggen uit dat vrijgave tijdens compaction plaatsvindt, omdat het voortdurend herschrijven van gegevens kostbaar is. Totdat gecoördineerd opruimen is voltooid, moeten fysieke opslag en logische zichtbaarheid als afzonderlijke statussen worden behandeld. Dat onderscheid verandert de uiteindelijke beslissing voor het huishouden.

Een betrouwbare verwijderingsadministratie koppelt de bronidentiteit daarom aan elke afgeleide en namespace. Ze registreert ook de generatie die wordt verwijderd, zodat een vertraagde verwijderingsgebeurtenis niet per ongeluk een nieuwere vervanging met dezelfde bestandsnaam verbergt.

Waar verouderde replica's en caches de verwijderingssemantiek doorbreken

Gedistribueerd zoeken of zoeken met meerdere processen brengt verspreidingsvertraging met zich mee. Eén worker kan de tombstone respecteren terwijl een andere een ouder segment aanbiedt; een responscache kan een eerder samengesteld antwoord teruggeven zonder de index überhaupt te raadplegen. Back-ups kunnen de verwijderde afgeleide later herstellen als de bewaarbeleidsregels deze niet omvatten.

DataStax beschrijft tombstones voor replica's als markeringen die over replica's worden verspreid voordat ze uiteindelijk worden verwijderd. De graceperiode beschermt tegen het opnieuw verschijnen van gegevens in gedistribueerde opslag, maar laat ook zien waarom voortijdig opruimen en inconsistente replica's zorgvuldige coördinatie vereisen. Deze grens blijft zichtbaar bij latere beoordeling van het bewijsmateriaal.

De foutgrens ligt bij de zichtbaarheid in queries, niet bij ingenomen bytes. Als een ondersteund zoekpad het verwijderde bewijsmateriaal nog kan teruggeven na het beloofde verwijderingsvenster, is de verwijdering niet voltooid, ook al meldt een dashboard succes.

-15% OFF
Single board computer zimaboard2

Bewijs de verwijdering via elk zoekpad

Leg vóór de verwijdering de bron-ID, afgeleide chunk-ID's, een unieke zin en één gecachte vraag vast. Verwijder het bestand en voer daarna vóór en na compaction queries uit op de zin, een semantische parafrase, een metadat filter, de bron-ID en de gecachte vraag.

Gebruik dezelfde discipline voor actuele bestanden als beschreven bij de status van incrementele indexering: de test moet logische zichtbaarheid, fysieke opslag en historische bewaring van elkaar onderscheiden. Controleer elke geconfigureerde replica of worker in plaats van op één geslaagde query te vertrouwen. De afhankelijkheid moet daarom in de praktijk afzonderlijk worden gemeten.

Slaag alleen wanneer geen enkel pad in de actuele modus de bron of de afgeleiden teruggeeft, caches ongeldig zijn gemaakt en compaction uiteindelijk de verwachte opslagruimte vrijmaakt. Als historisch herstel opzettelijk is toegestaan, scherm het dan af met afzonderlijke autorisatie en maak het onbeschikbaar voor gewone RAG-queries.

Tech & AI HUB

Meer om te lezen

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.