Hur återtar komprimering av vektordatabaser utrymme efter att dokument har tagits bort?

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.

Vektordatabaskomprimering återvinner borttaget utrymme genom att skriva om aktiva poster till rena segment och avveckla äldre segmentfiler som fortfarande innehåller borttagna vektorer.

När ett hushållsdokument tas bort från ett lokalt RAG-bibliotek kan det försvinna från sökresultaten direkt, medan diskanvändningen knappt förändras. Det betyder inte nödvändigtvis att borttagningen misslyckades. Många vektordatabaser skiljer på logisk synlighet och fysisk lagringsrensning, så att skrivningar i förgrunden förblir snabba och läsare kan fortsätta använda oföränderliga eller tilläggsorienterade segment. Komprimering är den senare underhållsprocess som omvandlar dessa logiska borttagningar till en mindre fysisk representation.

En borttagning ändrar vanligtvis synligheten innan lagrade byte skrivs om

Att fysiskt redigera en stor indexfil vid varje borttagning skulle skapa kostsamma slumpmässiga skrivningar och komplicerad samtidighetshantering. Många motorer registrerar i stället en borttagningsmarkör, en tombstone eller en borttagningslogg som instruerar sökningen att ignorera vektorn.

HNSW-tombstones gör att borttagna objekt blir obehöriga för grafbaserad sökning innan bakgrundsunderhåll fysiskt tar bort hela deras indextillstånd.

Resultatet för användaren och resultatet på disknivå inträffar därför vid olika tidpunkter. Posten kan sluta visas i närmaste-granne-resultat medan dess gamla byte fortfarande finns kvar i ett befintligt segment.

Denna uppdelning ger också databasen utrymme att samordna samtidiga frågor, repliker, ögonblicksbilder och lagringsregler innan historiska lagringsstrukturer förstörs.

Borttagna poster samlas i segment tills en rensningströskel nås

Ett segment kan innehålla både aktiva vektorer och poster som inte längre får användas i sökningar. När uppdateringar och borttagningar samlas på hög minskar andelen användbara data i förhållande till föråldrade data.

En tröskel för borttagna vektorer kan fördröja den kostsamma rensningen tills tillräckligt många föråldrade punkter har samlats för att en omskrivning av segmentet ska vara motiverad.

Att vänta på en tröskel fördelar underhållsarbetet över flera borttagningar. Att skriva om ett segment för att återvinna utrymmet från en enda liten borttagen post skulle kosta mer I/O än det sparade utrymmet. På en hemmaserver med frekvent omindexering kan den synliga mängden föråldrad fysisk lagring därför öka ett tag innan optimeraren bedömer att rensning är motiverad.

Komprimering kopierar aktiva data till nya eller sammanslagna segment

När underhållet börjar läser databasen berättigade källsegment, hoppar över logiskt borttagna poster och skriver kvarvarande vektorer och nyttolaster till en ny, kompakt representation.

komprimering genom segmentsammanslagning och rensning av borttagningar skriver om kvarvarande data till renare segment och utelämnar poster som redan är logiskt borttagna eller har löpt ut.

Små segment kan slås samman samtidigt, vilket minskar antalet separata strukturer som sökningen måste konsultera. Det nya segmentet representerar det aktiva tillståndet i stället för att föra vidare varje historisk ändring.

Denna omskrivning kan tillfälligt kräva extra ledigt utrymme eftersom gamla och nya segment kan finnas samtidigt tills ersättningen har verifierats och aktiverats.

Index byggs om utifrån den kvarvarande vektormängden

Att ta bort byte från vektorernas nyttolaster är bara en del av rensningen. Graflänkar, kvantiserade strukturer, filter och segmentmetadata kan hänvisa till poster som inte längre hör till det aktiva segmentet.

En komprimeringsprocess som bygger om index under optimeringen säkerställer att grafen och de kompletterande sökstrukturerna motsvarar den kvarvarande vektormängden i stället för att behålla hänvisningar till borttagna punkter.

För HNSW kan detta ändra grafens topologi även när de kvarvarande vektorerna själva är oförändrade. Därför kan komprimering påverka navigeringen bland ungefärliga grannar samtidigt som samma logiska datamängd bevaras. Mekanismen i den här artikeln handlar om lagringens livscykel: föråldrade poster utesluts från det omskrivna indexet så att deras fysiska fotavtryck så småningom kan försvinna.

Gamla segment måste avvecklas innan deras lagringsutrymme kan frigöras

När det komprimerade segmentet blir den aktiva representationen markeras gamla segment som föråldrade eller tas bort. De underliggande filerna kan fortfarande behöva vänta på en period för skräpsamling eller lagring innan de faktiska diskblocken frigörs.

När skräpsamling följer efter komprimeringen kan borttagna segmentfiler finnas kvar tillfälligt efter att den komprimerade ersättningen har aktiverats, så att filsystemets utrymme frigörs senare än synligheten i sökresultaten förändras.

Ögonblicksbilder, kvarhållning av säkerhetskopior, replikering eller läsare som håller referenser kan förlänga denna fördröjning i system som bevarar äldre segmentgenerationer.

Diskövervakning bör därför skilja mellan logiskt antal entiteter, storleken på aktiva segment, tillfälligt utrymme för komprimering, borttagna segment och ledig kapacitet i filsystemet.

Komprimering är bakgrundsunderhåll med egna resurskostnader

Att läsa gamla segment, skriva nya, bygga om index och ta bort föråldrade filer förbrukar CPU, diskbandbredd, minne och ibland tillfälligt dubblerat lagringsutrymme.

mätvärden för tombstone-rensning gör det möjligt att se borttagningsreparation som en underhållsbelastning med egna cykler, tidsåtgång och resursförbrukning.

Att undvika föråldrade indexposter efter filuppdateringar är ett krav uppströms: en borttagning från källan måste först nå vektordatabasen innan komprimeringen kan återvinna den föråldrade representationen.

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.