SSD上のSQL Serverデータベース-すべてのテーブルに対して個別のファイルを使用する利点はありますか？
約30のテーブルがあるデータベースを作成しています。各テーブルには数千万の行が含まれ、各テーブルには重要な列が1つと主/外部キー列が含まれています。更新と挿入を行い、クラスター化インデックスを多用します。 2つのテーブルには可変長テキストデータが含まれ、そのうちの1つには数億行が含まれますが、残りのテーブルには数値データのみが含まれます。
使用可能なハードウェア（約64 GBのRAM、非常に高速なSSD、16コア）からパフォーマンスの最後のすべての低下を本当に絞りたいので、各テーブルに独自のファイルを許可して、私は2、3、4、5、またはそれ以上のテーブルに参加しています。各テーブルは常に別のスレッドを使用して読み取られ、各ファイルの構造はテーブルの内容と密接に整列されます。これにより、断片化を最小限に抑えて高速化できますSQL Serverが特定のテーブルのコンテンツに追加するため。
1つの警告、私はSQL Server 2008 R2 Web Editionに行き詰まっています。これは、自動水平分割を使用できないことを意味し、パフォーマンスの向上として除外されます。
テーブルごとに1つのファイルを使用すると、実際にパフォーマンスが最大になりますか、それとも冗長にする組み込みSQL Serverエンジンの特性を見落としているか？
次に、テーブルごとに1つのファイルを使用する方が有利な場合、create table特定の論理ファイルではなく、ファイルグループにテーブルを割り当てるオプションのみを提供しますか？この場合、シナリオ内のすべてのファイルに対して個別のファイルグループを作成する必要があります。これは、SQL Serverが、提案していることを実行することから得られると私が想定している利点を想定していないことを示唆しています。
2、3、4、5、またはそれ以上のテーブルに参加している場合でも、各テーブルは常に個別のスレッドを使用して読み取られ、各ファイルの構造がなるように、各テーブルに独自のファイルを許可することを考えていましたテーブルの内容と密接に連携します。これにより、断片化が最小限に抑えられ、SQL Serverが特定のテーブルの内容に追加する速度が速くなります。
一体何を話しているのですか。どこから情報を取得したかはわかりませんが、その情報源は破棄する必要があります。ここであなたが想定していることから、実際に正しいものはありません。
SQL ServerのSSDパフォーマンスの良い説明を読みたい場合は、ブログシリーズがいくつかあります。いつものように、Paul Randalが1番読みです。
- ベンチマーク：SSDの紹介（パート1b：オーバーロードされていないログファイルアレイ）
- ベンチマーク：SSDの紹介（パート1：ログファイルアレイが過負荷にならない）
- ベンチマーク：SSDの紹介（パート2：順次挿入）
- ベンチマーク：SSDの紹介（パート3：待機統計の詳細を含むランダムな挿入）
- ベンチマーク：SSD上の複数のデータファイル（および最新のFusion-ioドライバー）
ブレントはこのトピックについても素晴らしいプレゼンテーションを行っています： SSD上のSQL：ホットでクレイジーな愛 、そしてもっとたくさんあります。
これらすべてのプレゼンテーションを見ると、すべてがwritesに焦点を合わせていることがすぐにわかります。これは、SSDのパフォーマンスが重要になるためです。投稿の文言はほぼ完全に読み取りに関するものであり、別のトピックです。読み取りが問題になる場合は、SSDではなくRAMについて、および適切なインデックス作成とクエリの戦略について話している必要があります。
私の最初の提案は、両方の構成に対して負荷テストを行わずに、パフォーマンスについて想定しないことです。
過去にこのような構成（紙の上で意味のあるもの）を見たことによる私の推測は、各テーブルを個別のファイルに置いてもパフォーマンスに測定可能なプラスの影響はなく、追加の複雑さがパフォーマンスの向上を相殺するだろうということです。測定可能であったとしても。
最後に、SQLサーバーからパフォーマンスの低下をすべて排除することになると、次のグラフを参照します（私のMicrosoftが提供するものです）。
アプリケーションの観点から行われる可能性のある最適化は、ハードウェア/データベース構成レベルでの可能な最適化を簡単に無視するので、適切に注意を向けます。
他の人が指摘したように、テーブルごとに1つのファイルから直接のメリットはありません。この神話の起源についてのスティーブジョーンズのすばらしい概要を以下に示します。 http://www.sqlservercentral.com/blogs/steve_jones/2009/10/13/sql-server-legend-data-files-and-threads /
また、2008 Web Editionでサポートされていると思われる分割ビューを調査することもできます。分割ビューに対するコーディングにはいくつかのトリックがありますが、分割テーブルの多くの機能を比較的簡単に模倣できます。
テーブルごとに別々のファイルを用意しても、パフォーマンスは向上しないと思います。正しいインデックスを使用すると、データベースサーバーでパフォーマンス（ディスク読み取り）が増加する可能性があります。
SQL Server 2008 R2は圧縮をサポートしていますか？はいの場合は、オンにします。
私が間違っている場合は修正してください。