0

たくさんの行（100億以上）があると予想されるテーブルのテーブルデザインを実験しています。すぐに頭に浮かぶいくつかのこと：

  • 私が「トール」テーブルアプローチと呼んでいるものでは、各行には、このタイプに対応する値とともに、約25の「タイプ」の1つがあります。これを、各タイプの値のNULL可能列を含む単一の行を持つ「ワイドアプローチ」に変換する必要がありますか？これは、保守性の観点からは優れたアプローチではありませんが（「タイプ」を追加する必要がある場合はどうなりますか）、サイズを二次的に考慮して、パフォーマンスに関心があります。
  • 行には日付のタイムスタンプがあります（分だけで十分なので、おそらくsmalldatetimeです）。表では、日時自体ではなく、日時に整数表現を使用する方がよいと聞いています。この日時は、クエリで頻繁に使用されることを期待しています（おそらく、クラスター化インデックスの一部である場合でも）。

私の主な関心事は、クエリのパフォーマンス、次にサイズの順です。大量のデータがテーブルにダンプされますが、変更または大きくなることはありません（おそらく、毎日または毎月の更新ですが、多くの更新ではなく、トランザクションと見なすものもありません）。

4

1 に答える 1

1

テーブルのパーティション分割の恩恵を受ける可能性があります。SQL ServerとOracleはどちらも、この機能を適切にサポートしています。テーブルのパーティション化により、クエリを続行する1つの論理テーブルを保持できますが、DBMSは実際には、指定したルールで維持するいくつかの物理ファイルに分割されます。たとえば、日付に基づいてパーティションを作成して、1990、2000、2010、または2020の範囲内にあるCreateDateを持つ行がそれぞれのパーティションに配置されるようにすることができます。

また、DBMSはパーティションを使用して並列処理を活用し、複数のパーティションにまたがるクエリのパフォーマンスを向上させることができます。

データベースのパーティション分割以外では、テーブルをシャーディングしないとパフォーマンスの向上は見られません。これは、保守が難しく、クエリをより複雑にします。

パーティショニングに関するMicrosoftのドキュメント

更新：パフォーマンスを向上させるために日時に整数を使用することを検討している場合、実際には、整数の日付にインデックスを配置するとそうなります。この理由は、整数の並べ替えが簡単であるため、Bツリーインデックスを作成すると、その特定のインデックスの全体的な速度が向上します。ただし、その列を使用して（where句またはgroup by句内で）クエリを実行しない場合は、インデックスを追加することはできますが、お勧めしません。実際、インデックスストレージがテーブルのサイズよりも大きい場合でも驚かないでしょう。

于 2011-12-08T22:01:55.930 に答える