SQL 2008 R2スタンドアロンサーバーが単一のテーブルに格納する必要がある行の最大推奨数はいくらですか？

Question

リアルタイムAJAX Webアプリケーションの機能とパフォーマンスのためにDBを設計していますが、現在DBサーバーの冗長性やロードバランシングを追加するリソースはありません。

残念ながら、私はデータベースに潜在的に何億もの行を格納する可能性のあるテーブルを持っており、Webインターフェイスの遅れを防ぐためにすばやく読み書きする必要があります。

この表の列のすべてではないにしても、大部分が個別に索引付けされています。大型表で問合せを実行するときにサーバーの負担を軽減する方法が他にあるかどうかを知りたいと思います。しかし、最終的には、単一のクラスタ化されていないSQLサーバーがチョークを開始する前に、テーブルのサイズ（行または GB）の上限がありますか？

私のDBには数十のテーブルしかありませんが、多分数十のキーとの関係があります。私のテーブルには8つ以上のカラムがありません。これらのテーブルの1つまたは2つだけが多くの行を格納してしまいます。うまくいけば、私のDBのシンプルさは、これらの夫婦テーブルの大量のデータを補うでしょう...

Answer 1

行は、使用可能なディスク容量によって厳密に制限されます。 SQL Serverには何億行ものデータが格納されています。もちろん、これらのサーバーはかなり大きくなっています。

ウェブインターフェイスがうまくいくようにするには、そのデータへのアクセス方法を考える必要があります。

大規模なデータの処理を必要とする任意のタイプの集約クエリから離れることです。 SUM（）のようなものは、処理しようとしているデータの量に応じてキラーになる可能性があります。このような状況では、事前に集計またはグループ化されたデータを計算し、サイトでこれらの分析表を照会するほうがずっと優れています。

次に、データを分割する必要があります。これらのパーティションを異なるドライブアレイに分割します。 SQLをディスクに移動する必要がある場合、読み込みを並列化しやすくなります。 （@Simonはこれに触れました）。

基本的にこの問題は、一度にアクセスする必要があるデータの量になります。これは、ディスクに保存されているデータの量に関係なく、主な問題です。ドライブの速度が遅く、DBサーバーの使用可能なRAMの量が不十分で、データベースを十分にメモリに保持できない場合、小さなデータベースでも突然終了する可能性があります。

通常、このようなシステムの場合、大量のデータは基本的に不活性であり、ほとんどアクセスされません。たとえば、POシステムではこれまで作成されたすべての請求書の履歴が保持されますが、実際には有効なもののみを処理します。

システムにも同様の要件がある場合は、アクティブなレコード用のテーブルがあり、夜間のプロセスの一部として別のテーブルに単純にアーカイブすることができます。そのアーカイブの一部として月間平均（例として）のような統計を再計算することさえできます。

ちょっと考えてください。

Answer 2

私の勇気は、あなたはおそらく大丈夫だと言いますが、パフォーマンスに対処する必要があります。これは、クエリからの検索可能な検索時間に依存することになります。

「何億もの行数」のテーブルでは、定期的に何パーセントのデータにアクセスしていますか？データの一部はアクセスされることはほとんどありませんか？一部のユーザーは選択したデータにアクセスし、他のユーザーは別のデータを選択しますか？データの分割によって利益を得ることができます。

Answer 3

唯一の制限は、プライマリキーのサイズです。 INTかBIGINTですか？

SQLは問題なくデータをうれしく保存します。しかし、100万の行では、データを分割するのが最適です。これにはarticleのような多くの良い記事があります。

パーティションを使用すると、1つのパーティションにつき1つのスレッドが同時に動作し、クエリを並列化することができます。