3

私たちは、受け取った請求の時間の経過とともに多数の値フィールドを取得するアドホック分析用のテーブルを設計しています。テーブル構造は基本的に (疑似コード) です。

   table_huge (
     claim_key int not null,
     valuation_date_key int not null,
     value_1 some_number_type,
     value_2 some_number_type,
     [etc...],
     constraint pk_huge primary key (claim_key, valuation_date_key)
   );

すべての値フィールドはすべて数値です。要件は次のとおりです。 テーブルには、最近 12 年以上 (できればそれ以上) の受理されたクレームが含まれている必要があります。各請求には、請求の開始から現在の日付までの各月末の評価日が含まれます。典型的な請求開始件数は、年間 50,000 ～ 100,000 件です。

これらすべてを合計すると、行数が 1 億程度のテーブルが予測されますが、ビジネスのニーズによっては、何年にもわたって 5 億にも達する可能性があります。テーブルは毎月再構築されます。消費者は選択するだけです。毎月の更新を除いて、更新、挿入、または削除は行われません。

私はこれをビジネス (消費者) 側から考えていますが、このテーブルの分析値を維持しながら IT コストを軽減することに関心があります。テーブルからの迅速なリターンについて圧倒的に心配しているわけではありませんが、テーブルに数十のクエリを投げて、1 日か 3 日ですべての結果を取得する必要がある場合があります。

議論のために、テクノロジ スタックが最新のハードウェアの 80 パーセンタイルにあると仮定しましょう。

私が持っている質問は次のとおりです。

  • 大量のテーブルに対するクエリの頻度が低いことを考えると、インデックスの費用対効果が過剰になるポイントはありますか?
  • SO コミュニティは 1 億行以上のテーブルの経験があり、管理方法に関するヒントを提供できますか?
  • データベース テクノロジの問題は IT に任せて解決するべきか、それともビジネス要件を抑えることを真剣に検討すべきか (そしてその理由は?)

これらはややソフトな質問であることは承知しており、構築する前にテストできる提案ではないことを読者が理解してくれることを願っています。

説明が必要な場合はお知らせください。読んでくれてありがとう！

4

4 に答える 4

6

まず第一に、技術的な問題を IT に任せる場合は、これが「問題なく機能する」ことを期待してください。特に、予算で「現在の 80%」のハードウェア レベルが許容される場合はなおさらです。

私は、エントリーレベルの古いハードウェアで MySQL の 2 億行以上を扱った経験があり、常に前向きな驚きを感じていました。

いくつかのヒント:

  • 毎月の更新時に、非プライマリ インデックスを使用せずにテーブルを読み込み、それらを作成します。最適な並列インデックス作成数を探します。日付がはるかに短いプロジェクト (約 10M) では、単純な「テーブルを作成してからデータをロードする」アプローチと比較して、ロード時間が 70% 短縮されました。

  • 同時クエリの数と複雑さを把握してみてください。これは、ハードウェアの決定に影響を与えます (同時実行数が少ない = IO が少ない、CPU が多い)。

  • それぞれ 64 ビットの数値フィールドが 20 個あり、2 億行を掛けるとします。正しく計算できれば、ペイロードは 32GB になります。安価なディスクを 64G RAM と交換すれば、IO のボトルネックが発生することはありません。

  • 必ず、テーブルスペースを読み取り専用に設定してください

于 2012-05-24T02:50:14.180 に答える
3

変更のみを保存するアンカー モデリングアプローチを検討できます。

行数が 100M からわずか 5M になり、行数が 100M からわずか 95% になると予想される非常に多くの行が繰り返されることを考慮すると、懸念事項のほとんどが取り除かれます。

この時点では、主にキャッシュの考慮事項です。テーブル全体が何らかの形でキャッシュに収まる場合、物事はかなり速く起こります。

「少ない」データ ボリュームの場合、次の構造はプレーン テーブルよりもクエリが遅くなります。ある時点で (データ量が増えるにつれて) 高速になります。その点はいくつかの要因に依存しますが、テストするのは簡単かもしれません。アンカー モデリングに関するこのホワイト ペーパーをご覧ください。10 ページのグラフを参照してください。

ここに画像の説明を入力

アンカーモデリングに関しては、次と同等です

ここに画像の説明を入力

モデリング ツールには自動コード生成機能がありますが、ドロップダウンに ORACLE もありますが、現時点では MS SQL サーバーのみを完全にサポートしているようです。コードヘルパーとして引き続き使用できます。

サポート コードに関しては、(最小) が必要になります。

  1. 最新のパース ビュー (自動生成)

  2. ポイントインタイム関数 (自動生成)

  3. この構造がロードされるステージング テーブル ( data-warehouse-loading のチュートリアルを参照)

  4. ステージングテーブルから構造体へのロード機能

  5. 繰り返し値を削除するための、各属性のプルーニング関数

自動生成コード パターンに従うことで、これらすべてを簡単に作成できます。

于 2012-05-25T13:34:38.207 に答える
1

進行中の更新/挿入がない場合、インデックスはパフォーマンスにマイナスの影響を与えることはなく、プラスの影響しかありません (このサイズのテーブルでは何桁も)。

さらに重大なことに、スキーマには深刻な欠陥があります。あなたが欲しいのは

Claim
    claim_key
    valuation_date

ClaimValue
    claim_key (fk->Claim.claim_key)
    value_key
    value

これは、実際に持っている値のみを格納するため、スペース効率が大幅に向上し、1 つの行の値の数が割り当てた列の数を超えた場合にスキーマを変更する必要がありません。

于 2012-05-24T02:41:53.207 に答える
0

パーティションの概念を使用して、実行するすべてのクエリにパーティション キーを適用すると、パフォーマンスがさらに向上します。

私たちの会社では、パーティションの概念で膨大な数のパフォーマンスの問題を解決しました。

もう1つの設計ソリューションは、テーブルが非常に大きくなることがわかっている場合、テーブルにこれ以上の制約を適用しないようにし、実行する前にロジックで処理し、行の連鎖を避けるためにテーブルに多くの列を持たないようにすることです問題。

于 2015-03-27T20:38:34.980 に答える