2

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

残念ながら、DB に数億行を格納する可能性があるテーブルがあり、Web インターフェイスの遅延を防ぐためにすばやく読み書きする必要があります。

このテーブルの列のすべてではないにしても、ほとんどは個別にインデックスが作成されています。大きなテーブルでクエリを実行するときにサーバーの負担を軽減する方法が他にあるかどうか知りたいです。しかし、クラスター化されていない単一の SQL サーバーが停止し始める前に、最終的にテーブルのサイズ (行数またはGB) に上限はあるのでしょうか?

私のDBには12個のテーブルしかなく、おそらく数十個の外部キー関係があります。私のテーブルはどれも 8 つ以上の列を持っておらず、これらのテーブルの 1 つまたは 2 つだけが多数の行を格納することになります。うまくいけば、私の DB のシンプルさが、これらの 2 つのテーブルの膨大な量のデータを補ってくれることを願っています...

4

3 に答える 3

4

行は、使用可能なディスク容量によって厳密に制限されます。何億行ものデータを含むSQLServerがあります。もちろん、それらのサーバーはかなり大きいです。

Webインターフェイスをスッキリと保つには、そのデータにアクセスする方法を考える必要があります。

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

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

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

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

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

いくつかの考え。

于 2010-12-20T18:49:31.550 に答える
4

唯一の制限は、主キーのサイズです。INT ですか、それとも BIGINT ですか。

SQL は問題なくデータを喜んで格納します。ただし、1 億行の場合は、データをパーティション分割することをお勧めします。この記事など、これに関する多くの優れた記事があります。

パーティションを使用すると、パーティションごとに 1 つのスレッドを同時に動作させて、パーティション化しない場合よりもさらに多くのクエリを並列化できます。

于 2010-12-20T18:29:09.527 に答える
1

私の直感は、あなたはおそらく大丈夫だと言っていますが、パフォーマンスに対処する必要があります. これは、クエリから結果を取得するまでの許容時間によって異なります。

「数億行」のテーブルでは、データの何パーセントが定期的にアクセスされますか? 一部のデータはめったにアクセスされませんか? 一部のユーザーは選択したデータにアクセスし、他のユーザーは別のデータを選択しますか? データのパーティショニングが役立つ場合があります。

于 2010-12-20T18:28:47.243 に答える