最简单(和性能最好的IMHO)方式是在数据库之间建立链接并编写简单的存储过程.在这种情况下,我们使用最小的技术和组件,所有功能都是“开箱即用”.
但是SOA(面向服务的体系结构)的良好做法?紧耦合怎么办?我们是否坚定地将数据库相互联系在一起?
还有另一种方法可以做到这一点:我们在每个方面构建2个java应用程序,并通过SOAP Web服务进行通信.这更加SOA友好!但性能下降和其他失败点值得吗?
在这种情况下最好的做法是什么? ETL如何适应SOA?
解决方法
所以,基本步骤是:
步骤1:调度程序运行并从服务A获取数据
Scheduler --get--> Service A Service A --data--> Scheduler
步骤2:调度器进行数据转换
[ Conversion --> Conversion --> Conversion --> Conversion ]
步骤3:调度程序将数据发送到另一个服务
Scheduler --data--> Service B
在Biztalk和SAP BusinessObject Data Integrator中,这些步骤是可配置的(它们可以从任何服务中检索,并且可以进行脚本数据转换),因此它更加灵活.
然而,仍然存在ETL处理可能会发生的常见问题.例如:数据太大,网络性能影响,RTO,重复数据等.因此,ETL最佳实践在这里仍然是一个要求(使用分段表,日志记录等).
But are the performance degradation and additional points of failure
worth it?
性能影响将会发生,因为现在您有额外的连接/认证步骤(webservice)和运输步骤(通过协议的web服务调度程序).但是出于容易出错的问题,我认为与其他服务调用需要处理的错误相同.
这值得么?这取决于.如果您在相同的环境中工作(相同的数据库),那么这是有争议的.如果您在不同的环境中工作(例如,从Asp.Net到SAP或至少不同的数据库实例两个不同的系统),那么这种体系结构是处理ETL的最佳选择.
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。