database - アップロードされた画像、SQL データベース、またはディスクファイルシステムを保存するのに最適な場所はどれですか?

Question

ユーザーがサーバーに画像をアップロードできるようにするアプリケーションを作成しています。1 日あたり約 20 枚の画像がすべて jpeg で、おそらく編集/サイズ変更されていないと予想しています。（これは別の質問です。保存する前にサーバー側で画像のサイズを変更する方法です。誰かがそのための.NETリソースをコメントなどにドロップしてください）。アップロードした画像を保存するのに最適な場所はどこだろうか。

イメージをファイルとしてファイルシステムに保存し、そのイメージへの正確なパスを含むテーブルにレコードを作成します。
または、データベースサーバーの「イメージ」または「バイナリデータ」データ型を使用して、イメージ自体をテーブルに格納します。

どちらにも長所と短所があると思います。a) が好きなのは、ファイルを簡単に再配置でき、テーブルエントリを変更するだけでよいからです。一方で、Web サーバーにビジネスデータを保存するのは好きではなく、ビジネスデータを保持する他のデータソースに Web サーバーを接続したくありません (セキュリティ上の理由から) b) すべての情報がクエリで簡単にアクセスできます。一方、データベースはすぐに非常に大きくなります。そのデータをアウトソーシングすることは、より困難になる可能性があります。

score 105 · Accepted Answer

例外もありますが、私は通常、ファイルシステムにファイルを保存します。ファイルの場合、ファイルシステムが最も柔軟でパフォーマンスの高いソリューションです (通常)。

データベースにファイルを保存する際には、いくつかの問題があります。ファイルは通常、平均的な行よりもはるかに大きくなります。多数の大きなファイルを含む結果セットは大量のメモリを消費します。また、書き込みにテーブルロックを使用するストレージエンジン (ISAM など) を使用している場合、そこに保存しているファイルのサイズ/レートに応じて、ファイルテーブルが頻繁にロックされる可能性があります。

セキュリティに関しては、通常、ドキュメントルートの外部にあるディレクトリ (http 要求ではアクセスできない) にファイルを保存し、最初に適切な承認を確認するスクリプトを使用してファイルを提供します。

score 51 · Accepted Answer

オプション B の唯一のメリットは、すべてのデータを 1 つのシステムに格納できることですが、これは誤ったメリットです。あなたのコードもデータの形式であり、したがってデータベースにも保存できると主張するかもしれません - どう思いますか?

あなたがいくつかのユニークなケースを持っていない限り：

ビジネスロジックはコードに属します。
構造化データはデータベースに属します (リレーショナルまたは非リレーショナル)。
バルクデータはストレージ (ファイルシステムまたはその他) に属します。

ファイル、コード、データ

ファイルを保持するためにファイルシステムを使用する必要はありません。代わりに、クラウドストレージ ( Amazon S3など) またはその上でサービスとしてのインフラストラクチャ ( Uploadcareなど) を使用できます。

https://uploadcare.com/upload-api-cloud-storage-and-cdn/

しかし、データベースにファイルを保存するのは悪い考えです。

score 23 · Accepted Answer

私はこれが古い投稿であることを知っています。しかし、このページへの多くの訪問者は、質問に関連するものを何も得ていません. 特に初心者の場合。

当社のウェブサイトに画像やファイルをアップロードして保存する方法:

静的な Web サイトの場合、一部の共有ホスティングのファイルストレージはまだ十分であるため、問題はないかもしれません。この問題は、動的な Web サイトが大きくなると発生します。データベースは大きい方が扱えますが、画像などのファイルが大きいのが問題になります。Web サイトには 2 種類の画像があります。

画像は動的ブログの管理者から提供されます。通常、これらの画像はアップロード前に最適化されています。
ユーザーがアバターなどの画像をアップロードすることを許可されている場合のユーザーからの画像。または、ユーザーがブログコンテンツを作成し、テキストエディターからいくつかの画像を挿入することもできます。この種の画像は、サイズを予測するのが困難です。ユーザーは、ビューのサイズを変更することで小さなコンテンツ用に大きな画像をアップロードできますが、画像のサイズを変更することはできません。

