1

Microsoft SQL Server データベースでも追跡されるファイル システム上のファイルを管理するために使用される Web サービスがあります。FileSystemWatcher クラスを使用して追加されたファイルを監視する .NET システム サービスがあります。ファイルが追加されたコールバックが FileSystemWatcher から来ると、ファイルに関するメタデータがデータベースに追加され、かなりうまく機能します。

私は今、スケーラビリティの問題に直面しています。ファイルシステムに大量のファイルを立て続けに追加していますが、ファイルの追加でデータベースに打撃を与え、Web フロントエンドがロックされてしまいます。

データベースのスケーラビリティの問題にはまだ取り組んでいないので、軽減策を考え出そうとしています。おそらくファイルの追加をキャッシュして、5 分ごとにデータベースに書き出すことだけを考えていましたが、それがどれほど実用的かはわかりません。いずれにせよ、これはある時点で私たちのデータベースへの道を見つける必要があるデータであるため、ある時点で叩かれる必要があります。1 秒あたりに書き込まれるファイル データベース エントリの数を特定の量に制限することもできますが、その量がファイルが追加される速度よりも少なくなるリスクがあります。どうすればこれに最もよく取り組むことができますか?

4

3 に答える 3

2

SQL Server Service Brokerのようなものを使用することを考えたことがありますか? そうすれば、大量のエントリを一気にプッシュでき、データベースへの挿入を平準化できます。

基本的に、メッセージをキューにプッシュし、その後、挿入を実行する受信側ストアド プロシージャによって消費されます。Web インターフェイスの応答性の問題を解決するために、実行するレシーバーの最大数を制限できます。

ここに素敵な紹介紙があります。これは 2005 の場合ですが、2005 と新しいバージョンの SQL Server の間で大きな変更はありません。

于 2013-01-08T21:53:54.310 に答える
1

パフォーマンスの問題があり、 Waits や Queuesなどのパフォーマンス調査手法を使用してアプローチする必要があります。実際の問題を特定したら、解決策について話し合うことができます。

これは単なる推測ですが、通知の「メタデータの更新」コードが単純な前方挿入であると仮定すると、通知ごとに 1 つのトランザクションを生成していることが問題になる可能性があります。これにより、コミット フラッシュの待機が発生します。Diagnosing Transaction Log Performanceを参照してください。バッチ コミット (コミットする前に複数の通知を集約する) は、標準的なソリューションです。

于 2013-01-08T22:01:26.603 に答える