非常に大きいが単純なテーブルを分割または分割する必要があるのはどの時点ですか

私たちのサイトには、統計情報のためのいくつかの大きくて単純な（INT、INT、DATE）テーブルがあります。各テーブルには最大300,000,000行があり、毎日大きくなります。

ホスティングプロバイダーは、テーブルを分割またはパーティション分割することを提案しており、この推奨事項を他の場所で何度も見ました。

しかしながら...

私はこのアドバイスをSQL Serverの最大容量 -524,272テラバイトのデータベースサイズと調整し、テーブルの行は「利用可能なストレージ」によってのみ制限されます。

これらの数値に基づいて、上記の表は数百万行（10の303乗）を簡単に持つことができます。

ああ、あなたは言うかもしれませんが、能力とパフォーマンスには違いがあります。

しかし、SQL Serverのパフォーマンスに関するほぼすべての質問で、答えは「テーブルの設計とクエリの設計によって異なります」です。

それが私がこの質問をしている理由です。テーブルの設計はこれほど単純ではありません。インデックス付きIDフィールドに基づく単純なcount（*）操作であるクエリもできません。

一般的なアドバイスは、テーブルのデザインとそのクエリに依存するということです。Stack Exchangeに関する他の投稿への私の回答も同様です。「インデックス付きIDフィールドに基づく単純なcount（*）操作であるクエリ」と言っても、検討中の行セットのカーディナリティについては何も述べられていないため、多くの情報は得られません。（現時点で認識されている）問題を軽減するためにできることは次のとおりです。

1. パーティショニング。具体的には、データはロギングタイプのデータのようです。私の推測では、時間単位で統計情報を取得したいと考えています（たとえば、「1日あたりのウィジェット」または「1時間あたりのwhozits」）。クォンタム（前の例では数日または数時間）でパーティション分割し、パーティションを読み取り専用ファイルグループに移動する場合があります。

2. 関連するメモとして、データが1回だけの場合は、期間がアクティブでなくなったら、データを事前に集計することを検討してください。つまり、そのデータが決して変わらない場合、なぜ3年前から1日に発生したイベントの数を数え続ける必要があるのですか？日が終わったら、その日のすべてを数え、別の場所に保管し、二度と数えることはありません。実際、詳細データが必要ない場合（つまり、詳細データに対してのみ集計を実行する場合）は、カウントした後で削除することを検討してください。このアイデアを実装すると、「アクティブな」期間のみをカバーするフィルター処理されたインデックスを使用してさらに賢くすることができます。これにより、大部分のデータをカバーしないため、クエリが高速になります。

しかし、他の投稿での私のアドバイスが示唆しているように、確実に知る唯一の方法は、適切な量のデータをロードして試してみることです。ここでできることは、おそらく一般的なケースで何が機能するかを言うことだけです。ハードウェア、データ、クエリの詳細がなければ、私たちにできることはすべて推測です。また、テストを実行すると、答えは「何もする必要がない」と提案していることに気付くかもしれません。

私は別のアプローチをとり、（SQL Serverの）パーティション分割は主にデータ管理機能であり、管理方法によってはクエリパフォーマンスが二次的な結果となる可能性があることに注意してください。¹

リンク先の記事で述べたように、パーティション分割の主な利点は、パーティション切り替えを使用してデータをすばやく移動できることです。たとえば、「涼しい」データを低速のストレージにアーカイブし、「熱い」データを高速ストレージに保持できます。定期的にスケジュールされた間隔で、ETLが転送を実行するのを待つプロセスを経ることなく、データをアーカイブパーティションにローリングすることにより、データをすばやくアーカイブできます。ただし、質問に対する初期のコメントの1つで述べたように、これを実装する前に慎重な検討と計画が必要になります。また、使用するSQL Serverのエディション（Enterprise）によっては、データ圧縮を利用して個々のパーティションを圧縮できます。

限りのパフォーマンスを懸念しているとして、あなたはにロックのエスカレーションを変更することができますAUTO（デフォルトはあるTABLE）ので、のように：

ALTER TABLE dbo.T1 SET (LOCK_ESCALATION = AUTO);
GO

さらに、パーティションが削除される可能性がありますが、クエリパターンはシステム内の非常に具体的で反復可能なパターンに適合する必要があります。パーティション化キーとクラスタリングキー、および一意のキーは相互接続され、非常に重要になります。このバランスが承認されて扱われずに設計されていない場合、パフォーマンスの悪夢に終わります。

