SQL Serverのパーティション分割-パーティションキーに何を使用するか

私はSQL Serverのパーティション分割を扱ったことがありませんが、現在、ボリュームがおそらくそれを保証するデータベースの設計に直面しています。システムはクーポン用です。クーポンは定期的に発行され、通常は6週間ごとに発行されますが、特別イベントなどの臨時の発行も行われます。1,500万人の顧客がおり、各発行イベントに対して、すべての顧客が6種類の異なるクーポンタイプを受け取り、合計9000万のクーポンインスタンスを提供します。通常、クーポンの有効期間は6週間ですが、クーポンインスタンスの償還データを追跡して6か月間維持する必要があります。無効なクーポンの引き換えリクエストは、POSによって検証されるため、データベースに到達しません。

6か月間で、クーポンインスタンステーブルには最大3億6,000万行、リデンプションテーブルには最大7,200万行（最大20％の償還率を想定）を格納する必要があります。これらの数値は単一のパーティションには大きすぎると感じますか？

私の質問は-パーティションキーとして何を使うのですか？明らかな候補の1つは、発行イベントによるもので、約6つのパーティションを提供します。しかし、それでも、パーティションサイズが大きすぎて最適なパフォーマンスを実現できないと思いますか？たとえば、発行イベント+カスタマーIDの最後の桁など、2つのキーでパーティション化することはできますか？したがって、ロジックは次のようになります。

If issuance event = 1 and last digit of customer id < 5 then
    Store in partition 1
Else if issuance event = 1 and last digit of customer id >4 then
    Store in partition 2
Else if issuance event =2 and last digit of customer id <5 then
    Store in partition 3
Else if issuance event =2 and last digit of customer id >4 then
    Store in partition 4
Etc...

また、必要なデータベースサーバーの仕様もわかりません。16GBと8CPUで十分でしょうか？DBは、0.5秒未満でバーコード数値にキー入力されたクーポンインスタンステーブルから結果を返すことができる必要があります。検証（選択）と引き換え（挿入）の予期されるトランザクション要求は、1分あたり約3,500でピークになると予想されます。

SQL Server 2008r2 64ビットdbサーバーは、高性能で大容量のSANにアクセスできる非常に強力なホストからVMとしてプロビジョニングされます。

同様のボリュームを管理するためにSQL Serverソリューションを導入した人からのアドバイスにとても感謝しています。

よろしく

ロブ。

サーバーの仕様に関する質問は、ServerfaultまたはDBA.SEに送信してください。

パーティション化の質問については、必ずしもこれのためにパーティション化する必要があるとは思いません。

360mの行はたくさんありますが、あまり扱いにくいものではありません。

どのような状況でも、フィールドの最後の桁に基づいてパーティション分割を試みないでください。これが機能するかどうかはわかりませんが、SAR可能ではなく、Tenableにはなりません。

数値キーに基づいて単一の行シークのみを実行する必要がある場合、パーティション化はおそらく役に立ちません。

パーティションルートを追跡することにした場合は、エンジンがチェックするパーティションを認識できるように、すべてのクエリでパーティションキーを含める必要があることを忘れないでください。そうしないと、すべてがチェックされ、実際にパフォーマンスが低下します。

永続的な計算列を使用する場合は、複数のキーでパーティション化できます。ただし、他の人が言ったように、パーティショニングはすべての状況で機能するわけではありません。特定の助言を与えるのに十分なほどあなたのシナリオを理解しているとは思いませんが、いくつかの一般的なガイドラインを次に示します。

• パーティション化は、パーティション化キーがSQLステートメントの一部である場合にデータを読み取るのに役立ちます。これにより、オプティマイザーはパーティションの除外を呼び出すことができます。選択したキーがほとんどのクエリに役立つことを確認する必要があります。

• 適切なパーティショニング戦略の利点の1つは、データの経年劣化です。たとえば、パーティションキーが日付ベース（つまり、年の日付）であり、特定の日付より古いすべてのデータを削除する場合、それらのパーティションを空のテーブルに切り替えて切り捨てることは非常に簡単です。

要件をもう少し明確に定義する必要があります。6か月で約3億6000万行を取得するとします。2年後はどうですか？あなたはまだあなたが現在成長している速度でのみ成長していますか？または、指数関数的な成長を経験する可能性があります。このテーブルのデータを永久に保持しますか？または、定期的にデータをアーカイブする必要があります。

パーティション化は、データのアーカイブに使用できます。スライディングウィンドウのシナリオを参照してください。このホワイトペーパーとこれをご覧ください。

パーティション化は、インデックスの断片化を管理するためにも使用できます。特定のパーティションを再構築/再編成できます。

また、パーティションテーブルではなく、パーティションビューを検討する必要があります。パーティションビューには、SQL Server Enterpriseライセンスは必要ありません。パーティションビューを使用すると、特定の「パーティション」でオンラインインデックスの再構築を実行することもできます。

災害復旧計画を立てるときは、パーティション化も検討できます。データベースの部分的な回復に使用できます。たとえば、古いパーティションをメイン/現在のパーティションとは異なるファイルグループに置くことができます。そして、回復するときは、プライマリファイルグループ、次に現在のパーティションが存在するファイルグループを回復し、最後に古いパーティションが存在するファイルグループを復元できます。これにより、アプリケーションを停止する時間を短縮できます。

パーティショニングに関するキンバリー・トリップのこの素晴らしいビデオをチェックしてください。

古いデータをアーカイブするためにパーティションを作成する場合を除き、間違った理由でパーティションを作成しているため、それを行うべきではありません。