25

1,000 万件のレコードを含むテーブルがあります。それは多くの記録と見なされますか？検索時間について心配する必要がありますか? そうでない場合、それは成長し続けるので、大きなテーブルと見なされるものは何ですか? テーブルのサイズは検索時間にどの程度影響しますか? また、できれば問題になる前に、これらの問題を改善するにはどうすればよいですか?

4

6 に答える 6

36

「大」は「スマート」のようなもので、相対的なものです。1,000 万行は適切なサイズですが、テーブルが大きいかどうかは多くの要因に依存します。

  • 列の数とそのデータ型は?
  • インデックスはいくつですか？
  • テーブルの実際のサイズ (たとえば、ページ数 * 8kb から取得できますsys.dm_db_partition_stats)。
  • それに対して実行されるクエリの種類は何ですか?
  • 個々のインデックスがメモリに保持されているか、またはほとんどのクエリがクラスター化されたインデックス スキャンの恩恵を受けているか (本質的に、テーブル全体がメモリにある必要がある場合)。
  • マシンのメモリはどれくらいですか？
  • 何が大きいと思いますか？

検索時間は必ずしもサイズ自体によって決まるわけではなく、インデックス作成戦略の有効性と、検索のために実行するクエリの種類によって決まります。次のようなものがある場合：

WHERE description LIKE '%foo%'

その場合、通常のインデックスでは何の役にも立たず、心配し始める必要があります。このような場合は、全文検索を検討してください。

単一の INT 列を持つテーブル (Numbers テーブルなど) の 1000 万行は意味がありません。長い説明、XML、地理データ、画像などを含む 1,000 万行の製品は、まったく別のものです。

SQL Server の最大容量の仕様に、テーブル内の行数の上限が記載されていないのには理由があります。

于 2012-09-19T15:48:07.643 に答える
7

大規模は、db 設計では有用な概念ではありません。

パフォーマンスは多くの要素によって決まりますが、レーベルlargeはその 1 つではありません。代わりに、次のことに注意してください。

  • ハードウェア
  • OS とデータベースの構成
  • スキーマ設計
  • 索引付け
  • クエリの最適化
  • 最も重要なことは、同等のハードウェアで同等のデータ量と同時使用の下で自分自身でテストすることです。

そうして初めて、あなたに関連する答えが得られます。これを超えて、アプリケーションの設計も大きな要因です。N+1 クエリとキャッシュは、知覚 (および実際の) パフォーマンスに大きな影響を与える可能性があります。

于 2012-09-19T15:51:28.043 に答える
7

アーロンが言ったように、それは相対的なものです。しかし、多分私はいくつかを詳しく説明することができます.

まず、主な要因の 1 つは、列の大きさです。1,000 万個の整数しかないテーブルがある場合 (そのようなものが必要な理由がある場合は、Tally Tablesを参照してください)、それはまったく大きくありません。一方、わずか 100 行の非正規化されたテーブルは多くのスペースを占有し、各行に id フィールドと主キーとして機能する整数が含まれ、その後に html の varchar(max) が続く場合、大きなパフォーマンスの問題が発生する可能性があります。次に、その html で使用される jpg を保持する一連の varbinary(max) 列。

したがって、テーブルのサイズを把握するには、行数と各行のサイズの両方を確認する必要があります。もう少し有用なサイズの指標の 1 つは、それが占めるスペースを調べることです。(これが SQL Server 2000 以降であると仮定すると、SSMS でテーブルを右クリックし、プロパティに移動して、[ストレージ] ページに移動できます。)

もちろん、それがいつパフォーマンスに影響を及ぼし始めるかを言うのはまだ難しい. テーブルが大きくなりすぎて RAM 内に収まらなくなると、パフォーマンスの変化に気付くでしょうが、特に部分的に非正規化することを選択し、懸念の原因とならない適切なサイズのデータ​​セットで頻繁に発生する可能性があります。インデックスが大きすぎて RAM 内に収まらない場合、パフォーマンスの問題が大きくなる可能性があり、それが評価の原因になる可能性があります。ただし、必ずしも問題になるとは限りません。特に、一部のクエリのカバリング インデックスであり、RAM に制約のある環境で作業している場合 (RAM の制約が意味するものも相対的ですが、大まかな経験則として、私はSQL Server で本格的な作業を行う予定のデスクトップでさえ、少なくとも 8 GB を配置します)。

