Home Assistant는 원본 데이터 외에 스토리지를 얼마나 더 사용하나요?

Home Assistant에는 보편적으로 적용되는 저장 공간 배수가 없습니다. 오버헤드는 이벤트 발생 빈도, 보존되는 기록, 통계, 인덱스, 로그, 백업, 애드온, 임시 작업 공간에 따라 달라집니다.

온도 센서는 아주 작은 값을 내보낼 수 있지만, 값의 변경은 타임스탬프가 포함된 상태, 속성, 인덱스 항목, 집계 데이터, 백업 복사본, 파일 시스템 메타데이터로 저장될 수 있습니다. 카메라 클립이나 애드온 데이터는 전혀 다른 이유로 저장 공간을 크게 차지할 수 있습니다. 따라서 유용한 추정은 각 저장 역할을 분리하고, 실제 가정의 엔티티 수, 업데이트 주기, 보존 기간, 로깅 수준, 백업 정책에 따른 일일 증가량을 측정하는 방식으로 이루어집니다.

소스 값은 구조화된 Recorder 데이터가 됩니다

소스 데이터는 장치나 통합에서 전달되는 값일 뿐입니다. Recorder는 선택한 상태 변경과 이벤트를 시간, 엔티티 참조, 속성, 관계형 구조와 함께 저장하므로 기록 및 기타 기능에서 이를 조회할 수 있습니다. 따라서 21.4와 같은 짧은 값도 데이터베이스 페이지와 관계 정보가 포함되면 눈에 보이는 문자 수보다 더 많은 공간을 차지합니다.

Home Assistant는 원시 상태와 단기 및 장기 통계 형식을 함께 유지합니다. 이 데이터베이스 및 통계 모델에 대한 자세한 설명은 보존 공간이 센서 페이로드의 명목상 크기가 아니라 변경 빈도와 집계 규칙에 따라 결정되는 이유를 보여줍니다.

이 첫 번째 계층은 일반적으로 발생 빈도에 따라 증가합니다. 자주 변경되는 엔티티는 안정적인 엔티티보다 더 많은 행을 생성하며, 상세한 속성은 그 차이를 더욱 키울 수 있습니다. 엔티티가 1,000개라고 해서 모든 가정에서 저장 공간이 동일한 것은 아닙니다. 오버헤드를 예측하려면 단순한 엔티티 수가 아니라 일일 변경 횟수, 보존 일수, 평균 저장 행 크기를 확인해야 합니다.

인덱스와 데이터베이스 페이지가 구조적 공간을 추가합니다

관계형 데이터베이스는 행을 안전하게 저장하고 검색할 수 있도록 여러 구조를 필요로 합니다. 테이블 페이지, 인덱스, 여유 페이지, 저널, 미리 쓰기 로그는 논리적 행 내용 외에 추가 공간을 차지할 수 있습니다. 이러한 구조는 일관성과 쿼리 성능을 향상시키지만, 오래된 기록을 삭제해도 파일 크기가 즉시 줄어들지는 않습니다.

SQLite는 고정 크기 페이지에 테이블과 인덱스를 저장하므로 물리적 크기는 단순히 필드 길이를 합산한 값이 아니라 페이지 할당 상태를 반영합니다. 이해하기 쉬운 SQLite 페이지 레이아웃 안내서는 레코드, 인덱스, 여유 공간이 데이터베이스 파일 안에서 어떻게 공존하는지 설명합니다.

이로 인해 논리적으로 보존된 데이터와 물리적으로 할당된 저장 공간이라는 두 가지 측정값이 생깁니다. 정리 작업으로 전자는 줄어들 수 있지만 후자는 즉시 감소하지 않을 수 있으며, 유지 관리 작업 중에는 공간을 반환하기 전에 추가 임시 공간이 필요할 수 있습니다. 용량을 계획할 때는 현재 데이터베이스 파일을 최대 필요 공간으로 간주하지 말고 작업 여유 공간을 확보해야 합니다.

통계는 장기 보존을 위해 상세 정보를 절충합니다

단기 기록은 제한된 기간 동안 세부적인 변경 사항을 보존하는 반면, 장기 통계는 지원되는 숫자형 엔티티에 대해 압축된 집계값을 유지합니다. 집계를 사용하면 모든 원시 상태를 영구적으로 보존하는 것보다 엔티티별 증가율을 낮출 수 있지만, 일반 기록과 수명이 다른 또 하나의 영구 데이터 세트가 생성됩니다.

따라서 Home Assistant의 데이터 모델에는 원시 상태, 단기 통계 샘플, 시간별 장기 요약이 동시에 포함될 수 있습니다. 이 시계열 통합 문서의 실제 분석은 과거 데이터를 분석할 때 컨트롤러의 현재 상태 요구 사항을 넘어서는 저장 역할이 추가되는 이유를 보여줍니다.

결과는 조건에 따라 달라집니다. 안정적인 이진 엔티티가 많은 가정은 통계 오버헤드가 적을 수 있지만, 에너지 및 환경 센서는 장기간 유지되는 집계값을 축적할 수 있습니다. 장기 통계는 원시 기록의 중복본이 아니라 낮은 해상도의 분석 가치를 보존하는 데이터입니다. 이를 설명되지 않은 단일 데이터베이스 배수에 포함하지 말고 별도의 일일 증가율로 추정해야 합니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

로그, 백업, 컨테이너 계층이 전체 사용량을 늘립니다

