0

これは、読者が引き続き利用できるようにする必要がある、頻繁にインデックス付けされたファクト タイプ テーブルにデータをすばやく取得するための最良の方法として、パーティションの切り替えを明確に決定した後の私の以前の質問へのフォロー アップです。

これは最善の方法のように思えますが、複数 (5 人未満) のユーザーが同時に一括挿入し、新しいデータにインデックスを付け、インデックス付きビューに表示する (ない) という要件を実際に満たすには十分ではありません。必ずしも実際のインデックス付きビューであり、インデックスに依存する選択のみ)。

パーティショニングの考え方は、各パーティションとそのパーティションをルートとするインデックス サブツリーを並行して読み取り専用としてロックし、作業テーブルにコピーし、新しいデータを挿入/更新し、インデックスを再構築してからメイン テーブルに戻すというものでした。したがって、読者は影響を受けません。

問題は、単一の作業テーブルです。各並列一括挿入には独自のコピーが必要であり、切り替えを可能にするためにメイン テーブルと同じ制約が適用されます。

これまでのところ、このボトルネックを回避しようとしていくつかの壁にぶつかりました。

  1. 同じパーティション関数を使用して、作業テーブルをパーティション分割してみました。パーティションごとにインデックスを無効にして、別のインデックスを再構築している間、パーティションに挿入することはできないため、これは機能しません。
  2. 作業テーブルとして一時テーブルを作成します。同じインデックス名を使用できますが、制約を動的に作成することは簡単ではなく、とにかくそれを切り替えることができないため、これは機能しません。
  3. 名前付き作業テーブルの固定セットがありますか? ストアド プロシージャが 1 つだけになるように、1 つを選択してエイリアスで操作するにはどうすればよいですか?
  4. 動的 SQL ? 私はその道を避けるために一生懸命努力してきました。そのままでは複雑です。

大きな挑戦ですが、ボトルネックを受け入れる前に何かアイデアはありますか? Sql 2012 は役に立ちますか? 適切なデータウェアハウスはこれにどのように対処しますか?

4

1 に答える 1

3

適切なデータウェアハウスはこれにどのように対処しますか? 妥協して、EDW の現実的な目標を設定します。データ ウェアハウスは、すべての人にとってすべてではありません。実装しているものは、(技術者/アナリストだけでなく) ビジネスにとって最適なソリューションであることを確認してください。経験豊富な同僚や専門家から解決策を見つけられない場合、目標は現実的ですか?

ジャンプするすべてのフープにコストを関連付けます。データは本当に最新のものである必要がありますか? パーティションの複製とインデックスの再構築を絶えず行っており、現在のソリューションでは IOPS の需要に対応できないため、ストレージにさらに 20 万ドルを費やす必要があると言ったらどうでしょうか? ある時点で、彼らはそれが無料ではないことに気付くでしょう。ただ断る必要はありませんが、関連するコストについて現実的かつ率直に考える必要があります。さらに、ストレージ管理者も感謝します。

2012 に関しては、アナリストのすべての検索要求をカバーするために使用している現在のすべての非クラスター化を削減または置き換えることができる新しい列ストア インデックスがあります。これは高度に圧縮されており、さまざまな検索引数をカバーし、新しいバッチ実行モードを利用しています。これは、ファクト テーブルで頻繁に実行されるような選択性の低いクエリで最適に実行されます。1 つの問題は、更新を直接行うことができないことです。パーティションをステージング テーブルに切り替え、列ストアをステージング テーブルにドロップし、ステージング テーブルを更新し、列ストアを追加し直してから、パーティションをファクト テーブルに戻す必要があります。多くのように聞こえますが、これらの非クラスター化をすべて維持するよりも大幅に高速で、必要な IO が少なくなる可能性があります。

私の質問は常に「常に変化している場合、それは本当にファクト テーブルですか?」というものでした。これはOLTPではありませんか？トランザクションを相殺してみるか、少なくともスケジュールされたオフピーク時間にすべての更新をプッシュしてください。ファクト テーブルの更新は過去のものになりつつあります。すべての大企業は、データ ウェアハウス用の「更新は眉をひそめる」列指向アーキテクチャに向かっています。PowerPivot と Analysis Services 表形式モデルは、列ストア テクノロジに基づいて構築されています。

最後に、Kimballs の DW Toolkit の書籍を確認してください。彼は、ベスト プラクティスを示し、エッジ ケース シナリオをカバーするいくつかの文書を持っています。彼らから学んだことは、データ ウェアハウス開発は単なるデータベース開発ではないということでした。また、政治や、ビジネスに最適なものにリソースを集中させることも含まれます。

于 2012-10-20T05:33:14.370 に答える