De quanto armazenamento para miniaturas e aprendizagem automática precisa o Immich para fazer cópias de segurança das fotografias da família?

O Immich não tem uma proporção fiável de armazenamento apenas para miniaturas, por isso as bibliotecas familiares devem medir os bytes gerados por recurso e reservar espaço separado para os modelos de ML.

Um arquivo de fotografias familiares de 2 TB não indica o tamanho que o diretório de miniaturas do Immich irá atingir, porque o número de recursos, a resolução de origem, as definições das miniaturas, a proporção de vídeos e os modelos ativados alteram o espaço ocupado. O método de dimensionamento mais seguro consiste em processar uma amostra representativa, medir separadamente as miniaturas e a cache dos modelos, projetar o crescimento da biblioteca e acrescentar margem operacional, em vez de tratar uma percentagem como requisito universal.

Separe os Originais do Armazenamento Gerado pelo Immich

Comece por estabelecer um limite: as fotografias e os vídeos originais são apenas uma parte do espaço em disco que suporta uma biblioteca do Immich. O servidor também mantém recursos gerados utilizados para navegação e compatibilidade, enquanto o serviço de aprendizagem automática mantém os ficheiros de modelos transferidos na sua própria cache. Estas categorias crescem por motivos diferentes, pelo que combiná-las numa percentagem vaga dificulta perceber qual a definição ou carga de trabalho que está realmente a consumir espaço.

Uma referência comunitária de dimensionamento do Immich, mantida há bastante tempo, indica que as miniaturas e o vídeo transcodificado podem acrescentar, em conjunto, cerca de 10–20% em média. Este valor é útil apenas como contexto geral: combina duas categorias geradas e, por isso, não deve ser apresentado como uma proporção exclusiva para miniaturas. Uma família com muitas fotografias e poucos vídeos pode obter um resultado muito diferente de um arquivo com muitos vídeos.

A arquitetura também é importante ao decidir onde colocar esse espaço adicional. A análise da ZimaSpace sobre a organização de fotografias com IA trata a indexação e os dados gerados como serviços em torno da biblioteca original, não como substitutos desta. Para o planeamento de capacidade, mantenha os originais, a área de miniaturas/pré-visualizações, os derivados de vídeo, a base de dados e a cache de ML em linhas separadas, mesmo que partilhem o mesmo disco físico.

Meça o Custo das Miniaturas por Recurso Antes de Aumentar a Escala

Escolha uma amostra representativa da biblioteca familiar, em vez dos mil ficheiros mais fáceis de selecionar. Esta deve incluir as diferentes gerações de telemóveis, resoluções de câmaras, retratos, capturas de ecrã, panoramas e outros tipos de imagem que façam parte da utilização normal. Aguarde que as tarefas relacionadas com miniaturas terminem, registe o número de recursos processados e meça o diretório das miniaturas. Dividir os bytes medidos pelo número de recursos processados fornece uma proporção local para o planeamento, que já reflete as definições de miniaturas e pré-visualizações escolhidas.

As instalações reais demonstram por que razão essa proporção local é importante. Uma discussão do Immich indicou 21 GB de miniaturas, além de 58 GB de vídeo codificado nesse sistema específico. O valor é meramente anedótico e não constitui um objetivo, mas mostra que as pastas derivadas podem ter tamanhos bastante diferentes e devem ser medidas separadamente, em vez de serem inferidas apenas a partir dos terabytes da biblioteca original.

Por exemplo, se 10 000 imagens representativas produzirem 12 GB de miniaturas e pré-visualizações, a taxa observada será de cerca de 1,2 MB por recurso. Uma biblioteca projetada com 60 000 imagens apontaria, portanto, para aproximadamente 72 GB com as mesmas definições, antes de acrescentar uma margem de crescimento. Repita a amostragem depois de alterar a resolução ou a qualidade das miniaturas, porque essas alterações invalidam a antiga proporção por recurso, mesmo que os ficheiros originais não tenham mudado.

A Cache dos Modelos de ML Depende Mais dos Modelos do que do Número de Fotografias

O armazenamento da aprendizagem automática comporta-se de forma diferente do das miniaturas. A cache de modelos contém principalmente ficheiros de modelos que o serviço de ML transfere e reutiliza, pelo que o espaço ocupado depende mais dos modelos de pesquisa inteligente e reconhecimento facial selecionados do que do facto de a biblioteca ter 20 000 ou 200 000 fotografias. O tamanho da biblioteca altera a quantidade de processamento efetuado, mas não exige uma nova cópia do modelo para cada recurso.

