Immich 메타데이터는 SSD에, 대용량 데이터는 HDD에 저장해야 할까요?

예, Immich 배포에서는 데이터베이스와 지연 시간에 민감한 생성 데이터를 SSD에 두고, 용량이 큰 원본 사진과 동영상 파일은 HDD에 저장하는 방식이 도움이 되는 경우가 많습니다. 특히 라이브러리가 앱 상태보다 훨씬 클 때 효과적입니다. 다만 경로, 여유 공간, 백업 및 복구 절차를 명확하게 유지할 수 있을 때만 이러한 분리가 유용합니다.

결정 기준은 “메타데이터는 빠르게, 미디어는 느리게”가 아닙니다. Immich는 여러 저장소 역할에 서로 다르게 접근합니다. PostgreSQL은 작은 상태 작업을 많이 처리하고, 썸네일과 미리보기는 탐색 중 자주 읽히며, 인코딩된 동영상은 용량이 클 수 있습니다. 원본은 저장 용량과 내구성이 중요합니다. 무엇이든 옮기기 전에 이러한 역할을 각각 측정하세요.

자주 사용되는 소규모 I/O 상태와 용량 중심 미디어를 분리하세요

PostgreSQL 데이터, 썸네일, 미리보기, 인코딩된 동영상, 모델 캐시, 업로드된 원본, 외부 라이브러리 및 백업 사본을 목록화하세요. 각 항목의 현재 크기, 증가량, 읽기/쓰기 빈도, 재생성 비용, 복원 후 반드시 보존되어야 하는지 여부를 기록하세요. 이렇게 하면 일반적인 “메타데이터” 폴더 이름 때문에 서로 전혀 다른 작업 부하가 가려지는 것을 막을 수 있습니다.

미디어 메타데이터와 활성 캐시를 배치하는 ZimaSpace 저장소 프레임워크는 중요한 차이를 보여 줍니다. 데이터베이스와 인덱스는 지연 시간이 낮은 저장소에서 이점을 얻는 반면, 대용량 원본 미디어는 동일한 IOPS가 필요하지 않은 접근 패턴이라면 용량 중심 저장소에 그대로 둘 수 있습니다. 현재 HDD에서 검색, 타임라인 탐색 및 백그라운드 작업 중 지연 시간이 낮다면 모든 파생 데이터를 SSD로 옮겨도 사용자가 체감할 수 있는 이점이 거의 없을 수 있습니다. 활성 저장소 경로에서 실제로 대기 중이라는 사실이 통제된 비교를 통해 확인될 때까지 현재 구성을 유지하세요.

PostgreSQL과 자주 읽는 파생 데이터를 대기 원인이 확인될 때 SSD에 두세요

PostgreSQL과 썸네일 중심의 탐색은 작은 읽기 및 쓰기를 많이 발생시키므로, 특히 가져오기나 백업이 같은 장치를 사용하는 동안에는 사용 중인 기계식 디스크에서 느리게 느껴질 수 있습니다.

현재 Immich 구성에서는 데이터베이스를 로컬의 지연 시간이 낮은 저장소에 두고, 지원되는 생성 데이터 경로를 임의의 중첩 마운트로 만들기보다 신중하게 옮기세요.

Immich 외부에서도 저장소 방식은 잘 알려져 있습니다. PostgreSQL 저장소 튜닝은 회전식 디스크보다 훨씬 저렴한 무작위 접근의 이점을 얻습니다. 이것이 Immich에서 눈에 띄는 성능 향상을 보장하지는 않지만, 측정된 대기 원인이 장치 지연 시간일 때 데이터베이스와 인덱스 작업이 SSD의 유력한 후보인 이유를 설명해 줍니다.

이동 전후에 동일한 앨범, 검색 및 가져오기 샘플을 사용해 개선 정도를 측정하세요. 데이터베이스 지연 시간은 줄었지만 사용자가 보는 요청이 여전히 네트워크 전송, 이미지 디코딩 또는 머신 러닝을 기다리고 있다면 남은 지연을 HDD 탓으로 돌리지 마세요.

용량과 보호가 무작위 I/O보다 중요할 때는 원본을 HDD에 두세요

원본 사진과 동영상은 일반적으로 가장 큰 저장소 분류에 속하며, 작은 데이터베이스 페이지가 아니라 전체 파일 단위로 읽히는 경우가 많습니다. 따라서 필요한 안정성, 처리량 및 백업 용량을 제공하는 대형 HDD 풀은 원본을 보관하기에 합리적인 선택이 될 수 있습니다. 다만 가져오기와 탐색 작업을 동시에 수행할 때에도 HDD 계층에 여유 공간과 양호한 지연 시간을 확보해야 합니다.

Immich에서 썸네일을 미디어와 분리하는 방법에 관한 장기 논의도 같은 운영상의 요구를 보여 줍니다. 생성된 탐색용 자산과 대용량 원본은 접근 우선순위가 서로 다릅니다. 그렇다고 모든 설치에 물리적 장치 두 개가 필요하다는 뜻은 아닙니다. 효과는 현재 요청이 어느 지점에서 대기하는지에 따라 달라집니다.

저렴하다는 이유만으로 대체할 수 없는 원본을 HDD에 두고 RAID를 백업으로 간주하지 마세요. 가정의 보호 목표에 맞춰 두 번째 사본과 호스트 외부 또는 오프라인 사본을 유지하세요. 저장소 계층화는 성능과 비용을 바꾸지만, 가족 라이브러리의 유일한 사본을 잃었을 때의 결과를 줄여 주지는 않습니다.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

저장소 역할을 한 번에 하나씩 옮기고 마운트를 재부팅으로 테스트하세요

경로를 옮기기 전에 데이터베이스와 일관성이 맞는 백업을 생성하고, 현재 호스트와 컨테이너 간 마운트 구성을 기록하세요. 한 번에 하나의 역할만 이동한 뒤 스택을 시작하고, 기존 및 새 자산을 확인하며, 검색을 실행하고, 동영상을 재생하고, 테스트용 파일을 업로드한 다음 새 쓰기가 의도한 장치에 저장되는지 확인하세요. 데이터베이스, 썸네일, 원본 및 백업 대상 경로를 한 번의 변경으로 모두 옮기지 마세요.

컨테이너만 다시 생성하지 말고 호스트를 재부팅하세요. 정상적인 분리 구성이라면 Immich가 쓰기를 시작하기 전에 SSD와 HDD 마운트가 모두 온라인 상태가 되고, 사용자 및 관계 정보가 유지되며, 샘플 원본을 읽고 두 계층 모두에서 여유 공간 모니터링이 작동해야 합니다. 예상 마운트 지점에 비어 있는 대체 디렉터리가 나타나면 중단해야 합니다. 측정된 병목이 개선되고 복구 구성을 이해하기 쉬운 상태로 유지된다면 분리 구성을 계속 사용하세요. 오래된 경로, 누락된 자산, 권한 변경 또는 한 계층만 보호하는 백업 프로세스가 생기면 되돌리세요. 최고의 저장소 설계란 올바르게 복원할 수 있는 가장 빠른 설계입니다.