如何在组织内共享数据

Question

如何在组织内共享数据

databaseweb-servicesoraclearchitecturemdm

4

组织分享关键数据给许多部门和应用的一些好方法是什么？

举个例子，假设有一个主要应用程序和数据库来管理客户数据。组织中还有其他十个应用程序和数据库读取该数据并将其与自己的数据相关联。目前，这种数据共享通过混合使用数据库（DB）链接、材料化视图、触发器、分段表、重新键入信息、Web服务等进行。

除了上述方法外，还有哪些好的分享数据的方法？如何比较您的方法与上述方法在以下方面的关注点：

重复数据

容易出错的数据同步过程

紧密度与宽松度（减少依赖性/脆弱性/测试协调）

架构简化

安全性

性能

定义良好的接口

其他相关问题

请记住，共享的客户数据用途广泛，从简单的单记录查询到与存储在不同数据库中的其他组织数据进行复杂的多谓词、多排序和连接查询。

感谢您的建议和意见...

- jlpp

3个回答

5

这绝对不是一个全面的回复。很抱歉我写了这么长，希望能对这里提出的想法有所补充。

针对你提到的一些方面，我有几点观察。

duplicate data

这通常是部门化或专业化的副作用。一个部门开创了某些数据的收集，其他专业组也认为这些数据有用。由于它们无法独占地访问这些数据，因为这些数据与其他数据混合在一起，所以为了利用它，他们也开始收集/存储数据，从而使其重复。这个问题永远不会消失，就像重构代码和删除重复内容需要不断努力一样，需要不断将重复数据带到集中访问、存储和修改。

well-defined interfaces

大多数接口都是在考虑其他限制条件的情况下，出于良好意图而定义的。然而，我们往往习惯于超越先前定义接口所设定的限制。这再次证明了持续重构的必要性。

tight coupling vs loose coupling

如果说有什么问题，大多数软件都会受到这个问题的困扰。紧密耦合通常是在时间限制下为了得到一个方便的解决方案而产生的结果。松散耦合会导致一定程度的复杂性，我们在想要完成任务时不喜欢这种复杂性。Web服务的口号已经流传了很多年，但我还没有看到一个完全消除这一点的好的解决方案的例子。

architectural simplification

对我来说，这是解决您在问题中提到的所有问题的关键。SIP与H.323 VoIP之间的故事浮现在我的脑海中。SIP非常简化和易于构建，而H.323则像典型的电信标准一样试图预见有关VoIP的每个问题并为其提供解决方案。最终结果是，SIP增长得更快。成为H.323兼容解决方案是很痛苦的。实际上，H.323的合规性是一个价值巨大的产业。

On a few architectural fads that I have grown up to.

多年来，我开始喜欢REST架构的简单性。它提供了一种简单而独特的访问数据的方式，并且易于在其周围构建应用程序。我发现企业解决方案比任何其他问题（如性能等）更容易受到数据重复、隔离和访问等问题的困扰。对我来说，REST为这些问题提供了一个灵丹妙药。

- pyfunc

它绝对为讨论增添了思路。谢谢，pyfunc。您会如何进行重构以减少系统间数据的重复？您将如何重构共享数据的接口以使其更加明确定义？ - jlpp

1

为了解决其中一些问题，我喜欢中央“数据中心”的概念。数据中心代表特定实体的“唯一真相”，但仅存储ID，不包括名称等信息。事实上，它只存储ID映射-例如，它们将系统A中的客户ID映射到系统B中的客户编号，并映射到系统C中的用户编号。系统之间的接口使用中央数据中心来知道如何将一个系统中的信息与另一个系统中的相关联。

这就像一个中央翻译器；与编写从A->B、A->C和B->C的特定映射代码不同，随着添加更多系统而呈指数级增长，你只需要转换到/从中央数据中心：A->中央数据中心，B->中央数据中心，C->中央数据中心，D->中央数据中心等。

- Jeffrey Kemp

非常有趣的解决方案。术语“数据中心”让我想到主数据管理，这在共享数据方面可能会有所帮助，特别是如果组织存在数据质量/同步问题。如果多个系统更新（而不仅仅是读取）各自数据库中的相同类型信息，然后必须同步此信息，则通常会出现这种情况。您通常会使用什么机制从另一个数据库中读取数据和一些最小业务数据，使用映射中心数据？DB链接？ - jlpp

机制因地而异，我认为。个人而言，我总是说“你越能在一个数据库实例上获取所有内容，就越好”，但在实践中，你最终不得不通过数据库链接、通过某种中间层解决方案（例如Web服务）或通过复制来设置接口。 - Jeffrey Kemp

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Will Hartung · Accepted Answer

