Recorder 데이터가 늘어날수록 Home Assistant 기록 쿼리가 느려지는 이유는 무엇인가요?

Home Assistant에는 추가되는 엔티티마다 속도가 저하되는 하나의 범용 ‘검색’ 엔진이 있는 것은 아닙니다. 더 분명한 확장성 문제는 과거 데이터 조회 작업입니다. History 패널, Logbook과 유사한 보기, 통계 및 기타 데이터베이스 기반 기능은 보존된 Recorder 데이터를 검색하고 정리해야 합니다.

데이터셋이 커질수록 요청 비용은 일치하는 행의 수, 이를 좁혀 주는 인덱스, 속성 조인의 필요 여부, 이미 메모리에 적재된 데이터의 양, 저장 장치가 누락된 페이지를 제공하는 속도에 따라 달라집니다. 데이터베이스 크기도 중요하지만 쿼리 형태 역시 그만큼 중요합니다.

History는 실시간 상태 머신만이 아니라 Recorder에서 읽습니다

현재 장치 값은 Home Assistant의 런타임 상태 모델에 저장되지만, History 통합은 Recorder에 저장된 관측값을 읽습니다. 따라서 현재 온도를 표시하는 대시보드 카드와 5일간의 History 그래프는 서로 다른 데이터 경로를 사용합니다.

Home Assistant 문서에 따르면 History는 Recorder에 의존하며 일반적으로 설정된 보존 기간 내의 원시 Recorder 데이터를 읽습니다. 선택한 기간이 해당 기간을 넘어가고 대상 센서에 장기 통계가 제공되는 경우에는 시간별 장기 통계를 대신 사용할 수 있습니다.

이 때문에 대규모 과거 데이터베이스는 History를 느리게 만들 수 있지만, 로컬 조명 자동화는 여전히 즉시 반응할 수 있습니다.

보존되는 상태가 많아질수록 행, 메타데이터, 인덱스 작업도 늘어납니다

기록되는 업데이트마다 데이터베이스에 정보가 추가됩니다. Home Assistant는 엔티티 식별자와 공유 속성을 관련 테이블로 분리해 중복을 줄이지만, 사용량이 많은 설치 환경에서는 여전히 많은 상태 행이 쌓일 수 있습니다.

현재 Home Assistant 데이터 모델에 따르면 기록된 상태는 엔티티 메타데이터와 공유 속성 행을 참조하며, 과거 데이터 쿼리에 사용되는 타임스탬프 및 관계 인덱스를 포함합니다. 따라서 빠르게 변하는 엔티티는 사람이 읽을 수 있는 값의 개수 이상으로 데이터 증가를 유발합니다.

보존 기간과 업데이트 빈도는 서로 곱해져 영향을 줍니다. 초마다 변하는 센서는 하루에 두 번 변하는 센서와 전혀 다른 작업 집합을 만들며, 둘 다 ‘하나의 엔티티’라는 점은 같습니다.

인덱스는 검색 작업을 줄이지만 결과 크기에 따른 비용을 없애지는 않습니다

SQLite는 인덱스를 사용해 일반적인 쿼리 조건과 정렬에 해당하는 모든 행을 스캔하지 않을 수 있습니다. 이는 History에 필수적이지만, 인덱스가 일치하는 범위가 넓을 때 결과를 반환하거나 관련 데이터를 조인하는 비용까지 없애 주지는 않습니다.

SQLite의 쿼리 플래너 문서에 따르면 인덱스는 조회와 정렬을 빠르게 하지만, 대규모 결과 집합, 행 조회, 정렬에는 선택한 데이터와 실행 계획에 비례하는 작업이 여전히 필요합니다. 플래너는 예상 비용을 기준으로 사용 가능한 경로 중 하나를 선택합니다.

따라서 ‘데이터베이스에 인덱스가 있다’는 것과 ‘이 쿼리가 영원히 일정한 시간 안에 실행된다’는 것은 같은 주장이 아닙니다. 더 넓은 시간 범위와 더 많은 변화를 발생시키는 엔티티는 여전히 더 많은 페이지와 행을 관련 대상으로 만들 수 있습니다.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Recorder 보존 기간은 성능과 용량을 제어합니다

Home Assistant는 상세한 상태 데이터가 무한히 증가하지 않도록 Recorder 데이터를 자동으로 정리합니다. 보존 기간을 늘리면 더 많은 고해상도 과거 데이터를 유지할 수 있지만, 현재 작업 집합, 백업 크기, 유지 관리 작업도 함께 증가합니다.

Recorder 문서는 데이터베이스가 지나치게 커지면 디스크 공간을 소모하고 Home Assistant가 느려질 수 있다고 명시적으로 경고합니다. 기본 정리 및 재압축 동작은 부분적으로 데이터베이스 증가를 제한하기 위해 존재합니다.

따라서 적절한 보존 기간은 제품 요구 사항입니다. 디스크에 여유 공간이 있다는 이유만으로 보존하지 말고, 실제 가정 내 질문에 답하는 데 필요한 기간만 고해상도 데이터로 유지하세요.

저장 장치와 캐시는 동일한 쿼리의 체감 비용을 결정합니다

반복되는 History 요청은 데이터베이스와 파일 시스템 페이지가 이미 메모리에 상주해 있기 때문에 더 빠를 수 있습니다. 재시작 후나 메모리 부족 상태에서는 동일한 쿼리가 더 많은 물리적 읽기를 필요로 할 수 있습니다. 같은 SSD에 있는 다른 서비스가 대량으로 데이터를 기록하는 경우에도 SQL 요청을 변경하지 않고 지연 시간이 증가할 수 있습니다.

ZimaSpace의 Home Assistant 메타데이터 및 과거 데이터 증가 원인 분석은 쓰기 측 원인을 설명합니다. 쿼리 성능은 읽기 측 결과입니다. 보존된 상태가 많다는 사실은 선택한 범위나 작업 집합이 실제로 해당 데이터에 접근할 때 가장 큰 영향을 미칩니다.

데이터베이스를 옮기거나 더 빠른 하드웨어를 구매하기 전에 저장 장치 지연 시간과 메모리 압박을 함께 측정하면서 쿼리 시간을 확인하세요.

유용한 과거 데이터를 줄이지 말고 불필요한 데이터를 줄여 쿼리 비용을 낮추세요

• 과거 변화가 의사 결정에 아무런 가치가 없는 엔티티는 제외하세요.
• 고빈도 변화가 유용하지 않다면 데이터 소스에서 업데이트 빈도를 낮추세요.
• 원시 데이터 보존 기간을 사용자가 실제로 확인하는 시간 범위에 맞추세요.
• 시간별 집계로 충분한 장기 범위에는 장기 통계를 사용하세요.
• 여유 공간을 확보한 안정적인 저지연 저장 장치에 Recorder를 두세요.
• 변경할 때마다 동일한 History 범위를 전후로 비교하세요.

유용한 지표는 데이터베이스 크기만이 아닙니다. 보존된 행 수, 요청한 시간 범위, 캐시 상태, 저장 장치 조건이 변할 때 쿼리 지연 시간이 어떻게 달라지는지가 중요합니다.

자주 묻는 질문

Recorder 데이터베이스가 커지면 로컬 자동화도 자동으로 느려지나요?

아니요. 실시간 장치 제어와 과거 데이터 쿼리는 서로 다른 경로입니다. Recorder 작업이 CPU, 메모리 또는 저장 장치의 공유 자원 경합을 일으키면 간접적으로 서로 영향을 줄 수 있지만, 느린 History 그래프만으로 자동화 엔진이 느리다고 단정할 수는 없습니다.