>> はじめに |
今月からはSharePlexが持つ機能や性能についてご紹介していきます。 まずは、SharePlexが誇るレプリケーションの高速化アーキテクチャについてです。
>> コミットを待たずにレプリケーションするのでリアルタイム |
バッチ処理などの大量更新時には、1つのトランザクションの時間が長くなる場合があります。SharePlexの場合には、コミットを待たずに発生したトランザクションの内容を逐次Capture (キャプチャー) プロセスによって取得し、最終的にターゲット側へと反映を行います。
そのため、ソース側でcommit (コミット) が行われた場合には、その内容が転送されると同時にターゲット側では、処理が完了することになります。つまり、途中のネットワークの転送遅延が少ない場合には、リアルタイム性がかなり高いということがわかります。
>> 他の論理レプリケーションソフトではどうしているの? |
SharePlexの場合には、コミットを待たずにリアルタイムに転送を行っていますが、他の論理レプリケーションソフトの場合には、commit (コミット) をソース側確認してから転送を行っているものが多いようです。
この場合、1つのトランザクションが短く、例えば極端に言えば1DML(Insert/Update/Delete)毎にcommit(コミット)を行っている状況では、違いはありません。
しかし、1つのトランザクションが長くなればなるほど、commit(コミット)の待ち時間が増えていきます。例えば極端な話をしますと、1つのトランザクションの実行に5分間かかったとします。その場合、SharePlexであれば、ターゲット側のデータ反映に対して、ほとんど影響を受けませんが、コミットを待ってから転送する仕組みの場合には、5分後にcommit(コミット)を確認してから、初めて転送を開始するので、その転送と反映にさらに時間がかかります。平均的に同じだけの反映時間がかかったと考えると、5分間の遅延の可能性があります。当然、この時間は、1つのトランザクションが長くなればなるほど、影響を及ぼすことになります。
>> なぜ他社製品もリアルタイムに転送しないの? |
コミットを待たない方がリアルタイム性が高いというご説明をしました。では、なぜ他社製品では同じような仕組みを持たないのでしょうか?
これは、単純にソース側で何の問題も発生しないという前提の場合には良いのですが、ソース側で万が一、トランザクションが取り消されるようなロールバックが行われた時の処理についての難しさがあります。
SharePlexでは、最初のバージョンをリリースしてから2012年現在で、14年に渡る開発経験があり、そうした豊富な技術力に裏付けられています。また、ロールバックについても、単純にソース側と同じようにロールバックするだけでなく、そのトランザクションのターゲット側への適用状況に合わせて調整する機能を持っています。これらの詳細については、また別途ご案内することにしましょう。
>> 製品選定の1つのポイントに・・・ |
できる限りリアルタイムな処理を希望されるお客様が多い中で、このコミットを待たないアーキテクチャは、大きな優位点になっています。特に日本のお客様の場合には、バッチ処理等を使用されるケースも多く、万が一の遅延をできる限り少なくしたい場合に有効です。
確認を行いたい場合には、1つのトランザクションの完了に5-10分くらいかかるバッチを作成して、実際に評価環境等で試してみてください。
>> まとめ |
次回も、高速化するアーキテクチャーの続編をご紹介します。