なぜデータベースファイルとメディアファイルはホームNASで異なる動作をするのか?

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

ホームNAS上では、データベースファイルとメディアファイルは異なる動作をします。データベースは可変のページの集合であるのに対し、メディアファイルは通常安定したバイトストリームだからです。

データベースは小さなランダム読み取りを行い、リカバリログを追記し、インデックスを更新し、耐久性のあるコミットを待ちます。一方、メディア再生は順序通りに長い範囲を読み取り、先読みバッファリングを行います。両者は同じギガバイト数を占有していても、レイテンシー、キャッシュ、ファイルシステムの記録、ディスクキューに対して非常に異なる負荷をかけます。

データベースファイルは可変ページ、メディアファイルは安定したストリーム

データベースエンジンはファイルを構造化されたページとして扱います。あるクエリは狭いインデックスページを取得し、次に無関係な複数のデータページにジャンプします。更新はデータ、インデックス、トランザクションログ、後にはチェックポイントに影響を与えます。データベースI/Oパターンの簡潔な概要は、同じエンジン内でログとデータファイルが異なるレイテンシープロファイルを持つ理由を説明しています。

完成した映画や音楽ファイルは再生中に通常変更されません。リーダーは長い範囲を進み、過去のバイトを書き換える必要はほとんどありません。この予測可能性により、OSやストレージデバイスはリクエストをまとめて先読みを行えます。

耐久性がデータベース書き込みを待機させる

多くのデータベースはライトアヘッドログ(WAL)を使用します。変更記録は、修正されたデータページが安全にコミットされたと見なされる前に安定したストレージに到達しなければなりません。ライトアヘッドログのシーケンスは、帯域幅が小さくても小さな連続ログ追記がクリティカルパスに入る理由を示しています。

チェックポイントは後で汚れたページをバッチでフラッシュし、2つ目のI/Oパターンを追加します。つまり、データベースは短いfsync感度のコミットと重いバックグラウンド書き戻しを交互に行います。SSDは両方を改善するかもしれませんが、メディアのスループット数値はデータベースの応答時間を予測しません。なぜならデータベースはしばしばメガバイト毎秒ではなく完了レイテンシーを待つからです。

メディア再生は先読みと範囲アクセスを活用する

連続検出によりカーネルはプレーヤーの要求前にデータを取得できます。NFSの例では、ネットワークファイルシステムの先読みを増やすことで大きな連続ファイルのスループットが大幅に向上しましたが、著者は過剰な先読みが半ランダムアクセスで無駄な作業を生むと警告しています。

プレーヤーは開始時やシーク時に選択したバイト範囲を要求することもあります。ビデオ範囲リクエストの実用的な説明は、クライアントが大きなファイルの一部にジャンプし、前の部分をすべてダウンロードせずに済む仕組みを示しています。これらのリクエストはデータベースのインデックスウォークよりも大きく予測可能で、両者ともネットワーク経由で届く場合でも同様です。

特性 データベースファイル メディアファイル NASへの影響
読み取りパターン キャッシュミス時は小さくランダム 長い連続範囲 レイテンシー対スループット
書き込みパターン ログ、ページ更新、チェックポイント 通常は一度書き込み、多数回読み取り 異なる書き込み増幅
耐久性 コミットは安定ストレージを待つ場合あり 再生はバッファリングを許容 fsyncレイテンシーは主にデータベースに影響
キャッシュの価値 小さなホットセットは頻繁に再利用される 大きなスキャンは一度だけ使用される メディアがデータベースページを追い出すことも

メディアライブラリもデータベースのような副次的作業を生む

メディア本体は連続的でも、その周囲のライブラリはそうではありません。ポスター、サムネイル、字幕、視聴履歴、検索インデックス、メタデータデータベースは小さなファイルやデータベースの活動を生み出します。スキャンはすべてのメディアヘッダーを読み取りながら、数千の小さな派生ファイルを書き込みます。

これが、再生はスムーズでもライブラリの閲覧やサムネイル生成が遅く感じられる理由です。大きなファイルのパスは健全ですが、サイドカーのデータベースはランダムI/Oや混雑したジャーナルを待っています。単一の映画コピーだけをテストすると、実際のユーザーの作業負荷を見逃します。

1台のNASで両方を提供できるが、ボトルネックは変わる

プラットフォームが対応していれば、ワークロード別のデータセットやボリュームを使いましょう。大きなレコードと先読みは安定したメディアに適し、データベースストレージは低レイテンシー、適切なページアラインメント、保守的なキャッシュ、信頼できる同期書き込みが有利です。メディアスキャンが繰り返しデータベース作業を停滞させる場合は、物理的に分けたプールがより強い分離を提供します。

ファイル拡張子だけで調整しないでください。データベースのコミットレイテンシーやキャッシュミスをメディアの読み取りスループットやバッファリングと並べて測定しましょう。最新の先読みチューニング比較は境界を明確にし、連続バックアップやビデオワークロードは大きな先読みで恩恵を受ける一方、ランダムなデータベースアクセスは無差別なポリシー適用で帯域を浪費する可能性があると示しています。

よくある質問

高速な連続NASベンチマークはデータベースの高速性を証明しますか?

いいえ。これはメディア転送に近いワークロードを測定しています。データベースの性能はランダムIOPS、キューイング、fsyncレイテンシー、キャッシュ挙動、チェックポイント干渉に大きく依存します。

メディアファイルとデータベースファイルは常に別々のSSDを使うべきですか?

必ずしもそうではありません。軽いワークロードなら共存可能です。スキャン、トランスコード、転送が繰り返しデータベースのレイテンシースパイクを引き起こし、スケジューリングやデータセットポリシーで制御できない場合に分離が有効になります。

再生はスムーズなのにメディア閲覧が遅くなるのはなぜですか?

閲覧はしばしばデータベースをクエリし、多数のサムネイルやサイドカーを開きます。再生は通常、いくつかの長い範囲を読み取り先読みするため、ストレージ経路の異なる部分に負荷をかけます。

テック&AIハブ

もっと読む

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.