4

私が働いているビジネスでは、プライマリ データベースの読み取り負荷を軽減する方法について議論しています。

提案されているオプションの 1 つは、プライマリ データベースからスレーブ データベースへの一方向のライブ レプリケーションを行うことです。その後、アプリケーションはスレーブ データベースから読み取り、プライマリ データベースに直接書き込みます。そう...

  • アプリケーションがスレーブから読み取る
  • アプリケーションがプライマリに書き込む
  • プライマリ更新スレーブを自動的に

この方法の主な長所と短所は何ですか?

4

2 に答える 2

2

いくつかの短所：

  • 2点の失敗
  • セカンダリ データベースからすぐに利用できないため、アプリケーション ロジックでは、何かを書き込んでから読み取るまでの遅延を考慮する必要があります。

私が使用した戦略は、主要なレポート データを毎晩セカンダリ データベースに送信し、途中で非正規化することです。これにより、テーブルをロックして OLTP サーバーからリソースを盗む代わりに、そのデータベースで強力なクエリを実行できます。正式なデータ ウェアハウスやレプリケーション ツールは使用していません。むしろ、最新のデータがなくても問題のない問題のあるクエリを特定し、それらのクエリ専用のデータ構造をセカンダリ サーバーに作成しています。

「すべてを複製する」アプローチには間違いなく長所があります。

  • セカンダリにはすべてのデータがあるため、任意のアドホック クエリをセカンダリで実行できます。
  • プライマリ サーバーが停止した場合、セカンダリ サーバーをすばやく再利用して引き継ぐことができます。
于 2008-09-04T11:29:15.100 に答える
1

一方向のレプリケーションを使用していますが、同じアプリケーションからではありません。私たちのアプリケーションは master データベースに対して読み取り/書き込みを行っており、データはレプリカ データベースに同期され、レポート ツールはこのレプリカを使用しています。

アプリケーションが別のデータベースから読み取ることは望ましくないため、このシナリオでは、マスター データベースでファイル グループとパーティション分割を使用することをお勧めします。ファイル グループ (特に異なるドライブ上) を使用し、ファイルとインデックスをパーティション分割すると、パフォーマンスが大幅に向上します。

于 2008-09-04T11:39:19.897 に答える