3

スケジュールに従って新しいデータの不規則な一括ロードを提供しながら、リーダーに高可用性を必要とするデータベースのデータ インポート メカニズムを作成しようとしています。

新しいデータには、新しいデータセットが追加された 3 つのテーブルだけが含まれ、それらによって参照される多くの新しいデータセット アイテムと、それらを参照するいくつかのデータセット アイテム メタデータ行が含まれます。データセットには、数万のデータセット アイテムが含まれる場合があります。

データセット アイテムは、WHERE 句のデータセット ID を含む大部分 (すべてではない) の読み取りを含む列のいくつかの組み合わせで大量にインデックス化されます。インデックスが原因で、データの挿入が遅すぎて流入に追いつくことができなくなりましたが、これらのインデックスのリーダーが優先されるため、メイン テーブルのインデックスを削除することはできませんが、コピーを作成する必要があります。

したがって、クエリ対象のテーブル/ビューの一部になるようにすばやく切り替える前に、コピー、挿入、および再インデックス化するある種の作業テーブルが必要です。問題は、その切り替えをすばやく実行するにはどうすればよいかということです。

外部キーであるデータセット ID の範囲でデータセット項目テーブルを分割することを検討しましたが、これは主キーの一部ではないため、SQL Server はそれほど簡単ではないようです。古いデータ パーティションを、すぐにインデックス付けされた更新されたバージョンに切り替えることができません。

パーティション化、スナップショット分離、パーティション化されたビューの使用を提案するさまざまな記事がありますが、古いデータ (日付でパーティション化) の一括読み込みとアーカイブ、またはインデックス作成を考慮しない単純なトランザクション分離について、この状況に直接答えるものはありません。

この一見一般的な問題に直接取り組む例はありますか?

新しいデータを大きなインデックス付きテーブルに一括ロードするときに、インデックスが無効になる時間を実際に最小限に抑えるために、人々はどのような戦略を持っていますか?

4

1 に答える 1

1

列のパーティション分割では、列が主キーの一部ではなく、クラスター化インデックス キーの一部である必要があることに注意してください。2つは独立しています。

それでも、パーティショニングは、テーブルに対して実行できる操作に多くの制約を課します。たとえば、切り替えが機能するのは、すべてのインデックスが整列されており、変更中のテーブルを参照する外部キーがない場合のみです。

これらすべての制限の下でパーティショニングを利用できる場合、これがおそらく最良のアプローチです。分割されたビューは柔軟性を高めますが、同様の制限があります。すべてのインデックスは明らかに整列されており、着信 FK は不可能です。

データの分割は簡単ではありません。これは、ウィザードをクリックして実行するだけのソリューションではありません。一連のトレードオフは非常に複雑です。

于 2012-08-13T11:56:16.257 に答える