Vektorsökningsindexets gravstenar: Hur raderade filer förblir sökbara tills komprimering utförs

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

Raderade filer kan fortfarande vara sökbara när ett index registrerar en logisk gravsten, men äldre segment, repliker, cacheminnen eller härledda delar fortfarande används för sökningar.

Att ta bort en PDF från en hem-NAS innebär inte nödvändigtvis att dess inbäddning, miniatyrtext, OCR-resultat eller cachade sökresultat också tas bort. Många lagringsmotorer markerar först poster som raderade och återvinner deras utrymme senare under komprimeringen. Korrekta sökvägar ska respektera markeringen omedelbart, men ofullständig spridning eller ett kringgått filter kan göra att föråldrad information visas.

En gravsten skiljer logisk radering från fysisk återvinning

I tilläggsorienterad lagring skulle det vara dyrt att skriva om ett stort segment för varje radering. En gravsten registrerar att en identifierare inte längre är aktiv. Frågor kontrollerar detta tillstånd, medan bakgrundskomprimering senare sammanfogar segment och tar bort både den föråldrade posten och dess markering när det är säkert.

En förklaring av logiska gravstenar i databaser noterar att gravstenar hindrar raderade rader från att returneras innan komprimeringen tar bort deras fysiska data. Samma princip är viktig för vektorsystem, även när deras implementationer av segment och raderingskartor skiljer sig åt.

Denna skillnad förklarar varför diskutrymmet kanske inte minskar efter en radering. Den förklarar däremot inte i sig ett synligt sökresultat: en korrekt aktuell fråga måste utesluta den gravstensmärkta vektorn även medan dess byte finns kvar på disken.

En raderad fil kan lämna flera oberoende härledda data

En källfil kan ge upphov till delar, inbäddningar, nyckelordsindex, sammanfattningar, OCR-text, miniatyrbilder och poster i svars- och frågecache. Om endast vektor-ID:na raderas finns andra sökvägar kvar. Ny indexering med en ny identifierare kan också skapa dubbletter som den ursprungliga raderingslistan inte omfattar.

Databasdokumentation om rensning genom komprimering förklarar att återvinning sker under komprimeringen eftersom det är kostsamt att skriva om data kontinuerligt. Tills den samordnade rensningen är klar måste fysisk lagring och logisk synlighet behandlas som separata tillstånd. Denna skillnad påverkar det beslut som hushållet fattar.

En tillförlitlig raderingslogg kopplar därför källans identitet till alla härledda data och namnrymder. Den registrerar också den generation som tas bort, vilket förhindrar att en fördröjd raderingshändelse av misstag döljer en nyare ersättning med samma filnamn.

Var föråldrade repliker och cacheminnen bryter raderingssemantiken

Distribuerad sökning eller sökning i flera processer medför fördröjningar i spridningen. En arbetare kan respektera gravstenen medan en annan använder ett äldre segment; ett svarscacheminne kan returnera ett tidigare sammansatt svar utan att alls fråga indexet. Säkerhetskopior kan senare återställa den raderade härledda datan om lagringsreglerna inte omfattar den.

DataStax beskriver gravstenar för repliker som markeringar som sprids mellan repliker innan de slutligen tas bort. Toleransperioden skyddar mot att data återuppstår i distribuerad lagring, men visar också varför för tidig rensning och inkonsekventa repliker kräver noggrann samordning. Denna gräns förblir synlig vid senare granskning av informationen.

Felgränsen gäller sökbarhet, inte upptaget utrymme. Om någon stödd sökväg fortfarande kan returnera den raderade informationen efter det utlovade raderingsfönstret har systemet inte slutfört raderingen, även om en instrumentpanel visar att den lyckats.

-15% OFF
Single board computer zimaboard2

Bevisa radering genom alla sökvägar

Före raderingen ska du registrera käll-ID:t, ID:na för härledda delar, en unik fras och en cachad fråga. Radera filen och sök sedan efter frasen, en semantisk parafras, ett metadatafilter, käll-ID:t och den cachade frågan före och efter komprimeringen.

Använd samma disciplin för aktuella filer som beskrivs i tillståndet för inkrementell indexering: testet ska skilja mellan logisk synlighet, fysisk lagring och historisk lagring. Kontrollera varje konfigurerad replik eller arbetare i stället för att lita på en enda lyckad fråga. Beroendet måste därför mätas separat i praktiken.

Godkänn endast när ingen aktuell sökväg returnerar källan eller dess härledda data, cacheminnena har ogiltigförklarats och komprimeringen så småningom återvinner det förväntade lagringsutrymmet. Om historisk återställning är avsiktlig ska den isoleras bakom separat behörighetskontroll och göras otillgänglig för vanliga RAG-frågor.

Teknik- och AI-hubb

Mer att läsa

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.