1

以下で構成される ASP.NET MVC3 Web アプリケーションがあります。

  • ウェブサイト (MVC3)
  • データ アクセス サービス (WCF + EF)
  • データベース サーバー (SQL Server 2008 R2)

パフォーマンス上の利点のために、次のアーキテクチャを実装することが提案されました。

  • Web サーバー クラスタ (Web サイト + データ アクセス サービス)
    • ラウンド ロビン ロード バランシングがあります。
    • このクラスター内の各サーバーにはキャッシュ(読み取り専用) データベースがあります
    • 読み取り SPと書き込み SPの 2 つのカテゴリに明確に分類できる一連の SP があります。
    • 各読み取り SP はキャッシュ DBに接続し、各書き込み SP は書き込み DBに接続します。
  • レプリケーション/ミラーリングを備えたデータベース サーバー
    • これは書き込み DBです。
    • 変更されるたびに、すべての変更をすべてのキャッシュ DBに伝播します。
    • それに加えて、レプリケーション/ミラーリングが実装されているため、ダウンしたときのバックアップがあります。

これは非常に大雑把な考えであり、システムのパフォーマンスが向上するかどうかはわかりません。

それを支持する議論は80%の時間であり、操作は読み取り専用です。これらはキャッシュ DBで作成できます(読み取り専用に構成されているため、より高速です)。残りの20%は書き込み DBで作成できます。

しかし、私は次の質問があります：

  • 読み取り専用構成: 実際にキャッシュ DBを読み取り専用に構成できますか? Write DBは、変更されるたびに変更をプッシュする必要があるためです。
  • 同期: ネットワーク上でこのような複雑な状況が発生している中で、すべてが同期されていることを確認するのはどれほど簡単でしょうか? ネットワーク遅延: すべてを同期させるためのネットワーク オーバーヘッドについてはどうでしょうか?
  • 複雑さとメンテナンス: 追加のメンテナンス オーバーヘッドとシステムの複雑さを考慮する価値はありますか?
4

1 に答える 1

0

素敵なデザインです。これは、誰もが追加できる監査データベースを作成する方法について以前行った議論に似ていますが、更新または削除は不可能です。

ステータスが読み取り専用に設定されている場合、データベースを変更することはできないため、SQL Server でその機能を利用することはできません。読み取り専用データベースの本当の利点は、クエリを実行するときにロックを無視できることと、何も変わらないことを知って特殊なインデックスを作成できることだと思います。http://sqlblog.com/blogs/linchi_shea/archive/2007/10/01/performance-impact-setting-a-database-to-read-only.aspx (SQL 2005 の場合) によると、読み取り専用はそれほど大きくありません。

ある程度の一貫性を犠牲にしても構わないと思っている場合は、クエリの分離レベルを下げることができます。

2 つのデータベースを作成する利点の 1 つは、異なるデータベース サーバー間でデータベースを分離できることです。これにより、CacheDb サーバーの CPU 負荷とネットワーク負荷が 100% の場合でも、書き込み操作が成功することが保証されます。

書き込み DB はすべてのユーザーに書き込みを許可する (そしておそらく読み取りを禁止する?) と仮定しますが、キャッシュ DB はユーザーに読み取り権限のみを与え、特定のサービス アカウントには書き込み権限を与えます。

書き込み DB とキャッシュ DB の間のコンテンツの同期は SQL Server Integration Services (SSIS) を使用して行うことができ、転送ロジックの設計はそれほど難しくないと思います。両方のサーバーが同じ建物内にあり、その間にギガビット ネットワークがあるということは、転送のレイテンシが低くなることを意味します。

于 2012-10-04T10:11:49.233 に答える