9

重複の可能性：
画像をDBに保存する-そうですか、それともそうですか？

何年もの間、私はデータベースや、それに関しては大きなBLOBに画像を保存しないように言われてきました。データベースが効率的でない/効率的でない理由は理解できますが、データベースが効率的でない理由は理解できませんでした。ファイルをどこかに置いて参照できるのなら、データベースエンジンが同じことをできないのはなぜですか。ダミアン・カッツが最近のStack Overflowポッドキャストでそれについて言及し、ジョエル・スポルスキーとジェフ・アトウッドが少なくとも黙って同意したことをうれしく思います。

Microsoft SQL Server 2008がBLOBを効率的に処理できるはずだというヒントを読んでいますが、それは本当ですか？もしそうなら、私たちがそこに画像を保存して1つの問題を取り除くことを妨げるものは何ですか？私が考えることができることの1つは、画像がどこかのファイルである場合、静的Webサーバーによって非常に迅速に提供できる一方で、データベース内にある場合、データベースからWebサーバーアプリケーションに移動する必要があるということです（これはより遅い場合があります）静的Webサーバー）そしてそれが提供されます。その最後の問題をキャッシュしてヘルプ/解決するべきではありませんか？

4

5 に答える 5

10

はい、それは本当です。SQLServer 2008は、あなたが言及したような機能を実装しただけで、ファイルストリームと呼ばれています。また、BLOBをDBに格納することは確かに良い議論です。アプリにSQL Serverのみを使用したい場合（または、パフォーマンスまたは新しいものの上に同様のレイヤーを開発する場合に代償を払う意思がある場合） DBサーバー）。異なるDBサーバーにまだ存在しない場合は、同様のレイヤーが表示されるようになると思いますが。

いつものように、実際のメリットは特定のシナリオによって異なります。比較的静的で大きなファイルを大量に提供する場合は、パフォーマンスと管理性の組み合わせを考慮すると、このシナリオとキャッシュがおそらく最良のオプションになります。

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

于 2009-07-01T22:20:45.807 に答える
4

あなたが何かをすることができるからといって、あなたがすべきだという意味ではありません。

効率を気にする場合でも、十分に大規模なファイル配信ではこれを実行したくない可能性があります。

また、このトピックはかなり議論されているようです...

于 2009-07-01T22:29:38.003 に答える
2

私はあなたの質問を分解し、できる限りあなたのさまざまな部分に対処しようとします.

  • SQL Server 2008 とファイルストリーム タイプ- 上記の Vinko の回答は、これまでに見た中で最高のものです。Filestream タイプは、SQL Server 2008 であり、探していたものです。Filestream はバージョン 1 であるため、エンタープライズ アプリケーションで if を使用することをお勧めしない理由がまだいくつかあります。たとえば、私の記憶では、基礎となる物理ファイルのストレージを複数の Windows UNC パスに分割することはできません。遅かれ早かれ、これはエンタープライズ アプリにとってかなり深刻な制約になるでしょう。

  • ファイルをデータベースに保存する- より壮大な計画では、Damien Katz の最初の方向性は正しかった。大規模なエンタープライズ コンテンツ管理 (ECM) プレーヤーのほとんどは、ファイルをファイル システムに格納し、メタデータを RDBMS に格納します。さらに拡大して Amazon の S3 サービスを見ると、非リレーショナル データベース バックエンドを備えた物理ファイルを見ていることになります。何十億ものストレージの下にあるファイルを測定している場合を除き、この方法を使用して独自のものを展開することはお勧めしません.

  • データベース内のファイルの詳細- 一見すると、多くのことがデータベース内のファイルを物語っています。1 つはシンプルさ、2 つはトランザクションの整合性です。Windows ファイル システムはトランザクションに参加できないため、データベースとファイル システム全体で発生する必要がある書き込みには、トランザクション補正ロジックが組み込まれている必要があります。DBA と話をするまで、この話の反対側は実際にはわかりませんでした。彼らは通常、ビジネス データと BLOB が混在することを好まない (バックアップが面倒になる) ため、ファイル ストレージ専用の別のデータベースがない限り、このオプションは通常、DBA にとって魅力的ではありません。他のすべての条件が同じであれば、データベースが高速になることは間違いありません。アプリケーションの使用例がわからないので、キャッシュ オプションについてはあまり言えません。多くのエンタープライズ アプリケーションでは、

お役に立てれば。

于 2009-07-02T02:45:40.577 に答える
1

BLOBをデータベースに格納する際の古典的な理由の1つは、データがトランザクション制御下で格納および編集（変更）されることです。つまり、DBMSは、変更をロールバックし、クラッシュ後に変更を回復できることを確認する必要があります。これは通常、トランザクションログのテーマのバリエーションによって行われます。DBMSが変更を2GBのBLOBに記録する場合は、何が変更されたかを識別する方法が必要です。これは、単純なもの（前の画像と後の画像）またはより洗練された（ある種のバイナリデルタ操作）可能性があり、計算コストが高くなります。それでも、最終的にはログに保存されるギガバイトのデータになる場合があります。これにより、システムのパフォーマンスが低下します。

データベースにファイル名を保存することのペナルティは、DBMSがファイルの変更時期を（一般的に）制御できないことです。したがって、データの再現性が損なわれます。DBMSの外部にあるものがデータを変更していないことを保証することはできません。（その議論の非常に一般的なバージョンがあります-誰かがデータベースストレージファイルを一般的に改ざんしていないことを確認することはできません。しかし、私はデータベースにファイル名を保存することを指します。 DBMS。DBMSによって制御されるファイルは、非特権者による偶発的な変更から保護されます。）

新しいSQLServerの機能は面白そうです。私はそれが何をするのかを調べていないので、それが上記でほのめかされた問題を回避または制限する程度についてコメントすることはできません。

于 2009-07-01T22:37:58.267 に答える
0

SQL Serverには、大きなBLOBのデータを格納する場所を管理するためのオプションがあります。これらは、少なくともSQL2005から存在しているため、大きなBLOBのデータを格納できなかった理由がわかりません。たとえば、MOSSは、アップロードしたすべてのドキュメントをSQLデータベースに保存します。

もちろん、ほとんどすべての場合と同様に、パフォーマンスに影響があります。したがって、必要がない場合はblobを取得しないように注意し、インデックスなどに含めないようにする必要があります。

于 2009-07-01T22:23:18.140 に答える