Recorderデータが増えると、なぜHome Assistantの履歴クエリは遅くなるのですか？

Home Assistantには、エンティティを追加するたびに速度が低下する、単一の万能な「検索」エンジンがあるわけではありません。より明確なスケーリング上の問題は、過去のクエリ処理です。履歴パネル、ログブックのような表示、統計、その他のデータベースに依存する機能では、保持されているRecorderデータを取得して整理する必要があります。

データセットが大きくなると、リクエストのコストは、一致する行数、どのインデックスで絞り込めるか、属性を結合する必要があるか、どれだけのデータがすでにメモリ上にあるか、ストレージが不足しているページをどれだけ速く読み出せるかによって決まります。データベースのサイズは重要ですが、クエリの形も同じくらい重要です。

履歴はライブの状態マシンだけでなくRecorderから読み込まれる

現在のデバイス値はHome Assistantの実行時状態モデルに保存されています。一方、履歴統合はRecorderに保存された観測値を読み込みます。そのため、現在の温度を表示するダッシュボードカードと、5日間の履歴グラフでは、異なるデータ経路が使われます。

Home Assistantのドキュメントでは、履歴はRecorderに依存し、通常は設定された保持期間内のRecorderの生データを読み取ると説明されています。選択した期間が対象センサーの保持期間を超える場合は、代わりに1時間単位の長期統計を利用できます。

このため、大規模な履歴データベースがあると履歴表示は遅く感じられる一方、ローカルの照明オートメーションは瞬時に反応し続けることがあります。

保持する状態が増えると、行数、メタデータ、インデックス処理も増える

記録される更新のたびに、データベースへ情報が追加されます。Home Assistantは、エンティティ識別子と共有属性を関連テーブルに分けることで重複を減らしていますが、稼働量の多い環境では、それでも大量の状態行が蓄積される可能性があります。

現在のHome Assistantのデータモデルでは、記録された状態がエンティティメタデータと共有属性の行を参照し、履歴クエリで使われるタイムスタンプのインデックスや関連情報を含んでいることが示されています。そのため、変化の激しいエンティティは、人間が読める値の数以上にデータ量を増加させます。

保持期間と更新頻度は互いに作用します。毎秒変化するセンサーは、どちらも「1エンティティ」であっても、1日に2回変化するセンサーとは作業セットが大きく異なります。

インデックスは検索処理を減らすが、結果のサイズに伴うコストをなくすわけではない

SQLiteは、一般的なクエリ条件や並べ替えに対してインデックスを使用し、すべての行をスキャンせずに済ませることができます。これは履歴機能に不可欠ですが、インデックスがあっても、一致する範囲の大量の結果を返したり、関連データを結合したりするコストはなくなりません。

SQLiteのクエリプランナーに関するドキュメントでは、インデックスは検索と並べ替えを高速化する一方、大規模な結果セット、行の参照、ソートには、選択されたデータ量と実行計画に応じた処理が依然として必要になると説明されています。プランナーは、推定コストに基づいて利用可能な経路から選択します。

つまり、「データベースにインデックスがある」ことと、「このクエリが永遠に一定時間で完了する」ことは同じではありません。時間範囲が広くなったり、変化の多いエンティティが増えたりすると、関連するページや行が増える可能性があります。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Recorderの保持期間はパフォーマンスと容量を制御する

Home Assistantは、詳細な状態データが無制限に増え続けないよう、Recorderのデータを自動的に削除します。保持期間を延ばすと、より長い期間の高解像度履歴を利用できますが、稼働中の履歴作業セット、バックアップサイズ、メンテナンス処理も増加します。

Recorderのドキュメントでは、データベースが大きくなりすぎるとディスク容量を消費し、Home Assistantの動作が遅くなる可能性があると明確に警告しています。データベースの増加を抑えるため、デフォルトの削除および再圧縮処理が用意されています。

したがって、適切な保持期間は要件によって決まります。ディスクに空きがあるからという理由だけで保持するのではなく、家庭で実際に確認したい疑問に答えられる期間だけ、高解像度データを保持してください。

ストレージとキャッシュによって、同じクエリの体感コストが変わる

データベースやファイルシステムのページがすでにメモリ上にあるため、同じ履歴リクエストが速く処理されることがあります。再起動後やメモリに余裕がない状況では、より多くの物理読み取りが必要になる可能性があります。同じSSDに対して別のサービスが大量の書き込みを行っている場合も、SQLリクエストを変えずにレイテンシが増加することがあります。

ZimaSpaceによるHome Assistantのメタデータと履歴が増加する原因の分析では、書き込み側の要因が説明されています。クエリパフォーマンスは読み取り側の結果です。保持状態の増加が最も影響するのは、選択した範囲や作業セットが実際にそのデータへアクセスするときです。

データベースを移動したり高速なハードウェアを購入したりする前に、ストレージのレイテンシとメモリ負荷を合わせてクエリ時間を測定してください。

有用な履歴を削るのではなく、不要なデータを減らしてクエリコストを下げる

• 履歴の変化が意思決定に役立たないエンティティを除外する。
• 高頻度の変化が不要な場合は、データの生成元で更新頻度を下げる。
• 生データの保持期間を、ユーザーが実際に確認する期間に合わせる。
• 長期間の確認で1時間単位の集計で十分な場合は、長期統計を使用する。
• Recorderを、空き容量に余裕のある信頼性の高い低レイテンシストレージに置く。
• 変更を行うたびに、同じ履歴範囲で比較する。

有用な指標は、データベースのサイズだけではありません。保持される行数、リクエストした時間範囲、キャッシュの状態、ストレージの状況が変化したときに、クエリのレイテンシがどう変わるかが重要です。

よくある質問

Recorderのデータベースが大きくなると、ローカルオートメーションは自動的に遅くなりますか？

いいえ。ライブデバイスの制御と履歴クエリは別の経路です。Recorderの処理がCPU、メモリ、ストレージを共有するリソースの競合を引き起こした場合は、間接的に互いへ影響する可能性があります。しかし、履歴グラフが遅いからといって、オートメーションエンジンが遅いとは限りません。