Varför växer Immich-metadata vid säkerhetskopiering av familjefoton?

Immich-metadata växer under säkerhetskopiering av familjefoton eftersom varje original skapar poster i applikationen och dessutom kan skapa miniatyrbilder, sökvektorer, ansiktsdata och annat härlett tillstånd.

Denna tillväxt motsvarar inte en enhetlig procentandel av det ursprungliga biblioteket. Ett hushåll med många små bilder, långa videor, många ansikten eller omfattande sökbehandling kan få en annan omkostnadsprofil än en annan familj med samma ursprungliga terabytevolym. Separera databasens tillstånd från genererade filer innan du avgör om tillväxten är förväntad.

Varje tillgång lägger till beständiga applikationsposter

Databasen behöver poster som kopplar en tillgång till dess ägare, sökväg, tidsstämplar, album, behörigheter och andra egenskaper som är synliga i applikationen. När antalet tillgångar och relationer ökar, ökar även detta beständiga tillstånd, även när originalfilerna lagras någon annanstans.

En översikt över lagringsdimensionering som skiljer databasens omkostnader från miniatyrbilder och original är användbar eftersom dessa roller skalas på olika sätt. Exempelsiffrorna bör betraktas som observationer från en specifik driftsättning, inte som ett garanterat förhållande för ett annat familjebibliotek.

Antalet tillgångar är därför en bättre utgångspunkt än källans gigabyte för vissa metadatafrågor. Tio tusen stora videor och tio tusen små foton kan kräva mycket olika ursprunglig lagringskapacitet, men båda behöver fortfarande poster och relationer på tillgångsnivå i applikationens databas.

Genererade filer för bläddring skapar en separat lagringskurva

Bläddring i tidslinjen är beroende av mindre representationer som visas snabbare än om varje original skulle öppnas. Dessa genererade filer är inte databasmetadata i strikt mening, men uppfattas ofta som ”Immich-omkostnader” eftersom de växer tillsammans med biblioteket och hanteras av applikationen.

Lagringslayouten med fyra tjänster i en hemlabsdriftsättning skiljer mellan foton, genererade medier och databasplacering. Denna åtskillnad är viktig ur driftssynpunkt eftersom härledda filer med hög förändringstakt och kritiskt databastillstånd inte har samma roll för säkerhetskopiering eller prestanda.

Uppskatta inte denna kurva enbart utifrån originalens byteantal. Antalet miniatyrbilder följer antalet tillgångar och aktiverade storlekar, medan kodad videoutdata följer videokompatibilitet och omkodningsinställningar. Mät varje genererad katalog separat efter att samma grupp har slutfört behandlingen.

Sök- och ansiktsfunktioner lägger till indexdata

Semantisk sökning och ansiktsfunktioner skapar numeriska representationer och relationer som gör visuellt innehåll sökbart utan att originalbilden skrivs om. Fler behandlade tillgångar, upptäckta ansikten och aktiverade analysfunktioner lägger därför med tiden till databas- och modellrelaterat tillstånd.

Förklaringen av semantiska inbäddningar visar varför ett visuellt sökindex kan växa även när filnamn och mappar förblir oförändrade. Modellen omvandlar varje behörig bild till en återanvändbar representation som sedan kan jämföras med textfrågor.

Detta tillstånd ska inte förväxlas med en andra kopia i full upplösning. Om sökrelaterad databasstorlek fortsätter att öka snabbt efter att antalet tillgångar, funktionsinställningar och modellinventering är stabila, bör du undersöka underhåll, duplicerad behandling eller någon annan databasmekanism i stället för att anta att normal indexering förklarar ökningen.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Familjens organisering lägger till relationer, inte bara filer

Album, personnamn, delningsrelationer, favoriter, redigeringar och andra användaråtgärder kan utöka applikationsmetadata oberoende av nya original. Två familjer med identiska medier kan därför ha olika databasstorlek eftersom den ena använder fler funktioner för organisering och delning.

ZimaSpaces översikt över familjefoton och lager för fotoorganisering belyser skillnaden mellan centraliserade original och de sökbara personer, platser, händelser och album som läggs ovanpå dem. Dessa relationer är en del av användarupplevelsen och måste beaktas i återställningsplaneringen.

Mekanismen förklarar inte längre stor oförklarad tillväxt i loggar, skrivbara containerlager, temporära filer eller duplicerade källtillgångar. Dessa kategorier har andra orsaker och bör mätas utanför modellen för databas och härledda filer, i stället för att räknas in i ett enda ”metadata”-tal.

Mät tillväxt utifrån lagringsroll

Ta en baslinje före en representativ import: byteantal och antal ursprungliga medier, databasstorlek, lagring för miniatyrbilder eller förhandsvisningar, lagring för kodad video, modellcache, säkerhetskopior samt temporärt utrymme och loggutrymme. Upprepa mätningen efter att samma grupp har slutfört sina aktiverade bakgrundsjobb och igen efter normal användning i hushållet.

Ett arbetsflöde för säkerhetskopiering av familjefoton från ZimaSpace understryker varför original och viktigt applikationstillstånd måste skyddas tillsammans, medan återskapningsbara utdata kan hanteras på annat sätt. Lagringsredovisningen bör ta hänsyn till återställningsvärdet såväl som byteantalet.

Acceptera tillväxt när förändringen kan kopplas till nya tillgångar, härledda filer, databasposter och aktiverade funktioner. Undersök vidare när en roll växer utan motsvarande aktivitet bland tillgångar eller funktioner, eller när den uppmätta totalen avviker väsentligt från summan av de kända lagringsrollerna.