具有不同模式的两个数据库之间的双向同步

Question

我正在着手一个项目，其目标是在具有不同模式的两个数据库系统之间创建一个双向同步机制。一个是建立在MongoDB上的定制客户关系管理应用程序，另一个是Salesforce (概念上的SQL)，但我希望建立一种机制，理论上可以链接和同步包含“相似”数据的任何两个数据库系统。我有为这两个系统构建接口的技术技能，但我正在寻找解决这一挑战的最佳方法的建议。我最初的想法是，我需要构建一个相当复杂的实体关系映射工具，它允许我声明/定义两个系统之间的联系。这些链接定义将包含处理两个系统中的基数/模式结构不同这一事实的结构。然后，每个系统中的功能将监控这些变化，并将其输入一个中央机制，该机制将将数据转换为一个不同的“形状”，以便插入到“其他”系统中。我预计我的机制将包括一个数据存储区，它保存了大量关于主键、辅助键、当前字段值等的信息。

在这一挑战中，有谁有什么智慧吗？有人知道关于模式匹配的任何技术论文可能会有帮助吗？或者可能包含有用概念的研究论文？或者在这些领域提供某些功能的开源工具？非常感谢。

Answer 1

如果这是可行的，这在很大程度上取决于“相似”数据的含义，如果系统有足够的不同，这可能会变得任意复杂，您可能不得不重新设计现有的系统。通常，在这两个系统中都有业务实体是不够的，它们可以以1:1的方式相互映射--涉及这些实体的所有类型的事务也必须进行映射。

让我们举一个例子:既然我们谈论的是CRM，那么您肯定在这两个系统中都有客户实体。首先，您必须确保这里是主键，并且唯一的索引不会发生冲突。如果只有一个系统会禁止两次使用相同的名称，那么您可能已经遇到了麻烦:如果将一个客户c1添加到系统1，而另一个c2添加到系统2，但不小心两个系统都有相同的名称，那么当系统1对名称有唯一的约束时，这对同步过程意味着什么？

• 系统1中的客户可能是早些时候输入的，所以c1“赢了”，但是如果c2不能在没有手动干预的情况下转移到system 1，那么可能包括一堆c2相关的数据，然后这些数据就不能传输到system 1，您的用户可能会不高兴。
• 如果同步机制将尝试“合并”两个客户，但在现实中，这些是不同的公司，您的用户也不会高兴。
• 同步机制还可以通过自动重命名来解决问题，以使c2与系统1中的c1保持分离，但这需要对如何进行重命名以及用户如何处理这种重命名的客户记录进行彻底的分析。

如果您只对每个系统使用不同ID范围的代理ID，而不使用其他唯一索引，则可以克服此问题。这就是DB复制(在具有相同模式的系统之间)通常是如何实现的，但是您是在谈论现有的系统吗?您可以这样重新设计它们吗？

即使您解决了这个问题，如果在system 1中，每个客户都有额外的数据，一旦输入它就禁止删除它，并且这个额外的数据在system 2中没有挂件，会发生什么？现在，在system 2中，允许某人删除c1 (因为没有这样的相关数据)，但是在system 1中不允许删除。这对同步过程意味着什么？

这可以通过禁止对system 2中的实体进行直接删除来克服，至少在它们与system 1同步之后，这意味着您必须跟踪同步状态并将其建模到系统中。

这一切都意味着：

• 这是可能的，但您必须将复制/同步深入设计到系统中。

不要期望将通用的双向同步机制作为一个“独立的独立模块”引入到两个现有的系统中，而不严重地触及现有的设计。使用“单向”方法，一个领导系统，是一个数量级的更容易实现，并避免了这些痛点。

Answer 2

你不应该这么做。

进行单向同步是很有挑战性的，会给系统增加一堆约束，但在这一点上，这是一个众所周知的问题。当你使事情双向的时候，你就失去了你唯一的真理之源。如何防止更新循环？如果比赛发生记录冲突时会发生什么情况？在没有其他系统替换记录的情况下，如何删除？

相反，最好是让其中一个系统成为您的真实来源，并将其用户更改为双重更新，通常使用某种中介(消息总线或持久队列)。