項目番号を無視して。上記の 1、項目番号の迅速な解決策。2. ウェブサイトに画像最適化機能がない場合は、次のヒントで一時的に解決できます。

ユーザーを画像ギャラリーにリダイレクトして、ユーザーがテキストエディターから直接アップロードできるようにしないでください。このページでは、コンテンツに埋め込む前に、ユーザーは事前にファイルをアップロードする必要があります。このメソッドは、ファイルマネージャーと呼ばれます。
ユーザーが画像をアップロードするには、画像のトリミング機能を使用します。これにより、ユーザーが非常に大きなファイルをアップロードしても画像サイズが制限されます。最終的な画像は、トリミングされた画像の結果です。サーバー側でサイズを定義し、たとえば 500Kb 以下のみを受け入れることができます。

今、それは一時的なものです。最終的な解決策については、質問が繰り返されます。

大きな画像ストレージを処理するには?
拡張子をサイズ変更または変更します。
大規模または中規模の Web サイトまたは e コマースは、画像のファイルストレージをどのように処理しますか?

次にできること：

共有ホスティング VPS から移行します。十分ではない？その後、Dedicated にアップグレードすることでさらに高くなります。
ファイルストレージ用の独自のサーバーを作成します。それを行うためにグーグル。これはあなたが思うほど難しくありません。ウェブサイトのためにそれを行う人もいます。
簡単な方法は、CDN ファイルストレージサービスを使用することです。

さて、1と2は少し高価です。しかし、No 3 が最善の解決策だと思います。

一部の CDN サービスでは、必要な数の Web ファイルを保存できます。

質問「当社の Web サイトから CDN にファイルをアップロードするにはどうすればよいですか?」

通常は無料で登録すると、ファイルをアップロードする方法と、Web サイトから/へのリンクを取得する方法についてのガイダンスが表示されます。API などを取得します。それは簡単です。

一部のプロバイダーは、ストレージと帯域幅が制限された 14 日間の無料サービスを提供しています。しかし、それは出発点としては問題ありません。唯一の問題は、「人々は決して挑戦しない」からです。

初心者に役立つことを願っています。

score 13 · Accepted Answer

いくつかの異なるバックエンドでオプション B (データベースストレージ) を要求するクライアントが何度かありましたが、最終的には常にオプション A (ファイルシステムストレージ) に戻ることになりました。

このような大きな BLOB は、私たちが試した最新の SQL Server 2005 でも十分に処理されていません。

具体的には、深刻な肥大化が見られ、おそらくロックの問題だと思います。

もう 1 つの注意点: NTFS ベースのストレージ (Windows サーバーなど) を使用している場合は、何千ものファイルを 1 つのディレクトリに配置する方法を見つけることを検討してください。理由はわかりませんが、ファイルシステムがその状況にうまく対応できない場合があります。誰かがこれについてもっと知っているなら、私はそれを聞きたいです.

しかし、私は常にサブディレクトリを使用して物事を少し分解しようとしています。多くの場合、作成日はこれに適しています。

画像/2008/12/17/.jpg

...これにより、適切なレベルの分離が提供され、デバッグ中にも少し役立ちます。エクスプローラーと FTP クライアントは、本当に巨大なディレクトリがある場合、少し詰まる可能性があります。

編集: 2017 年の簡単なメモですが、SQL Server の最近のバージョンでは、私が説明した欠点を回避するはずの多くの BLOB を処理するための新しいオプションがあります。

編集: 2020 年の簡単なメモ、AWS/Azure/etc の Blob Storage も、何年も前からオプションになっています。これは安価であり、多くの場合、展開、複数サーバーへのスケーリング、必要に応じた他の環境のデバッグなどに関する特定の問題を単純化できるため、多くの Web ベースのプロジェクトに最適です。

score 12 · Accepted Answer

最近、PDF/Word ファイルを MySQL テーブルに格納する PHP/MySQL アプリを作成しました (これまでのところ、ファイルあたり 40MB の大きさです)。

長所：