我相信你早已看到这一点，“它取决于情况。” 它取决于一切。与A部门分享客户数据的解决方案可能与与B部门分享完全不同。我最喜欢的概念是多年来涌现的“最终一致性”概念。该术语来自于亚马逊谈论分布式系统。前提是，尽管分布式企业中的数据状态现在可能不是完全一致的，但它“最终”将成为一致的。例如，当在A系统上更新客户记录时，B系统的客户数据现在已经过时且不匹配。但是，“最终”，通过某个过程，A中的记录将被发送到B。因此，最终，两个实例将匹配。当您使用单个系统时，您没有“EC”，而是具有即时更新、单个“事实来源”和通常用于处理竞争条件和冲突的锁定机制。您的操作越能够使用“EC”数据，就越容易将这些系统分开。一个简单的例子是由销售使用的数据仓库。他们使用DW运行其每日报告，但他们直到清晨才运行其报告，并始终查看“昨天”（或更早）的数据。因此，DW没有与每日操作系统完全一致的实时需求。例如，可以在营业结束时运行一个过程，并在大型、单个更新操作中移动那天的交易和活动。您可以看到这个要求可以解决很多问题。没有竞争事务数据，不必担心某些报告数据将在统计期间更改，因为报告对实时数据库进行了两次单独的查询。白天无需进行高详细度的互动式处理网络和CPU处理等。现在，这是EC的一个极端、简化和非常粗糙的例子。但考虑像Google这样的大型系统。作为搜索的消费者，我们不知道Google收集的搜索结果何时出现在搜索页面上，需要多长时间。 1ms？1s？10s？10小时？如果您正在访问Google的西海岸服务器，很容易想象您可能会得到与访问他们的东海岸服务器不同的搜索结果。这两个实例从未完全一致。但是在很大程度上，它们基本上是一致的。对于他们的用例，他们的消费者并未受到滞后和延迟的影响。考虑电子邮件。A希望向B发送消息，但在此过程中，该消息通过C、D和E系统路由。每个系统都接受消息，承担全部责任，然后将其移交给另一个系统。发件人看到邮件在其途中。接收者并不真正错过它，因为他们并不一定知道它即将到来。因此，该消息要在系统中移动的时间窗口很大，而没有任何关注它到达速度的人。

另一方面，A可能正在与B通电话。“我刚刚发送了它，你收到了吗？现在？现在？现在收到了吗？”因此，存在某种潜在的、暗示的性能和响应水平。最终，“最终”，A的发件箱与B的收件箱匹配。这些延迟、接受陈旧数据的情况，无论是一天前还是1-5秒前，都控制着系统的最终耦合度。要求越松散，耦合度越松散，在设计方面就有更多的灵活性。这一点在CPU的核心方面也是如此。运行在同一系统上的现代、多核、多线程应用程序可能对“相同”的数据有不同的观点，只有微秒的时间差。如果您的代码可以正确地处理潜在的不一致的数据，那么就可以愉快地运行。否则，您需要特别注意确保数据完全一致，使用像易失性内存限定或锁定结构等技术。所有这些技术都会以其方式消耗性能。因此，这是基本的考虑。所有其他决策都从这里开始。回答这个问题可以告诉您如何将应用程序分区到不同的机器上，共享哪些资源以及如何共享。可以使用哪些协议和技术来移动数据，以及执行传输所需的处理成本。基于这个概念，可以进行复制、负载平衡、数据共享等等决策。编辑，回应第一条评论。正确，确切地说。例如，如果B不能更改客户数据，那么更改后的客户数据有什么危害？你能“冒险”让它过时一段时间吗？也许您的客户数据足够缓慢，以至于可以立即从A复制到B。假设更改被放在一个队列中，由于低容量，很容易被接收(<1s)，但即使如此，它仍然会与原始更改“脱节”，因此存在一个小窗口，在这个窗口中，A将拥有B没有的数据。现在，思维真正开始旋转。在那1秒的“滞后”期间会发生什么情况？最坏的情况是什么？你能通过工程来解决它吗？如果您可以解决1秒的延迟，那么您可能可以解决5秒、1分钟甚至更长时间的延迟。您实际上在B上使用了多少客户数据？也许B是一个设计用于从库存中选择订单的系统。很难想象除了仅仅需要一个客户ID和姓名之外，还需要更多的东西来粗略地识别订单是为谁组装的。

拣选系统不需要在拣选过程中打印所有客户信息，直到拣选结束，而在此之时，订单可能已经移交给另一个系统，该系统也许更加及时地提供了特别是运输信息方面的数据。因此，最终拣选系统几乎不需要任何客户数据。事实上，您可以将客户信息嵌入和去规范化到拣选订单中，因此无需同步后续信息。只要客户ID正确（这永远不会改变），姓名（变化很少，不值得讨论），那么这是您所需的唯一真正参考，所有拣选单在创建时都是完全准确的。

关键是将系统分解并专注于任务所必需的基本数据。您不需要的数据不需要复制或同步。人们对去规范化和数据减少等事情感到不满，特别是当他们来自关系数据建模世界时。有充分的理由谨慎考虑它。但是一旦您进行分布式，您就已经隐含地去规范化了。见鬼，您现在正在批量复制它。因此，您可能会更加聪明地处理它。

所有这些都可以通过坚实的程序和对工作流程的彻底了解来缓解。确定风险并制定政策和程序来处理它们。

但是，难点在于在开始时断开与中央数据库的联系，并指示人们他们不能像他们预期的那样“拥有一切”，就像当您拥有单个、中央、完美的信息存储库时一样。