テーブルが、あるイベントに関する詳細なデータを格納しているとしましょう。イベントの日付、約3万のタイプを持つタイプディメンション、約100のカテゴリを持つカテゴリディメンション、およびいくつかの数値ファクトがあります。
平均して、1日あたり1,500万のトランザクションがあります。年間50億以上、10年間で60G以上。それはビッグデータではありませんが、たくさんあります。
SQL Server 2012テーブルはいくつの行を保持できますか?
もちろん、古いデータはそれほど頻繁に使用されず、同じDB上の複数のテーブルに分割される可能性があります。しかし、いつこのパーティショニングが発生し始めるのでしょうか?年間1テーブルですか? 5年?
コメントから収集された追加情報:
考慮:私はそのイベントの300億の記録を保持するのに十分なストレージを持っています。各イベントレコードに1KBが必要な場合、そのテーブルには30TBがあり、そのため(およびそのログのために)十分なストレージがあります。そのPKはbigintです。
1つのテーブルに履歴データがあり、別のテーブルに最新データがあることについてどう思いますか?トランザクションイベントの代わりに、テーブルにはカタログ(クライアントなど)があります。 OLTPのカタログは毎日DWにコピーされます。したがって、履歴データを保持するテーブルと最新のレコードを含む別のテーブルがあります。
私が使用する設計では、ETLが履歴テーブルにフィードし、row_number()を使用して、各エンティティの最新のレコードをそのNKで取得します。実行には非常にコストがかかりますが、この方法では、過去に存在していて、OLTP=)に存在しないエンティティを保持します。
MSSQL2012テーブルはいくつのレコードを保持できますか?
MSDNページに記載されている SQL Serverの最大容量仕様 (SQL Server 2012の場合):
「テーブルあたりの行数=使用可能なストレージによって制限される」(32ビットと64ビットの両方のプラットフォームで同じ)
しかし、いつこのパーティショニングが発生し始めるのでしょうか?年間1テーブルですか? 5年?
これはすべてシステムのニーズに依存します。パフォーマンスの問題だけに基づいて、パーティション化する固有の必要性はありません。パーティショニングは主に、テーブルへの大量のデータの取り込みやテーブルからの取り出しをできるだけ簡単に管理し、競合をできるだけ少なくする手段として意図されています。純粋にクエリのパフォーマンスを支援したい場合は、約10億行のテストを開始しますが、それでも、適切なデータモデルと適切なインデックスが作成されている場合は、これに悩む必要はないでしょう。また、フィルター選択されたインデックス、さらにはフィルター処理された統計でさえ、テーブルパーティショニングの実装を選択する多くの場合に十分に機能します(意図が純粋にパフォーマンスに関連している場合)。
しかし、おそらく古いデータを期限切れにするために行の大きなブロックをすばやく削除する必要がある場合は、「古い」データをSWITCH
できるので、テーブルのパーティション分割が役立ちます。そしてこのレベルでは、それは行の問題ではなく、管理したい時間の長さの問題です。データを毎月交換したい場合は、毎月パーティションを作成します。毎年データを古くする場合は、年次パーティションを試してください。
[〜#〜]更新[〜#〜]
なぜこれについて前に触れなかったのかはわかりませんが、パーティションビューを見てください。同じスキーマの複数のテーブルと、それらの間でUNION ALLを実行するビューがあり、各テーブルにCHECK CONSTRAINT
そのテーブル内の特定の範囲のデータを強制します(したがって、クエリオプティマイザーはデータの取得元を認識します)。これを行うことで、現在と履歴の2つのテーブルを作成し、どちらかをヒットするクエリを作成できます(最新の90のみをヒットするクエリなど、時間枠が事前にわかっている場合)。日)、またはデータがどちらかにある場合はビューを使用します。詳しくは以下をご覧ください:
「現在の」テーブルがパーティション化されている組み合わせ(着信データをすばやく切り替えて、「古くなっている」データを切り替えることができるようにする)、パーティション化されていない履歴テーブル、およびそれらの2つを結合する分割ビュー。次に、新しくスイッチアウトされたパーティションから「履歴」テーブルにデータを取得する方法が必要です。
また、パフォーマンスに関しては、使用しているエディションに応じて、他にも提供される機能があります(一部はEnterprise Editionにのみ付属しています)。ただし、ColumnStoreインデックス、データ圧縮、その他いくつかを検討する必要があります。