Quanta memoria aggiuntiva richiede Immich oltre ai dati originali?

Immich non applica una percentuale di spazio di archiviazione universale; l’overhead dipende principalmente dal numero di risorse, dalla combinazione di foto e video, dalle impostazioni dei derivati, dalla crescita del database e dai backup conservati.

Una libreria familiare da un terabyte composta soprattutto da foto sarà molto diversa da una dominata da lunghi video del telefono. Pianifica lo spazio misurando ogni classe generata dopo un’importazione rappresentativa, quindi riserva spazio separato per la crescita, i file temporanei e le copie di ripristino.

I contenuti multimediali derivati costituiscono solitamente la maggior parte dell’overhead visibile

Immich prepara immagini più piccole per le timeline e i visualizzatori e può creare versioni codificate dei video per la riproduzione compatibile. Questi output dipendono dal numero di risorse, dalle scelte di risoluzione, dalle impostazioni di qualità e dalla durata o dalla combinazione di codec dei video. Sono aggiuntivi rispetto ai file originali, anche quando gli utenti non li scaricano mai direttamente.

Una misurazione della community relativa a una libreria esterna da 772 GiB ha riportato circa 18 GiB di miniature e 65 GiB di video codificati. Questa osservazione, pari a circa 83 GiB, è utile come esempio pratico, non come rapporto di pianificazione, perché la combinazione di foto e video e le impostazioni di un’altra libreria possono modificare sostanzialmente entrambe le componenti.

Registra le directory delle miniature e dei video codificati dopo aver importato un campione rappresentativo contenente le foto reali della famiglia, i file RAW, i brevi filmati e i video lunghi. Calcola separatamente il rapporto tra ogni classe derivata e il numero di risorse e quello rispetto ai byte di origine. I rapporti basati sulle risorse e quelli basati sui byte rispondono a domande diverse sulla crescita.

Il database e lo stato della ricerca crescono in base alle relazioni

L’overhead del database deriva dai record delle risorse, dagli utenti, dagli album, dai metadati, dai volti, dalle rappresentazioni per la ricerca, dagli indici e dallo stato dei processi. Un’immagine minuscola e un video di grandi dimensioni possono creare un numero simile di alcuni record, nonostante le dimensioni di origine siano molto diverse. Per questo la crescita del database è più strettamente legata alle entità e alle funzioni abilitate che ai terabyte originali.

L’articolo sui backup di Immich di ZimaSpace distingue gli originali essenziali e lo stato del database dai percorsi derivati che possono essere ricostruiti. Questa distinzione è importante nelle previsioni perché l’eliminazione dei derivati può recuperare spazio temporaneamente, mentre la perdita del database modifica le relazioni che le miniature non possono ricostruire.

Registra le dimensioni del database prima e dopo l’importazione di un gruppo noto, quindi annota quali funzioni di elaborazione sono state completate. Ripeti la misurazione dopo il completamento dell’elaborazione dei volti e della ricerca. Non estrapolare da una coda non completata, perché l’overhead apparente per risorsa aumenterà quando verranno scritte ulteriori rappresentazioni e relazioni.

I backup e i file temporanei modificano il limite minimo di capacità

Un totale calcolato durante il normale funzionamento esclude lo spazio necessario mentre vengono creati i backup, scaricati i database, preparate le importazioni o sostituiti i derivati. Durante un aggiornamento o una rigenerazione, i vecchi e i nuovi artefatti possono coesistere. Un disco dimensionato esattamente sul consumo stabile può quindi non riuscire a gestire la normale manutenzione, anche quando la crescita annuale dei contenuti multimediali è modesta.

Un articolo sulla pianificazione dello spazio descrive come Immich abbia riempito un SSD precedentemente libero con originali, miniature, metadati e attività di apprendimento automatico. La lezione più ampia è che la crescita dell’applicazione e le copie di ripristino competono con il margine operativo; pertanto, lo spazio libero deve coprire la condizione di manutenzione più impegnativa, non lo stato di inattività odierno.

Mantieni la conservazione dei backup come voce separata, perché le copie esterne proteggono da un tipo diverso di guasto. Riserva inoltre un margine operativo misurato in base all’importazione, alla ricodifica o al test di aggiornamento più impegnativo. Avere più spazio inutilizzato non è automaticamente meglio, ma un margine massimo misurato pari a zero rende prevedibile il rischio di esaurimento della capacità.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Crea un prospetto dell’overhead specifico della libreria

Crea righe per originali, miniature e anteprime, video codificati, database, artefatti di apprendimento automatico, dump dei backup locali e spazio temporaneo di picco. Misura una baseline vuota, quindi importa un gruppo rappresentativo. Attendi il completamento delle code e registra nuovamente ogni riga prima di calcolare le differenze.

Una discussione tra utenti su collocazione su SSD e HDD distingue i dati generati sensibili alla latenza dagli originali in massa. Per la pianificazione della capacità, questa distinzione mantiene visibile l’overhead del livello veloce anche quando gli originali risiedono altrove; altrimenti il grande totale del NAS può nascondere un SSD dell’applicazione quasi pieno.

Ripeti il test del gruppo una seconda volta per ottenere un intervallo invece di un solo rapporto. Prevedi ogni riga in base al driver appropriato: numero di risorse, byte o durata dei video, crescita degli utenti e delle relazioni, numero di copie conservate oppure attività di manutenzione di picco. Aggiungi la crescita prevista delle fonti solo dopo aver reso visibili separatamente le esigenze derivate e di ripristino.