MS SQL Server で多数のテーブルを管理する最善の方法は何ですか?

Question

この質問は別の質問に関連しています。
複数のファイルグループがあるとデータベースの速度が向上しますか?

私たちが開発しているソフトウェアは、MS SQL Server 2005 を使用してリレーショナル データを保存する分析ツールです。最初の分析は (数百万行または数十億行のデータを処理しているため) 遅くなる可能性がありますが、以前の分析を迅速に呼び出すにはパフォーマンス要件があるため、各分析の結果を「保存」します。

現在のアプローチは、分析結果を一連の「実行固有」テーブルに保存することですが、分析は非常に複雑なので、分析ごとに 100 ものテーブルが必要になる可能性があります。通常、これらのテーブルは分析ごとに数百 MB を使用します (これは、数百 GB、場合によっては数 TB のソース データと比較すると小さいです)。しかし、全体としては、ディスク容量は私たちにとって問題ではありません。テーブルの各セットは 1 つの分析に固有であり、多くの場合、これによりソース データを参照するよりもパフォーマンスが大幅に向上します。

保存された分析結果が十分に蓄積されると、このアプローチは破綻し始めます。より堅牢なアーカイブ/クリーンアップ機能を追加する前に、テスト データベースは数に達していました。 百万 テーブル。しかし、実稼働環境であっても、100,000 を超えるテーブルがあることは無理ではありません。Microsoft は、sysobject のサイズに非常に大きな理論上の制限 (約 20 億) を設けていますが、データベースが 100,000 を超えると、CREATE TABLE や DROP TABLE などの単純なクエリの速度が大幅に低下する可能性があります。

私たちのアプローチについて議論する余地はありますが、より多くの背景がなければそれは難しいかもしれないと思うので、代わりにより一般的な質問をしたいと思います。非常に多くのテーブルを作成する必要がある場合、それらを管理するための最良の方法は何でしょうか?複数のファイルグループ?複数のスキーマ/所有者?複数のデータベース?

別のメモ:私は、「問題にハードウェアを投入するだけ」という考えにはあまり興味がありません（つまり、RAM、CPU パワー、ディスク速度を追加します)。しかし、特に (たとえば) RAM の追加や複数のファイル グループの使用が大規模なシステム カタログの管理にどのような影響を与えるかを誰かが明確に教えてくれる場合は、その可能性も排除しません。

Answer 1

最終的にデータベースを複数のデータベースに分割することになりました。したがって、メイン データベースには 1 つ以上の「実行」データベースを参照する「データベース」テーブルが含まれており、それぞれのデータベースには個別の分析結果セットが含まれています。次に、メインの「実行」テーブルにはデータベース ID が含まれ、保存された結果を取得するコードにはすべてのクエリに関連するデータベース プレフィックスが含まれます。

このアプローチにより、各データベースのシステム カタログがより合理的になり、コア/永続テーブルと動的/実行テーブル間の分離が向上し、バックアップとアーカイブの管理も容易になります。また、複数のファイル グループを使用することでデータを複数の物理ディスクに分割することもできます。全体として、現在の要件を考慮すると、これはうまく機能しており、予想される成長に基づいて、私たちにとってもうまく拡張できると考えています。

また、SQL 2008 は SQL 2000 や SQL 2005 よりも大規模なシステム カタログをうまく処理できる傾向があることにも気づきました。(この質問を投稿した時点ではまだ 2008 にアップグレードしていませんでした。)

Answer 2

最初にシステム全体を確認することなく、キーの一部として RunID を使用して履歴実行を結合テーブルに保存することをお勧めします。ここでは次元モデルも関連する可能性があります。このテーブルは改善のためにパーティション化することができ、これによりテーブルを他のファイル グループに分散することもできます。

もう 1 つの方法は、各実行を独自のデータベースに入れてからそれらを切り離し、必要な場合にのみ (読み取り専用形式で) アタッチすることです。

マスター データベースまたはモデル データベースがこの種の動作に対して最適化されていないため、CREATE TABLE および DROP TABLE のパフォーマンスが低下している可能性があります。

また、データベース設計の選択について Microsoft に相談することをお勧めします。

Answer 3

テーブルはすべて異なる構造ですか?それらが同じ構造であれば、単一のパーティション化されたテーブルで済む可能性があります。

それらが異なる構造であっても、ディメンション列の同じセットのサブセットにすぎない場合でも、適用されない列に NULL を含む同じテーブル内のパーティションにそれらを格納できます。

これが分析 (デリバティブ価格計算など) であれば、計算実行の結果をフラット ファイルにダンプし、フラット ファイルからロードすることで計算を再利用できます。

Answer 4

これは、あなたが取り組んでいる非常に興味深い問題/アプリケーションのようです。ぜひこのようなことに取り組みたいと思っています。:)

問題の表面積が非常に大きいため、支援を開始するのが困難になります。投稿では明らかになっていないソリューションのパラメータがいくつかあります。たとえば、実行分析テーブルをどのくらいの期間保存する予定ですか?他にも尋ねなければならない質問がたくさんあります。

本格的なデータ ウェアハウジングとデータ/テーブルのパーティショニングを組み合わせる必要があります。保持およびアーカイブしたいデータの量に応じて、テーブルの非正規化と平坦化を開始する必要がある場合があります。

これは、Microsoft に直接連絡することが相互に利益をもたらす可能性がある非常に良いケースです。Microsoft は他の顧客に紹介できる良い事例を入手し、あなたはベンダーから直接支援を受けることができます。