1

Web アプリケーション (asp.net + mssql) で販売履歴を表示するという非常に一般的なタスクがあります。次のような販売トランザクションのテーブルがあります。

 - SellerID (string)
 - Product PartNumber
 - Product ManufacturerName
 - ProductID (string uniq normalized PN+MN)
 - Date of sale
 - Price
 - Qty
 - Option 1
 - Option 2
 - Option 3

オプションは、いくつかの特定の属性 (契約番号など) です。

Qty と Amount の合計を含む productID でグループ化された販売データを表示する必要があります。また、SellerId、Date、および Options でフィルタリングできるようにする必要があります。したがって、ユーザーはテーブルを見る必要があります：

 - Part Number
 - Manufacturer Name
 - Sum(Qty)
 - Sum(Price)

また、ユーザーは表示された列でソートおよびフィルタリングし、ページを移動できます

現在、約 500 万件の販売レコードがあり、このようなグループ化、フィルタリング、および並べ替えを使用した «直接» クエリは時間がかかりすぎます (また、この Web サービスを複数の同時ユーザーが使用できるようにすることは考えていません)。

より高速に動作させるために、クエリで使用されているすべての基準でキャッシュ キーを作成し、クエリの結果全体を同じスキーム (およびキャッシュ キー) でキャッシュ テーブルにコピーしていました。ただし、キャッシュ テーブルが急速に大きくなる、キャッシュ テーブルにインデックスを作成するのが難しい (挿入が遅くなる) など、いくつかの欠点があります。

このタスクは非常に一般的であり、販売を扱うほとんどのビジネス アプリケーションで有名であると確信しています。

人々はこれらすべての問題をどのように解決するのでしょうか?

UPD：言及するのを忘れていました。

  1. 販売データの挿入はありません (以前は四半期に 1 回手動でロードしていました)

  2. オラップについて考えていましたが、実際に作業したことはありません。オラップを使うのは理にかなっていますか？

  3. 他のデータベースを使用することが理にかなっていれば、SQL Server に強く制約されることはありません。

4

1 に答える 1

2

問題の解決策は、クエリの組み合わせとデータの構造によって異なります。

あなたが説明していることについて、自然な形式は、真ん中にファクトテーブルを持つスタースキーマです。ただし、ファクト テーブルはおそらく現在のものにかなり近いものです。違いはレコードのサイズです。ファクト レコードは、"読み取り可能な" コンテンツの多くを参照テーブルに移動するため、各レコードは可能な限り小さくなります。次のようになります。

  • SellerID -- 整数 ID
  • ProductID -- 整数 ID
  • 販売日
  • 価格
  • 数量
  • オプション 1 -- smallint
  • オプション 2 -- smallint
  • オプション 3 -- smallint

次のようなもの：

  • 製品型番
  • 商品メーカー名
  • 販売者名

参考表になります。

これにより、ファクト テーブルがキャッシュに適したサイズに縮小される場合があります。

次に、インデックスの作成を開始します。フィルタリング基準に応じて、おそらく複数のインデックスが必要になるでしょう: (date, salesid, productid, option1, option2, option3)、(productid, date)、およびその他。インデックスの挿入には追加の労力が必要であることを認識しています。影響は、1 日あたりの挿入数によって異なります。意思決定支援システムの場合、定期的にデータを更新する「データ ラグ」を許容できるはずです。挿入をバッチ処理すると、インデックス作成のオーバーヘッドが軽減されます。

要件がリアルタイムのレポート作成である場合は、データを分割して、最新のデータが小さなパーティションに収まるようにすることを検討してください。パーティション化されたインデックスは小さいため、挿入のオーバーヘッドは小さくなります。

また、要件が本当に重い場合 (1 分間に大量のリアルタイム更新、多数のリアルタイム レポートのスライシングとダイシング、完全な履歴を必要とする多数のクエリ) の場合は、より多くのメモリに投資して、テーブルが簡単に収まるようにします。メモリー。途中で、中央のデータ構造を最適化して、追加のデータを保持する参照テーブルを使用して、ID と数値で構成されるようにすることができます。主キーでの結合は、データを保存するよりも高速です。そうしないと、何倍も大きくなります。

于 2013-07-21T00:31:23.833 に答える