센서 유지가 스마트 홈 서버 저장소에 어떻게 영향을 미치나요?

에바 왕

IceWhale author

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

How Does Sensor Retention Drive Smart Home Server Storage? - Zima Store Online

센서 보존은 엔티티 수, 샘플 빈도, 기록 오버헤드, 인덱스 증가 및 백업 이력을 시간에 따라 곱하여 스마트 홈 서버 저장소를 구동합니다.

가정은 몇 개의 온도 및 동작 엔티티로 시작할 수 있으며, 이후 전력 미터, 공기질 센서, 누수 감지기, 도어 접촉 센서, 기상 데이터, 가전제품 원격 측정 및 계산된 통계를 추가할 수 있습니다. 각 값은 작지만 서버는 타임스탬프, 식별자, 속성, 인덱스, 트랜잭션 기록 및 종종 여러 백업 복사본을 함께 저장합니다. 아래 섹션들은 보존이 단순한 “센서당 바이트 수” 계산이 아니라 데이터 수명 주기 결정인 이유와 집계가 장기 곡선을 어떻게 변화시키는지 보여줍니다.

저장소 증가는 단위 시간당 샘플 수에서 시작됩니다

첫 번째 변수는 각 엔티티가 새 기록을 생성하는 빈도입니다. 5분마다 보고하는 온도 센서는 하루에 288개의 판독값을 생성하는 반면, 5초마다 보고하는 전력 미터는 17,280개를 생성합니다.

장기 ESPHome 배포는 종종 고주파 센서 데이터를 저해상도 과거 데이터와 분리합니다. 원시 속도는 초기 쓰기 부하와 이후 분석에 사용할 수 있는 세부 정보 양을 결정합니다.

보고 빈도에 엔티티 수와 보존 기간을 곱하세요. 하나의 고속 에너지 채널은 느리게 변하는 수십 개의 접촉 센서보다 더 많은 행을 생성할 수 있습니다.

하나의 센서 값은 숫자 페이로드보다 더 많은 공간을 차지합니다

부동 소수점 값은 몇 바이트만 사용할 수 있지만, 데이터베이스 행은 타임스탬프, 엔티티 참조, 스키마 필드, 페이지 공간, 트랜잭션 메타데이터 및 때로는 반복되는 속성이나 상태 문자열도 필요합니다.

시계열 시스템은 타임스탬프 기록에 최적화되어 있지만, 저장소에는 청크 메타데이터, 인덱스, 선행 기록 로그 및 압축 오버헤드도 포함됩니다. 기록이 희소하거나 텍스트가 많거나 자주 인덱싱될 때 페이로드 크기와 디스크 크기 간의 차이가 가장 큽니다.

이 때문에 “판독값당 8바이트”로 보존을 추정하는 것은 신뢰할 수 없습니다. 올바른 측정은 실제 스키마, 기록기 설정 및 센서 조합에 따른 일일 데이터베이스 성장입니다.

속성이 많은 엔티티는 설명적인 JSON이 자주 변경되거나 과거 행에 중복될 때 특히 비용이 많이 듭니다.

인덱스와 쿼리 속도는 자체 저장 비용을 추가합니다

과거 대시보드는 시간 범위 내에서 하나의 엔티티를 찾고 여러 센서를 비교하며 일별 또는 월별 집계를 계산해야 합니다. 인덱스는 추가 검색 가능한 구조를 저장하여 이러한 쿼리를 가속화합니다.

시계열 데이터베이스 비교 연구에 따르면 쓰기 성능, 압축, 쿼리 동작 및 저장 효율성은 데이터베이스 설계에 따라 다릅니다. 최근 쿼리에 최적화된 레이아웃은 단순한 추가 전용 아카이브보다 더 많은 인덱스 또는 메모리 자원을 사용할 수 있습니다.

모든 인덱스를 제거하면 공간을 절약할 수 있지만 다년간 차트와 문제 해결이 비현실적일 수 있습니다. 따라서 보존 계획은 원시 용량과 가정에서 실행할 쿼리 간의 균형을 맞춥니다.

-15% OFF

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

Single board computer zimaboard2

원시 보존과 과거 보존은 다른 해상도를 필요로 합니다

최근 문제 해결에는 5초마다 전력 판독값이 필요할 수 있지만, 5년간 에너지 비교에는 시간별 또는 일별 합계만 필요할 수 있습니다. 두 질문을 모두 원시 해상도로 유지하면 유용한 장기 세부 정보 없이 용량만 낭비됩니다.

최신 TSDB는 보존 정책, 압축 및 롤업을 사용하여 데이터를 여러 계층으로 나이 들게 합니다. 원시 기록은 몇 주 또는 몇 달 후에 만료될 수 있지만 시간별, 일별 또는 월별 집계는 수년간 유지됩니다.

집계 함수는 센서에 맞아야 합니다. 온도는 최소, 최대 및 평균이 필요할 수 있고, 에너지 카운터는 차이가 필요하며, 접촉 센서는 산술 평균 대신 지속 시간 또는 전환 횟수가 필요할 수 있습니다.

원시 행이 삭제되면 집계는 모든 짧은 급증이나 이벤트를 재구성할 수 없습니다. 미래에 답변해야 할 질문을 결정한 후에만 롤업을 선택하세요.

백업은 보존된 데이터베이스 크기를 곱합니다

실시간 데이터베이스는 한 개의 복사본일 뿐입니다. 예약된 스냅샷, 애플리케이션 백업, 파일시스템 스냅샷, 복제본, 내보낸 아카이브 및 오프사이트 복사본은 동일한 기록이 차지하는 저장소를 여러 배로 늘릴 수 있습니다.

시계열 저장소는 빈번한 쓰기를 사용하므로 저장소 파티션과 압축 패턴이 스냅샷이 변경 사항을 얼마나 효율적으로 보존하는지에 영향을 미칩니다. 전체 데이터베이스를 반복적으로 복사하는 백업 시스템은 증분 블록이나 네이티브 내보내기를 캡처하는 시스템보다 더 빨리 성장할 수 있습니다.

따라서 보존은 실시간 시스템과 백업 모두에 대해 정의되어야 합니다. 활성 데이터베이스에서 오래된 행을 삭제해도 해당 스냅샷이 만료될 때까지 불변 스냅샷의 공간은 회수되지 않습니다.