4

SQLサーバーでのスケールアウトに問題があります。これは主にいくつかの理由によるものです：1）不十分に設計されたデータ構造、2）重労働およびビジネス/処理ロジックはすべてT-SQLで実行されます。これは、サーバーで分析を実行するために雇ったRedmondのMicrosoftSQL担当者によって検証されました。私たちは文字通り、コマンドタイムアウトを継続的に増やすことで問題を解決しています。これはばかげており、長期的な解決策としては適切ではありません。それ以来、次の戦略と一連のフェーズをまとめました。

フェーズ1：出血を止めるために、問題にハードウェア/ソフトウェアを投げます。

これには、キャッシングサーバーなどのいくつかの異なるものが含まれますが、ここで皆さんに質問したいのは、特に、新しいSQLサーバーでの双方向トランザクションレプリケーションの実装に関連しています。これを実装するための2つのユースケースがあります。

  1. この新しいSQL「処理ボックス」で長時間実行（およびテーブル/行のロック）SELECTを実行し、それらをキャッシュレイヤーにスローして、UIにキャッシュから読み取らせることを考えていました。これらのSELECTはレポートを生成し、Web上に結果を返します。

  2. ほとんどのビジネスロジックはSQLです。処理ロジックを実行するSELECT、INSERT、UPDATE、およびDELETEに対して実行中のクエリがいくつかあります。最終結果は、処理が完了した後（多くのカーソル）、実際にはINSERT、UPDATE、およびDELETEでいっぱいになります。これら2つのサーバー間の負荷を分散することが考えられます。

いくつか質問があります：

  1. これらは、双方向のトランザクションレプリケーションの優れたユースケースですか？

  2. このソリューションが「正しく機能」し、競合について心配する必要がないことを確認する必要があります。このソリューション内で競合が発生するのはどこですか？衝突を防ぐためにIDシードの増分をリセットすることに関するいくつかの記事を読みましたが、これは理にかなっていますが、UPDATE / DELETEまたは競合が発生する可能性のあるその他の場所をどのように処理しますか？

  3. 他にどのような問題が発生する可能性があり、注意する必要がありますか？

  4. この問題に対するより良い解決策はありますか？

フェーズ2：ロジックを.NETに書き直し、SQLストアドプロシージャを最適化して、セットベースの操作のみを実行するようにします。

これには明らかにしばらく時間がかかります。そのため、ユーザーが経験している苦痛を止めるために実行できるいくつかの準備手順があるかどうかを確認したかったのです。

ありがとう。

4

1 に答える 1

5

私見の双方向レプリケーションは、「うまくいく」とはかけ離れています。更新の競合を防ぐには、綿密な計画が必要です。これにより、すべての「処理」が慎重に調整され、重複するデータが処理されることはありません。マスター マスター レプリケーションは、実行するのが最も難しいソリューションの 1 つです。

これを考慮してください。コードをほとんど変更せずに安価な 2 倍のスケールアウトを提供するソリューションを思い描いています。このようなソリューションは非常に便利で、どこにでも展開されることが予想されます。まだどこにも見られません。

(より一般的な) MySQL マスター/マスター デプロイに関する落とし穴や警告を説明している多くのブログや記事を検索することをお勧めします (例:マルチマスター レプリケーションをデプロイする必要がある場合は、最初にお読みください)。価値がある。

私はあなたがしているすべての詳細を持っているわけではありませんが、アプリケーションに焦点を当てます. 問題に短期的に投資したい場合は、スケールアウト (SSD/Fusion ドライブ、より多くの RAM) を検討する前に、安価なスケールアップが使い果たされていることを確認します。また、ロックが主な問題である場合は、スナップショットの分離レベルを調査し、コミットされたスナップショットを最初に読み取ります。

于 2012-11-21T23:09:36.847 に答える