アップロードされたファイルは、他のすべてのものと一緒にバックアップサーバーに複製されます。個別のバックアップ戦略は必要ありません (安心してください)。
uploads/ フォルダーを用意して、すべてのアプリケーションにその場所を伝える必要がないため、Web サーバーのセットアップは少し簡単になります。
編集にトランザクションを使用してデータの整合性を改善できるようになりました - 孤立したファイルや欠落したファイルについて心配する必要はありません

短所：

テーブルの 1 つに 500MB のファイルデータがあるため、mysqldump には非常に長い時間がかかります。
ファイルシステムと比較すると、全体的にメモリ/CPU効率があまり良くありません

私の実装は成功と言えます。バックアップ要件を処理し、プロジェクトのレイアウトを簡素化します。アプリを使用する 20 ～ 30 人のユーザーにとって、パフォーマンスは問題ありません。

score 10 · Accepted Answer

画像のサイズを必ず変更し、可能であれば形式を確認してください。悪意のあるファイルがアップロードされ、無意識のホストによって提供されるケースがありました。たとえば、GIFAR の脆弱性により、GIF ファイルに悪意のある Java アプレットを隠すことができ、現在のコンテキストで Cookie を読み取って送信することができます。クロスサイトスクリプティング攻撃の別のサイト。通常、画像のサイズを変更すると、埋め込まれたコードが変更されるため、これを防ぐことができます。この攻撃は JVM パッチによって修正されていますが、スクラブせずに単純にバイナリファイルを提供すると、さまざまな脆弱性が発生する可能性があります。

ほとんどのウイルススキャナーはファイルシステムに対してのみ実行できることに注意してください。バイナリを DB に保存すると、それらに対してスキャナーを簡単に実行することはできません。

score 8 · Accepted Answer

これは基本的に私がやっています。

アップロードされた画像を一時ディレクトリまたはメモリに保存します。
永久に保存する前に、その画像を処理します。2.1. 色補正 2.2. 2.3を圧縮します。画像の寸法に基づいていくつかのコピーを作成します 2.4. .xl、.lg、.md、.sm などのサフィックスを付けて名前を変更します
処理されたすべての画像ファイルを (単一のファイルから) フォルダー名のフォルダー内にパックします。このフォルダー名はid、任意の行/ドキュメントのデータベースに保存されますimage file name(または画像名としてランダムな名前の場合もあります)。
yyyy/mm/d pathフォルダーが存在しない場合は作成します。たとえば、2016/08/21。そのパスを覚えておいて、同じドキュメントと行をデータベースに保存してください。
画像idフォルダをpathフォルダに移動します。(パスフォルダーは、/var/web-content フォルダーにある場合があります。)
メモリバッファをフラッシュするか、一時ファイルを削除します。

ドキュメントに記載されている画像にアクセスする必要がある場合は、画像を含むフォルダーのパスと ID が必要です。例えば/var/web-content/{{path}}/{{id}}/image-file-name.sm.jpg

このように、処理されたすべての画像ファイルを削除する必要がある場合は、フォルダーとそのコンテンツを再帰的に削除するだけです。

score 7 · Accepted Answer

私は自分のウェブサイトでアップロードされた画像を使用していますが、間違いなくオプション a) を使用します。

私が強くお勧めするもう 1 つのことは、ファイル名を、ユーザーが写真に付けた名前から、より管理しやすい名前にすぐに変更することです。たとえば、各写真を一意に識別する日付と時刻を含むもの。

また、ユーザーのファイル名から奇妙な文字を取り除き、将来の複雑さを回避するのにも役立ちます。

score 5 · Accepted Answer

SQL Server 2008 には、RunAs ラジオ #74で話題になったfilestream データ型と呼ばれる一種のハイブリッドアプローチがあります。これは、両方の長所のようなものです。ほとんどの人は2008オプションを持っていませんが、持っている場合、このオプションはかなりクールに見えます

score 3 · Accepted Answer

ほとんどの実装はオプション A です。

オプション B では、データベースからそれらのビットをブラウザーに表示できるものにマーシャリングするときに、whoop4ss の大きな缶全体を開きます...また、データベースがダウンしている場合、画像は利用できません。

スペースはそれほど問題ではないと思います...テラバイトドライブは現在数百ドルです。

オプション B を実行する時間やリソースがないため、オプション A を使用して実装しています。

score 3 · Accepted Answer

