데이터가 늘어날수록 Immich 검색 또는 쿼리 결과가 느려지는 원인은 무엇인가요?

에바 왕

IceWhale author

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

What Causes Immich Search or Query Results to Slow as Data Grows?

Immich 검색은 사진이 존재하기 때문이 아니라, 라이브러리가 커지면서 더 큰 인덱스와 작업 집합이 효율적인 캐시, 필터링 또는 스토리지 동작 범위를 벗어날 때 느려집니다.

라이브러리가 커지면 행, 임베딩, 메타데이터, 썸네일, 가능한 필터 조합이 동시에 증가합니다. 어느 단계가 느려지는지 진단해야 합니다. 더 빠른 파일 스토리지는 잘못된 쿼리 경로를 개선할 수 없고, 데이터베이스 튜닝으로 원격 썸네일 마운트를 빠르게 만들 수도 없기 때문입니다.

성장하면 원래 라이브러리보다 더 많은 요소가 확장됩니다

자산이 추가될 때마다 데이터베이스 행, 추출된 메타데이터, 검색 표현, 얼굴 데이터, 썸네일, 인코딩된 미디어가 늘어날 수 있습니다. 이러한 구조는 서로 다른 속도로 증가하며 서로 다르게 접근됩니다. 따라서 요청이 얼마나 많은 검색 가능한 엔터티와 파생 객체를 탐색하는지 모르면 원본 라이브러리의 테라바이트 수만으로 검색 지연 시간을 예측할 수 없습니다.

ZimaSpace의 Immich 데이터 경로 분석은 백그라운드 처리, 검색 가능한 표현, 데이터베이스 선택, 전달되는 미디어를 구분합니다. 쿼리 진단에서 얻을 수 있는 실질적인 교훈은 라이브러리의 성장으로 검색 카탈로그와 결과 이후에 제공되는 파일이 모두 변한다는 점이며, 이에 따라 지연이 발생할 수 있는 지점도 하나 이상이라는 것입니다.

각 단계에서 자산 수, 데이터베이스 크기, 벡터 인덱스 크기, 썸네일 사용 공간, 자주 사용하는 필터의 카디널리티를 기록하세요. 시간에 따른 추이를 확인하면 어떤 구조가 지연 시간과 함께 증가하는지 파악할 수 있으며, 원본 동영상 바이트 수의 무관한 증가를 데이터베이스 선택 시간의 원인으로 잘못 지목하는 일을 막을 수 있습니다.

벡터 인덱스는 메모리 적합성에 민감해집니다

시맨틱 검색은 모든 원본 이미지를 읽는 대신 표현 인덱스를 탐색합니다. 인덱스가 커지면 활성 그래프나 페이지가 더 이상 메모리에 상주하지 못할 수 있습니다. 그러면 무작위 캐시 누락으로 인해 메모리 속도로 처리되던 작업이 스토리지 읽기로 바뀌고, 평균 CPU 사용률이 보여 주는 것보다 테일 지연 시간이 더 급격히 증가합니다.

PostgreSQL 벡터 검색에 관한 엔지니어링 분석에 따르면, 활성 그래프가 메모리를 초과하면 무작위 접근 탐색이 캐시 누락에 민감해져 HNSW 성능이 저하될 수 있습니다. Immich 버전과 인덱스 구현은 달라질 수 있으므로, 이를 특정 구성에 대한 처방이 아니라 검증할 메커니즘으로 활용하세요.

재시작 직후, 한 번 워밍업한 후, 관련 없는 라이브러리 영역에 접근한 후에 동일한 시맨틱 쿼리를 측정하세요. 데이터베이스 읽기, 캐시 적중 동작, 장치 지연 시간을 비교합니다. 워밍업 후 성능이 크게 향상되지만 작업 집합이 넓어지면 그 효과가 사라진다면 메모리 적합성 가설을 뒷받침합니다. 쿼리가 일관되게 느리다면 다른 원인을 살펴봐야 합니다.

카디널리티에 따라 필터와 쿼리 계획이 바뀔 수 있습니다

날짜, 인물, 소유자, 앨범 및 기타 조건은 순위 산정 전이나 도중에 남는 후보 수를 바꿉니다. 데이터 분포가 변하면 동일한 필터라도 라이브러리에서 훨씬 더 큰 비율을 선택할 수 있습니다. 따라서 검색어 자체가 바뀌지 않았더라도 데이터베이스 통계와 쿼리 계획 선택이 중요해질 수 있습니다.

pgvector 제한 사항 검토에서는 벡터 검색과 메타데이터 필터를 결합하기 어려울 수 있으며, 벡터 작업이 트랜잭션 작업과 PostgreSQL의 CPU, 메모리, I/O를 공유한다고 설명합니다. 이 글은 일반적인 PostgreSQL 근거이므로 특정 Immich 쿼리 계획을 입증하기보다는 해당 메커니즘을 뒷받침하는 자료로 활용해야 합니다.

알려진 결과 집합을 사용해 필터 하나를 적용한 검색과 적용하지 않은 검색을 쌍으로 만드세요. 브라우저의 완료 시간뿐 아니라 서버 측 쿼리 시간과 데이터베이스 활동도 수집합니다. 선택 시간이 늘어나지만 반환된 썸네일은 빠르다면 미디어 스토리지가 아니라 계획, 통계, 인덱스 적합성, 경합에 집중하세요.

-15% OFF

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

Single board computer zimaboard2

결과 선택과 결과 렌더링을 분리하세요

데이터베이스가 일치하는 자산 식별자를 이미 선택한 후에도 인터페이스가 느리게 느껴질 수 있습니다. 렌더링에는 썸네일 조회, 스토리지 읽기, 응답 전송, 클라이언트 디코딩이 여전히 필요합니다. 파생 파일 트리가 커지거나 원격 마운트를 사용하는 경우 이 두 번째 단계가 지연될 수 있지만, 실제 검색 쿼리는 정상일 수 있습니다.

대규모 가져오기 보고서에서는 수십만 개의 메타데이터 및 썸네일 작업이 대기 중인 동안 Immich 전반이 느려졌다고 설명합니다. 이는 백그라운드 압박이 겹친 사례를 보여 주는 것이지 보편적인 규모 제한을 입증하는 것은 아닙니다. 또한 성장 테스트를 대기열이 활성화된 상태와 대기열이 비워진 후 모두 실행해야 하는 이유를 보여 줍니다.

브라우저 타이밍이나 API 관찰을 사용해 결과 응답 완료 시점과 마지막으로 표시되는 썸네이カイル의 시점을 পৃথ পৃথ로 기록하세요. 대기열을 일시 중지한 상태와 활성화한 상태에서 알려진 검색을 반복합니다. 식별자 반환이 느리다면 데이터베이스와 인덱스 경로를 조사하고, 이미지만 느리다면 썸네일 스토리지, 네트워크 전송, 클라이언트 디코딩, 경쟁하는 백그라운드 I/O를 점검하세요.