データベースの配置がPlexの信頼性と復旧に与える影響

エヴァ・ウォン

IceWhale author

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

How Database Placement Affects Plex Reliability and Recovery

Plexの信頼性は、アクティブなデータベースとメタデータを低レイテンシのローカルストレージに置き、大容量のメディアを別の場所に保存すると、通常は向上します。

Plexサーバーは、大容量HDDやネットワークストレージから映画をストリーミングしながら、アプリケーションデータについては別の経路で多数の小さな読み書きを行えます。この違いが重要なのは、メディアファイルがほぼシーケンシャルデータである一方、ライブラリデータベース、メタデータ、サムネイル、ログはアプリケーションの状態に近い動作をするためです。データベースの配置は、容量の問題ではなく、レイテンシと復旧に関する判断だと考えてください。

Plexのデータベースがメディアファイルと異なる動作をする理由

Plexのデータディレクトリには、ライブラリデータベースに加えて、メタデータ、アートワーク、キャッシュ、その他のサーバー状態が保存されます。これらのファイルは、ブラウジング、スキャン、メタデータ処理、再生状態の更新、メンテナンス中にアクセスされるため、アプリケーションデータの経路でレイテンシの急増が起きると、映画ファイル自体を素早く読み取れる場合でも、サーバー全体の信頼性が低下したように感じられます。

Plexは、頻繁にアクセスされるライブラリの状態をSQLiteデータベースに保持します。そのため、データベースのレイテンシと整合性は、大容量メディアのスループットとは分けて評価する必要があります。これが、データベースの配置と復旧を検討する際の基本です。

観察されるパターンは単純です。ブラウジング、ライブラリの更新、起動が遅い一方で、すでに開いているファイルのDirect Playが問題なく行えるなら、メディアディスクより先にアプリケーションデータの経路を確認すべきです。

スループットだけでなくレイテンシと復旧を測定する

重要な変数は、ランダムI/Oのレイテンシ、ファイルシステムの安定性、空き容量、書き込みの永続性、バックアップの動作です。データベースは大容量の動画ストリームのようには動作しないため、ピーク時のシーケンシャルスループットは二次的な要素です。

データベースの配置と復旧を測定する際は、リソースごとのボトルネック確認で、1つの平均値に頼るのではなく、CPU、メモリ、ネットワーク、ストレージにおける使用率、飽和度、エラーを確認します。

アプリケーションデータを移動したことで、メディア再生のスループットを変えずに起動時間やスキャン時の停止が短くなったなら、メディアストレージではなく、メタデータやデータベースがボトルネックだったと切り分けられます。

高速ストレージの効果がなくなる地点

ローカルSSDでは、CPU負荷が原因のトランスコード、アップロード帯域幅の飽和、クライアントが対応していないコーデック、故障しつつあるメディアディスクの問題は解決できません。データベースのレイテンシが十分に低下し、これらの別の段階が支配的になった後は、アプリケーションデータ用デバイスのIOPSを増やしても効果は次第に小さくなります。

データベースの配置と復旧における障害の境界では、破損が実際に発生している場合、損傷した元のデータベースを繰り返し変更するよりも、復旧可能なデータから新しくクリーンなSQLiteデータベースを作成するほうが安全です。

境界を確認するには、データベースの整合性と空き容量を、症状が発生するタイミングと比較します。整合性に問題がなく、アプリケーションデータのレイテンシも低いなら、再びストレージをアップグレードするのではなく、CPU、ネットワーク、クライアントの互換性、またはメディア経路に調査対象を移してください。

Featured

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

ZimaCube2

4段階の配置テストを実施する

Plexのアプリケーションデータ用経路は永続的なローカルファイルシステムに置き、最新のバックアップを維持し、大容量メディアは別の容量層として扱います。そのうえで、配置を変更する前後に、再現可能なライブラリ操作を1つベンチマークします。コンピュート、アプリケーションデータ、メディアストレージ、ネットワークの役割を分けて記録すると、ホームメディアサーバーのストレージ構成を評価しやすくなります。

データベースの配置と復旧に関する変更を採用する前に、一貫性のあるSQLiteバックアップを、書き込み中のアクティブなデータベースファイルを無制御にコピーするのではなく、安全なバックアップまたはスナップショットのワークフローで作成してください。

再現テストで起動、ナビゲーション、スキャンの動作が変わらなくなったら、データベース用デバイスの最適化を止めます。その時点で次に有用な測定対象は、同じワークロードで依然として時間を消費している段階です。