Hur påverkar ögonblicksbilder av filsystemet komprimeringen av vektordatabaser?

Filsystemsnapshots kan göra att vektorkomprimering behåller både gamla och omskrivna block, vilket fördröjer återvinningen av utrymme och ökar copy-on-write-belastningen under sammanslagningar.

En vektordatabas kan komprimera segment för att ta bort tombstones, slå samman små filer och förbättra lokaliteten vid frågor, samt radera föråldrade filer efter ett säkert byte. En filsystemsnapshot som togs före sammanslagningen refererar fortfarande till deras gamla block, så lagringspoolen behåller dem samtidigt som den allokerar det komprimerade resultatet. Snapshoten bevarar återställningsmöjligheten, men beteendet för ledigt utrymme och fördröjning skiljer sig från ett filsystem utan snapshot.

Komprimering skriver om logiska poster till nya filer

Många vektorlagringar använder oföränderliga segment eller loggstrukturerade komponenter. Uppdateringar och borttagningar lägger till nytt tillstånd, varefter bakgrundskomprimeringen läser aktiva poster, skriver konsoliderade filer, uppdaterar manifest och tar bort ersatta segment efter en säker commit. Denna effekt bör förbli mätbar under den avsedda hemserverbelastningen.

Den grundläggande LSM-komprimeringen beskriver loggstrukturerade merge-träd som en hierarki som samlar skrivningar i batcher och slår samman komponenter över tid. Detta omskrivningsmönster förklarar varför komprimering tillfälligt behöver både indata och utdata. Skillnaden är viktig när flera pipeline-steg delar på samma lagrings- och minnesbudget.

Vektorspecifika strukturer lägger till graflänkar, postningslistor, nyttolastindex och kvantiseringsfiler, så antalet komprimerade byte behöver inte motsvara antalet borttagna byte. Rensning på databasnivå och återvinning av block på filsystemnivå är separata händelser. Den gränsen måste testas med representativa hushållsdata i stället för att antas.

Snapshots håller block före komprimeringen nåbara

En copy-on-write-snapshot registrerar en blockgraf från en viss tidpunkt. När komprimeringen skriver nya filer refererar det aktiva filsystemet till nya block, medan snapshoten fortsätter att referera till gamla segment; att radera filnamn från livevyn kan inte frigöra block som fortfarande behövs av snapshoten.

OpenZFS blockbevarande i snapshots definierar snapshots som skrivskyddade versioner av ett filsystem eller en volym vid en viss tidpunkt. Deras utrymmesanvändning växer när aktiva data avviker, vilket är precis vad en stor, omskrivningstung komprimering skapar.

Ett snabbt snapshot-kommando kan därför föregå en betydande senare ökning av utrymmesanvändningen. Kostnaden uppstår vid efterföljande skrivningar, inte nödvändigtvis när snapshoten skapas, och kvarstår tills varje refererande snapshot har tagits bort. Denna effekt bör förbli mätbar under den avsedda hemserverbelastningen.

Lite ledigt utrymme kan omvandla kvarhållning till fördröjning

Komprimering behöver tillfälligt utrymme, och copy-on-write-allokering behöver lediga block. När snapshots bevarar gamla segment kan poolen fragmenteras eller närma sig kapacitetstaket, vilket saktar ned skrivningar och förlänger komprimeringen; längre komprimering lämnar i sin tur fler segment och mer frågearbete.

Milvus vektorkomprimering beskriver komprimering som en sammanslagning av små segment och rensning av borttagna data för att förbättra lagrings- och frågebeteendet. Mekanismen visar varför vektordatabaser kan skriva om omfattande filer även när den logiska ändringen består av en uppsättning borttagningar.

Felgränsen är att anta att snapshotstorleken som rapporteras vid skapandet förutsäger den slutliga kostnaden. Komprimeringsvolym, uppdateringsfrekvens, komprimering, borttagna vektorer, poolens lediga utrymme och snapshotens livslängd avgör antalet kvarhållna byte och den svansfördelade fördröjningen. Skillnaden är viktig när flera pipeline-steg delar på samma lagrings- och minnesbudget.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Vanliga frågor om snapshots och vektorkomprimering

Bör snapshots inaktiveras under komprimering?

Inte automatiskt. Snapshots skyddar återställningspunkter, men schemaläggning av stora komprimeringar utanför snapshotfönster kan minska kvarhållen avvikelse. Alla ändringar bör bevara en testad plan för säkerhetskopiering och databasens konsekvens. Den gränsen måste testas med representativa hushållsdata i stället för att antas.

Varför förblir databasstorleken hög efter att borttagna vektorer har komprimerats?

Gamla block kan fortfarande refereras av snapshots, kloner eller säkerhetskopior även efter att live-databasen har tagit bort föråldrade segment. Kontrollera databasfiler och filsystemets refererade utrymme separat. Denna effekt bör förbli mätbar under den avsedda hemserverbelastningen.

Kan en snapshot fånga ett inkonsekvent vektorindex?

Ja, om databasfiler, skrivförhandsloggar, manifest och relaterade metadata inte har pausats eller fångats atomiskt. Använd databasens mekanism för kontrollpunkt eller tömning före filsystemsnapshoten när det krävs. Skillnaden är viktig när flera pipeline-steg delar på samma lagrings- och minnesbudget.

Mät snapshotavvikelse under en kontrollerad sammanslagning

Klona ett representativt index, registrera logisk och fysisk storlek, ta en snapshot och kör sedan en uppmätt cykel med borttagning och komprimering. Följ komprimeringsbyte, tillfälligt topputrymme, snapshotens refererade byte, poolens lediga utrymme, skrivfördröjning, svansfördröjning för frågor och tiden tills utrymmet återvinns efter att snapshoten har tagits bort.

Jämför resultatet med mekanismen för snapshotstopp i mekanismen för snapshotstopp. Upprepa utan snapshot och med olika kvarhållningstider, samtidigt som databasversion, index, data, komprimering, poolinställningar och bakgrundsbelastning hålls konstanta. Den gränsen måste testas med representativa hushållsdata i stället för att antas.

Planera snapshots och komprimering utifrån uppmätt marginalutrymme snarare än bekvämlighet. Behåll en databas­konsistent återställningspunkt, reservera utrymme för både gamla och nya segment och låt snapshots löpa ut endast enligt den fastställda kvarhållningspolicyn, i stället för att ta bort skyddet för att dölja fel i kapacitetsplaneringen.