大規模なSQL Serverデータベース設計の提案
MSSQL 2008 R2 Standardでデータベースを作成し、そこに多数のレコードを格納します。毎年1つのテーブルで2億件以上のレコードを見積もり、主にデータのUPDATEまたはDELETEをほとんど行わずにINSERTを実行しています。これは、履歴レコードを毎日挿入するデータアーカイブシステムです。ユーザーの要求に応じて、この履歴レコードに関するさまざまな種類のレポートを生成するため、懸念事項があり、技術的な入力とアドバイスが必要です。
- この種のアーカイブテーブルとデータベースを管理する最良の方法は何ですか？
これが私の意見です：
- 更新/削除がほとんどない場合は、ページフィル係数を95％に増やすことができます。これはスペースと読み取りを節約します。いくつかのテストを行います。
- 年などの幅広いカテゴリに基づいてテーブルを分割します。
- これらのパーティションを異なるファイルグループに配置します。
年間2億行はそれほど大きくありません（行が異常に大きくない限り）。適切なデータベース設計原則（正規化）に注意を払い、インデックス作成やパーティション分割などの標準機能を利用する必要があります。もちろん、適切なハードウェアも重要です。
ここには具体的なアドバイスをするのに十分な情報がありません。詳細な設計と実装についてサポートが必要な場合は、誰かを雇うことを検討してください。
あなたのデザインがあなたの挿入が常にテーブルの最後になることを可能にすることを確認してください。ヒントクラスタ化インデックス。
最小限に維持するために実行する必要があるレポートをサポートする非クラスター化インデックスはほとんどありません。これらのレポートは事前に生成されていますか？はいの場合は、この質問を検討してください。レポートの生成に2時間かかる場合は問題ありませんか（インデックスなし）または1分（インデックスあり）。たぶん、レポートのインデックスが1つ少なくなるまで2時間かかることは問題ありませんか？またはそうでないかもしれません？レポートが適切に事前生成されていない場合、これは別の問題です。ユーザーが待つのが好きではないため、レポートをサポートするためにより多くのインデックスを実装する必要があるかもしれません。
このデータベースをどのように説明するかから、多くの行を期待しているように聞こえ、データが追加され、大きく成長します。このシステムをバックアップする方法を検討しましたか？ほとんどのデータは同じで新しいものを追加するだけだと思いますか？このシステムのビジネス要件はわかりませんが、1〜2年でこれはかなりのサイズのデータベースになり、多くの完全バックアップを作成するのに問題が発生するようです。定期的に（毎週？）、差分（毎日？）、トランザクションログ（毎時？）を使用して1つの完全バックアップを作成することを検討してください。アーカイブシステムでは、サイズが問題になることがあります。