Home Assistant의 저장 공간은 Recorder에만 사용되지 않습니다. 반복되는 오류나 디버그 세션 중에는 로그가 증가할 수 있습니다. 백업에는 데이터베이스, 구성, 애드온 상태, 선택한 공유 폴더가 복사될 수 있습니다. 컨테이너 배포에서는 이미지, 쓰기 가능 계층, 볼륨, 때로는 동일한 시스템 디스크에 저장된 이전 버전이나 빌드 캐시도 유지됩니다.

Docker 디스크 사용량은 하나의 애플리케이션 디렉터리가 아니라 여러 저장소에 분산됩니다. 이 Docker 디스크 공간 안내서는 이미지, 컨테이너, 볼륨, 캐시를 구분하여 파일 시스템 증가량이 눈에 보이는 Home Assistant 데이터 폴더보다 커질 수 있는 이유를 설명합니다.

백업 보존은 선택한 데이터를 복사본 수만큼 늘리지만, 압축 및 증분 방식에 따라 정확한 비율은 달라질 수 있습니다. 실제 데이터베이스가 2GB라고 해서 백업마다 정확히 2GB가 추가되는 것은 아니며, 구성 폴더가 작다고 해서 백업도 작게 유지된다는 보장도 없습니다. 보관된 세대 수와 함께 아카이브의 구성 요소를 별도로 측정해야 합니다.

임시 공간으로 인해 정상 상태보다 사용량이 최고점에 도달합니다

데이터베이스 유지 관리, 백업 생성, 압축 해제, 업데이트, 이미지 가져오기, 마이그레이션 중에는 기존 형식과 새 형식이 함께 존재하면서 임시 공간이 필요할 수 있습니다. 작업이 성공한 뒤에는 사라지기 때문에 이 최고점은 쉽게 놓칠 수 있습니다. 정상 상태의 데이터 세트가 디스크 대부분을 이미 사용한 경우, 작업을 완료하는 데 필요한 여유 블록이 부족해져 안정성 문제가 발생합니다.

SQLite의 기본 데이터베이스와 WAL은 체크포인트 또는 압축 조건이 충족될 때까지 할당된 공간을 유지할 수 있습니다. SQLite 파일 증가에 대한 성능 분석은 애플리케이션에 보이는 논리적 데이터와 데이터베이스 및 미리 쓰기 로그의 증가 방식이 서로 다를 수 있는 이유를 설명합니다.

필요한 최고 공간은 작업에 따라 달라집니다. 데이터베이스를 다시 작성하는 작업에는 데이터베이스 크기에 비례하는 공간이 필요할 수 있고, 이미지 업데이트 중에는 이전 계층과 새 계층이 모두 임시로 유지될 수 있습니다. 오버헤드 구성 요소를 파악한 뒤 Home Assistant 작업을 위한 여유 저장 공간에 대한 ZimaSpace 안내에서 운영 기준을 확인할 수 있습니다.

단일 오버헤드 비율이 통하지 않는 경우

한 구성 요소가 대부분을 차지하면 고정 비율은 실패합니다. 오류가 반복되는 동안 디버그 로그가 Recorder보다 빠르게 증가할 수 있고, 로컬 카메라 미디어가 모든 데이터베이스 테이블보다 훨씬 커질 수 있으며, 대형 애드온이 자체 볼륨을 확장할 수 있습니다. 또한 백업을 오래 보존하는 정책으로 인해 복사본이 실제 운영 상태 데이터보다 커질 수 있습니다. 작업량이 변하면 어제의 비율도 더 이상 유효하지 않습니다.

컨테이너 디스크 부족 문제를 다루는 안내서가 이미지, 쓰기 가능 계층, 로그, 볼륨, 빌드 캐시를 구분하는 이유는 각각의 증가 방식이 다르기 때문입니다. 이 Docker 저장 공간 분석의 5개 항목 인벤토리는 최상위 총합 하나만으로는 주요 원인을 파악할 수 없는 이유를 보여줍니다.

설치 유형이 다르면 이 비율도 오해를 불러일으킵니다. Home Assistant OS, 컨테이너, VM, supervised 호스트 패키지는 시스템 데이터를 서로 다른 방식으로 저장합니다. 동일한 유형끼리 비교하고, Home Assistant의 백업이나 런타임이 실제로 관리하지 않는 미디어 또는 관련 없는 애플리케이션 데이터는 계산에서 제외해야 합니다.

7일간의 저장 공간 증가 모델 만들기

데이터베이스 파일, 구성, 로그, 백업, 애드온 볼륨, 컨테이너 이미지와 계층, 미디어, 여유 공간을 기준으로 한 번 측정합니다. 대표적인 7일 동안 보존 및 로깅 설정을 일정하게 유지합니다. 매일 같은 시간에 각 구성 요소를 기록하고 업데이트, 재시작, 백업 작업, 비정상적인 오류, 장치 추가 여부를 함께 적습니다.

저장 공간 관리는 가시성을 확보하는 것에서 시작합니다. 볼륨, 이미지, 쓰기 가능 계층, 캐시는 서로 다른 수명 주기를 갖기 때문입니다. 이 Docker 저장 공간 내부 구조 문서는 측정한 바이트를 영구 애플리케이션 데이터와 런타임 패키징 오버헤드로 구분하는 데 도움이 됩니다.

각 역할의 일일 증가량을 계산하고 자체 보존 기간을 곱한 다음, 관찰된 임시 최고 사용량과 복구 여유 공간을 더합니다. 통합을 추가하거나 로깅, 미디어, 백업 설정을 변경한 뒤에는 다시 확인합니다. 이러한 구성 요소별 모델은 신뢰할 수 있는 용량 범위를 제시하지만, 보편적인 배수 하나로는 이를 산출할 수 없습니다.