現在、テーブルのサイズは確かに検索速度の要因となる可能性があり、それに対処する方法があります。しかし、それらについて話す前に、通常、これはパフォーマンスに関して私が注目する小さな要因の 1 つであることを指摘しておきます。私は最近、これについての記事をここに書きました。テーブルのサイズについて考える前に、クエリが最適化されていること、およびインデックスが適切であることを確認します。テーブルのサイズを心配する前に、RAM を増やしてより高速なハードドライブを入手することも検討します (目的に十分な大きさの SSD を購入できる場合は、 SSDが違いを生みます)。

ただし、テーブルのサイズを小さくしたい場合:

  • ノーマライズ。これは実際にはパフォーマンスに大きな欠点をもたらす可能性がありますが、パフォーマンス上の利点がいくつかある可能性があり、ビッグ データの一貫性とストレージの利点があります。
  • データ型を考慮してください。NVarchar が必要な場合は、NVarchar が必要です。しかし、varchar が機能する場合は、使用するスペースが少なくなります。int vs bigint と同じです。
  • パーティション。繰り返しますが、これを間違って行うとパフォーマンスが向上するどころか低下する可能性がありますが、正しく行うとパフォーマンスが向上します。正しく行うのはやや難しい場合があるため、注意してアプローチしてください。
  • 古い不要なデータをアーカイブ ウェアハウスに移動し、メイン システムから外します。もちろん、これは不要なデータを正しく定義することにかかっています。

概要：

思ったより長くなってしまったのでまとめると

  1. 相対的な大きさですが、列のサイズと行数を考慮する必要があります。
  2. テーブルのサイズは間違いなくパフォーマンスに影響を与えますが、他の多くの要因がパフォーマンスに影響を与える可能性があるため、最初に、または 2 番目に確認することはありません。
  3. テーブルのサイズを小さくする必要がある場合は、基本的に不要なデータを取り除き、他のデータを別の場所に再割り当てします。しかし、あなたはどのように賢くなければ、善よりも害を及ぼすことができます.
于 2012-09-19T16:16:34.537 に答える
2

すべては相対...

私は以前、マーケティング データベースの設計、構築、およびホストを行う会社の DBA でした。数十億行のデータベースが存在することは珍しくありませんでした。そのため、数百万行の他のデータベースは「小さい」と見なされました。

また、スキーマには大量のデータ (トランザクションなど) を持ついくつかのテーブルが存在する傾向があり、他のテーブルは小さなルックアップ テーブルである可能性があります。

私が得ているのは、テーブルが「大きく」なるポイントがないということです。

大きなテーブルがある場合、それは確かに最適化の候補です。テーブルが非常に大きくなることは完全に合理的ですが、クエリに使用されることはめったにないため（たとえば、ある種の履歴テーブル）、「可能」と言います。

于 2012-09-19T15:52:59.927 に答える
0

どのように「大きい」かは、データの種類、実行するクエリの種類、ハードウェアの種類、検索時間の理由の定義に依存することについて、他のポスターと同じです。

ただし、「大きい」を定義する 1 つの方法があります。「大きい」テーブルとは、ホストが SQL Server に割り当てることができる実際のメモリの量を超えるテーブルです。SQL Server は、サイズが物理メモリを大幅に超えるテーブルを完全に処理できますが、クエリでそのようなテーブルのテーブル スキャン (つまり、すべてのレコードの読み取り) が必要になると、いつでもデータが失われます。理想的には、テーブル全体をメモリに保持する必要があります。それが不可能な場合は、少なくとも必要なインデックスをメモリに保持する必要があります。クエリをサポートするインデックスがあり、そのインデックスを RAM に保持できる場合でも、パフォーマンスは十分に向上します。

クラスター化インデックス (データの物理的な配置) と非クラスター化インデックス (基本的にクラスター化インデックスへのポインター) がどうあるべきかが設計者として明らかでない場合、SQL Server には定義に役立つ非常に優れたプロファイリング ツールが付属しています。ワークロードに適した方法でインデックスを作成します。

最後に、問題にハードウェアを投入することを検討してください。SQL Server のパフォーマンスは、ほとんどの場合、CPU バウンドではなくメモリ バウンドです。そのため、高速な 8 コア マシンを購入して 4 GB の物理メモリで機能を損なうことは避けてください。100 GB のデータベースで確実に低レイテンシーを実現する必要がある場合は、RAM が 64 GB (または 128 GB) のマシンでホストすることを検討してください。

于 2012-09-19T16:46:30.343 に答える