Por que os metadados do Immich aumentam durante a cópia de segurança das fotografias de família?

Os metadados do Immich crescem durante a cópia de segurança das fotografias de família porque cada original cria registos da aplicação e pode também criar miniaturas, vetores de pesquisa, dados faciais e outros estados derivados.

Esse crescimento não corresponde a uma percentagem uniforme da biblioteca original. Uma família com muitas imagens pequenas, vídeos longos, inúmeros rostos ou processamento de pesquisa extensivo pode gerar um perfil de consumo adicional diferente do de outra família com os mesmos terabytes de origem. Separe o estado da base de dados dos ficheiros gerados antes de decidir se o crescimento é esperado.

Cada recurso acrescenta registos persistentes da aplicação

A base de dados precisa de registos que associem um recurso ao seu proprietário, caminho, marcas temporais, álbuns, permissões e outras propriedades visíveis na aplicação. À medida que aumenta o número de recursos e relações, aumenta também este estado persistente, mesmo quando os ficheiros originais estão armazenados noutro local.

Uma visão geral do dimensionamento do armazenamento que separa a sobrecarga da base de dados das miniaturas e dos originais é útil porque estas funções crescem de forma diferente. Os valores exemplificativos devem ser tratados como observações de implementações, e não como um rácio garantido para outra biblioteca familiar.

Por isso, para algumas questões relacionadas com metadados, o número de recursos é uma variável inicial melhor do que os gigabytes de origem. Dez mil vídeos grandes e dez mil fotografias pequenas podem ocupar capacidades originais muito diferentes, mas ambos continuam a exigir registos e relações ao nível dos recursos na base de dados da aplicação.

Os ficheiros gerados para navegação acrescentam uma curva de armazenamento separada

A navegação pela linha temporal depende de representações menores, mais rápidas de apresentar do que a abertura de cada original. Estes ficheiros gerados não são metadados da base de dados em sentido estrito, mas são frequentemente percecionados como “sobrecarga do Immich” porque crescem juntamente com a biblioteca e são geridos pela aplicação.

A disposição do armazenamento em quatro serviços descrita numa implementação num laboratório doméstico distingue as fotografias, os conteúdos multimédia gerados e a localização da base de dados. Essa separação é operacionalmente importante porque os ficheiros derivados, sujeitos a muitas alterações, e o estado crítico da base de dados não têm o mesmo papel em termos de cópias de segurança ou desempenho.

Não estime esta curva apenas com base nos bytes originais. A quantidade de miniaturas depende dos recursos e dos tamanhos ativados, enquanto a saída de vídeo codificado depende da compatibilidade dos vídeos e das definições de transcodificação. Meça cada diretório gerado separadamente depois de o mesmo conjunto ter concluído o processamento.

As funcionalidades de pesquisa e rostos acrescentam estado de indexação

A pesquisa semântica e as funcionalidades faciais criam representações numéricas e relações que tornam o conteúdo visual pesquisável sem reescrever a imagem original. Assim, mais recursos processados, rostos detetados e funcionalidades de análise ativadas acrescentam gradualmente estado relacionado com a base de dados e os modelos.

A explicação sobre os embeddings semânticos mostra por que motivo um índice de pesquisa visual pode crescer mesmo quando os nomes dos ficheiros e as pastas permanecem inalterados. O modelo transforma cada imagem elegível numa representação reutilizável, que fica então disponível para comparação posterior com consultas de texto.

Este estado não deve ser confundido com uma segunda cópia em resolução total. Se o crescimento da base de dados relacionado com a pesquisa continuar rapidamente depois de o número de recursos, as definições das funcionalidades e o inventário de modelos permanecerem estáveis, investigue a manutenção, o processamento duplicado ou outro mecanismo da base de dados, em vez de presumir que a indexação normal o explica.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

A organização familiar acrescenta relações, não apenas ficheiros

Álbuns, nomes de pessoas, relações de partilha, favoritos, edições e outras ações dos utilizadores podem expandir os metadados da aplicação independentemente da adição de novos originais. Por isso, duas famílias com conteúdos multimédia idênticos podem ter utilizações diferentes da base de dados, porque uma usa mais funcionalidades de organização e partilha.

A visão geral da ZimaSpace sobre as camadas de organização de fotografias destaca a diferença entre os originais centralizados e as pessoas, locais, eventos e álbuns pesquisáveis criados sobre eles. Essas relações fazem parte da experiência do utilizador e devem ser consideradas no planeamento da recuperação.

O mecanismo deixa de explicar um crescimento elevado e inexplicado nos registos, nas camadas graváveis dos contentores, nos ficheiros temporários ou nos recursos originais duplicados. Essas categorias têm causas diferentes e devem ser medidas fora do modelo de base de dados e derivados, em vez de serem incluídas num único número de “metadados”.

Meça o crescimento por função de armazenamento

Faça uma medição de referência antes de uma importação representativa: bytes e quantidade de conteúdos multimédia originais, tamanho da base de dados, armazenamento de miniaturas ou pré-visualizações, armazenamento de vídeos codificados, cache de modelos, cópias de segurança e espaço temporário ou de registos. Repita a medição depois de o mesmo conjunto concluir as tarefas de fundo ativadas e novamente após a utilização normal pela família.

Um fluxo de trabalho de cópia de segurança familiar da ZimaSpace reforça a razão pela qual os originais e o estado essencial da aplicação devem ser protegidos em conjunto, enquanto as saídas regeneráveis podem ser tratadas de forma diferente. A contabilização do armazenamento deve seguir o valor para a recuperação, além da quantidade de bytes.

Aceite o crescimento quando a alteração puder ser relacionada com novos recursos, derivados, registos da base de dados e funcionalidades ativadas. Investigue mais quando uma função crescer sem uma atividade correspondente de recursos ou funcionalidades, ou quando o total medido divergir significativamente da soma das funções de armazenamento conhecidas.