3

いくつかのリレーショナル列と、かなり大きなデータのチャンクを保持する 1 つの XML 列を含むテーブルがあります。データベースを使用する単純な Web サービスもあります。XML 列内の特定の要素のすべてのインスタンス、特定の要素のすべての個別の値のリストなどについてレポートできる必要があります。

要素の個別の値すべてのリストを取得できましたが、それ以上のことはできませんでした。C# では非常に単純に見えることを実行するために、非常に複雑な T-SQL コードを作成することになりました。つまり、このテーブルのすべての行を調べて、これ ( XPath | XQuery | XSLT ) を XML 列に適用します。リレーショナル列をフィルター処理してデータ量を減らすことができますが、一部のクエリでは依然として大量のデータです。

私の計画は、SQL Server (私は 2008 SP2 を使用しています) にアセンブリを埋め込み、特定のクエリに対してその場でインデックス付きビューを作成することでした (このビューをクリーンアップする他のロジックが必要です)。これにより、ネットワーク トラフィックを抑えることができ、Excel や MSRS レポートなどのツールを安価なユーザー インターフェイスとして使用できる可能性もありますが、多くの人が「SQL アセンブリではなくアプリケーション ロジックを使用するだけ」と言っています。 . （私はここで間違ったツリーを完全に吠えている可能性があると思います）.

大量のデータを Web サービスに取得し、そこで処理を行うことにも利点があります。SQL Server 環境による制約が少なくなり (その中に住んでいないため)、セットアップ プロセスがより簡単になります。しかし、ネットワーク経由で大量のデータを取り込み、処理中にメモリに保存し、その一部を破棄していることは確かです。

ここでアドバイスをいただければ幸いです。

ありがとう

編集：

ありがとうございます。問題は、ファイルのテーブルに行を生成していて、各ファイルが複数の結果を持つ可能性があり、特定のビルド ジョブを実行するたびにこれを行っていたことです。これをテーブル ビューにフラット化したかったのです。

このビルド ジョブを実行するたびに、数千のファイルのいくつかの属性がチェックされ、場合によっては、これらの各テストで数千の結果が生成されていました (MSIVAL テストが最悪の原因でした)。

答えは (当たり前!) 、データベースに入る前にフラット化することです! あなたのフィードバックに基づいて、各ファイルの各テストの各結果の行を作成してみることにしました。XML にはその 1 つの結果の詳細のみが含まれていました。これにより、クエリがはるかに簡単になりました。もちろん、このツールを実行するたびに数十万行になりますが、パフォーマンスははるかに優れています。ビルド ジョブによって出力される結果のクラスの 1 つのフラット化されたバージョンを作成するビューができました。これは、200,000 を超えて返され、5 秒未満かかります。これまでの同等の (複雑な) クエリの場合は約 3 分でした。よりフラットなルートで、古い (データベースではない) バージョンの XML ファイル処理に 10 ～ 30 分かかります。

現在、接続回数に問題がありますが、それを修正する方法について考えています。

再度、感謝します！+1 のすべてのラウンド

4

2 に答える 2

2

TSQL で標準の xml ツールを使用することをお勧めします。( http://msdn.microsoft.com/en-us/library/ms189075.aspx )。これを使用したくない場合は、別のマシンで xml を処理することをお勧めします。SQLCLR は小規模な関数には最適ですが、使用できるメソッドに制限があるため、より高度なことをしようとすると、フラストレーションがたまる傾向があります。

于 2011-05-26T19:58:12.530 に答える
1

あなたが求めているのは、実際には大きなバランスをとる行為であり、それはいくつかの要因に完全に依存しています. まず、データベースの現在の負荷は? すでに負荷が高いデータベースでこれを実行している場合は、おそらく Web サービスでこの解析を実行したいと思うでしょう。XML のシュレッディングとクエリは、特にスキーマが定義されていないインデックスのない列に対して行う場合、SQL Server では非常にコストのかかる手順です。スキーマとインデックスはこの処理のオーバーヘッドを軽減しますが、XML 解析が安価ではないという事実を排除することはできません。次に、処理するデータの量です。ネットワークを介してプッシュするには、データが多すぎる可能性があります。サーバーの場所とデータ量に応じて、

最後に、あなたのマシンの相対的なスペックは? Web サービス マシンのメモリが少ない場合、XML を解析しようとして仮想メモリの内外でデータをスラッシングし、パフォーマンスを低下させます。おそらく、最も強力なデータベース ハードウェアを実行しておらず、XML の細断処理を行うと、データベース マシンに搭載されている CPU のパフォーマンスが大幅に低下する可能性があります。

結局のところ、実際に知る唯一の方法は、両方の方法を試して、自分にとって意味のあるものを見つけることです. LINQ to XML は、T-SQL に押し込まれた XQuery よりも XML を解析する洗練された方法であるため、Web サービス マシンでの開発はほぼ間違いなく簡単になります。あなたが質問で提供した情報を考えると、レポート目的でデータベース内のすべての行または少なくともほとんどの行で XML 解析を行っているため、長期的には T-SQL のパフォーマンスが向上するということです。その種の情報をネットワーク経由でプッシュするのは、見苦しいものです。とはいえ、パフォーマンスがそれほど重要でない場合は、アプリケーション サーバーですべての解析を行うという、より簡単で保守しやすい方法を採用することについて、言及すべきことがあります。

于 2011-05-26T20:56:41.657 に答える