7

バイナリまたは画像ファイルを保存する最良の方法は何ですか?

  1. データベースシステム
  2. ファイルシステム

理由を説明してください。

4

5 に答える 5

10

本当の最善の方法はありません。多くのトレードオフがあります。

データベースの長所:
1. クラスタリング環境での処理がはるかに簡単。
2. ファイル サーバーなどの追加リソースに依存しません。
3. 負荷分散環境で「同期」操作をセットアップする必要はありません。
4. バックアップにはファイルが自動的に含まれます。

データベースの短所:
1. データベースのサイズ/成長。
2. DB サーバーと言語によっては、入れたり取り出したりするのが難しい場合があります。
3.スピード/パフォーマンス。
4. DB サーバーによっては、アップロードおよびエクスポート時にファイルをウイルススキャンする必要があります。

ファイルの利点:
1. 単一の Web サーバーまたは単一のデータベース サーバーのインストールの場合、高速です。
2. ファイルを操作する十分な能力。つまり、ディスク容量が不足した場合に、ファイルを別の場所に移動するのは簡単です。
3. ファイルが「保存されている」場合にウイルス スキャンを実行できます。これにより、スキャナーの更新を利用できます。

ファイルの短所:
1. 複数の Web サーバー環境では、アクセス可能な共有が必要です。これもフェイルオーバー用にクラスター化する必要があります。
2. ファイル アクセスを処理するための追加のセキュリティ要件。Web サーバーや共有でファイルの実行が許可されていないことに注意する必要があります。
3. トランザクション バックアップでは、ファイル システムを考慮する必要があります。

上記で述べたように、SQL 2008 には、両方の世界を組み合わせた FILESTREAM と呼ばれるものがあります。データベースにアップロードすると、ディスク上のディレクトリにファイルが透過的に保存されます。取得するときは、データベースから取得できます。または、ファイル システム上の場所に直接移動することもできます。

于 2010-01-08T16:06:32.480 に答える
5

バイナリ ファイルを DB に保存する利点:

  • システムのデータ アクセス レイヤーは、DB + ファイル システムではなく、DB へのインターフェイスのみを必要とするため、複雑さがいくらか軽減されます。
  • データベースの残りの部分を保護するのと同じ包括的な権限ベースのセキュリティを使用して、ファイルを保護できます。
  • バイナリ ファイルは、データベース バックアップによって、残りのデータと共に損失から保護されます。個別のファイルシステム バックアップ システムは必要ありません。

バイナリ ファイルを DB に保存することの短所:

  • ファイルのサイズ/数によっては、かなりのスペースを占有する可能性があり、パフォーマンスが低下する可能性があり (バイナリ ファイルが、他のコンテンツに対して頻繁にクエリされるテーブルに格納されているかどうかによって異なります)、バックアップ時間が長くなります。

バイナリ ファイルをファイル システムに保存する利点:

  • これは、ファイル システムが得意とするところです。ファイル システムは最適化を適切に処理し、ファイルの取得 (Web サーバーを介してビデオ ファイルをストリーミングするなど) は、データベースを使用する場合よりも高速になる可能性があります。

バイナリ ファイルをファイル システムに保存することの短所:

  • 少し複雑なデータ アクセス層。独自のバックアップシステムが必要です。参照整合性の問題を考慮する必要があります (たとえば、データベース内のポインターを削除すると、ファイル システム内に「孤立した」ファイルがないように、ファイルが削除される必要があります)。

バランスをとって、ファイルシステムを使用します。以前は、SQL Server 2005 を使用して、db テーブルにバイナリ ファイルへの「ポインタ」を格納するだけでした。通常、ポインターは GUID です。

SQL Server 2008 を使用している場合 (およびその他の場合も - 私にはわかりません) に朗報です。新しい VARBINARY(MAX) FILESTREAM データ型を使用したハイブリッド ソリューションのサポートが組み込まれています。これらは VARBINARY(MAX) 列のように論理的に動作しますが、バックグラウンドで SQL Sever 2008 がデータをファイル システムに格納します。

于 2010-01-08T16:04:05.830 に答える
4

最善の方法はありません。

何？もっと情報が必要ですか？

私が知っている方法は 3 つあります... 1 つは、データベース内のバイト配列です。2 つ目は、データベースに保存されたパスを持つファイルとして。3 つ、ハイブリッドとして ( FileStreamタイプなど、DB が許可する場合のみ)。

最初の方法は、同じステップでデータのクエリと取得ができるため、非常に優れています。これはいつもいいです。しかし、たくさんのファイルがあるとどうなるでしょうか? データベースが大きくなります。今度は、1 テラバイトを超えるデータベースのバックアップの試行など、データベースのメンテナンスに関する大きな問題に対処する必要があります。ファイルへの外部アクセスが必要な場合はどうなりますか? 型変換、大量操作 (すべての画像のサイズ変更、透かしの適用など) など? ファイルがある場合よりもはるかに困難です。

2 つ目は、ファイル数がやや多い場合に適しています。それらを NAS デバイスに保存したり、増分バックアップを作成したり、データベースを小さく保つことができます。しかし、大量のファイルがあると、ファイル システムの制限に直面し始めます。また、それらをネットワーク上に拡散すると、遅延の問題、ユーザー権限の問題などが発生します。また、ネットワークが再編成された場合は、申し訳ありません。ファイルの場所を変更するには、データベースで大規模な更新を実行する必要があります。

次に、ハイブリッドオプションがあります。ほぼ完璧です。クエリを介してファイルを取得できますが、データベースは大規模ではありません。これですべての問題が解決しますか？おそらくそうではありません。データベースはもはや移植できません。特定の DBMS にロックされています。そして、これはまだ成熟していないので、歯が生えるプロセスを楽しむことができます. そして、これがすべての異なる問題を解決すると誰が言いますか?

事実、「最善」の方法はありません。要件を決定し、それらに応じて最適な選択を行い、間違ったことをしたことがわかったらそれを吸い上げるだけです。

于 2010-01-08T16:05:42.910 に答える
0

データベースに画像を保存するのが好きです。データベースを変更するだけで（ファイルをコピーすることなく）、開発から本番への切り替えが簡単になります。また、データベースは、ファイル システムと同様に、作成日/変更日などのプロパティを追跡できます。

于 2010-01-08T15:53:06.500 に答える
0

個人的には、パフォーマンスのためにデータベースに画像を保存することはありません。私のすべてのサイトには、保存する画像の種類に基づいてサブフォルダーを配置できる「/files」フォルダーがあります。次に、慣習に従って名前を付けます。

たとえば、プロフィール写真を保存する場合、「/files/profile/」に profile_2.jpg として保存します (2 がアカウントの ID の場合)。サーバー上の画像のサイズを必要な最大サイズに変更し、必要に応じてより小さいサイズに変更することを常にルールにしています。したがって、「profile_2_thumb.jpg」と「profile_2_full.jpg」を保存します。

自分でルールを作成することで、コード内で img src="/files/profile__thumb.jpg" を呼び出すだけです。

それはとにかく私がそれを行う方法です！

于 2010-01-08T15:54:29.867 に答える