では、実際に検証作業を行います
前回は、EqualumのExactly Once & Allの動作検証として、検証過程を制御するPythonベースのツールに関する紹介をさせて頂きました。
今回は、その検証ツールを実際に動かして処理された「オリジナル側」と「Equalumにより即時同期されたターゲット側」のテーブル状況を、SQLクライアントとして広く使われているDBeaverを使って確認して行きたいと思います。
因みに、今回の検証を行う謎のモチベーションとしては、もしかするとこんな事が出来たら何か良い事が有るかな？・・という「極めて個人的な興味に基づく妄想」によるものです（苦笑）。
前回の続きから・・・
まずは、検証用のデータをCDC設定されたオリジナル側のMySQLに連続挿入して、想定通りのデータがテーブル上に展開されているかを確認します。
無事にデータが挿入されてテーブルが出来上がっている事が確認出来ました。
また、同時にEqualumの即時同期により「Append設定」した「ターゲット側のMySQL」上の処理状況も確認してみます。
こちらも無事に想定通りの同期処理が実行されている事を確認出来ました。
この第１段階のイメージはこんな感じです・・
第２段階以降では、この物理的・論理的に異なる２つのDB上に展開されるExactly Once即時同期情報を活用して、今回の検証テーマである「不死身のDB化（勝手な妄想（汗））」に関する作業を進めて行きます・・・・
元気が有れば何でも出来る！
という名言がありますが、今回の検証の場合は・・・・
正しいデータが手元に有れば何でも出来る！
を確認できれば成功という事で・・・早速次の工程に移ります。
ということで、オリジナルDB側を悪戯してみます・・・
今回は、初期データを作成した「インサート処理」ではなく、SQLで一般的に使われる「アップデート処理」を利用し、先程のオリジナル側DB上に展開中の初期データ・テーブルの中身を書き換えてみます。
イメージとしては、このような感じになります・・・
今回は、検証環境の関係上「極めてシンプルな処理」での作業になりますが、それぞれの役割分担に応じたコンピューティング資源を割り当てた環境で有れば、より高度で複雑な処理の実証実験や各種の動作検証が行えると思います。
ツールの改竄処理ボタンを押すと、あっという間にオリジナル側のテーブルが別の情報に書き換えられてしまいました・・・
でも、安心してください！！
オリジナルのデータは、Exactly Once & All処理で「物理的に異なるDB上に即時同期されています」ので、その情報を利活用して書き戻しを行なって行きます・・・・・データが手元に有れば・・何とか出来る！はずですので・・（苦笑）
Exactly Once & Allの状況を確認・・・
さて、今回の最重要検証確認ポイントになりますが、直前の改竄処理が加えられたオリジナル側のDB状況に、Equalum経由で即時同期しているDB側は、実際にはどの様なテーブル状況になっているのでしょうか？
無事に、当初の想定通りに「Exactly Once & All]でのAppend追記型処理が行われている事が確認出来ました！
余談・・
検証前にEqualum社の製品担当者に話を聞いた際には、このモードは監査・セキュリティーログ的な用途を目的として設定された、ある意味では通常のデータベース用途とは異なる領域でも利用を想定している・・という事でしたので、逆にEqualumの同期処理の即時性と、Exactly Once処理が可能な組み合わせを効果的に活用し、最新のロジカル監査・AI連携技術等と組み合わせる事により、データ駆動型DX環境における「面白く・新しいチャレンジ」が可能になるかもしれない・・・という検証結果が得られました。
また、即時同期型を上手く活用すれば、現場側の既存系に「色々な意味で負担を掛ける事無く」、物理的・論理的に異なるDB上に「即時同期統合」させて、そのDBに対して「常時全量」での各種データ処理を行えば良い・・・
因みにそう考えると・・効率的に同期戦略を立てて、現在の環境を維持しながら（電子帳簿として利用）同じデータを別の役割を持つDB上で全力展開させ、時系列で得られるDX系の成果や改善結果を「同期先のクローンDB上に反映」させて、「どこかのタイミングでDX側をメインに格上げする」・・・という、時系列での連続性を保った形での持続発展可能型システム進化（常時開発なので）を実現できるかも・・・といった妄想がドンドンと膨らむばかりですね・・・（苦笑）
ターゲット側の情報を活用してデータを復活！！
オリジナル側のデータは全滅している事を「無事に確認出来た」ので、後はターゲット側にExactly Once & Allで生き残っている情報を活用して、粛々淡々とロジカルに情け容赦無く復活させていく作業になります。
処理のイメージはこんな感じになります。
今回は、検証環境の限界問題が有りましたので、単純にオリジナル側のデータを気持ち良く捨て去って、条件に合うターゲット側の追記型テーブル上からデータを再生する処理をシンプルに作成し、検証ツールのGUI上にある起動ボタンで処理を行いました。
処理が終わったオリジナル側のテーブルの状況になります。
無事に復活出来ている様です・・・よかった（苦笑）
因みに改竄前の検証データ挿入直後のテーブル状況になります。
因みに、MySQLが自動的に付与するidとts意外に、通常データとして処理IDと処理時間情報も最初のオリジナルDB上への挿入の際にカラム情報として保持するようにしていますので（OP_id, OP_ts)、その情報も念のために確認したところ問題なく揃っていました(まあ、規模限定のシンプル型とはいえ・・ロジカルに処理を行いましたので。。（汗））
ちょっと重要な事・・・
今回の動作検証は、EqualumのExactly Onceの処理機能とターゲット側処理のモードをAppend(追記）型に設定した場合、仕組みとしてどの様な動作になるかを確認する目的で実施しました。
通常のEqualumの動作としては、オリジナル側の電子帳簿で発生する「記録・検索・修正・削除」等の一般的な業務的データ処理結果を、外部参照型のCDC処理により即時にノーコードで作成したFLOWの作業ステップを経て、指定されたターゲット側のDBに同期していく形ですが、敢えてターゲット側を追記型処理に強制固定する事により、完全に履歴参照型の利用としても応用可能な事が確認出来ました。
因みに、「全てのオリジナル側の処理を反映する」という極めて真面目なExactly OnceベースのCDC同期が常に実行され続けますので、最初の方で確認できた改竄状況も漏れなくExactly Onceで処理されるという点と、復旧作業の際に発生する正常なDB処理に関わる内容も漏れなくExactly Onceで処理されるという点に対する処理が必要になるという留意点があります。
改竄データをどのように判別して処理するか？
正常なデータを使ってどのように修復するか？
その修復作業により発生するデータをどのように取り扱うか？
この辺は、多くの流儀・流派が有ると思いますし、今後出てくる新進気鋭のソリューション群と連携させる等の選択肢が有りますので、良い出会いが有れば別の機会に挑戦してみたいと思います。
Exactly Once & All + Appendモードテーブル処理
ゴミ整理＆復旧処理後の状況
さて次回は・・・
次回は、今回の検証の際に作成した可視化用のワードクラウド部分を紹介させて頂こうかと考えております。
謝辞
本検証は、Equalum社の全面バックアップにより実施しています。この貴重な機会を提供して頂いたEqualum社に対して感謝の意を表すると共に、本内容とEqualum社の公式ホームページで公開されている内容等が異なる場合は、Equalum社の情報が優先する事をご了解ください。
EqualumのExactly Once & All動作検証（１）はこちら
EqualumのExactly Once & All動作検証（３）はこちら
[適材適所・常時全量のデータ処理を時系列透過で実現するコンセプト]
役割分担型データ・システムというアプローチはこちら