가족 사진을 백업할 때 Immich 메타데이터가 증가하는 이유는 무엇인가요?

가족 사진을 백업하는 동안 Immich 메타데이터가 증가하는 이유는 원본 하나마다 애플리케이션 레코드가 생성되고, 썸네일, 검색 벡터, 얼굴 데이터 및 기타 파생 상태도 생성될 수 있기 때문입니다.

이 증가량은 원본 라이브러리의 일정한 비율로 나타나지 않습니다. 작은 이미지가 많거나, 긴 동영상이 많거나, 인식된 얼굴이 많거나, 검색 처리를 광범위하게 수행하는 가정은 동일한 원본 테라바이트를 가진 다른 가족과 다른 오버헤드 양상을 보일 수 있습니다. 증가량이 예상 범위인지 판단하기 전에 데이터베이스 상태와 생성 파일을 구분하세요.

모든 자산은 영구 애플리케이션 레코드를 추가합니다

데이터베이스에는 자산과 소유자, 경로, 타임스탬프, 앨범, 권한 및 기타 애플리케이션에서 확인할 수 있는 속성을 연결하는 레코드가 필요합니다. 자산과 관계의 수가 증가하면 원본 파일이 다른 곳에 저장되어 있더라도 이러한 영구 상태의 크기도 커집니다.

썸네일과 원본에서 데이터베이스 오버헤드를 분리해 설명하는 스토리지 용량 개요가 유용한 이유는 각 요소의 증가 양상이 서로 다르기 때문입니다. 예시 수치는 다른 가족의 라이브러리에 그대로 적용되는 보장된 비율이 아니라, 특정 배포 환경에서 관찰된 값으로 보아야 합니다.

따라서 일부 메타데이터 관련 질문에서는 원본 용량보다 자산 수를 더 적절한 출발점으로 삼을 수 있습니다. 대용량 동영상 1만 개와 소용량 사진 1만 개는 원본 용량이 크게 다를 수 있지만, 두 경우 모두 애플리케이션 데이터베이스에 자산 단위의 레코드와 관계가 필요합니다.

생성된 탐색 파일은 별도의 스토리지 증가 곡선을 만듭니다

타임라인 탐색은 모든 원본을 여는 것보다 빠르게 표시할 수 있는 작은 표현에 의존합니다. 이러한 생성 파일은 엄밀한 의미의 데이터베이스 메타데이터는 아니지만, 라이브러리와 함께 증가하고 애플리케이션이 관리하기 때문에 흔히 “Immich 오버헤드”로 인식됩니다.

홈 랩 배포 환경의 4서비스 스토리지 구성은 사진, 생성 미디어, 데이터베이스의 위치를 구분합니다. 이러한 분리는 운영 측면에서 중요합니다. 변경이 잦은 파생 파일과 중요한 데이터베이스 상태는 백업 및 성능 측면에서 같은 역할을 하지 않기 때문입니다.

원본 바이트 수만으로 이 증가 곡선을 추정하지 마세요. 썸네일 수는 자산 수와 활성화된 크기에 따라 달라지고, 인코딩된 동영상 출력은 동영상 호환성과 트랜스코딩 설정에 따라 달라집니다. 동일한 자산 묶음의 처리가 완료된 후 각 생성 디렉터리를 별도로 측정하세요.

검색 및 얼굴 기능은 인덱스 상태를 추가합니다

시맨틱 검색과 얼굴 기능은 원본 이미지를 다시 작성하지 않고도 시각적 콘텐츠를 검색할 수 있도록 수치 표현과 관계를 생성합니다. 따라서 처리된 자산, 감지된 얼굴, 활성화된 분석 기능이 많아질수록 데이터베이스와 모델 관련 상태도 시간이 지나면서 증가합니다.

시맨틱 임베딩에 대한 설명은 파일 이름과 폴더가 그대로여도 시각적 검색 인덱스가 증가할 수 있는 이유를 보여줍니다. 모델은 조건에 맞는 각 이미지를 재사용 가능한 표현으로 변환하고, 이 표현은 이후 텍스트 쿼리와 비교할 때 사용할 수 있습니다.

이 상태를 전체 해상도의 두 번째 복사본으로 혼동해서는 안 됩니다. 자산 수, 기능 설정, 모델 목록이 안정된 후에도 검색 관련 데이터베이스 증가가 빠르게 계속된다면, 정상적인 인덱싱 때문이라고 단정하기보다 유지 관리, 중복 처리 또는 다른 데이터베이스 메커니즘을 조사하세요.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

가족 단위 정리는 파일뿐 아니라 관계도 추가합니다

앨범, 인물 이름, 공유 관계, 즐겨찾기, 편집 내용 및 기타 사용자 작업은 새 원본이 추가되지 않아도 애플리케이션 메타데이터를 증가시킬 수 있습니다. 따라서 동일한 미디어를 가진 두 가족이라도 한쪽이 정리 및 공유 기능을 더 많이 사용하면 데이터베이스 사용량이 달라질 수 있습니다.

ZimaSpace의 사진 정리 계층에 관한 가족 사진 개요는 중앙화된 원본과 그 위에 추가되는 검색 가능한 인물, 장소, 이벤트 및 앨범의 차이를 강조합니다. 이러한 관계는 사용자 경험의 일부이므로 복구 계획에서 고려해야 합니다.

로그, 컨테이너 쓰기 가능 계층, 임시 파일 또는 중복된 원본 자산에서 크게 설명되지 않는 증가가 발생한다면 이 메커니즘만으로는 충분하지 않습니다. 이러한 범주는 원인이 서로 다르므로 데이터베이스 및 파생 파일 모델에 포함해 하나의 “메타데이터” 수치로 합치지 말고 별도로 측정해야 합니다.

스토리지 역할별로 증가량을 측정하세요

대표적인 가져오기를 시작하기 전에 기준값을 기록하세요. 원본 미디어의 바이트 수와 개수, 데이터베이스 크기, 썸네일 또는 미리 보기 스토리지, 인코딩된 동영상 스토리지, 모델 캐시, 백업, 임시 파일 및 로그 공간을 측정합니다. 동일한 자산 묶음의 활성화된 백그라운드 작업이 완료된 후, 그리고 일반적인 가정 내 사용 후에 다시 측정하세요.

ZimaSpace의 가족 백업 작업 흐름은 원본과 필수 애플리케이션 상태를 함께 보호해야 하는 반면, 재생성 가능한 출력은 다르게 취급할 수 있는 이유를 다시 보여줍니다. 스토리지 회계는 바이트 수뿐 아니라 복구 가치를 기준으로 이루어져야 합니다.

증가량이 새 자산, 파생 파일, 데이터베이스 레코드 및 활성화된 기능으로 설명된다면 정상적인 증가로 받아들여도 됩니다. 한 역할의 사용량이 그에 상응하는 자산 또는 기능 활동 없이 증가하거나, 측정된 총량이 알려진 스토리지 역할의 합계와 크게 다르다면 추가로 조사하세요.