私たちが開発しているシステムは、Webアプリのフロントエンドと、SQL Server 2008 R2のストアドプロシージャを使用して大量のデータ処理を行うバックエンドで構成されています（なぜかは聞かないでください...）。これらのストアドプロシージャは、一時テーブル（作成、挿入、結合）を多用するため、一時データベース書き込みと読み取りの I/O レートは高くなります。クライアントは速度を必要としているため、次のことをお勧めします。
- メイン データベースを保存するための RAID 1 SSD アレイ (予算があれば RAID10 も可) を備えたサーバーを購入し、OS と SQL Server のインストール用に別のハード ドライブを使用して、重要なデータが高速ドライブにレプリケーションされて保存され、64 GB の RAM が搭載されているサーバーを購入します。
- 保存にはRAMディスクを使用する一時データベースデータベースなので、一時テーブル (パフォーマンスの最大のボトルネックであると考えられます) は RAM で処理されます。
いくつかのコンテキストデータ:
- 当社のデータベースは 10 GB を超える容量を使用せず、予想される増加率は非常に低くなっています。Tempdb は通常、2～3 GB を超えることはありません。
- サーバーは DB と Web サーバーに使用されます。
- Ramdisk ソフトウェアは、Windows の起動時に Ramdisk をマウントできます。
私たちは、大量の RAM を搭載したラップトップで RAM ディスク アプローチをテストしました。少なくとも、速度の向上は顕著です (ストアド プロシージャの実行時間が 1/3 に短縮されました)。
これが良い解決策であるかどうかを判断し、見逃している可能性のある欠陥（明らかなものも、それほど明らかでないものも）を検出するために、助けが必要です。
編集: これまでの回答に感謝します。アプリケーションを同時に使用するユーザーがいるため、複数の一時テーブル操作が実行されるということを明確に述べるのを忘れていました。また、Web サーバーと DB サーバーを混在させることは私たちの選択ではありません。最適ではないことはすでにわかっています ;)
答え1
レートだけではなく、待機時間も重要です。適切なベンチマークを実施してください。IOPS とディスク キューの長さを確認してください。Perfmon と SQL プロファイリングを使用してください。どうぞ、お待ちください。
実際にパフォーマンス上の懸念がある場合、OS を 1 セットのスピンドルに、MDF を別のセットに、LDF を別のセットに、そして tempdb ファイルをさらに別のセットに配置する必要があることは既にご存じでしょう。それを実行できない場合は、ベンチマークを行って優先順位を確認してください。また、読み取りと書き込みのパターンが異なると、それぞれに異なる RAID レベルが指示されることがあります。
適切な RAID 構成の標準ディスクで必要な機能を実現でき、エンタープライズ SSD に頼る必要がないことがわかるかもしれません。ただし、tempdb が十分に負荷をかけられている場合は、単一の SSD が適している可能性があります。パフォーマンスのために RAID を使用する必要はないかもしれませんが、冗長性のために RAID を使用するのは良い考えかもしれません。もちろん、予算とダウンタイムの長さによって異なります。
また、SQL サーバーは Web サーバーとは別々にする必要があることもご存知ですよね? パフォーマンスが懸念される場合は? 今は問題がなくても、規模が大きくなると、どちらがより大きな負荷を受けているのか、適切な修正方法は何かを判断するのが難しくなります。
答え2
RAIDは冗長性パフォーマンスは完全に失われます。例えば、RAID 5でデータを読み取る場合、全てコンポーネントディスクを読み取り、パリティチェックを行う必要があります（は単一のディスクから読み取るよりも遅く、ヘッドの動きは必ずしも同期されないため、最長平均だけでなくセット全体)、書き込みはすべての読み取り、パリティの計算、新しいデータとパリティの書き込みを意味し、単に書き込むよりも明らかに遅くなります。
はい、適切な RAID 実装とスマートなオペレーティング システムにより、この問題を大幅に軽減できます (必ず実行してください。単一のディスクでも RAM に対して非常に遅いため、優れたオペレーティング システムであれば、ディスクに関係なく、広範囲にキャッシュを実行します)。
はい、スマート DBMS は可能な限りデータを RAM にキャッシュします (データの一貫性、障害耐性などに関する約束を尊重し、必要に応じて、データがディスク上に安全に格納されるまで明示的に待機してから処理を続行します)。
どの DB にとっても、RAM ディスクは完全に有害です (「データは明示的にディスクに書き込まれるため安全」ではありません)。
答え3
回答をありがとうございました。とても役に立ちました。その後の調査で、I/O 速度は一般的には重要ですが、この特定のケースでは主なボトルネックではないことがわかりました。tempdb 管理のベスト プラクティスには、少なくとも 4 つのデータ ファイルがあることが含まれます。Microsoft も、CPU コアごとに 1 つのデータ ファイルを推奨しています。ファイル数が多いと、競合の問題のいくつかの種類を軽減するのに役立ちます。
これに関するいくつかのリンク:
答え4
tempdbのI/Oレートが書き込みと読み取りで高くなるようにする
RAM が少なすぎます。tempdb はオーバーフローした場合にのみ IO を実行します。それ以外の場合、SQL Server は tempdb ページをディスクにダンプしません。
したがって、RAM ディスクは役に立ちません。むしろ、メモリを増やす必要があります。