JellyfinのメタデータをSSDに、大容量データをHDDに保存すべき？

エヴァ・ウォン

IceWhale author

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

Should You Put Jellyfin Metadata on SSD and Bulk Data on HDD? - Zima Store Online

ライブラリの閲覧、スキャン、またはトランスコードで遅延が発生する場合は、Jellyfinのデータベースと頻繁に更新されるキャッシュをSSDに配置し、読み取りが安定している場合は大容量メディアをHDDに置いておきます。

閲覧が遅い、最初のフレームの表示が遅れる、または大容量ファイルの再生時だけ問題が発生していませんか？何かを移動する前に、アプリケーションの状態、キャッシュ、メディア、バックアップの役割を分けて考えましょう。すべてのデータを高速化することが目的ではありません。それぞれの役割に必要なレイテンシーと耐久性を与えることが目的です。

観測した挙動に基づいてデータベースとキャッシュを配置する

Jellyfinの設定、データベース、メタデータのインデックス、ログでは、小さな読み書きが頻繁に発生します。トランスコード用の一時領域や画像生成も更新頻度が高い処理です。ディスクキューやレイテンシーが症状と相関している場合は、これらの役割をローカルSSDに移します。完全なスキャンと、同時に実行する最大数のトランスコードに対応できる十分な空き容量を確保してください。

役割を移動した後は、設定されたパス、所有者、空き容量、および再起動を確認します。JellyfinのキャッシュとメタデータをNFSに移動したコミュニティ事例は、ネットワーク経由のパスをローカルストレージと同等だと決めつけず、レイテンシーと永続性をテストする必要がある理由を示しています（キャッシュ配置の事例）。

コンテナの再作成と再起動の後にデータベースのパスを確認し、サービスが小さな状態変更を書き込めることを確認します。パスが元に戻る場合は、マウントまたは環境変数のマッピングが永続化されていません。

読み取りに問題がなければ、大容量メディアを容量重視の階層に置く

映画や番組は主に大容量のシーケンシャル読み取りなので、Direct Playや通常のトランスコードにはHDDで十分な場合があります。マウントされている各ライブラリから1つずつファイルをテストし、リモートファイルや高ビットレートのファイルも含めて確認してください。HDDのスピンアップや共有ネットワークマウントが再生を遅らせる場合は、より高速なデータベース用ディスクを購入する前に、マウントのタイミングを修正するか、ストレージパスを分離します。

移動の前後で、最初のフレームが表示されるまでの時間とライブラリの閲覧速度を比較します。測定した遅延が改善し、バックアップ経路の信頼性も低下しない場合にのみ、SSDへの配置を維持してください。

キャッシュをネットワークマウント上に置く場合は、コールドスタートと一時的なNAS停止をテストします。起動時に共有が利用できる場合にしか動作しない構成は、信頼できるアプリケーションパスではありません。