Waarom groeit de Immich-metadata tijdens het back-uppen van familiefoto’s?

Immich-metadata groeit tijdens het maken van back-ups van familiefoto’s, omdat elk origineel toepassingsrecords aanmaakt en mogelijk ook miniaturen, zoekvectoren, gezichtsgegevens en andere afgeleide gegevens genereert.

Die groei vormt geen vast percentage van de oorspronkelijke bibliotheek. Een huishouden met veel kleine afbeeldingen, lange video’s, talrijke gezichten of uitgebreide zoekverwerking kan een ander overheadprofiel hebben dan een ander gezin met dezelfde hoeveelheid brondata in terabytes. Scheid de databasestatus van gegenereerde bestanden voordat je bepaalt of de groei te verwachten is.

Elk item voegt blijvende toepassingsrecords toe

De database heeft records nodig die een item koppelen aan de eigenaar, het pad, tijdstempels, albums, machtigingen en andere eigenschappen die in de toepassing zichtbaar zijn. Naarmate het aantal items en relaties groeit, groeit ook deze blijvende status, zelfs wanneer de originele bestanden elders worden opgeslagen.

Een overzicht voor het dimensioneren van opslag waarin database-overhead wordt gescheiden van miniaturen en originelen is nuttig, omdat deze onderdelen verschillend schalen. De voorbeeldcijfers moeten worden gezien als waarnemingen uit implementaties en niet als een gegarandeerde verhouding voor een andere familiebibliotheek.

Het aantal items is daarom voor sommige metadata-vragen een beter uitgangspunt dan het aantal gigabytes aan brondata. Tienduizend grote video’s en tienduizend kleine foto’s kunnen een zeer verschillende oorspronkelijke opslagcapaciteit gebruiken, maar voor beide zijn records en relaties per item in de toepassingsdatabase nodig.

Gegenereerde bladerbestanden voegen een aparte opslagcurve toe

Voor het bladeren door de tijdlijn zijn kleinere representaties nodig die sneller kunnen worden weergegeven dan wanneer elk origineel wordt geopend. Deze gegenereerde bestanden zijn strikt genomen geen databasemetadata, maar worden vaak ervaren als “Immich-overhead”, omdat ze samen met de bibliotheek groeien en door de toepassing worden beheerd.

De opslagindeling met vier services in een thuislab-implementatie maakt onderscheid tussen foto’s, gegenereerde media en de plaatsing van de database. Dat onderscheid is operationeel belangrijk, omdat afgeleide bestanden met veel wijzigingen en kritieke databasestatus niet dezelfde back-up- of prestatierol hebben.

Schat deze curve niet alleen op basis van de oorspronkelijke bytes. Het aantal miniaturen volgt het aantal items en de ingeschakelde formaten, terwijl de uitvoer van gecodeerde video’s afhankelijk is van videocompatibiliteit en transcodeerinstellingen. Meet elke gegenereerde map afzonderlijk nadat dezelfde groep items volledig is verwerkt.

Zoek- en gezichtsfuncties voegen indexstatus toe

Semantisch zoeken en gezichtsfuncties maken numerieke representaties en relaties aan waarmee visuele inhoud vindbaar wordt zonder de oorspronkelijke afbeelding opnieuw te schrijven. Meer verwerkte items, gedetecteerde gezichten en ingeschakelde analysefuncties voegen daarom na verloop van tijd database- en modelgerelateerde status toe.

De uitleg van semantische embeddings laat zien waarom een visuele zoekindex kan groeien, zelfs wanneer bestandsnamen en mappen ongewijzigd blijven. Het model zet elke geschikte afbeelding om in een herbruikbare representatie, die vervolgens beschikbaar is voor latere vergelijking met tekstquery’s.

Deze status mag niet worden verward met een tweede kopie op volledige resolutie. Als de databasegroei door zoekfuncties snel doorgaat nadat het aantal items, de functie-instellingen en de modelinventaris stabiel zijn gebleven, onderzoek dan onderhoud, dubbele verwerking of een ander databasemechanisme in plaats van aan te nemen dat normale indexering dit verklaart.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Gezinsorganisatie voegt relaties toe, niet alleen bestanden

Albums, namen van personen, deelrelaties, favorieten, bewerkingen en andere gebruikersacties kunnen toepassingsmetadata uitbreiden zonder dat er nieuwe originelen bijkomen. Twee gezinnen met exact dezelfde media kunnen daardoor een verschillende databaseomvang hebben, omdat het ene gezin meer organisatie- en deel functies gebruikt.

Het familie-foto-overzicht van ZimaSpace over lagen voor fotoorganisatie benadrukt het onderscheid tussen gecentraliseerde originelen en de doorzoekbare personen, plaatsen, gebeurtenissen en albums die daarbovenop worden aangebracht. Deze relaties maken deel uit van de gebruikerservaring en moeten worden meegenomen in de herstelplanning.

Het mechanisme verklaart geen grote onverklaarde groei in logboeken, beschrijfbare containerlagen, tijdelijke bestanden of dubbele bronitems. Deze categorieën hebben andere oorzaken en moeten buiten het model van database en afgeleide bestanden worden gemeten, in plaats van ze op te nemen in één getal voor “metadata”.

Meet groei per opslagfunctie

Leg vóór een representatieve import een nulmeting vast: bytes en aantallen van de oorspronkelijke media, databaseomvang, opslag voor miniaturen of voorbeelden, opslag voor gecodeerde video’s, modelcache, back-ups en tijdelijke ruimte of logruimte. Herhaal dit nadat dezelfde groep items alle ingeschakelde achtergrondtaken heeft voltooid en nogmaals na normaal huishoudelijk gebruik.

Een workflow voor gezinsback-ups van ZimaSpace benadrukt opnieuw waarom originelen en essentiële toepassingsstatus samen moeten worden beschermd, terwijl opnieuw te genereren uitvoer anders kan worden behandeld. De opslagboekhouding moet zowel de herstelwaarde als het aantal bytes volgen.

Accepteer groei wanneer de verandering kan worden herleid tot nieuwe items, afgeleide bestanden, databaserecords en ingeschakelde functies. Doe verder onderzoek wanneer één opslagfunctie groeit zonder overeenkomstige activiteit van items of functies, of wanneer het gemeten totaal aanzienlijk afwijkt van de som van de bekende opslagfuncties.