2

当社は、テキストファイルを解析するための内部プロジェクトを開発しています。これらのテキストファイルは、通常の式を使用して抽出されたメタデータで構成されています。10台のコンピューターが24時間年中無休でテキストファイルを解析し、抽出されたメタデータをハイエンドのIntel Xeon SQLServer2005データベースに供給しています。

簡略化されたデータベーススキーマは次のようになります。

アイテム

| Id | 名前|
| ---- | -------- |
| 1 | サンプル|

Items_Attributes

| ItemId | AttributeId |
| -------- | ------------- |
| 1 | 1 |
| 1 | 2 |

属性

| Id | AttributeTypeId | 値|
| ---- | ----------------- | ------- |
| 1 | 1 | 500mB |
| 2 | 2 | 1.0.0 |

AttributeTypes

| Id | 名前|
| ---- | --------- |
| 1 | サイズ|
| 2 | バージョン|

内部に異なるメタデータを持つ多くの異なるテキストファイルタイプがあります。すべてのテキストファイルに対して、Itemおよび抽出されたすべてのメタデータ値に対して、Attribute.

Items_Attributes allow us to avoid duplicate Attribute values which avoids database size to increase x^10.

This particular schema allows us to dynamically add new regular expressions and to obtain new metadata from new processed files no matter which internal structure they have.

Additionally this allow us to filter the data and to obtain dynamic reports based on the user criteria. We are filtering by Attribute and then pivoting the resultset (http://msdn.microsoft.com/en-us/library/ms177410.aspx). So this example pseudo-sql query

SELECT FROM Items WHERE Size = @A AND Version = @B

would return a pivoted table like this

| ItemName | Size  | Version |
|----------|-------|---------|
| Sample   | 500mB | 1.0.0   |

The application has been running for months and performance decreased terribly at the point is no longer usable. Reports should take no more than 2 seconds and Items_Attributesテーブルは週に平均10,000,000行増加します。すべてが適切にインデックス化されており、クエリ実行プランの分析と最適化にかなりの時間を費やしました。

だから私の質問は、レポートの実行時間を短縮するためにこれをどのようにスケーリングしますか？

私たちはこの可能な解決策を持ってきました：

  • ハードウェアを追加購入し、SQLServerクラスターをセットアップします。（適切な「クラスタリング」戦略に関するアドバイスが必要です）
  • HBaseのようなキー/値データベースを使用します（問題が解決するかどうかはわかりません）
  • RDBMSではなくODBMSを使用する（db4oを検討してきました）
  • ソフトウェアをクラウドに移動します（経験はありません）
  • 実行時に静的にレポートを生成します。（私たちは本当にしたくありません）
  • 一般的なレポートの静的インデックスビュー（パフォーマンスはほぼ同じ）
  • スキーマの非正規化（一部のレポートには、1回のクエリで最大50個のテーブルが含まれます）
4

7 に答える 7

2

正確なテーブルメタデータ（インデックスの詳細とともに）、正確なクエリテキスト、および実行プランを投稿することから始めます。

現在のテーブルレイアウトでは、次のようなクエリがあります。

SELECT FROM Items WHERE Size = @A AND Version = @B

(Size, Version)このようなインデックスを作成することは不可能であるため、で複合インデックスを使用することでメリットを得ることができません。

に自己結合が含まれるため、インデックス付きビューを作成することもできませんattributes。

おそらく最良の決定は、次のようにテーブルを非正規化することです。

ID名サイズバージョン

にインデックスを作成します(size, version)

于 2009-06-16T15:14:08.550 に答える
2

おそらく、エンティティ属性値データベースモデルの落とし穴に関するSQL Server CATチームによるこのホワイトペーパーが役立つ可能性があります：http ：//sqlcat.com/whitepapers/archive/2008/09/03/best-practices-for-semantic-data -modeling-for-performance-and-scalability.aspx

于 2009-06-16T15:15:00.203 に答える
2

そのようなスキーマで多くの時間を費やしました。彼らは決してうまく機能しません。最良の方法は、必要に応じてデータを次の形式で保存することです。

| ItemName | サイズ| バージョン| | ---------- | ------- | --------- | | サンプル| 500mB | 1.0.0 |

その後、ピボットする必要はありません。ところで、元のEAVスキーマを「正規化」と呼ばないでください。正規化されていません。

于 2009-06-16T16:26:44.693 に答える
1

OLTPトランザクション用に最適化されたデータベースでいくつかのOLAPクエリを発行するように見えます。詳細がわからない場合は、実行しているクエリの種類に合わせて最適化された別の「データウェアハウス」を構築することをお勧めします。これには、データの集約（可能な場合）、非正規化、および1日ほど前のデータベースの作成が含まれます。毎日または任意の間隔でデータを段階的に更新します。

于 2009-06-16T15:24:14.163 に答える
1

正確なDDLとインデックスを投稿してください。ID列にインデックスがある場合、クエリはスキャンになります

このようなものの代わりに

SELECT FROM Items WHERE Size = @A AND Version = @B

あなたはこれをする必要があります

SELECT FROM Items WHERE ID = 1

つまり、テキスト値を取得し、インデックスを作成しているIDを見つけて、それをクエリとして使用し、代わりに結果を返す必要があります。

おそらく、データを分散するためのパーティショニング機能を検討することもお勧めします

クラスタリングはパフォーマンスではなく可用性のために行われます。一方のノード（アクティブクラスター）が停止すると、もう一方のノード（パッシブクラスター）がアクティブになります。もちろん、アクティブアクティブクラスタリングもありますが、それは別の話です。

于 2009-06-16T15:28:07.820 に答える
0

短期的な修正は、水平分割を使用することです。私はあなたの最大のテーブルがであると仮定していますItems_Attributes。このテーブルを水平方向にパーティション分割して、各パーティションを個別のディスクコントローラ上の個別のファイルグループに配置することができます。

ItemIdこれは、一度にすべてのレポートを作成しようとしていないことを前提としています。

于 2009-06-16T15:20:22.533 に答える
0

1回のクエリで50個のテーブルについて言及します。SQL Serverは単一のモノリシッククエリで最大256のテーブルをサポートしますが、このアプローチを採用すると、オプティマイザーが効率的なプランを作成する可能性が低くなります。

現状のスキーマに慣れている場合は、レポートクエリを一連のステップに分割して、結果を一時（＃）テーブルに具体化することを検討してください。このアプローチにより、クエリの最も選択的な部分を個別に実行でき、私の経験では、パフォーマンスが大幅に向上します。クエリは一般的に保守性も高くなります。

また（少し長い目で見れば、これは）どのSQLサーバーのバージョンを使用しているかはわかりません。ただし、SQL 2005を使用している場合は、レポートに含まれるテーブルの数とデータの量を考えると、SQLサーバーが少なくともSP2にパッチされていることを確認する価値があります。

数億の行数を持つテーブルを使用してETLプロジェクトに取り組みましたが、SQL 2005 RTM / SP1のクエリオプティマイザーでは、1つ以上のテーブルがこのスケールの。この問題はSP2で解決されました。

于 2009-06-17T07:39:29.087 に答える