Jellyfin、そのデータベース、メタデータ、トランスコードキャッシュ、メディアライブラリを1台のSSDに置く方法はシンプルで、非常に高速になる場合があります。アプリケーションの状態と大容量メディアを異なる物理ドライブに分離すると複雑さは増しますが、パフォーマンス、障害、バックアップ、容量に関する境界を明確にできます。
この比較は「SSD対HDD」ではありません。どちらの構成でもSSDを使用できます。問題は、1台のストレージデバイスにすべての役割を担わせるか、それともJellyfinの小容量でレイテンシーに敏感な状態を、はるかに大容量のメディア層から分離するかです。
小規模なライブラリなら、シンプルさで1台のSSDが有利
十分な容量のあるSSDを1台使えば、OS、Jellyfinデータベース、メタデータ、キャッシュ、トランスコード、一元化されたメディアをすべて同じ低レイテンシーのデバイスに置けます。マウントポイントやケーブルが少なく、メディアディスクのスリープ解除による遅延もなく、コンテナ定義もシンプルです。
小規模なライブラリと控えめな書き込み負荷であれば、最新のSSD 1台で十分なIOPSとシーケンシャル帯域幅を確保でき、キューの競合がユーザーに見えることはないでしょう。主なトレードオフは、テラバイトあたりのコストと、物理的な単一障害ドメインです。
データセット全体を経済的にバックアップでき、将来の増加によって高額な一括交換を迫られない場合は、1台のドライブが適しています。
アプリケーション状態のレイテンシーを独立させたい場合は、分離したドライブが有利
Jellyfinのデータベースとメタデータでは、多数の小さな読み書きが発生します。一方、メディア再生では主に大きなシーケンシャルファイルを読み取ります。バックアップ、インポート、ダウンロード、メディア分析、生成アセットによって、さらに混在したI/Oが発生することもあります。
Jellyfinでは、永続ストレージと一時ストレージの役割を分けられます。現在の設定ドキュメントでは、データ、設定、キャッシュ、ログ、その他のサーバーパスが区別されています。物理デバイスを分けることで、大量のメディアコピーや再構築によって、レイテンシーに敏感なアプリケーション状態と同じデバイスキューが共有されるのを防げます。
ZimaSpaceのJellyfinデュアルストレージ構成では、実際の導入方法を紹介しています。この比較では、両方の層が高速な場合でも、分離が有用な理由に焦点を当てます。
デバイスを分けると障害ドメインが小さくなる
SSDを1台だけ使う場合、そのデバイスが故障すると、同時にJellyfinのアプリケーション状態とメディアが失われます。バックアップから両方を復元できますが、復元範囲は大きくなります。
デバイスを分けておけば、アプリケーションデータ用SSDが故障しても、比較的小容量のバックアップから復元でき、メディアボリュームはそのまま維持できます。メディアドライブが故障した場合も、Jellyfinのデータベースやユーザー情報を上書きすることなく再構築または交換できます。
これは冗長化ではありません。どちらのドライブも故障する可能性があり、独立したバックアップも引き続き必要です。利点は、1回の故障であらゆるストレージの役割が自動的に同時消失するわけではないことです。
役割を分けるとバックアップ範囲を効率化できる
Jellyfinのアプリケーション状態は頻繁に変化しますが、容量は比較的小さいものです。数テラバイトのメディアライブラリはゆっくり変化することが多く、元のディスクや別のアーカイブから再取得できるコンテンツが含まれている場合もあります。
デバイスを分けることで、異なるスケジュールを設定できます。アプリケーション状態は頻繁にバックアップし、メディアの保護はより低頻度に行い、トランスコードキャッシュには別の一時データポリシーを適用できます。SSDを1台だけ使う場合でも、バックアップツールでフォルダーを除外することは可能ですが、物理容量と障害の境界は分離されません。
小規模なシステムでは、1台のSSDのほうが高速な場合もある
2台目のデバイスを追加しても、自動的にパフォーマンスが向上するわけではありません。小規模なライブラリを高速なNVMe SSDに置く構成は、メディア層が低速だったり、性能の低いUSBブリッジを経由していたりする分離構成より高速な場合があります。
分離のメリットが現れるのは、同時実行するワークロードが競合するとき、メディアの増加が容量の大部分を占めるとき、または復旧範囲が重要なときです。ストレージの分離が必要だと判断する前に、ダッシュボードの閲覧、ライブラリスキャン、再生開始、大容量メディア転送を同時に実行してテストしてください。
増加と復旧の観点で構成を比較する
| 項目 | 1台のSSD | アプリ+メディア用の分離ドライブ |
|---|---|---|
| 導入のシンプルさ | 最も優れている | マウントとデバイスが増える |
| ランダム/シーケンシャルI/Oの分離 | キューを共有 | デバイスごとに独立したキュー |
| 障害ドメイン | アプリとメディアが同時に故障 | 役割ごとに独立して故障 |
| 容量のアップグレード | 統合された層を交換または拡張 | メディアを個別に増設 |
| バックアップポリシー | 論理的な除外が必要 | 物理的な役割とバックアップ範囲が一致 |
| 小型で静音のサーバー | 非常に適している | 必要以上にハードウェアが増える |
シンプルさ、静音性、コンパクトさを重視し、作業データ全体が1台のデバイスの容量とバックアップ計画に十分収まる場合は、1台のSSDを選びましょう。メディアの増加、混在I/Oの競合、独立した復旧、または低コストな大容量ストレージのメリットによって追加デバイスの価値が得られる場合は、役割を分離してください。
よくある質問
アプリケーション用ドライブとメディア用ドライブを分けると、Jellyfinは必ず高速になりますか?
いいえ。分離が役立つのは、ワークロードが競合する場合や、ストレージの役割ごとにレイテンシーと容量の要件が異なる場合です。十分な余裕のある高速なSSD 1台でも、小規模なJellyfinライブラリには十分対応できます。
製品比較
もっと読む

Home Assistantは家中のデバイス制御でopenHABを置き換えられますか?
Home Assistant が openHAB に取って代われるのは、すべての必須デバイスと自動化について、並行移行テストとロールバックテストに合格した場合に限ります。

Home AssistantにはミニPC、シングルボードサーバー、NASのどれが適しているか
小型で効率的なアプライアンスにはSBCを、柔軟な余裕が必要ならミニPCを選び、共有ホスト運用がすでに成熟している場合にのみNASを選択してください。

専用のHome Assistantサーバーと共有アプリホストの選び方
障害の切り分けをシンプルにするなら専用ホスティングを選び、分離性、メンテナンスウィンドウ、復旧性が実証されているなら共有ホストを選びましょう。

