database - 少数の画像を保存する: blob または fs?

Question

ユーザーが自分のプロフィール写真をアップロードできるように、サイトにいくつかの機能を追加しているので、データベースに BLOB として保存するか、ファイル システムに配置するかを考えていました。

私はここでこれに似た質問を見つけました: Storeing images in DB: Yea or Nay .おそらく 150x150 ピクセル)、および少数のそれらの数: おそらく最大 1000 または 2000 です。

このシナリオでの DB BLOB とファイルシステムの違いについてどう思いますか? クライアントは、DB からのイメージとファイルシステムからのイメージをどのようにキャッシュしますか?

DB に保存されている BLOB が最適な場合 -それらを保存する場所について知っておくべきことはありますか? 大多数のユーザーは写真をアップロードしないと思うので、必要に応じuser_picsて通常のusersテーブルに (外部) 結合するテーブルを作成する必要がありますか?

---

編集：リンク先の2つの重複ではないため、この質問を再開します。この質問は、特に少数の画像に DB または FS を使用することの長所/短所に関するものです。上で述べたように、もう 1 つの質問は、何千もの大きな画像を保存する必要がある人を対象としています。

Answer 1

あなたの質問の一部に答えるには：

クライアントは、DBからの画像とファイルシステムからの画像のキャッシュをどのように処理しますか？

データベースの場合：データベースにlast_modifiedフィールドがあります。クライアントのブラウザが適切にキャッシュできるように、Last-ModifiedHTTPヘッダーを使用します。ブラウザが「新しい場合」の画像を要求するときは、必ず適切な応答を送信してください（画像の名前を思い出せません。HTTP要求ヘッダーがあります）。

ファイルシステムの場合：同じことを行いますが、ファイルの変更時刻を使用します。

DBに格納されているBLOBが進むべき道である場合、それらを格納する場所について知っておくべきことはありますか？私のユーザーの大多数は写真をアップロードしないと思いますが、必要に応じて通常のユーザーテーブルに（外部で）参加するためにuser_picsテーブルを作成する必要がありますか？

BLOBと関連するメタデータを独自のテーブルに配置し、BLOBとユーザーテーブルの間に何らかの関係を持たせます。これを行うと、データのテーブルストレージ方法を最適化するのが簡単になり、物事が整頓され、拡張性の余地が残ります（たとえば、一般的な「ファイル」テーブル）。

Answer 2

私はかつて、PDFファイル用の小さなDMSで同様の質問に直面しました。シナリオはあなたのシナリオとは異なりました。最大で100ファイル、それぞれ最大10 MBのサイズで、プロフィール写真に期待するものではありません。しかし、友人が私に返した答えは、あなたのケースにも当てはまります。

各ストレージシステムを使用して、設計されていることを実行します。

データベースにデータを保存します。ファイルシステムにファイルを保存します。

これは最終的な答え（*）ではありませんが、初心者にとっては良い経験則です。

Aaron Digullaが彼の答えで述べているように、Windows FSが遅く、時には信頼できないことを聞いたことがありません。そのような問題がある場合、これは確かに考慮に入れる必要があります。しかし、アバターの写真の場合、それは私にとってそれほど重要ではありません。

（*）わかっている、わかっている、42..。

Answer 3

DB は、レイテンシー、トランザクションなどに対して最適化されています。

イメージ ストレージは、読み取りレイテンシ、ストレージ コストなどに対して最適化されています。

ブロブ ストアは、何百万もの画像を格納するのに理想的です。私は SeaweedFS に取り組んでいます。これは、ユーザーの写真を保存するための Facebook の設計に基づいていました。

Answer 4

それらを提供する、それらを提供するためのコードを書く、バックアップ手順などの観点から、より便利なものは何でしょうか？あなたは他の誰かのための正しい答えではなく、あなたのための正しい答えを望んでいます。

Answer 5

私はそれらをデータベースに保存します：

1. バックアップ/復元は簡単です（ファイルとデータベースもバックアップする場合、ポイントインタイムリカバリはより複雑になります）
2. データベース内のトランザクションは、そこにないファイル名を指さしてしまうことは決してないことを意味します
3. 誰かが危険な画像アップロードハックを介してサーバーにスクリプトを配置する卑劣な方法を理解する可能性は低くなります

少数の画像について話しているので、リンクされた質問で議論されているパフォーマンスの問題よりも、使いやすさ/管理を優先する必要があります。

Answer 6

私の観点からは、データベースの外に残される可能性のあるものはすべて外にとどめるべきです。毎日複製またはバックアップしないファイルシステムまたは個別のテーブルである可能性があります。これにより、データベースが大幅に軽量化され、成長が遅くなり、理解と保守が容易になります。

MSSQL を使用している場合は、ブロブが別のデータ ファイルに保存されていることを確認してください。他のすべてのようにプライマリではありません。

Answer 7

それらをデータベースに格納すると、管理しやすいという利点があると思います。それらは他のデータと一貫してバックアップおよび復元できます-古いものを削除することを忘れることはありません（そうかもしれませんが、可能性は少し低いです）。データベースを別のマシンに移行すると、イメージは一緒に移動しますそれ。

Answer 8

Windows では、できるだけ多くのデータをデータベースに入れます。ファイルシステムはやや遅く、信頼できない場合さえあります。

Linux では、より多くのオプションがあります。ここでは、大きなファイルをファイル システムに移動し、名前を DB に保持することを検討する必要があります。Ext3 や ReiseFS などの最新のファイルシステムを使用すると、非常に優れたパフォーマンスで多数の小さなファイルを作成することもできます。

また、データへのアクセス方法も考慮する必要があります。DB にすべてがある場合、1 つのアクセス パスがあり、別のアクセス許可のセットについて心配する必要はありませんが、BLOB の読み取り/書き込みの余分な複雑さに対処する必要があります。多くの DB では、BLOB を検索できません。

ファイルシステムでは、ファイルが DB に保存されている場合は不可能な、データに対して他のツールを実行できます。