关于证券行业的痛点进行交流探讨,梳理4点

这两篇文章涉及的券商业务系统,主要包含交易系统和业务支持两类。交易系统主要有两类任务,一是满足客户的日间交易,是典型OLTP;二是完成盘后 的清算,类似于银行的结算批任务。而业务支持类主要注重数据挖掘与分析,是典型的OLAP。    文中所述痛点还是比较切合实际的,...显示全部

这两篇文章涉及的券商业务系统,主要包含交易系统和业务支持两类。交易系统主要有两类任务,一是满足客户的日间交易,是典型OLTP;二是完成盘后 的清算,类似于银行的结算批任务。而业务支持类主要注重数据挖掘与分析,是典型的OLAP。

    文中所述痛点还是比较切合实际的,针对其推导出来的用户需求我分别说一下,欢迎参与讨论交流:

1、高弹性。中国是典型的散户市场,日间交易业务的峰谷差距巨大这个是中国证券行业的现实情况,也是监管的要求。目前来看没有什么好的解决方案, 券商一般是按照满足峰值需求来部署软硬件,行情低迷时则资源大量闲置。按使用计费的云可能是一个解决思路。

2、清算速度。清算是重IO负载的批任务,在业务逻辑、SQL及数据库性能已调优的情况下,全闪存应该是不错的解决方案。不知道国内金融行业有没 有成功的案例可供参考?

3、高并发。各券商的部署不尽相同,从我司的情况看,达到高并发的瓶颈一般不涉及存储IO,更多的可能在业务逻辑、业务通道能力、网络能力等方 面。

4、同城异地容灾。券商的日间交易业务本质上是一种通道服务,因此在容灾切换时,首要目标是恢复服务,允许少量事务丢失。文章中提出的存储层数据 同步,和券商很多采用的业务数据逻辑同步(数据同步软件)相比,各自的优势和劣势是什么?

收起
参与43

查看其它 8 个回答wangql的回答

wangqlwangql系统工程师NULL

刚刚打了好多字 提交的时候网断了  悲哀啊

个人看法

先从123来说吧,业务系统性能的提升我认为可以分成两个部分:1是软件和业务层面的优化和调整 2是硬件性能的提升   从软件和业务层面着手,是一个长期的过程,对技术有比较高的要求,也需要投入较大的精力和较长的时间。第二个是硬件方面,这个受整个it产业链环境的制约,当然也受钱的制约。比如当下的产业环境,长期硬伤的IO领域,闪存高速发展,为解决IO问题提供了一个客观条件。抛开软件层面的调整,替换或调整整个存储环境为闪存,是一个最为简单粗暴的方式,也是一个见效最快最明显的方式。

再说问题4,我接触的好多客户都比较青睐软件或业务层面的容灾,比如oracle的golden gate,db2的hadr等技术。觉得这种容灾方式直接基于应用,简单明了一目了然。而基于存储块级复制的容灾技术,用户不知道都复制了些什么东西,也不知道复制完后到底行不行。所以有些抵触。但块级复制技术作为成熟的容灾方案商业方案已经存在并发展了好多年,只要做好了,稳定性和可靠性还是非常高的。只要在应用层做好了配置,一般都不会出什么问题。而且对于有些应用的容灾方式,各家存储已经提供了融合支持,比如各家对vmware的srm都提供了对应的软件包支持。 而且随着技术的发展,容灾技术也有了很大的进步,和前几年相比,已经不仅仅是量级的提升了。比如ibm的svc,已经不单单作为容灾的角色出现,还集成了存储整合、rtc、easytier、与tsm的fcm备份集成等等高级特性,做到容灾的同时,已经完成并加速了整个存储环境,有了非常高的附加价值。svc esc的同城方案对应用来说,已经可以说是双活了。而svc或8000的hyperswap已经做到了真正意义上的容灾双活,这些相对基于软件的容灾都是非常大的优势。

IT咨询服务 · 2015-11-11
浏览5743

回答者

wangql
wangql41446
系统工程师NULL
擅长领域: 存储备份软件定义存储

wangql 最近回答过的问题

回答状态

  • 发布时间:2015-11-11
  • 关注会员:9 人
  • 回答浏览:5743
  • X社区推广