Home Assistantはソースデータ以外にどれくらいストレージ容量を消費しますか？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

How Much Storage Overhead Does Home Assistant Add Beyond Source Data? - Zima Store Online

Home Assistantは、ストレージに一律の倍率を適用しません。オーバーヘッドは、イベントの頻度、保持する履歴、統計情報、インデックス、ログ、バックアップ、アドオン、一時的な作業領域によって異なります。

温度センサーが小さな値を送信していても、その変化はタイムスタンプ付きの状態、属性、インデックスエントリ、集計値、バックアップコピー、ファイルシステムメタデータになる可能性があります。カメラクリップやアドオンデータは、まったく異なる理由で容量を大きく消費することがあります。したがって有用な見積もりでは、各ストレージ用途を分け、実際のエンティティ数、更新頻度、保持期間、ログレベル、バックアップポリシーに基づいて、1日あたりの増加量を測定します。

ソース値は構造化されたRecorderデータになる

ソースデータとは、デバイスやインテグレーションから届く値にすぎません。Recorderは、選択された状態の変化やイベントを、時刻、エンティティ参照、属性、リレーショナル構造とともに保存し、履歴やその他の機能からクエリできるようにします。そのため、21.4のような短い値でも、データベースページや関連情報を含めると、表示される文字数以上の容量を占有します。

Home Assistantは、生の状態に加えて、短期および長期の統計形式を保持します。このデータベースと統計モデルの解説では、保持容量がセンサーのペイロードの名目サイズではなく、変化の頻度と集計ルールに左右される理由を説明しています。

この最初の層は通常、頻度によって増加します。頻繁に変化するエンティティは、安定したエンティティより多くの行を生成し、詳細な属性によって差がさらに広がることがあります。エンティティが1,000個あっても、すべての家庭で同じ容量になるわけではありません。オーバーヘッドを予測するには、エンティティ数だけでなく、1日あたりの変化回数、保持日数、保存される1行あたりの平均的な影響量が必要です。

インデックスとデータベースページが構造上の容量を追加する

リレーショナルデータベースには、行を永続化して検索可能にする構造が必要です。テーブルページ、インデックス、空きページ、ジャーナル、先行書き込みログは、論理的な行の内容以外にも容量を消費することがあります。これらの構造は一貫性とクエリ性能を向上させますが、古い履歴を削除してもファイルサイズがすぐに縮小するとは限りません。

SQLiteはテーブルとインデックスを固定サイズのページに保存するため、物理サイズはフィールド長の単純な合計ではなく、ページの割り当てを反映します。わかりやすいSQLiteのページレイアウトの解説では、レコード、インデックス、空き領域がデータベースファイル内でどのように共存するかを説明しています。

その結果、論理的に保持されているデータと、物理的に割り当てられたストレージという2種類の測定値が生じます。パージによって前者は減っても、後者はすぐに減らないことがあります。また、メンテナンス操作では、空き容量を解放する前に追加の一時領域が必要になる場合があります。容量計画では、現在のデータベースファイルを最大必要容量とみなすのではなく、作業用の余裕を確保する必要があります。

統計情報は長期保持のために詳細度を抑える

短期履歴は限られた期間、詳細な変化を保持する一方、長期統計は対応する数値エンティティの集約値をコンパクトに保存します。すべての生の状態を永久に保持する場合と比べて、集計によってエンティティあたりの増加率は低下しますが、通常の履歴とは異なる期間にわたって存続する、別の永続データセットが作成されます。

そのため、Home Assistantのデータモデルには、生の状態、短期統計サンプル、1時間ごとの長期サマリーが同時に含まれることがあります。この時系列インテグレーションの記事にある実用的な内訳は、履歴分析によって、コントローラーの現在状態に必要な容量とは別のストレージ用途が生じることを示しています。

結果は条件によって異なります。安定したバイナリエンティティが多い家庭では統計情報のオーバーヘッドが控えめな場合がありますが、エネルギーセンサーや環境センサーでは長期間保持される集計値が蓄積することがあります。長期統計は生の履歴の重複ではなく、解像度を下げた分析価値を保持するものです。説明のない単一のデータベース倍率に含めるのではなく、1日あたりの増加量を別に見積もってください。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

ログ、バックアップ、コンテナレイヤーが容量を増幅する

