DBMotoのレプリケーションパフォーマンスを向上させる方法

DBMotoのレプリケーションはデフォルト設定のままお使いいただいても、十分に性能を発揮できるようになっていますが、適宜環境に合わせて設定を変更していただければパフォーマンスの向上を望めます。

1 ■概要
2 ■ミラーリングとシンクロナイゼーションにおけるログチェック間隔
3 ■履歴・ログをデータベースに保存する
4 ■SQL ServerおよびMySQLへのリフレッシュパフォーマンスを改善する
5 ■ミラーリング時の読み込み量を変更する
6 ■ミラーリング時のターゲット更新単位を変更する
7 ■スレッド設定の変更でパフォーマンスを上げる
8 ■リフレッシュ時のSELECT COUNTを行わない
9 ■ターゲットテーブルへの仮想PK設定時のパフォーマンス向上方法

■概要

DBMotoの処理パフォーマンスは、１つ変わるだけでも大きく変わることがあります。DBMotoの処理時間は利用可能なリソースに依存します。

DBMSサーバとDBMotoが実行されているサーバとの間の接続のネットワーク帯域
関係するマシンのプロセッサ数
プロセッサのタイプ
利用可能なメモリ
CPU使用率

DBMotoのレプリケーションデザインは、レプリケーション処理中のボトルネックを回避するよう、慎重にバランスをとる必要があります。
気をつけるべき指標は以下になります。

ソースとターゲットの接続数
レプリケーション対象のテーブル数
レプリケーション対象のテーブルそれぞれのレコードサイズとレコード数
レプリケーションモード（リフレッシュ・ミラーリング・シンクロナイゼーション）
ソースデータベースの秒ごとのトランザクション数
データベース接続の開始およびクエリ処理を最適化するレプリケーショングループ

例えば、レプリケーションされるテーブルのサイズとトランザクション数は、単一のフルリフレッシュとその後の連続したミラーリングを実行するより、特定の期間はリフレッシュを連続して実行するほうが、便利であるかどうかを評価するのに重要です。

また、DBMoto Management CenterはDBMoto Dashboardへのアクセスを提供します。

これは指定したDBMotoメタデータと履歴ファイルまたは履歴データベースの内容をもとに、一定時間内のレプリケーションデータとパフォーマンスを分析するツールです。
選択したテーブルのセットにおける、それぞれのテーブルに対する以下の情報を供給します。

処理されたレコードの総計
処理に失敗したレコードの総計
レコードの総計
レプリケーションセッションの総計
単位時間あたりの、すべてのレプリケーションで処理されたレコードの総計
特定のレコードをレプリケーションするのにかかった平均時間

これにより、指定期間内の、レプリケーションによるセッション数やレプリケーションされたレコード数などを確認し、どのような設定を行うことが適切であるか、判断することが可能です。
詳細は下記弊社ブログ記事をご覧ください。
【DBMoto】レプリケーションの統計情報が一括で確認できるダッシュボード機能

上記を踏まえて、以下の設定を適用することにより、自社環境でパフォーマンスを改善できるかどうかを検討してください。

ミラーリングとシンクロナイゼーションにおけるログチェック間隔
履歴・ログをデータベースに保存する
SQL ServerおよびMySQLへのリフレッシュパフォーマンスを改善する
ミラーリングパフォーマンスを改善する
スレッド設定の変更でパフォーマンスを上げる
リフレッシュ時のSELECT COUNTを行わない
ターゲットテーブルへの仮想PK設定時のパフォーマンス向上方法

■ミラーリングとシンクロナイゼーションにおけるログチェック間隔

ミラーリングおよびシンクロナイゼーションモードでは、デフォルトでは60秒間隔でトランザクションログを参照しますが、よりリアルタイム性を追求したい場合は、15秒間隔に変更することが可能です。

ログチェックの頻度の変更は、以下の手順で行います。

Data Replicatorを停止するか、レプリケーションを無効化します。
レプリケーションを選択し右クリックします。
メニューからプロパティを選択します。
レプリケーションプロパティダイアログで、「優先」タブを開きます。
「参照間隔」フィールドの値を変更します。デフォルト値は60秒です。
「OK」を押し、レプリケーションプロパティダイアログを閉じます。

レプリケーションを有効化しData Replicatorを起動させれば、新しい間隔でレプリケーションが実施されます。
ただし15秒以内に処理が終わらない量のトランザクションが発生している場合、この設定を行うと処理が滞留してかえってリアルタイム性を損ないます。ご注意ください。

■履歴・ログをデータベースに保存する

履歴・ログはデフォルトでテキストファイルに保存されますが、大量のレプリケーションが実行されている場合、テキストファイルではなくデータベースに記録を保存すると、レプリケーション性能がよくなることがあります。

Data Replicatorを停止します。
Data Replicatorオプションを開きます。
Data Replicatorオプションダイアログで、ログタブを選択します。
「ログ出力先」フィールドで、ドロップダウンリストから、「データベース」を選択します。
メタデータ保存先のデータベース（デフォルトではローカルで使用されるSQL Server CE）、またはDBMotoで接続可能な任意のデータベースを選択します。
必要に応じて保存されるメッセージの数を制限できます。DBMoto Dashboardツールは時間に応じたパフォーマンスを表示するので、メッセージの数を制限することは、表示可能なデータの量を削減することに注意してください。
「履歴ログを有効」オプションにチェックを入れます。これにより履歴ファイルもデータベースに保存されます。
OKを押し、ダイアログを閉じます。

