Home Assistant는 언제 별도의 데이터베이스 또는 스토리지 호스트를 사용해야 할까요?

에바 왕

IceWhale author

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

When Should Home Assistant Use a Separate Database or Storage Host? - Zima Store Online

Home Assistant는 측정된 용량, 보존 기간, 백업 또는 장애 도메인 문제를 해결할 때만 별도의 데이터베이스나 스토리지 호스트를 사용해야 합니다. 컨트롤러에서 상태를 분리한다고 해서 자동으로 업그레이드되는 것은 아닙니다.

많은 가정에서는 안정적인 SSD 스토리지에 로컬 SQLite Recorder 데이터베이스를 사용하는 것이 가장 간단한 방법입니다. 네트워크, 인증, DNS, 데이터베이스 서버 시작에 대한 의존성을 없앨 수 있기 때문입니다. 다른 호스트를 만들기 전에 실제 문제가 과도한 Recorder 쓰기, 긴 보존 기간, 느린 기록 쿼리, 제한된 로컬 용량인지, 아니면 한 서비스를 독립적으로 복구해야 하는 요구인지 먼저 확인하세요.

데이터베이스 서버를 추가하기 전에 Recorder를 조정하세요

Recorder의 증가 속도는 저장되는 엔터티와 이벤트, 변경 빈도, 기록 보존 기간에 따라 결정됩니다. 소음이 많은 센서나 불필요한 도메인이 쓰기 작업의 대부분을 차지한다면, 동일한 작업을 더 큰 데이터베이스 서버로 옮기는 것은 문제를 없애는 대신 위치만 바꾸는 것입니다.

최신 Recorder 조정 워크플로에서는 데이터베이스 마이그레이션을 고려하기 전에 보존 기간, 포함/제외 규칙, 커밋 동작이 쓰기 작업량에 어떤 영향을 미치는지 설명합니다. 조정 후 데이터베이스 크기, 기록 쿼리 시간, 스토리지 지연 시간, 쓰기 활동을 측정하세요.

조정된 작업량이 원활하게 처리되고, 백업이 유지보수 시간 내에 완료되며, 사용 가능한 SSD 용량에 충분한 여유가 있다면 데이터베이스를 로컬에 유지하세요. 클라이언트-서버 데이터베이스가 항상 더 빠르다는 막연한 믿음이 아니라, 실제 요구 사항을 충족하지 못할 때 분리를 선택해야 합니다.

운영상 이점이 실제로 있을 때 외부 데이터베이스를 사용하세요

Home Assistant가 이미 안정적으로 운영되는 데이터베이스 플랫폼을 공유하거나, 긴 보존 기간으로 지속적인 쿼리 부하가 발생하거나, 컨트롤러 호스트를 가볍고 교체 가능하게 유지해야 하거나, 데이터베이스 백업과 모니터링에 독립적인 수명 주기가 필요하다면 별도의 MariaDB, MySQL 또는 PostgreSQL 호스트를 사용하는 것이 적절할 수 있습니다.

SQLite에서 MariaDB로 마이그레이션하는 예시는 이 선택으로 새롭게 추가되는 요소를 보여 줍니다. 데이터베이스 서비스, 자격 증명, 네트워크 주소, 스키마 초기화, 마이그레이션 절차, 검증, 롤백이 이에 해당합니다. 더 큰 규모의 실제 Home Assistant 데이터베이스 마이그레이션 사례는 긴 기록 기간과 대규모 데이터 세트가 추가 관리 작업을 정당화할 수 있는 이유를 보여 줍니다.

ZimaSpace의 외부 데이터베이스 업그레이드 안정성 문서는 이에 해당하는 유지보수 경계를 제시합니다. 데이터베이스는 보이지 않는 인프라로 취급할 것이 아니라 독립적인 서비스로 백업, 업그레이드, 복원해야 합니다.

기본적으로 네트워크 공유에 실행 중인 SQLite 데이터베이스를 두지 마세요

원격 데이터베이스 서버와 SMB 또는 NFS에 저장된 데이터베이스 파일은 서로 다른 아키텍처입니다. 클라이언트-서버 데이터베이스는 데이터베이스 서비스 내부에서 잠금과 트랜잭션을 처리하고 네트워크를 통해 요청을 주고받습니다. SQLite는 파일 시스템을 통해 데이터베이스 파일의 잠금을 처리하므로 네트워크 파일 시스템의 동작, 마운트 사용 가능 여부, 지연 시간, 잠금 동작이 모든 트랜잭션의 일부가 됩니다.

