Moet je Immich-metadata op een SSD en bulkgegevens op een HDD zetten?

Ja, een Immich-implementatie heeft er vaak baat bij om de database en latentiegevoelige gegenereerde gegevens op een SSD te bewaren en grote originele foto- en videobestanden op een HDD op te slaan, vooral wanneer de bibliotheek veel groter is dan de app-status. Deze scheiding is alleen nuttig als de paden, marges voor vrije ruimte, back-ups en herstelstappen duidelijk blijven.

De beslissing is niet simpelweg “metadata snel, media langzaam”. Immich gebruikt verschillende opslagrollen op verschillende manieren: PostgreSQL verwerkt veel kleine statusbewerkingen; miniaturen en voorbeelden worden tijdens het bladeren vaak gelezen; gecodeerde video kan groot zijn; originelen zijn vooral gebaat bij capaciteit en duurzaamheid. Meet deze rollen afzonderlijk voordat je iets verplaatst.

Scheid actieve kleine I/O-status van mediabestanden die vooral capaciteit vereisen

Breng de PostgreSQL-gegevens, miniaturen, voorbeelden, gecodeerde video, modelcache, geüploade originelen, externe bibliotheken en back-upkopieën in kaart. Noteer de huidige omvang, groei, lees- en schrijffrequentie, herbouwkosten en of elke rol na een herstel behouden moet blijven. Zo voorkom je dat een algemene mapnaam als “metadata” meerdere zeer verschillende werklasten verbergt.

Het ZimaSpace-opslagframework voor het plaatsen van mediametadata en actieve cache maakt het nuttige onderscheid: databases en indexen profiteren van opslag met een lage latentie, terwijl bulkmedia van de bron op opslag met hoge capaciteit kan blijven staan wanneer het toegangspatroon niet dezelfde IOPS vereist. Als je huidige HDD tijdens zoekopdrachten, het bladeren door tijdlijnen en achtergrondtaken een lage latentie laat zien, levert het verplaatsen van elke afgeleide mogelijk weinig merkbare winst op. Behoud de huidige indeling totdat een gecontroleerde vergelijking aantoont dat het actieve opslagpad daadwerkelijk moet wachten.

Plaats PostgreSQL en vaak gelezen afgeleide gegevens op een SSD wanneer daar de vertraging zit

PostgreSQL en bladeren met veel miniaturen zorgen voor veel kleine lees- en schrijfbewerkingen die traag kunnen aanvoelen op een drukke mechanische schijf, vooral wanneer imports of back-ups hetzelfde apparaat gebruiken.

Houd bij huidige Immich-indelingen de database op lokale opslag met lage latentie en verplaats ondersteunde paden voor gegenereerde gegevens doelgericht, in plaats van willekeurige geneste koppelingen te maken.

Het opslagmechanisme is buiten Immich goed bekend: opslagafstemming voor PostgreSQL profiteert van veel goedkopere willekeurige toegang dan draaiende schijven bieden. Dat garandeert geen merkbare verbetering in Immich, maar verklaart waarom database- en indexbewerkingen sterke kandidaten voor een SSD zijn wanneer de latentie van het apparaat de gemeten wachttijd veroorzaakt.

Meet de verbetering met hetzelfde album, dezelfde zoekopdracht en hetzelfde importsample voor en na de wijziging. Als de databaselatentie daalt maar het voor de gebruiker zichtbare verzoek nog steeds wacht op netwerkoverdracht, het decoderen van afbeeldingen of machine learning, schrijf de resterende vertraging dan niet langer toe aan de HDD.

Bewaar originelen op een HDD wanneer capaciteit en bescherming belangrijker zijn dan willekeurige I/O

Originele foto’s en video’s vormen meestal de grootste opslagcategorie en worden vaak als volledige bestanden gelezen in plaats van als kleine willekeurige databasepagina’s. Grote HDD-pools kunnen daarom een verstandige plaats zijn voor originelen wanneer ze de vereiste betrouwbaarheid, doorvoersnelheid en back-upcapaciteit bieden. Ook de HDD-laag heeft vrije ruimte en een gezonde latentie nodig tijdens gelijktijdige import- en bladerwerkzaamheden.

Een langdurige Immich-discussie over het scheiden van miniaturen en media weerspiegelt dezelfde operationele wens: gegenereerde browse-assets en bulkoriginelen hebben verschillende toegangsprioriteiten. Dit bewijst niet dat elke installatie twee fysieke apparaten nodig heeft; de winst hangt af van de plek waar verzoeken momenteel wachten.

Zet onvervangbare originelen niet op een HDD alleen omdat die goedkoper is en beschouw RAID vervolgens als de back-up. Bewaar een tweede kopie en een kopie buiten de host of offline, afgestemd op het gewenste beschermingsniveau voor het huishouden. Opslaglagen veranderen prestaties en kosten; ze verminderen niet de gevolgen van het verlies van de enige kopie van de familiebibliotheek.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Migreer één opslagrol tegelijk en test de koppelingen na een herstart

Maak voordat je een pad verplaatst een consistente back-up van de database en leg de huidige koppelingen tussen host en container vast. Verplaats één rol, start de stack, controleer oude en nieuwe assets, voer een zoekopdracht uit, speel een video af, upload een wegwerpbestand en bevestig dat de nieuwe schrijfbewerkingen op het bedoelde apparaat terechtkomen. Verplaats de database, miniaturen, originelen en back-upbestemmingen niet in één wijziging.

Herstart de host in plaats van alleen de containers opnieuw aan te maken. Een geslaagde gesplitste indeling brengt zowel de SSD- als de HDD-koppelingen online voordat Immich schrijft, behoudt gebruikers en relaties, leest steekproefsgewijs originelen en houdt de bewaking van vrije ruimte op beide lagen actief. Een lege vervangingsmap op een verwachte koppellocatie is een reden om te stoppen. Behoud de gesplitste indeling wanneer de gemeten bottleneck verbetert en de herstelkaart begrijpelijk blijft. Zet de wijziging terug als de indeling verouderde paden, ontbrekende assets, verschoven rechten of een back-upproces introduceert dat slechts één laag beschermt. Het beste opslagontwerp is het snelste ontwerp dat je nog steeds correct kunt herstellen.