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への過剰な書き込み、長い保持期間、遅い履歴クエリ、限られたローカル容量、または1つのサービスを独立して復旧する必要性のどれなのかを確認してください。

データベースサーバーを追加する前にRecorderを調整する

Recorderの増加量は、保存するエンティティとイベント、変化の頻度、履歴の保持期間によって決まります。ノイズの多いセンサーや不要なドメインが書き込みの大部分を占めている場合、同じ負荷をより大きなデータベースサーバーへ移しても、問題の場所が変わるだけで解決にはなりません。

最新のRecorder調整ワークフローでは、データベース移行を検討する前に、保持期間、include/excludeルール、コミット動作が書き込み負荷に与える影響を確認する方法を説明しています。調整後に、データベースサイズ、履歴クエリ時間、ストレージのレイテンシー、書き込みアクティビティを測定してください。

調整後の負荷で応答性が維持され、バックアップがメンテナンス時間内に完了し、利用可能な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	多くの場合、レイテンシーより容量が重要
バックアップ	少なくとも1つのホスト外コピー	アクティブなホストの喪失に耐える

分離を恒久化する前に、起動、障害、復元を実証する

古い復旧経路を削除せずに、新しいデータベースまたはストレージの役割を段階的に導入してください。Home Assistantより先にデータベースホストを再起動する、データベースの準備が整う前にHome Assistantを再起動する、ネットワークを切断する、認証情報をローテーションする、対象ファイルシステムを予備容量のしきい値近くまで埋める、クリーンなインスタンスにデータベースを復元するといったテストを行います。

95パーセンタイルの履歴クエリ時間、Recorderの高負荷時におけるオートメーションのレイテンシー、再起動時間、バックアップ所要時間、データベースホストの停止後の復旧時間を測定してください。分離によって1つの指標が改善しても、30秒のコントローラー再起動が複数サービスにまたがる復旧手順に変わるなら、その運用コストを判断に含めます。

ローカルストレージがすでに目標を満たしているなら、そのまま使用してください。クライアントサーバー型データベースの処理と独立した復旧が実際のメリットになる場合は、別のデータベースホストを使用します。大量データとバックアップには別のストレージホストを使用できますが、検証済みの理由なしに、重要なローカル制御をリモートファイルシステムに依存させないでください。