Home AssistantのストレージはRecorderだけではありません。繰り返し発生するエラーやデバッグセッション中には、ログが増大することがあります。バックアップには、データベース、設定、アドオンの状態、選択した共有フォルダーがコピーされる場合があります。コンテナ環境では、同じシステムディスク上にイメージ、書き込み可能なレイヤー、ボリューム、古いバージョンやビルドキャッシュが残ることもあります。

Dockerのディスク使用量は、1つのアプリケーションディレクトリではなく、複数の保存領域に分散しています。このDockerのディスク容量ガイドでは、イメージ、コンテナ、ボリューム、キャッシュを分けて説明しており、ファイルシステムの増加量がHome Assistantのデータフォルダーから見える容量を超える理由を理解するのに役立ちます。

バックアップの保持数によって、選択したデータはコピー数に応じて増えますが、圧縮や増分方式によって正確な比率は変わります。稼働中のデータベースが2GBあっても、各バックアップが必ず2GBずつ増えるとは限りません。また、設定フォルダーが小さいからといって、バックアップも小さいとは限りません。アーカイブの内容と保持世代数は、それぞれ独立して測定してください。

一時領域によって定常状態を超えるピークが生じる

データベースのメンテナンス、バックアップの作成、展開、アップデート、イメージの取得、移行では、古い形式と新しい形式が共存する間、一時的な容量が必要になることがあります。このピークは処理が成功すると消えるため、見落としやすいものです。しかし、定常状態のデータセットだけですでにディスクの大半を埋めていると、処理を完了するための空きブロックが不足し、信頼性の問題になります。

SQLiteのメインデータベースとWALは、チェックポイント処理や圧縮の条件が満たされるまで、割り当てられた容量を保持することがあります。SQLiteのファイル増大に関するパフォーマンス分析では、アプリケーションから見える論理データとは異なる形で、データベースと先行書き込みログが拡大する理由を説明しています。

必要なピーク容量は操作によって異なります。データベースの再構築では、データベースサイズに近い空き容量が必要になることがあります。一方、イメージの更新では、古いレイヤーと新しいレイヤーの両方が一時的に保持される場合があります。Home Assistantのジョブに必要な空き容量に関するZimaSpaceのガイダンスでは、オーバーヘッドの各要素を特定した後の運用上の目安を示しています。

単一のオーバーヘッド比率が通用しないケース

1つの要素が容量の大半を占める場合、固定の割合は役に立ちません。エラーループ中はデバッグログがRecorderを上回ることがあり、ローカルのカメラメディアがすべてのデータベーステーブルをはるかに上回ることもあります。大規模なアドオンが独自のボリュームを拡張したり、長期のバックアップ保持ポリシーによってコピーが稼働中の状態データより大きくなったりすることもあります。ワークロードが変化すれば、昨日の比率も古くなります。

コンテナのディスク枯渇に関するガイドでは、イメージ、書き込み可能なレイヤー、ログ、ボリューム、ビルドキャッシュを分けています。これは、それぞれの増加メカニズムが異なるためです。このDockerストレージ分析にある5項目のインベントリは、全体の合計だけでは容量を支配している要因を特定できない理由を示しています。

この比率は、インストール方式によっても誤解を招きます。Home Assistant OS、コンテナ、仮想マシン、Supervisedホストでは、システムデータの扱いがそれぞれ異なります。同じ条件同士で比較し、Home Assistantのバックアップやランタイムが実際に管理していないメディアや無関係なアプリケーションデータは、計算に含めないでください。

7日間のストレージ増加モデルを作成する

データベースファイル、設定、ログ、バックアップ、アドオンのボリューム、コンテナのイメージとレイヤー、メディア、空き容量について、最初の基準値を1回記録します。保持期間とログ設定を一定にしたまま、代表的な7日間を観察します。各項目を毎日同じ時刻に記録し、アップデート、再起動、バックアップジョブ、異常なエラー、デバイスの追加もメモしてください。

ストレージ管理は、可視化から始まります。ボリューム、イメージ、書き込み可能なレイヤー、キャッシュには、それぞれ異なるライフサイクルがあるためです。このDockerストレージの内部構造に関する記事は、測定した容量を永続的なアプリケーションデータと、ランタイムのパッケージングによるオーバーヘッドに振り分けるのに役立ちます。

各用途について1日あたりの増加量を計算し、それぞれの保持期間を掛けたうえで、観測された最大の一時ピークと復旧用の予備容量を加えます。インテグレーションを追加したり、ログ、メディア、バックアップの設定を変更したりした後は、再度確認してください。この要素別モデルなら、根拠のある容量範囲を算出できます。一律の倍率では算出できません。