SQL Server 2014の登場により、大きなテーブルで統計を積極的に監視および更新/作成する場合に非常に便利な増分統計を利用することもできます。

では、テーブルはどの時点でパーティション化する必要がありますか？これは、クエリのワークロード、データのプロファイルによって異なりますが、最も重要なのは、パーティション化のどの管理機能を絶対に活用する必要があるかによって異なります。パーティショニングはクエリのパフォーマンスのためではなく、主にデータの管理と管理のためです。

パーティションの大きさを決定する前に、パーティション分割のクエリプランの影響を検討してください。純粋にパフォーマンスの観点から見ると、パーティションは粗い粒度の形式として機能します。これは追加のパフォーマンスを提供できますが、特にパーティションキーがすべてのクエリに表示されない場合は、パフォーマンス低下の原因にもなります。ここから、私はあなたがこの宿題をすでにやったと思います（あなたがそうであるように）。

必要なパーティションサイズの目安は次のとおりです。ボックス上にあるDRAMのサイズの約半分。この推奨の理由は次のとおりです。

1. あふれることなく、パーティションのインデックスを再構築できますtempdb。これは、ディスクアクセスを使用する場合よりもはるかに高速です（SSDを使用する場合でも）。
2. この再構築を行っている間も、パーティション全体（通常は最新）をDRAMに保持して、クエリのパフォーマンスを順調に維持できます。

つまり、2つのパーティションを保持するのに十分なDRAMが必要であり、必要なパーティションサイズは実行するマシンによって異なります。より大きなマシンは、より大きなパーティションを快適に処理できます。

このガイダンスは以下の最小サイズも提供することに注意してくださいtempdb：少なくとも最大のパーティションのサイズ（インデックスを再構築するときに十分なDRAMがない場合、そこにインデックスの構築をあふれさせることができます）。

これよりも小さいパーティションサイズを検討することもできますが、そうする場合、これは通常、パフォーマンスの最適化を目的としており、データの管理性をサポートすることを目的としていません。

パーティションで遊ぶことができる他のトリックがたくさんあります。たとえば、読み取り専用のパーティションで圧縮、集計、Fill Factor 100を使用します。ただし、基本的な原則は次のとおりです。管理するデータの各チャンクをDRAMよりも小さく保つようにしてください。

PS：答えとして「依存している」をとらないことを嬉しく思います。常に答えを得る方法を求めてください。

他のいくつかの機能と同様に、テーブルのパーティショニングはかなり頻繁に（またはおそらく最も頻繁に？）、不適切に使用されます。@swasheckの回答には、私が注意する点がすべて明記されています。

さらに、考慮すべき代替案はパーティションビューです。これは、完全に別個のテーブルを保持する方法ですが、ビューでUNION ALLを介してそれらをリンクします。各テーブルには、各テーブルが保持するデータの範囲を強制するCHECK CONSTRAINTが必要です。オプティマイザーはこの構成を認識しており、ビューを使用してクエリで必要とされる基になるテーブルにのみアクセスする必要があります（この作業を意図したとおりに行うためのすべての要件を思い出していないため、下部のCREATE VIEWリンクを参照してください。以前に設定したことがあり、期待どおりに動作させることは難しくありませんでした）。

確かにいくつかの制限があり、主な欠点は、テーブルのパーティション分割と比較して透過性が低いことです。ただし、主な利点は、これらが別々のテーブルであり、したがって統計が完全に分離していることですが、パーティションテーブルではテーブル全体に対するものです（SQL Server 2014以降、パーティションごとに統計を更新できる場合でも）。

パーティションの切り替えを使用しない場合は、このオプションを検討する必要があります。特に、古いデータを保持しているテーブルではインデックス/統計をほとんど頻繁に更新する必要がないため（またはそのデータが変更されない場合でも）、古いデータがあまり変化していない場合。

あまり言及されずに気付かれずに頻繁に行われるテーブルパーティションのもう1つの欠点は、SQL Server 2012以降、パーティションインデックスを再構築するときに「無料」のUPDATE STATISTICS WITH FULLSCANが得られなくなったことです。それでも、パーティション化されていないインデックスの再構築でこの更新統計を取得します。パーティション化されたビューのテーブルのインデックスは:)になります。

パーティションビューの詳細については、MSDNページでCREATE VIEWを確認し、「備考」の下にある「パーティションビュー」のセクションを探してください。