2

トランザクション プログラミングは、今日の現代の開発では欠かせないものです。同時実行性とフォールト トレランスは、アプリケーションの寿命にとって重要であり、当然のことながら、トランザクション ロジックは実装が容易になりました。ただし、アプリケーションが成長するにつれて、トランザクション コードはアプリケーションのスケーラビリティに対してますます負担になる傾向があるようです。また、分散トランザクションとミラーリングされたデータ セットにブリッジすると、問題が非常に複雑になり始めます。データ サイズやアプリケーションの複雑さの点で、トランザクションが頻繁に問題の原因になり始めている点 (タイムアウト、デッドロック、ミッション クリティカルなコードでのパフォーマンスの問題など) は、修正やトラブルシューティングがより面倒であることに興味があります。または、それ自体がよりフォールト トレラントなデータ モデルを設計するよりも回避策を講じる必要があります。または他の手段を使用してデータの整合性を確保します。また、これらの影響を最小限に抑えたり、標準的なトランザクション ロジックを時代遅れにしたり、問題にならないようにしたりするのに役立つ設計パターンは何ですか?

--

編集：これまでのところ、妥当な品質の回答がいくつかありますが、追加の創造性を刺激しようとするために聞いたことのいくつかを取り上げるために、自分で回答を投稿すると思います。私が得ている回答のほとんどは、問題に対する悲観的な見方です。

もう 1 つの重要な注意点は、すべてのデッドロックが不十分なコード化された手順の結果であるとは限らないということです。場合によっては、異なる順序で類似のリソースに依存するミッション クリティカルな操作や、互いにステップする異なるクエリの複雑な結合があります。これは避けられない問題のように思えることもありますが、私はワークフローの再構築に参加して、この問題が発生する可能性が低い実行順序を容易にしています。

4

5 に答える 5

2

この問題をそれ自体で解決できる設計パターンはないと思います。優れたデータベース設計、優れたストア プロシージャ プログラミング、特にトランザクションを短くする方法を習得することで、ほとんどの問題が緩和されます。ただし、問題が発生しないという 100% 保証された方法はありません。

基本的に、私のキャリアで見たすべてのケースで、デッドロックとスローダウンは、ストアド プロシージャを修正することで解決されました。

  • すべてのテーブルが順番にアクセスされていることを確認することで、デッドロックを防ぎます
  • インデックスと統計を修正すると、すべてが高速になります (したがって、デッドロックの可能性が減少します)。
  • トランザクションの実際の必要性がなく、単に「見える」だけの場合もありました
  • 場合によっては、複数のステートメント ストアド プロシージャを 1 つのステートメント ストアド プロシージャに作成することで、トランザクションをなくすことができます。
于 2008-09-17T21:30:26.680 に答える
2

共有リソースの使用は、長期的には間違っています。既存の環境を再利用することで、ますます多くの可能性が生まれるからです。ビジービーバーを見直してください :) Erlang の進む道は、フォールトトレラントで簡単に検証可能なシステムを作成するための正しい方法です。

しかし、トランザクショナル メモリは、広く使用されている多くのアプリケーションにとって不可欠です。たとえば、数百万人の顧客を持つ銀行に相談する場合、効率のためにデータをコピーするだけではいけません。

モナドは、状態を変更するという難しい概念を処理するためのクールな概念だと思います。

于 2008-09-17T21:34:08.700 に答える
0

最小限の指示で、データベース レベルで変更を加えるようにしてください。

一般的なルールは、リソースをロックする時間をできるだけ短くすることです。T-SQL、PLSQL、Java on Oracle、または同様の方法を使用すると、各トランザクションが共有リソースをロックする時間を短縮できます。実際、データベース内のトランザクションは、行レベルのロック、マルチバージョン、およびその他の種類のインテリジェントな手法で最適化されています。データベースでトランザクションを行うことができれば、ネットワークの待ち時間を節約できます。ODBC/JDBC/OLEBD などの他のレイヤーとは別に。

プログラマーは、データベースの優れた点 (トランザクション、並列、分散) を取得しようとすることがありますが、データのキャッシュは保持します。次に、データベース機能の一部を手動で追加する必要があります。

于 2008-09-17T22:52:21.320 に答える
0

私が聞いたアプローチの 1 つは、バージョン管理された挿入のみのモデルを作成し、更新が発生しないようにすることです。選択中は、最新の行のみを選択するためにバージョンが使用されます。このアプローチで私が知っている欠点の 1 つは、データベースがかなり急速に大きくなる可能性があることです。

また、FogBugz などの一部のソリューションは、強制的な外部キーを使用しないことも知っています。SQL クエリ プランは、データが変更されていない場合でも、選択または更新中にリンク テーブルをロックできるため、これらの問題の一部を軽減するのにも役立つと思います。また、競合の激しいテーブルがロックされると、DeadLock または Timeout の可能性が高くなる可能性があります。

私はそれらを使用したことがないので、私はこれらのアプローチについてあまり知りません.

また、Carlo Pescio の最近の投稿からいくつかの資料を調べています。残念ながら十分な時間がありませんでしたが、資料は非常に興味深いようです。

于 2008-09-19T16:24:23.023 に答える
0

ここで「クラウド コンピューティング」について話している場合、その答えは、各トランザクションをクラウド内で発生する場所にローカライズすることです。

(ご指摘のとおり) パフォーマンスが低下するため、クラウド全体を一貫させる必要はありません。簡単に言えば、何がどこで変更されたかを追跡し、変更がシステム全体に伝播するときに複数の小さなトランザクションを処理します。

ユーザー A がレコード R を更新し、クラウドの反対側にいるユーザー B がそれを (まだ) 見ていない状況は、現在の厳格なトランザクション環境でユーザー A がまだ変更を行っていない場合と同じです。これは、更新の多いシステムで不一致につながる可能性があるため、システムは可能な限り更新を行わないようにアーキテクチャを設計する必要があります。データの集計に物事を移動し、正確な数値が重要になったら集計を引き出します (つまり、一貫性の要件を移動します)。書き込み時間から重要な読み取り時間まで)。

まあ、私のPOVだけです。この場合、アプリケーションにとらわれないシステムを想像するのは困難です。

于 2008-09-17T21:36:14.670 に答える