画像の保存：DB またはファイル システム -

Question

この点に関していくつかの投稿を読みましたが、私の場合の最善の解決策がまだわかりません。

新しい WebApp の作成を開始しており、バックエンドは約 100 ～ 1000 万の画像. 。（平均サイズ 200-500kB 単一の画像の場合)

私のサイトはコンテンツと画像を提供します 100 ～ 1000 ユーザー 同時に。

また、プロバイダーのコストをできるだけ低く抑えたいと考えています (ただし、これは二次的な要件です)。DB サイズのコストと比較すると、ファイル システムのスペースの方が安価であると考えています。

個人的には、すべての画像を DB に保存するというアイデアが気に入っていますが、提案があれば大歓迎です :)

私の場合、DB アプローチが正しい選択だと思いますか?

Answer 1

これらの画像をすべてデータベースに入れると、非常に大きくなります。これは、代わりにホットアプリケーションデータをキャッシュする可能性があるときに、DBエンジンがすべてのイメージ（実際には設計されていないタスク）のキャッシュでビジー状態になることを意味します。

ファイルキャッシュをOSやリバースプロキシに任せる-彼らはそれでうまくいくでしょう。

Answer 2

ファイルシステムに画像を保存するその他の理由：

• 画像サーバーは、データベースがビジーまたはダウンしている場合でも実行できます。
• ファイルシステムは、ファイルを保存するために作成されており、非常に効率的です。
• データベースにデータをダンプすると、バックアップやその他の操作が遅くなります。
• イメージを提供するのにサーバー側のコーディングは不要で、単純な古いIIS / Apache
• ダート安いWebサーバーを使用するか、潜在的にCDNを使用すると、より迅速にスケールアップできます。
• データベースを使用せずに、関連する作業（サムネイルの生成など）を実行できます。
• データベースサーバーは、より多くの＆quot; real＆quot;を保持できます。クエリのデータベース速度を取得するメモリ内のテーブルデータ。貴重なメモリを使用して画像ファイルのキャッシュを保持している場合、メモリに多くの写真インデックスを持っているのと比べて、速度に関してほとんど何も買えません。

Answer 3

ほとんどの大規模サイトはファイルシステムを使用しています。

写真をファイルとして保存またはWebアプリのデータベースにありますか？

Answer 4

バイナリオブジェクトを扱うときは、PDFや画像などのドキュメントをデータベースに保存せずに、ドキュメント中心のアーキテクチャのアプローチに従ってください。データベースであらゆる種類のパフォーマンスの問題が発生し始めたら、最終的にリファクタリングする必要があります。ファイルをファイルシステムに保存し、データベースのテーブル内にパスを入れるだけです。また、シリアル化してデータベースに保存するために使用するデータ型のサイズには物理的な制限もあります。ファイルシステムに保存してアクセスするだけです。

Answer 5

最初の文は、このテーマに関するいくつかの投稿を読んだことを示しているので、これをカバーする記事へのリンクを挿入することはありません。私の経験では、画像の数と画像のサイズに関する投稿に基づいて、それらをDBに保存する場合、DBのパフォーマンスに大きな負担をかけることになります。ファイルシステムに保存します。

Answer 6

どのようなデータベースを使用していますか?MS SQL Server 2008 は FILESTREAM ストレージを提供します

SQL Server 2008 と NTFS ファイル システムを組み合わせて使用​​すると、BLOB データの保存と効率的なアクセスが可能になります。BLOB ストレージの選択、FILESTREAM データを使用するための Windows と SQL Server の構成、FILESTREAM と他の機能を組み合わせる際の考慮事項、パーティション分割やパフォーマンスなどの実装の詳細について説明します。

詳細

Answer 7

イメージング用に最適化されたサーバーであるFileNetを使用します。とても高価です。安価なソリューションは、ファイルサーバーを使用することです。

データベースサーバーに大きなファイルを保存することは考えないでください。

他の人が述べたように、データベースに大きなファイルへの参照を保存します。