Deve colocar os metadados do Immich num SSD e os dados em massa num HDD?

Sim, uma implementação do Immich beneficia frequentemente de manter a base de dados e os dados gerados sensíveis à latência em SSD, enquanto armazena ficheiros grandes de fotografias e vídeos originais em HDD, especialmente quando a biblioteca é muito maior do que o estado da aplicação. A separação só é útil quando os caminhos, as margens de espaço livre, as cópias de segurança e os passos de recuperação permanecem claros.

A decisão não é “metadados rápidos, multimédia lenta”. O Immich utiliza vários tipos de armazenamento de forma diferente: o PostgreSQL processa muitas operações pequenas sobre o estado; as miniaturas e pré-visualizações são lidas frequentemente durante a navegação; os vídeos codificados podem ser grandes; os originais privilegiam a capacidade e a durabilidade. Meça cada função separadamente antes de mover qualquer elemento.

Separe o Estado Pequeno e de E/S Frequente da Multimédia Orientada para a Capacidade

Faça um inventário dos dados do PostgreSQL, miniaturas, pré-visualizações, vídeos codificados, cache dos modelos, originais carregados, bibliotecas externas e cópias de segurança. Registe o tamanho atual, o crescimento, a frequência de leitura/escrita, o custo de reconstrução e se cada função tem de sobreviver a uma restauração. Isto evita que um rótulo genérico como pasta de “metadados” esconda várias cargas de trabalho muito diferentes.

A estrutura de armazenamento ZimaSpace para colocar os metadados multimédia e a cache ativa estabelece a distinção útil: as bases de dados e os índices beneficiam de armazenamento de baixa latência, enquanto a multimédia de origem em grande volume pode permanecer num armazenamento de capacidade quando o seu padrão de acesso não exige os mesmos IOPS. Se o HDD atual apresentar baixa latência durante pesquisas, a navegação pela linha temporal e as tarefas em segundo plano, mover todos os derivados para SSD poderá proporcionar poucos ganhos visíveis para o utilizador. Mantenha a disposição atual até uma comparação controlada demonstrar que o caminho de armazenamento ativo está efetivamente à espera.

Coloque o PostgreSQL e os Derivados Lidos Frequentemente em SSD Quando Forem a Causa da Espera

O PostgreSQL e a navegação com muitas miniaturas criam muitas leituras e escritas pequenas que podem parecer lentas num disco mecânico ocupado, sobretudo enquanto as importações ou cópias de segurança utilizam o mesmo dispositivo.

Nas disposições atuais do Immich, mantenha a base de dados em armazenamento local de baixa latência e mova deliberadamente os caminhos de dados gerados suportados, em vez de inventar montagens aninhadas arbitrárias.

O mecanismo de armazenamento é bem compreendido fora do Immich: o ajuste do armazenamento do PostgreSQL beneficia de um acesso aleatório muito mais barato do que o dos discos magnéticos. Isto não garante um ganho visível no Immich, mas explica por que motivo o trabalho da base de dados e dos índices é um forte candidato ao SSD quando a latência do dispositivo é a espera medida.

Meça a melhoria com o mesmo álbum, pesquisa e amostra de importação antes e depois. Se a latência da base de dados diminuir, mas o pedido visível para o utilizador continuar à espera da transferência de rede, da descodificação de imagens ou da aprendizagem automática, deixe de atribuir o atraso restante ao HDD.

Mantenha os Originais no HDD Quando a Capacidade e a Proteção Forem Mais Importantes do que a E/S Aleatória

As fotografias e os vídeos originais são normalmente a maior classe de armazenamento e são frequentemente lidos como ficheiros completos, em vez de pequenas páginas aleatórias da base de dados. Grandes conjuntos de HDD podem, por isso, ser uma opção adequada para os originais quando oferecem a fiabilidade, o débito e a capacidade de cópia de segurança necessários. O nível HDD continua a precisar de espaço livre e de uma latência saudável durante cargas de trabalho simultâneas de importação e navegação.

Uma discussão prolongada sobre o armazenamento do Immich relativa à separação das miniaturas da multimédia reflete o mesmo objetivo operacional: os recursos gerados para navegação e os originais em grande volume têm prioridades de acesso diferentes. Isto não prova que todas as instalações precisem de dois dispositivos físicos; o ganho depende do ponto onde os pedidos estão atualmente à espera.

Não coloque originais insubstituíveis num HDD apenas por ser mais barato e depois trate o RAID como cópia de segurança. Mantenha uma segunda cópia e uma cópia fora do anfitrião ou offline, de acordo com o objetivo de proteção da casa. A hierarquização do armazenamento altera o desempenho e o custo; não reduz as consequências de perder a única cópia da biblioteca familiar.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Migre Uma Função de Armazenamento de Cada Vez e Teste as Montagens Após Reiniciar

Antes de mover um caminho, crie uma cópia de segurança consistente da base de dados e registe o mapa atual das montagens entre o anfitrião e os contentores. Mova uma função, inicie a pilha, verifique os recursos antigos e novos, faça uma pesquisa, reproduza um vídeo, carregue um ficheiro descartável e confirme que as novas escritas são feitas no dispositivo pretendido. Não mova a base de dados, as miniaturas, os originais e os destinos das cópias de segurança numa única alteração.

Reinicie o anfitrião, em vez de apenas recriar os contentores. Uma disposição dividida funcional disponibiliza as montagens SSD e HDD antes de o Immich escrever, preserva os utilizadores e as relações, lê originais selecionados, e mantém a monitorização do espaço livre em ambos os níveis. Um diretório de substituição vazio num ponto de montagem esperado é uma condição para parar. Mantenha a separação quando o estrangulamento medido melhorar e o mapa de recuperação continuar compreensível. Reverta se a disposição introduzir caminhos obsoletos, recursos em falta, alterações indevidas de permissões ou um processo de cópia de segurança que proteja apenas um dos níveis. O melhor design de armazenamento é o mais rápido que ainda consegue restaurar corretamente.