Bör du lagra Immich-metadata på en SSD och stora datamängder på en HDD?

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

Should You Put Immich Metadata on SSD and Bulk Data on HDD? - Zima Store Online

Ja, en Immich-distribution gynnas ofta av att databasen och latenskänsliga genererade data ligger på SSD, medan stora originalfoton och videofiler lagras på HDD, särskilt när biblioteket är mycket större än appens tillstånd. Uppdelningen är bara användbar när sökvägar, marginaler för ledigt utrymme, säkerhetskopior och återställningssteg förblir tydliga.

Beslutet handlar inte om ”snabba metadata, långsamma medier”. Immich använder flera lagringsroller på olika sätt: PostgreSQL hanterar många små tillståndsoperationer; miniatyrer och förhandsvisningar läses ofta vid bläddring; kodad video kan vara stor; original prioriterar kapacitet och hållbarhet. Mät dessa roller separat innan du flyttar något.

Separera aktivt tillstånd med små I/O-operationer från kapacitetsorienterade medier

Inventera PostgreSQL-data, miniatyrer, förhandsvisningar, kodad video, modellcache, uppladdade original, externa bibliotek och säkerhetskopior. Notera aktuell storlek, tillväxt, läs- och skrivfrekvens, återskapandekostnad och om varje roll måste överleva en återställning. Det förhindrar att en generell mappetikett som ”metadata” döljer flera mycket olika arbetsbelastningar.

ZimaSpace-lagringsramverket för att placera mediemetadata och aktiv cache gör den användbara skillnaden tydlig: databaser och index gynnas av lagring med låg latens, medan källmedier i bulk kan ligga kvar på kapacitetslagring när åtkomstmönstret inte kräver samma IOPS. Om din nuvarande HDD uppvisar låg latens vid sökningar, tidslinjebläddring och bakgrundsjobb kan det ge liten synlig nytta att flytta alla derivat till SSD. Behåll den nuvarande layouten tills en kontrollerad jämförelse visar att den aktiva lagringssökvägen faktiskt väntar.

Placera PostgreSQL och ofta lästa derivat på SSD när det är där väntetiden uppstår

PostgreSQL och miniatyrintensiv bläddring skapar många små läsningar och skrivningar som kan upplevas som långsamma på en belastad mekanisk disk, särskilt när importer eller säkerhetskopieringar använder samma enhet.

För aktuella Immich-layouter bör databasen ligga på lokal lagring med låg latens, och sökvägar för genererade data bör flyttas medvetet i stället för att godtyckliga kapslade monteringar skapas.

Lagringsmekanismen är välkänd även utanför Immich: PostgreSQL-lagringsjustering gynnas av betydligt billigare slumpmässig åtkomst än snurrande diskar. Det garanterar inte en synlig förbättring i Immich, men förklarar varför databas- och indexarbete är starka SSD-kandidater när enhetens latens är den uppmätta väntetiden.

Mät förbättringen med samma album-, sök- och importprov före och efter. Om databaslatensen minskar men den synliga begäran fortfarande väntar på nätverksöverföring, bildavkodning eller maskininlärning ska du sluta tillskriva den återstående fördröjningen till HDD:n.

Behåll original på HDD när kapacitet och skydd är viktigare än slumpmässig I/O

Originalfoton och videor är vanligtvis den största lagringsklassen och läses ofta som hela filer snarare än som små slumpmässiga databassidor. Stora HDD-pooler kan därför vara ett lämpligt hem för original när de erbjuder den tillförlitlighet, genomströmning och säkerhetskopieringskapacitet som krävs. HDD-nivån behöver fortfarande ledigt utrymme och god latens under samtidiga import- och bläddringsarbetsbelastningar.

En långvarig Immich-diskussion om att separera miniatyrer från medier återspeglar samma operativa behov: genererade bläddringstillgångar och original i bulk har olika åtkomstprioriteringar. Den bevisar inte att alla installationer behöver två fysiska enheter; nyttan beror på var begäranden för närvarande väntar.

Placera inte oersättliga original på HDD enbart för att det är billigare och betrakta sedan RAID som säkerhetskopian. Behåll en andra kopia samt en kopia utanför värddatorn eller offline enligt hushållets skyddsmål. Lagringsskiktning förändrar prestanda och kostnad; den minskar inte konsekvensen av att förlora den enda kopian av familjens bibliotek.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

Flytta en lagringsroll i taget och testa monteringar efter omstart

Innan du flyttar en sökväg ska du skapa en databaskonsistent säkerhetskopia och dokumentera den aktuella monteringskartan mellan värd och container. Flytta en roll, starta stacken, verifiera gamla och nya tillgångar, kör en sökning, spela upp en video, ladda upp en fil som kan tas bort och bekräfta att de nya skrivningarna hamnar på avsedd enhet. Flytta inte databas, miniatyrer, original och säkerhetskopieringsmål i samma ändring.

Starta om värddatorn i stället för att bara återskapa containrar. En fungerande uppdelad layout tar både SSD- och HDD-monteringarna online innan Immich skriver, bevarar användare och relationer, läser in utvalda original och upprätthåller övervakning av ledigt utrymme på båda nivåerna. En tom ersättningskatalog på en förväntad monteringspunkt är ett stoppvillkor. Behåll uppdelningen när den uppmätta flaskhalsen förbättras och återställningskartan förblir begriplig. Återställ om layouten leder till inaktuella sökvägar, saknade tillgångar, ändrade behörigheter eller en säkerhetskopieringsprocess som bara skyddar den ena nivån. Den bästa lagringsdesignen är den snabbaste som du fortfarande kan återställa korrekt.