Data Replicatorを起動すると、設定にしたがいデータベースへの保存を開始します。

他のオプションに関しては以下の弊社ブログ記事をご覧ください。
DBMotoがサポートするログの出力先・・・ファイル、DB、Windowsイベントログ、Apache Log4Net

■SQL ServerおよびMySQLへのリフレッシュパフォーマンスを改善する

SQL ServerまたはMySQLに対するリフレッシュ性能を向上させる方法として、バルクインサートの設定を変更する方法があります。

ターゲット接続ウィザードにおいて、接続に使うドライバに、SQL ServerであればMicrosoft SQL Server .NET Data Provider、MySQLであればMySQL .NET Data Providerを選択していることが条件です。

Data Replicatorを停止するか、レプリケーションを無効化します。
レプリケーションプロパティを開き、優先タブを選択します。
リフレッシュオプションで、「Insertモード」がBulkInsertになっていることを確認します。
「ブロックサイズ」を調整します。概ね、50から100の間で最適なパフォーマンスを発揮しますが、実際の値は、デフォルトの設定値の場合と比較して設定してください。

レプリケーションを有効化しData Replicatorを起動させれば、レプリケーションで新しいバルクインサートのサイズが適用されます。

■ミラーリング時の読み込み量を変更する

AS400/SQL Server/Oracle/トリガー形式のミラーリング性能を向上させる方法として、ジャーナルからデータを読み込む量を変更する方法があります。
ミラーリング間に発生するトランザクションが大量にある場合に、このブロックサイズ設定は有効です。

DBMotoではジャーナルから読み込んだレコードを一時ファイルに保存します。もしファイルが多数のレコード、または少数ではあるがフィールド数が大きいレコードを含んでいると、パフォーマンスに影響が出ます。
この場合、一度に扱うレコードの数を制限することが可能です。
「最大ミラーリングブロックサイズ」プロパティの値を250にすれば、1度にレプリケーションするレコード数は250に限られます。

※画像はAS400のものですが、SQL Server/Oracleおよびその他のトリガー形式でも設定項目名は変わりません。

Data Replicatorを停止します。
ソース接続のリストからデータベースの接続を選択し、右クリックで開くメニューから「プロパティ」を選択します。
開いたソース接続プロパティダイアログから、「最大ミラーリングブロックサイズ」プロパティを探します。
レコードのサイズと、一度にミラーリングしたいレコードの数に応じて値を設定します。
「OK」をクリックして接続プロパティダイアログを閉じます。

■ミラーリング時のターゲット更新単位を変更する

DBMotoではレプリケーションの一貫性を保つため、ミラーリングではデフォルトで単一レコードの更新ごとにコミットを行います。ただこの場合、コミット単位が細かくなるため、ターゲットDBの性能によってパフォーマンスが低下することがあります。

これに対して、ソースがOracle、Microsoft SQL Server、IBM DB2 for i、 IBM DB2 LUW、 IBM Informixの場合（トランザクションログ方式がトリガーの場合は不可）、ソースでのコミット単位と同様のコミット単位でターゲットにまとめて、更新をコミットすることができます。この設定を行うことで、ソース側のコミット単位にもよりますが、パフォーマンスを向上させることができます。

Data Replicatorを停止します。
レプリケーション選択し、右クリックで開くメニューから「プロパティ」またはグループを選択し、「レプリケーションを編集」を選択します。
開いたレプリケーションプロパティダイアログの「優先」で、「コミットモード」プロパティを探します。
「CommitmentControl」に変更します。
「OK」をクリックし、プロパティダイアログを閉じます。

■スレッド設定の変更でパフォーマンスを上げる

マシンスペックが低く、かつVistaなどの古いOSを使用している場合に関して有効な方法です。
下記弊社ブログ記事に詳細がまとまっていますので、こちらをご参照ください。
[DBMoto]スレッド設定の調整でレプリケーション速度を向上させる方法

また、各レプリケーションを処理するスレッドごとに優先順位を設定することも可能です。
優先タブの「一般」から、スレッド優先順位で設定が可能です。

■リフレッシュ時のSELECT COUNTを行わない

DBMotoがリフレッシュを行う際は、ソーステーブルにあるレコードの数をSELECT COUNT文で取得してから、実際のデータをレプリケーションします。
このSELECT COUNT文は総レコード数をレプリケーション開始時に通知するために行われるものであり、レプリケーション処理そのものにはかかわりません。

SELECT COUNT文はInnoDBを使用しているMySQLなど、大量のレコードがあるテーブルに行うとタイムアウトエラーを起こす可能性があります。
タイムアウトエラーを起こす場合、DBMotoの設定でSELECT COUNT文の発行を行わないようにできます。

レプリケーションプロパティの、優先タブから、「レコード数をスキップ」をTrueに変更します。

■ターゲットテーブルへの仮想PK設定時のパフォーマンス向上方法

DBMotoではテーブルに主キーが設定されていない場合に、仮想PKという機能を使うことで、１つまたは複数のフィールドを疑似的にPKであると認識させてミラーリングレプリケーションを実施できます。

ターゲットに仮想PKを設定しているとき、ミラーリングの更新量が多い（特にUPDATE文）とレプリケーションのパフォーマンスが劣化することがあります。その際は、仮想PKと指定しているフィールドにINDEXを付与するとパフォーマンスが改善されます。

仮想PKに関しては、この弊社ブログ記事をご覧ください。
差分レプリケーションに必要なDBの主キーとDBMotoの仮想PK