jlp*_*lpp 3 database architecture oracle web-services mdm
组织在许多部门和应用程序之间共享关键数据有哪些好方法？
举个例子,假设有一个主应用程序和数据库来管理客户数据.组织中有十个其他应用程序和数据库读取该数据并将其与自己的数据相关联.目前,这种数据共享是通过混合数据库(DB)链接,物化视图,触发器,登台表,重新输入密钥信息,Web服务等完成的.
有没有其他好的方法来共享数据？而且,您的方法与上述问题相比如何:
请记住,共享客户数据以多种方式使用,从简单的单记录查询到复杂的,多谓词,多排序,与存储在不同数据库中的其他组织数据的连接.
感谢您的建议和意见......
我相信你看到了这个,"它取决于".
这取决于一切.与部门A共享客户数据的部门A共享客户数据的解决方案可能完全不同.
多年来我最喜欢的概念是"最终一致性"的概念.这个词来自亚马逊谈论分布式系统.
前提是虽然分布式企业中的数据状态现在可能不完全一致,但它"最终"将是.
例如,当客户记录在系统A上更新时,系统B的客户数据现在已过时且不匹配.但是,"最终",来自A的记录将通过某个过程发送给B. 所以,最终,这两个实例将匹配.
当您使用单个系统时,您没有"EC",而是拥有即时更新,单一的"事实来源",以及通常用于处理竞争条件和冲突的锁定机制.
您的操作能够使用"EC"数据的能力越强,分离这些系统就越容易.一个简单的例子是销售使用的数据仓库.他们使用DW来运行他们的日常报告,但他们不会在清晨运行他们的报告,他们总是查看"昨天"(或更早)的数据.因此,DW不需要与日常运营系统完全一致.对于一个进程来说,完全可以接受,比如说,关闭业务,并在一个大型的单一更新操作中大量移动日期交易和活动.
您可以看到此要求如何解决许多问题.事务数据没有争用,不用担心某些报告数据会在累积统计数据的过程中发生变化,因为报告对实时数据库进行了两次单独的查询.白天不需要高细节聊天来吸收网络和CPU处理等.
现在,这是EC的极端,简化和非常粗略的例子.
但考虑像谷歌这样的大型系统.作为搜索的使用者,我们不知道Google收集搜索结果的时间或时间长度,以及搜索页面上的搜索结果.1ms的？1秒？10秒？10小时？如果您使用Googles West Coast服务器,您可以很容易地成像,如果您使用东海岸服务器,您可能会获得不同的搜索结果.这两个实例在任何时候都不完全一致.但在很大程度上,它们大多是一致的.而对于他们的用例,他们的消费者并没有真正受到滞后和延迟的影响.
考虑邮件.A想要向B发送消息,但在此过程中消息通过系统C,D和E进行路由.每个系统都接受该消息,承担完全的责任,然后将其交给另一个.发件人看到电子邮件正在发送.接收器并没有真正错过它,因为它们不一定知道它的到来.因此,有一个很长的时间窗口可以让该消息在系统中移动而无需任何人知道或关心它的速度.
另一方面,A本来可以和B一起打电话."我刚发过它,你明白了吗？现在？现在？现在就来吧？"
因此,存在某种潜在的,隐含的表现和反应水平.最后,"最终",A的发件箱与B收件箱相匹配.
这些延迟,接受陈旧数据,无论是一天之前还是1-5岁,都可以控制系统的最终耦合.这种要求越松散,联轴器越松散,您在设计方面就越灵活.
这适用于CPU中的核心.在同一系统上运行的现代多核,多线程应用程序可以具有"相同"数据的不同视图,只有几微秒过时.如果你的代码能够正确地处理可能彼此不一致的数据,那么快乐的一天,它就会拉长.如果不是,您需要特别注意确保您的数据完全一致,使用诸如易失性存储器资格或锁定构造等技术.所有这些都以其成本方式实现.
所以,这是基本考虑因素.所有其他决定都从这里开始.回答这个问题可以告诉您如何跨机器分区应用程序,共享哪些资源以及如何共享它们.有哪些协议和技术可用于移动数据,以及在执行传输的处理方面将花费多少.所有基于此概念的复制,负载平衡,数据共享等.
编辑,以回应第一条评论.
正确,准确.比如这里的游戏,如果B无法改变客户数据,那么改变客户数据的危害是什么？你可以"冒险"它在短时间内过时吗？也许您的客户数据进展缓慢,您可以立即将其从A复制到B. 假设变化被放在一个队列中,由于体积很小,很容易被接收(<1s),但即使它仍然是原始变化的"超出事务",所以A会有一个小窗口B没有的数据.
现在头脑真的开始旋转了.在那个"滞后"1期间会发生什么,最糟糕的情况是什么.你可以围绕它工程吗？如果你可以设计大约1秒的滞后,你可以设计大约5s,1m甚至更长的滞后.您在B上实际使用了多少客户数据？也许B是一个旨在促进从库存中挑选订单的系统.很难想象除了简单的客户ID和名称之外还需要什么.在组装时,只需要严格确定订单的用户.
拣选系统不一定需要打印出所有客户信息,直到拣选过程结束,到那时订单可能已经转移到另一个可能更新的系统,尤其是发货信息,所以最后,拣选系统根本不需要任何客户数据.实际上,您可以在拣配顺序中嵌入和反规范化客户信息,因此以后不需要或期望同步.只要客户ID是正确的(无论如何都不会改变)和名称(这很少变化,不值得讨论),这是您需要的唯一真实参考,并且您的所有选择单都是完全准确的.创建.
诀窍是思维方式,打破系统并专注于任务所必需的基本数据.您不需要的数据不需要复制或同步.人们对非规范化和数据缩减这样的事情感到不满,特别是当他们来自关系数据建模世界时.有充分理由,应该谨慎考虑.但是一旦你分发了,你就会隐含地反规范化.哎呀,你现在正在批发它.所以,你也可以更聪明一点.
所有这些都可以通过可靠的程序和对工作流程的透彻理解来缓解.识别风险并制定处理这些风险的政策和程序.
但是,困难的部分是在开始时打破中央数据库的链条,并指导人们,如果你有一个单一的,中央的,完美的信息存储,他们就不能"拥有一切".
这绝对不是一个全面的答复。抱歉，我的帖子很长，我希望它能增加这里提出的想法。
对于你提到的一些方面，我有一些看法。
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 对我来说提供了解决其中一些弊病的灵丹妙药。
| 归档时间： |
|
| 查看次数： |
2860 次 |
| 最近记录： |