自動サイズ変更については、imagemagick を試してください... 多くの主要なオープンソースコンテンツ/写真管理システムで使用されています....net 拡張子がいくつかあると思います。

score 2 · Accepted Answer

オプションA。

画像が読み込まれると、保存する前に形式を確認してサイズを変更できます。http://www.codeproject.comには、画像のサイズを変更するための.Netコードサンプルが多数あります。例： http： //www.codeproject.com/KB/cs/Photo_Resize.aspx

score 2 · Accepted Answer

セキュリティ上の理由から、 IEのコンテンツスニッフィングによって引き起こされる問題を回避することもベストプラクティスです。これにより、攻撃者は、サイトのコンテキストで実行される可能性のある画像ファイル内にJavaScriptをアップロードできます。したがって、この種の攻撃を防ぐために、画像を保存する前に、何らかの方法で画像を変換（トリミング/サイズ変更）することをお勧めします。この答えには他にもいくつかのアイデアがあります。

score 2 · Accepted Answer

さて、私はユーザーがサーバーにファイルをアップロードする同様のプロジェクトを持っています。私の見解では、オプションa）はより柔軟であるため、最良のソリューションです。あなたがしなければならないことは、サブディレクトリによって分類された保護されたフォルダに画像を保存することです。コンテンツはスクリプトを実行してはならず（非常に重要）、httpリクエストでアクセスできないように保護されている（読み取り、書き込み）必要があるため、メインディレクトリは管理者が設定する必要があります。

これがお役に立てば幸いです。

score 2 · Accepted Answer

A を使用します。共有ドライブに配置します (複数のサーバーを実行する予定がない場合を除きます)。

これがスケールしないときが来たら、キャッシングメカニズムを調査できます。

score 2 · Accepted Answer

もちろん、オプション A に賛成です。他の人は、データベースが BLOB を処理するように設計されているかどうかに関係なく、一般的に BLOB をうまく処理できないと述べています。一方、ファイルシステムはこの目的のために生きています。RAID ストライピングを使用して、イメージを複数のドライブに分散させたり、地理的に離れたサーバーに分散させたりするオプションがあります。

もう 1 つの利点は、データベースのバックアップ/レプリケーションが巨大になることです。

score 1 · Accepted Answer

それらが編集する必要のない小さなファイルである場合、オプション B は悪いオプションではありません。ファイルを保存するためのロジックを記述し、クレイジーなディレクトリ構造の問題に対処するよりも、これを好みます。1 つのディレクトリに多くのファイルがあるのは良くありません。エムケイ？

ファイルが大きい場合や、特に Office などのプログラムから頻繁に編集する必要がある場合は、オプション A が最適です。

ほとんどの場合、これは好みの問題ですが、オプション A を選択する場合は、ディレクトリにあまり多くのファイルが含まれないようにします。オプション B を選択した場合は、BLOB 化されたデータを含むテーブルを独自のデータベースおよび/またはファイルグループに作成します。これは、メンテナンス、特にバックアップ/復元に役立ちます。通常のデータはおそらくかなり小さいですが、画像データは時間の経過とともに巨大になります。

score 1 · Accepted Answer

それはあなたの要件、特にボリューム、ユーザー、検索の頻度によって異なります。ただし、小規模または中規模のオフィスでは、Apple Photos や Adobe Lightroom などのアプリケーションを使用するのが最適なオプションです。これらは、この種のリソースの保存、カタログ化、インデックス作成、および整理に特化しています。しかし、大規模な組織で、ストレージの要件が厳しく、ユーザー数が多い場合は、Nuxeo や Alfresco などのデジタルアセット管理を使用してコンテンツ管理プラットフォームをインスタンス化することをお勧めします。どちらも非常に優れたリソースを提供し、それらを取得するための単純化された方法で非常に大量のデータを管理します. そして、非常に重要なのは、両方のプラットフォームに無料 (オープンソース) のオプションがあることです。

database - アップロードされた画像、SQL データベース、またはディスク ファイル システムを保存するのに最適な場所はどれですか?

18 に答える 18

Related

Reference

database - アップロードされた画像、SQL データベース、またはディスクファイルシステムを保存するのに最適な場所はどれですか?