SQL Server 2008または2012をどのようにスケーリングしますか？

SQL Server 2008（または2012）をどのようにスケーリングしますか？基本的に、2つのオプションがあることを理解しています。

拡大する：

CPUがバインドされている場合、1 CPUコアから2から4に明らかになります。または、RAM使用量が急増している場合は、RAMを追加するだけです。SQL Server 2008/2012は、アプリケーションレベルの変更がないと想定して、実際にスラックを取り、そのようにスケールアップしますか？憶測を最小限に抑えるために、CPUサイクルの書き込みやクロス結合など、馬鹿げたことをしていないとしましょう。

規格外：

スケールアウトがどのように機能するかは明確ではありません。私が最初のSQLサーバーのすぐ隣に別のSQLサーバーを追加した場合、クエリはどのサーバーで実行するかをどのようにして知るのですか？前面にロードバランサーはありますか（SQL Serverソフトウェアに付属していますか？）？スケールアウトを機能させるためにアプリケーションレベルの変更が必要ですか？それとも私が持っているデータをシャードとデータベース・サーバーの正しいモーニングコールは、キーをシャーディングデータに応じたことをカスタムコードを持っていますか？

より経験豊富な人々からのインプットをいただければ幸いです。

SQL Serverはそのようにスケールアウトしません。スケールアップします。

これを行うには3つの領域があり、エディションの制限に従います

• CPUコア
• 羊
• ストレージ

そしてもちろん、より高いエディションを使用します

SQL Serverはシャーディングを行わず、そのようなソリューション（MySQLシャーディングソリューションを調査できます）はシステムに複雑さとオーバーヘッドを追加します。

1つのサーバー（+スタンバイノード/ミラー）のスケールアップは、通常、RAM、SSD、IOを分散するためのディスクボリュームの追加、tempdbとログ用の個別のドライブなどで非常に簡単です。

また、SQL ServerがCPUにバインドされていることがわかった場合は、大量の負荷がない限り、通常、設計やインデックス、クエリの記述が不十分です。

gbnが言うように、SQLは他のRDBMのように実際にはスケールアウトしません。ただし、スケールアウトには、多くの人が見落としている側面が1つあります。それは、レポート用に常に別のシステムを用意することです。

本番環境に対してレポートを実行しないでください。別のサーバーにレポートデータベースを構築します。

理想的には、レポートシステムにはレポートに必要なデータのみが含まれ、本番システムとは異なる方法で構造化および最適化されます。

データは、必要に応じてレポートシステムにフィードされます（つまり、本番からの1時間ごとのトリクル更新、毎日のフィードなど）。

迅速でダーティな（そして非常に非効率的な）アプローチは、本番データベースの完全なコピーを別のサーバーに置くことです。このコピーは、完全バックアップ、トランザクションログ配布、ミラーリング（スナップショットを使用）、レプリケーションなどによって維持できます。

ただし、この方法はお勧めしません。特に大規模なデータベースでは、完全バックアップと復元には時間がかかります。レプリケーションは複雑で問題があります。ログ配布では、読み取り専用のデータベースが残ります。スナップショットを使用したミラーリングは良い答えかもしれませんが、それでもレポート作成用に最適化されていない本番スキーマに行き詰まっています。

別の報告システムが進むべき道です。

CPUがバインドされている場合、1 CPUコアから2から4に明らかになります。または、RAM使用量が急増している場合は、RAMを追加するだけです。SQL Server 2008/2012は、アプリケーションレベルの変更がないと想定して、実際にスラックを取り、そのようにスケールアップしますか？

SQL Serverの別のエディションが異なる制限持って、彼らが使用しようとしているCPUやメモリの観点を。ただし、それ以外は答えは「はい」です。空のCPUサイクルまたはメモリページが利用可能な場合、サーバーは通常、特に設定されていない限り、必要なときにそれらを使用します。

または、データをシャーディングし、正しいデータベースサーバーを呼び出すカスタムコードを持っている必要がありますか

基本的にはい。「スケールアウト」は、ロックの競合を回避する必要がある場合によく行われます。広範囲にわたるロックを伴う長時間実行のクエリがある場合は、ユーザーが何らかのインターフェースを操作してプロンプト応答を待機していることによって開始される「リアルタイム」のインタラクティブなクエリやクエリ更新サイクルからこれらを分離することができます。明らかに、これに対処するには、アプリケーションの変更（または、3層設計の場合は、少なくともミドルウェアの変更）が必要になります。