これについてはすでにいくつかの質問があるかもしれませんが、ほとんどの回答が古いため、最新の回答を得たいと思います。画像、データベース、またはファイルシステムの保存に適しているのはどれですか?
画像はさまざまな拡張子になる可能性があるため、Facebookはデータベースを使用していると思います:| たとえば、次のリンクを参照してください: jpeg jpg png gif
そう思われるかもしれませんが、これは好みの問題ではなく、パフォーマンスの問題です。私は両方の方法を試してきました。現在生きていてキックしているプロジェクトで、開発期間中に教訓を学びました。
ファイルをデータベースに保存することは、展開や保守などが容易なオールインワン セットアップを作成するための優れた方法のように思えるかもしれません。しかし、より大きなファイル (高解像度画像など) になると、読み込み時間が大幅に長くなる可能性があります。
一方、ユーザー アバター、製品のサムネイル、その他のサムネイルなどの小さな画像について言えば、サーバーのファイル システムへの要求が少なくなるため、読み込み速度が向上する可能性があります。この特定のケースでは、それはすべて、持っている可能性のある SQL スキルとクエリの最適化レベルに依存します。
それらだけでなく、多くの画像を含むプロジェクトで私自身がこれまでに使用した提案をします。
おおよそ次の構造で、データベースにテーブルを作成します。
id INT(5) AUTO_INCREMENT PRIMARY KEY
filename VARCHAR(255)
fullsize_path CHAR(255)
image BLOB
mime CHAR(25)
size INT(20)
エラー... おわかりのように、BLOB フィールドは画像が送信される場所です。何かのサムネイルの場合、fullsize_path は空のままではなく、フル サイズの画像へのパスが示されます。
このように、たとえば製品を含むページを表示する場合、すべてのクエリは SQL ベースになりますが、特定の製品にアクセスすると、fullsize_path がブラウザーに兄弟がどこにあるかを伝えます。
もちろん、このようなものを展開する際には他にも心配すべきことがあります。ここでいくつかの概要を説明します。
もちろん、事前にいくつかのパフォーマンス テストを行うことは非常に貴重な練習です。
あなたのウェブサイトの images/ フォルダーなどにファイルを保存することをお勧めします。ファイルの名前を乱数または ID で保存し、その情報をデータベースに保存します。それは両方の素晴らしいコンビでしょう!
Filetableオプションも確認することをお勧めします。プラスはプログラミングモデル(T-SQLとWindows APIを使用可能)と管理(SSMS経由)がシンプルですが、マイナスはデータベースが大きくなることです。このオプションを選択した場合は、ファイルテーブルを専用のファイルグループに配置し、ファイルグループのバックアップを含めるようにバックアップ戦略を調整する必要があります。
もう1つの可能性は、SQL Server 2012 Feature Pack(メイン製品には含まれていません)の一部として出荷されたRBS(リモートBLOBストア)を確認することです。
私は以前に両方のストレージ方法を使用してシステムを作成しましたが、通常はコンテキストによって異なります。
サーバー数が少ない(通常は1台のサーバー)多数のファイルにアクセスするシステムの場合、ファイルへの保存は開発と保守が容易です。
サーバー数が多いシステムの場合、すべてのサーバーがファイルにアクセスする必要があります。時々私はファイルとrsyncでそれを設定しました。また、ファイルをデータベースに保存して、レプリケーションで処理できるようにすることもあります。
Facebookや他のサイトが画像をデータベースに保存する理由は、おそらくそのためです。ファイルをコピーするオーバーヘッドを必要とせずに、多くのサーバーでファイルにアクセスする必要があります。
データベースに画像を保存することは、ファイル システムにデータを保存するよりも安全です。しかし、パフォーマンスに関しては、イメージをファイル システムに格納する方がはるかに効率的です。要件に応じて最善の方法を選択する必要があります。