一般的に、ファイル システムではなく、データベース (具体的には mssql) にファイルを格納すると、パフォーマンス ヒットはどの程度低下するのでしょうか? アプリケーションの移植性以外に、ファイルを varbinaries として SQL Server に保存する理由が思いつきません。
10 に答える
この答えを見てください:
基本的に、ユーザー数によっては、スペースとパフォーマンスへの影響が非常に大きくなる可能性があります。また、Web サーバーは安価であり、負荷を分散するために簡単に追加できますが、データベースは通常、Web アーキテクチャの一部として最も高価であり、スケーリングが最も困難です。
反対の例もいくつかありますが (Microsoft Sharepoint など)、通常、ファイルをデータベースに保存することはお勧めできません。
デスクトップ アプリを作成したり、今後のユーザー数を大まかに把握している場合を除きますが、公共の Web サイトのようにランダムで予期しないものでは、データベースにファイルを保存するために高い代償を払う可能性があります。
SQL Server 2008に移行できる場合は、両方の長所を提供するFILESTREAMサポートを利用できます。ファイルはファイルシステムに保存されますが、データベース統合は、ファイルパスをvarcharフィールドに保存するよりもはるかに優れています。クエリは標準の.NETファイルストリームを返すことができるため、統合が非常に簡単になります。
私は、それはあなたの状況に依存すると思います。たとえば、私は地方自治体で働いており、マグショットなどの画像がたくさんあります。ユーザー数は多くありませんが、データに関する優れたセキュリティと監査が必要です。データベースはこれを簡単にし、スケーリングの問題に遭遇しないため、私たちにとってより良いソリューションです。
ここで質問は何ですか?
最新の DBMS SQL2008 には、BLOB を処理するためのさまざまな方法があり、それらはテーブルに固執するだけではありません。もちろん、一長一短はありますが、もう少し深く考える必要があるかもしれません。
これは故人 (?) Jim Gray による興味深い論文です。
パフォーマンスは問題ですが、最新のデータベース設計により、小さなファイルの問題ははるかに少なくなったと思います.
パフォーマンスは別として、データがどれだけ密結合しているかにも依存します。データベースのフィールドに密接に関連するデータがファイルに含まれている場合、そのファイルは概念的にそれに近いものに属し、blob に格納される場合があります。複数のレコードに関連する可能性がある情報や、データベースのコンテキスト外で使用される可能性のある情報が含まれている場合、その情報は外部に属します。たとえば、Web ページ上の画像は、そのページにリンクしているページとは別の要求で取得されるため、(特定の設計およびセキュリティの考慮事項に応じて) 外部に属している可能性があります。
私たちの妥協案は、それが最善であるとは約束しませんが、小さな XML ファイルはデータベースに格納し、画像やその他のファイルはデータベースの外側に格納することです。
私自身の経験では、ファイルをファイルとして保存する方が常に優れています。その理由は、ファイル システムがファイル ストレージ用に最適化されているのに対し、データベースは最適化されていないためです。もちろん、いくつかの例外はありますが (たとえば、非常に噂されている次世代の MS ファイルシステムは、SQL サーバーの上に構築する必要があります)、一般的にはそれが私のルールです。
パフォーマンスの問題を予想して、 http: //www.freshlogicstudios.com/Products/Folders/のvarbinaryとして保存することを決定しました。うまくいったことに嬉しい驚きを感じたと言えます。
@ZombieSheepに同意します。もう 1 つだけ。一般的には、DBMS ベンダーが提供するすべての機能を見逃しているため、データベースを実際に移植可能にする必要はないと思います。別のデータベースへの移行は、最後に検討することだと思います。0.02 ドル
blob (画像) をバイト配列に解析し、それを適切なファイル名でディスクに書き込んでから読み取る必要があるというオーバーヘッドは、特にファイルがかなり大きい。
漠然としたものではありませんが、保存する「ファイル」の種類が最大の決定要因の 1 つだと思います。基本的に、ファイルとして保存できる大きなテキスト フィールドについて話している場合、私の好みは db ストレージです。