SQL Server 2008 は、電子商取引 Web サイトのイメージ ストアとして使用するのに適したオプションですか? さまざまなサイズと角度の製品画像を保存するために使用されます。Web サーバーはこれらの画像を出力し、クラスター化された ID でテーブルを読み取ります。画像の合計サイズは約 10 GB ですが、スケーリングする必要があります。ファイル システムを使用するよりも多くの利点があると思いますが、サイトのトラフィックが多いことを考えると、O(1) ルックアップを持たない SQL サーバーは最適なソリューションではないのではないかと心配しています。それはボトルネックになるでしょうか？いくつかの考え、またはおそらく他のオプションは何ですか?
14188 次
6 に答える
27
10 Gb はそれほど大量のデータではないので、おそらくデータベースを使用して保存することができ、大きな問題はありませんが、もちろんファイル システムを使用することがパフォーマンス上最も優れており、安全管理上は DB を使用する方が優れています。 (バックアップと整合性)。
幸いなことに、Sql Server 2008 では、ケーキを食べて食べることができます。
SQL Server 2008 では、FILESTREAM 属性を varbinary 列に適用すると、SQL Server はその列のデータをローカルの NTFS ファイル システムに格納します。ファイル システムにデータを格納することには、次の 2 つの主なメリットがあります。
- パフォーマンスは、ファイル システムのストリーミング パフォーマンスと一致します。
- BLOB サイズは、ファイル システムのボリューム サイズによってのみ制限されます。
ただし、列は SQL Server の他の BLOB 列と同じように管理できるため、管理者は SQL Server の管理機能とセキュリティ機能を使用して、BLOB データ管理をリレーショナル データベースの残りのデータと統合できます。ファイルシステムデータを個別に。
SQL Server でデータを FILESTREAM 列として定義すると、データベース内のリレーショナル データと、ファイル システムに物理的に格納されている非構造化データとの間のデータ レベルの一貫性も保証されます。FILESTREAM 列は BLOB 列とまったく同じように動作します。つまり、バックアップや復元などのメンテナンス操作が完全に統合され、SQL Server セキュリティ モデルと完全に統合され、完全なトランザクションがサポートされます。
Application developers can work with FILESTREAM data through one of two programming models; they can use Transact-SQL to access and manipulate the data just like standard BLOB columns, or they can use the Win32 streaming APIs with Transact-SQL transactional semantics to ensure consistency, which means that they can use standard Win32 read/write calls to FILESTREAM BLOBs as they would if interacting with files on the file system.
In SQL Server 2008, FILESTREAM columns can only store data on local disk volumes, and some features such as transparent encryption and table-valued parameters are not supported for FILESTREAM columns. Additionally, you cannot use tables that contain FILESTREAM columns in database snapshots or database mirroring sessions, although log shipping is supported.
于 2008-12-02T20:43:04.957 に答える
3
MS Research のこのホワイト ペーパーを参照してください ( http://research.microsoft.com/research/pubs/view.aspx?msr_tr_id=MSR-TR-2006-45 ) 。
彼らはあなたが探しているものを正確に詳しく説明します. 簡単に言うと、ファイル サイズが 1 MB を超えると、ファイル システムにデータを保存する場合に比べてパフォーマンスが低下し始めます。
于 2008-12-02T20:46:37.617 に答える
1
O(log n)ルックアップが問題になるとは思えません。あなたは10GBの画像があると言います。平均画像サイズを 50KB とすると、200,000 枚の画像になります。200K 行のテーブルでインデックス付きルックアップを行うことは問題ではありません。実際にディスクからイメージを読み取り、アプリを介してクライアントに転送するのに必要な時間と比較すると、わずかです。
ファイルシステム上のファイルへのパスをデータベースに保存することと、画像をデータベースに保存することの通常の長所と短所を検討する価値はまだあります。例えば：
- データベース内の画像は、トランザクションの分離に従い、行が削除されると自動的に削除されます。
- もちろん、10GB の画像を含むデータベースは、画像ファイルへのパス名のみを格納するデータベースよりも大きくなります。バックアップ速度やその他の要因が関連しています。
- アプリケーションを介してデータベースから画像を提供する場合、応答に MIME ヘッダーを設定する必要があります。
- ファイルシステム上の画像は、Web サーバー (Apache mod_mmap など) によってより簡単にキャッシュされるか、lighttpd のような無駄のない Web サーバーによって提供される可能性があります。これは実際にはかなり大きなメリットです。
于 2008-12-02T20:46:41.160 に答える
0
e コマース Web サイトのようなものでは、データベースのブロブ ストアに画像を保存する可能性が高くなります。時期尚早の最適化に関与したくない場合は、画像をデータと一緒に簡単に整理でき、非常に移植性が高いという利点だけが、e コマースのようなものにとって自動的な利点の 1 つです。
于 2008-12-02T20:41:38.940 に答える
0
画像がインデックス化されている場合、ルックアップは大きな問題にはなりません。よくわかりませんが、ファイルシステムのルックアップはO(1)ではなく、O(n)のようなものだと思います(ファイルシステムによってインデックスが作成されているとは思いません)。
このセットアップで私が心配しているのはデータベースのサイズですが、正しく管理されていれば大きな問題にはなりません。大きな利点は、バックアップするものが 1 つ (データベース) しかなく、ディスク上のファイルについて心配する必要がないことです。 .
于 2008-12-02T20:41:55.490 に答える
0
Normally a good solution is to store the images themselves on the filesystem, and the metadata (file name, dimensions, last updated time, anything else you need) in the database.
Having said that, there's no "correct" solution to this.
于 2008-12-02T20:43:32.290 に答える