Vad är en tombstone i ett vektorindex, och varför är den viktig efter att en fil har raderats?
En vektorsindex-tombstone är en logisk raderingsmarkör som döljer en borttagen post innan den underliggande sökstrukturen har återanvänt dess fysiska utrymme.
I ett lokalt RAG-index kan en raderad PDF eller bild försvinna från vanliga resultat långt innan vektorgrafen, segmentfilerna eller lagringssidorna har skrivits om. Tombstones gör att databasen kan bevara indexets konsistens medan underhållet sker senare. Detta mellanläge är viktigt för lagringsuppskattningar, indexets hälsa, ändringsfrekvens och alla antaganden om att en logisk radering är samma sak som omedelbar fysisk radering.
En tombstone markerar en post som raderad före fysisk rensning
Att radera en post från ett approximativt index innebär inte alltid att alla fysiska referenser kan tas bort i en enda billig operation. Systemet kan i stället markera objektet som raderat, utesluta det från synliga resultat och lämna den strukturella rensningen till ett senare underhållstillfälle.
I ett HNSW-index markerar tombstones raderade objekt och kan finnas kvar i grafen tills en rensningsprocess tar bort dem.
För en kunskapsbas i hemmet innebär detta att källfilen kan vara borta och frågelagret korrekt kan dölja dess textsegment, även om det interna indextillståndet fortfarande minns att dessa noder en gång fanns.
Sökningen kan dölja en raderad vektor medan indexet fortfarande innehåller tillstånd
Logisk radering och fysisk återvinning besvarar olika frågor. Den första gäller om posten får visas i sökresultat; den andra gäller om dess byte och indexrelationer har tagits bort från lagring och minnesstrukturer.
Segmentbaserade index kan lämna raderade poster tills segmenten fogas samman i stället för att tvinga varje radering att omedelbart skriva om ett segment.
Denna åtskillnad är anledningen till att antalet poster i en samling kan minska innan diskutrymmet gör det. Den förklarar också varför arbetsbelastningar med många raderingar och uppdateringar kan bygga upp ett underhållsbehov utan att gamla poster åter visas i vanliga sökningar.
En övervakningspanel bör därför skilja mellan aktiva poster, väntande raderade poster, antal segment och faktisk diskanvändning, i stället för att behandla ett enda mått som bevis på att rensningen är klar.
Tombstones samlas när filer ändras eller ersätts upprepade gånger
Ett privat index kan skapa raderingsmarkörer under normala uppdateringar, inte bara när en användare tar bort en fil permanent. När en dokumentversion ersätts kan gamla textsegment raderas och nya läggas till, medan omorganisering av mappar kan avveckla poster som hörde till tidigare identiteter.
Föränderliga vektorsamlingar samlar uppdateringar och raderingar innan segmentoptimering konsoliderar ändringarna asynkront.
Om en kunskapsbas i hemmet bäddar om dokument ofta kan tombstone-belastningen bli en bättre indikator på ändringsfrekvens än antalet filer som för närvarande går att söka i. Rensningsfrekvensen bör anpassas efter uppdateringstakten och tillgängligt I/O-utrymme.
En tombstone är inte säker radering
En logisk markör är utformad för att säkerställa indexets korrekthet, inte för forensisk radering. Gamla byte kan finnas kvar i segmentfiler, ögonblicksbilder, repliker, säkerhetskopior, ledigt filsystemutrymme eller andra härledda lagringsplatser tills separata livscykelprocesser tar bort dem.
Det senare steget med komprimering efter radering är en annan mekanism än själva tombstonen, eftersom den kan skriva om föråldrat segmenttillstånd och återvinna utrymme.
Behandla radering av känsliga uppgifter som ett heltäckande lagringsproblem som omfattar källfiler, vektorlagringar, metadata, cachar, ögonblicksbilder och säkerhetskopior. Tombstones är en mellanliggande mekanism för konsistens i denna större livscykel.
Denna gräns förhindrar också en missvisande förväntan på lagringen: att radera tusentals textsegment kan vara omedelbart korrekt för sökningen, samtidigt som det inte syns i diagram över ledigt utrymme förrän den schemalagda rensningen är klar.
Rekommenderade produkter
Teknik- och AI-hubb
Mer att läsa
Vad är Plex-tillståndet och vilka delar måste bevaras?
Beständig Plex-tillståndsinformation är den information som bevarar serverupplevelsen efter omstarter och återuppbyggnad; media och tillfälliga omkodningsdata har separata funktioner.
Hur hanterar Plex autentisering för lokala och fjärranslutna sessioner?
Plex-autentisering börjar med serverns och kontots identitet, därefter avgör lokala eller fjärranslutna nätverksvägar åtkomligheten och hur säkra anslutningar fungerar.
Varför kan Plex-sökningar bli långsammare när biblioteksdata ökar?
Att biblioteket växer är inte i sig en diagnos. Testa frågeformen, indexen, cachetillståndet, lagringsfördröjningen och skrivaktiviteten innan du skyller på databasens storlek.
