Perché i metadati di Immich aumentano durante il backup delle foto di famiglia?

I metadati di Immich crescono durante il backup delle foto di famiglia perché ogni originale crea record dell’applicazione e può anche generare miniature, vettori di ricerca, dati sui volti e altro stato derivato.

Questa crescita non corrisponde a una percentuale uniforme della libreria originale. Una famiglia con molte immagini di piccole dimensioni, video lunghi, numerosi volti o un’elaborazione di ricerca estesa può produrre un profilo di overhead diverso da quello di un’altra famiglia con gli stessi terabyte di origine. Prima di decidere se la crescita sia prevista, separa lo stato del database dai file generati.

Ogni risorsa aggiunge record applicativi persistenti

Il database deve contenere record che colleghino una risorsa al proprietario, al percorso, ai timestamp, agli album, alle autorizzazioni e ad altre proprietà visibili nell’applicazione. All’aumentare del numero di risorse e relazioni, cresce anche questo stato persistente, persino quando i file originali sono archiviati altrove.

Una panoramica sul dimensionamento dello storage che separa l’overhead del database dalle miniature e dagli originali è utile perché questi componenti scalano in modo diverso. Le cifre d’esempio vanno considerate osservazioni relative a una distribuzione specifica, non un rapporto garantito per la libreria di un’altra famiglia.

Per alcune domande sui metadati, il numero di risorse è quindi una variabile di partenza migliore dei gigabyte originali. Diecimila video di grandi dimensioni e diecimila foto di piccole dimensioni possono occupare capacità originale molto diversa, ma entrambi richiedono comunque record e relazioni a livello di risorsa nel database dell’applicazione.

I file generati per la consultazione aggiungono una curva di storage separata

La consultazione della sequenza temporale dipende da rappresentazioni più piccole, più rapide da visualizzare rispetto all’apertura di ogni originale. Questi file generati non sono metadati del database in senso stretto, ma spesso vengono percepiti come “overhead di Immich” perché crescono insieme alla libreria e sono gestiti dall’applicazione.

La suddivisione dello storage in quattro servizi descritta in una distribuzione in un home lab distingue tra foto, contenuti multimediali generati e posizione del database. Questa separazione è importante dal punto di vista operativo perché i file derivati soggetti a frequenti modifiche e lo stato critico del database non hanno lo stesso ruolo in termini di backup o prestazioni.

Non stimare questa curva basandoti solo sui byte originali. Il numero di miniature dipende dalle risorse e dalle dimensioni abilitate, mentre l’output video codificato dipende dalla compatibilità dei video e dalle impostazioni di transcodifica. Misura ogni directory generata separatamente dopo che la stessa coorte ha completato l’elaborazione.

Le funzionalità di ricerca e riconoscimento dei volti aggiungono stato agli indici

La ricerca semantica e le funzionalità relative ai volti creano rappresentazioni numeriche e relazioni che rendono individuabili i contenuti visivi senza riscrivere l’immagine originale. Un numero maggiore di risorse elaborate, volti rilevati e funzionalità di analisi abilitate aggiunge quindi nel tempo stato relativo al database e ai modelli.

La spiegazione degli embedding semantici mostra perché un indice di ricerca visiva possa crescere anche quando nomi dei file e cartelle restano invariati. Il modello trasforma ogni immagine idonea in una rappresentazione riutilizzabile, disponibile in seguito per il confronto con le query testuali.

Questo stato non va confuso con una seconda copia a piena risoluzione. Se la crescita del database legata alla ricerca continua rapidamente dopo che il numero di risorse, le impostazioni delle funzionalità e l’inventario dei modelli sono rimasti stabili, è necessario verificare la manutenzione, l’elaborazione duplicata o un altro meccanismo del database, invece di presumere che il normale indicizzamento ne sia la causa.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

L’organizzazione familiare aggiunge relazioni, non solo file

Album, nomi delle persone, relazioni di condivisione, preferiti, modifiche e altre azioni degli utenti possono ampliare i metadati dell’applicazione indipendentemente dai nuovi originali. Due famiglie con contenuti multimediali identici possono quindi avere impronte diverse nel database, perché una utilizza più funzionalità di organizzazione e condivisione.

La panoramica di ZimaSpace sull’organizzazione delle foto mette in evidenza la distinzione tra gli originali centralizzati e i livelli di persone, luoghi, eventi e album ricercabili costruiti sopra di essi. Queste relazioni fanno parte dell’esperienza utente e devono essere considerate nella pianificazione del ripristino.

Questo meccanismo non spiega la grande crescita non giustificata nei log, nei livelli scrivibili dei container, nei file temporanei o nelle risorse originali duplicate. Queste categorie hanno cause diverse e devono essere misurate al di fuori del modello database-derivati, invece di essere incluse in un unico numero di “metadati”.

Misura la crescita in base al ruolo dello storage

Acquisisci una baseline prima di un’importazione rappresentativa: byte e numero dei contenuti multimediali originali, dimensioni del database, storage di miniature o anteprime, storage dei video codificati, cache dei modelli, backup e spazio temporaneo o per i log. Ripeti la misurazione dopo che la stessa coorte ha completato i processi in background abilitati e di nuovo dopo il normale utilizzo familiare.

Una procedura di backup familiare di ZimaSpace ribadisce perché gli originali e lo stato essenziale dell’applicazione debbano essere protetti insieme, mentre gli output rigenerabili possono essere gestiti diversamente. La contabilità dello storage dovrebbe seguire il valore ai fini del ripristino oltre al semplice conteggio dei byte.

Considera accettabile la crescita quando la variazione può essere ricondotta a nuove risorse, derivati, record del database e funzionalità abilitate. Approfondisci l’indagine quando un ruolo cresce senza un’attività corrispondente delle risorse o delle funzionalità, oppure quando il totale misurato diverge in modo significativo dalla somma dei ruoli di storage noti.