0

私の質問はこの質問と同じですが、少し追加します。私の問題は、Web アプリのユーザーが新しいバージョンのレコードを作成できることです。レコードのすべての新しいバージョンは、その特定のバージョンへの個々の変更を記録するために、50 の他の関連テーブルに対応する「新しいバージョン」を作成することになります。関連する約 50 のテーブルを含むこの新しいバージョンの作成は、トランザクション内で実行されます (エラーが発生した場合にすべての変更をロールバックするため)。多くの場合、この手順は遅くなります。当然のことながら、テーブルの「挿入」が多すぎる「長いトランザクション」が原因です。

このようなシナリオを実装するためのより良いソリューション/設計を検討しています。

  1. 特に複数のテーブルであまりにも多くの重複を作成する場合、同じレコードの「バージョン」を維持するためのより良い方法はありますか?
  2. 「すべての行バージョン」に挿入されるレコードが多すぎるため、設計自体は良いとは思いませんが、少なくとも差し迫った問題である「長いトランザクション」に対処したいと思います-これは時々遅延を引き起こします. 抜け道はないかもしれませんが、それでも質問したい - 「バージョン管理」をトランザクション内に配置しない場合、エラーが発生した場合にロールバックするより良い方法はありますか (トランザクションが他の OLTP をブロックしているように見えるため)クエリ - すべてのプライマリ テーブルに新しいバージョンを挿入するため)

バージョン管理クエリは現在約 10 秒間実行されますが、時々悪化します。どんな考えでも大歓迎です

4

1 に答える 1

1

「作成された」または「失敗した」メッセージをリアルタイムで返す必要がありますか? 以下もソリューションにとってやり過ぎかもしれませんが、スケーラブルなソリューションを作成します。

Web サーバーは、アクションを要求するメッセージを (ある種のキューに) 投稿できます。この時点で、ユーザーは引き続きサイトを使用して他のことを行うことができます。バックグラウンドの Windows サービスは、(Web サイトのコンテキスト外で) メッセージを処理し、(スタック オーバーフロー通知と同様に、Web サイト内のメッセージによって) ユーザーに通知するか、タスクが実行または失敗したことを電子メールで通知できます。

ほぼリアルタイムで分離された処理を行うことができる場合は、Windows サービスを変更してスケーリングできます。リクエストを管理するためのスレッド プールを持つことができます。そのため、負荷を制限するために一度に 5 つのスレッドしか実行できない場合があります。より多くのパフォーマンスの問題が発生した場合は、キューの 2 つ以上のプロセッサを持つことができるシステムをスケールアウトして開発できます (それは、それ自体の問題/複雑さを追加します)。

于 2012-03-21T09:26:57.210 に答える