Uma implementação recente do Immich alojada pelo próprio descreve uma cache persistente de modelos montada para o serviço de aprendizagem automática e indica que os modelos utilizados ocupavam, no total, menos de 1 GB. Trata-se de uma configuração específica, não de uma garantia. O mecanismo importante é a persistência e a reutilização: depois de os ficheiros selecionados estarem presentes, o crescimento normal do número de fotografias não multiplica os binários dos modelos.

Para um servidor familiar que possa alterar os modelos mais tarde, é sensato planear uma margem maior do que a cache mínima observada atualmente. Um responsável pela manutenção do Immich sugeriu que, em geral, cerca de 10 GB de armazenamento são suficientes, dependendo dos modelos escolhidos. Considere isto uma margem inicial conservadora, não um requisito, e substitua-a pelo tamanho efetivo da cache da sua configuração em funcionamento depois de concluídas as primeiras tarefas de ML.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

A Proporção de Vídeos e a Cache do Cliente Podem Invalidar uma Estimativa Apenas para Fotografias

A estimativa de miniaturas mais ML deixa de ser uma descrição útil do armazenamento total quando a biblioteca contém muitos vídeos ou quando se analisa o armazenamento local do dispositivo. A compatibilidade com vídeos pode criar derivados grandes no servidor, enquanto as caches de telemóveis e navegadores ocupam armazenamento no cliente que não faz parte do diretório de miniaturas nem da cache de modelos de ML do servidor. Misturar esses valores pode fazer uma estimativa normal de miniaturas parecer extremamente errada.

O relato de um utilizador com uma biblioteca grande ilustra esta distinção: uma biblioteca de aproximadamente 2,4 TB, com 179 000 fotografias e 19 000 vídeos, registou 822 GB de derivados no servidor para miniaturas e vídeo transcodificado, enquanto a aplicação Android também acumulou dezenas de gigabytes localmente. É um caso anedótico, não uma regra de dimensionamento, mas mostra como o vídeo e a cache do cliente podem dominar um modelo simples baseado apenas em fotografias.

Mantenha as categorias separadas durante a medição: dados de miniaturas/pré-visualizações do servidor, vídeo codificado, cache de modelos de ML, base de dados e cache local do cliente. Se o armazenamento das miniaturas parecer inesperadamente elevado, inspecione o próprio diretório de miniaturas, e não toda a árvore de dados do Immich. Se o vídeo codificado for a pasta dominante, a questão de planeamento relevante passou da sobrecarga de indexação de fotografias para a compatibilidade de vídeos e a política de transcodificação.

Utilize uma Fórmula Baseada em Amostras e Crescimento para o Armazenamento Familiar

Utilize três dados: os bytes medidos de miniaturas por recurso representativo, o número de imagens projetado para os próximos um a dois anos e o tamanho medido da cache de modelos de ML. Multiplique os dois primeiros, acrescente a cache de modelos e depois adicione uma margem operacional para regenerações, alterações de definições e o crescimento normal do sistema de ficheiros. Uma margem de 20–25% é uma heurística de planeamento, não um requisito do Immich; os utilizadores com discos quase cheios devem medir com maior frequência, em vez de presumirem que a margem será sempre suficiente.

Um limite conservador para a cache de modelos pode começar pela orientação do responsável pela manutenção de que cerca de 10 GB deverão, em geral, ser suficientes, dependendo da escolha dos modelos. Combine esse valor com a sua própria medição de miniaturas, e não com a estimativa de 10–20% para miniaturas mais transcodificação. Para uma ocupação projetada de 72 GB para miniaturas, uma margem de 10 GB para os modelos e uma margem adicional de 25%, a reserva de planeamento seria de aproximadamente 103 GB.

Recalcule quando qualquer variável que influencie a estimativa mudar: resolução ou qualidade das miniaturas, uma alteração significativa na resolução das câmaras, um modelo de ML diferente, um grande crescimento do volume de vídeos ou um aumento substancial do número de familiares que carregam recursos. O limiar de decisão é simples: se o armazenamento gerado projetado, mais a margem, se aproximar do espaço livre disponível no volume rápido pretendido, mova o caminho dos derivados, acrescente capacidade ou reduza as definições de geração relevantes antes de a biblioteca atingir esse ponto.