보다 자세한 SQLite 잠금 분석에서는 네트워크 파일 시스템이 로컬 디스크와 다른 잠금 동작을 일으킬 수 있는 이유를 설명합니다. Home Assistant의 네트워크 공유 장애 사례는 실행 중인 Recorder 데이터베이스가 원격 마운트에 의존할 때 발생할 수 있는 실제 위험을 보여 줍니다.

백업 사본, 내보내기 파일, 미디어 및 네트워크 스토리지를 위해 설계된 기타 데이터에는 NAS를 자유롭게 사용하세요. 활성 Recorder 상태를 다른 컴퓨터에 두어야 한다면 SQLite 파일을 공유 폴더로 옮기기보다 지원되는 클라이언트-서버 데이터베이스를 사용하는 것이 좋습니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

대용량 스토리지와 활성 Home Assistant 상태를 분리하세요

성장하는 Home Assistant 디렉터리가 모두 동일한 스토리지 계층에 있어야 하는 것은 아닙니다. 구성, 통합 상태, 활성 Recorder 데이터베이스, 미디어, 카메라 클립, 내보내기 파일, 백업은 각각 필요한 지연 시간과 복구 방식이 다릅니다. 별도의 서비스가 의도적으로 관리하지 않는 한, 자주 업데이트되는 작은 상태 데이터는 지연 시간이 낮은 로컬 스토리지에 보관하세요.

대용량 미디어나 여러 세대의 백업은 안정적인 마운트 지점 뒤의 NAS 용량으로 옮기세요. 해당 마운트 없이 Home Assistant가 부팅해도 되는지 문서화하세요. 사진 보관소가 없다고 조명 자동화가 시작되지 않아서는 안 되지만, 활성 데이터베이스가 없을 때는 아무도 알아차리지 못하는 조용한 대체 동작이 아니라 명시적인 성능 저하 상태가 발생해야 합니다.

데이터 역할	기본 위치	분리해야 하는 이유
구성 및 활성 상태	로컬 SSD	낮은 지연 시간과 간단한 복구
Recorder SQLite	로컬 SSD	네트워크 파일 시스템 잠금 의존성 방지
외부 SQL 데이터베이스	로컬 또는 별도 데이터베이스 호스트	독립적인 확장, 보존, 백업, 관리
미디어 및 내보내기 파일	로컬 또는 NAS	지연 시간보다 용량이 중요한 경우가 많음
백업	최소 하나의 호스트 외부 사본	활성 호스트의 손실에 대비

분리를 영구적으로 적용하기 전에 시작, 장애, 복구를 검증하세요

기존 복구 경로를 삭제하지 않은 상태에서 새 데이터베이스나 스토리지 역할을 단계적으로 적용하세요. Home Assistant보다 먼저 데이터베이스 호스트를 재부팅하고, 데이터베이스가 준비되기 전에 Home Assistant를 재부팅하고, 네트워크를 중단하고, 자격 증명을 교체하고, 대상 파일 시스템을 여유 공간 임계값 근처까지 채우고, 깨끗한 인스턴스에 데이터베이스를 복원하세요.

95백분위 기록 쿼리 시간, Recorder 활동이 많은 동안의 자동화 지연 시간, 재시작 시간, 백업 소요 시간, 데이터베이스 호스트 장애 후 복구 시간을 측정하세요. 분리로 한 지표가 개선되더라도 컨트롤러 재시작 시간이 30초에서 여러 서비스가 필요한 복구 절차로 늘어난다면, 해당 운영 비용을 의사 결정에 포함하세요.

현재 로컬 스토리지가 목표를 이미 충족한다면 그대로 유지하세요. 클라이언트-서버 데이터베이스 작업과 독립적인 복구가 실제 이점이 될 때 별도의 데이터베이스 호스트를 사용하세요. 대용량 데이터와 백업에는 별도의 스토리지 호스트를 사용하되, 검증된 이유 없이 중요한 로컬 제어가 원격 파일 시스템에 의존하도록 만들지는 마세요.