スキーマが異なる2つのデータベース間の双方向同期
スキーマが異なる2つのデータベースシステム間で双方向の同期メカニズムを作成することを目標とするプロジェクトに着手します。 1つはMongoDBで構築されたカスタムCRMアプリ、もう1つはSalesforce（概念的にはSQL）ですが、理論的には、「類似した」データを含む2つのデータベースシステムをリンクして同期できるメカニズムを構築しようとしています。私は両方のシステムへのインターフェースを構築するための技術的スキルを持っていますが、この課題に取り組むための最良の方法に関するアドバイスを探しています。私の最初の考えは、2つのシステム間のリンクを宣言/定義できるようにするかなり複雑なエンティティ関係マッピングツールを構築する必要があるということです。これらのリンケージ定義には、2つのシステム内のカーディナリティー/スキーマ構造が異なるという事実に対処する構造が含まれます。次に、各システム内の機能が変更を監視し、これらを中央メカニズムに送り、データを別の「形状」に変換して「他の」システムに挿入します。私のメカニズムには、主キー、副キー、現在のフィールド値などに関する多くの情報を保持するデータストアが含まれることを期待しています。
誰かがこの挑戦について知恵の言葉を持っていますか？スキーママッチングに関するテクニカルペーパーを知っている人はいますか？それとも有用な概念が含まれている可能性のある研究論文？または、これらの領域のいずれかで何らかの機能を提供するオープンソースツールですか？どうもありがとう。
これが可能かどうかは、「類似した」データの意味に大きく依存し、システムが十分に異なる場合、これは任意の複雑なものになる可能性があり、既存のシステムを再設計する必要がある場合があります。通常、両方のシステムにビジネスエンティティを1：1の方法でマッピングできるだけでは不十分です。これらのエンティティを含むあらゆる種類のトランザクションもマッピングする必要があります。
例を挙げましょう。CRMについて話しているので、両方のシステムに顧客エンティティが確実にあります。ここで最初に確認する必要があるのは、主キーと一意のインデックスが衝突しないことです。システムの1つだけが同じ名前を2回使用することを禁止する場合、すでに問題が発生している可能性があります。顧客c1がシステム1に追加され、別のシステムc2がシステム2に追加されたが、誤って両方が同じ名前を持っている場合、これは、システム1に名前に一意の制約がある場合の同期プロセスを意味しますか？
システム1の顧客が以前に入力された可能性があるため、c1が「勝ち」ますが、c2を手動の介入なしにシステム1に転送できない場合、おそらくシステム1に転送できない一連のc2関連データが含まれている可能性があります。幸せにならないでください。
同期メカニズムが両方の顧客を自動的に「マージ」しようとするが、実際にはこれらが異なる会社である場合、ユーザーも満足しません。
同期メカニズムは、システム1でc2をc1から分離するように自動的に名前を変更することで問題を解決することもできますが、これには、この名前変更がどのように行われるか、およびユーザーがそのような名前変更された顧客レコードをどのように処理できるかを徹底的に分析する必要があります。
この問題は、システムごとに異なるID範囲でのみサロゲートIDを使用し、他の一意のインデックスを使用しない場合に解決できます。これは、DBレプリケーション（スキーマが等しいシステム間）がしばしば実装される方法ですが、あなたは既存のシステムについて話しています-そのようにシステムを自由に再設計できますか？
これを解決しても、システム1で何が起こるかは、顧客ごとに追加のデータがあり、それが入力されるとすぐにそれを削除することを禁止します。この追加のデータはシステム2にペンダントがありません。システム2では、誰かがc1を削除できます（そのような関連データがないため）が、システム1ではこの削除は許可されていません。これは同期プロセスにどのような意味がありますか？
これは、少なくともシステム1に同期された後、システム2のエンティティの直接削除を禁止することで克服できます。つまり、同期状態を追跡し、これをシステムにモデル化する必要があります。
ここでこれが意味することは次のとおりです。
- 可能かもしれませんが、レプリケーションを設計する/システムに深く同期するする必要があります。
既存の設計にあまり手を加えずに、汎用の双方向同期メカニズムを「分離した独立したモジュール」として2つの既存のシステムにすぐに導入することを期待しないでください。 「単一方向」アプローチを使用すると、1つの主要なシステムで実現することが非常に容易になり、これらの問題点のほとんどを回避できます。
これを行うべきではありません。
単方向の同期を行うことは困難であり、システムに制約の山を追加しますが、現時点ではかなりよく知られている問題です。物事を双方向にすると、真実の唯一の情報源を失うことになります。更新ループを防ぐにはどうすればよいですか？レコードが競合する場所でレースが発生するとどうなりますか？他のシステムがレコードを置き換えることなく、どのように削除を行いますか？
代わりに、システムの1つを真の情報源にして、ユーザーを変更して、通常はある種の中間手段（メッセージバスまたは永続キュー）を使用して二重更新を行うようにします。