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

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

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

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

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

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

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

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

收起
参与43

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

FOSSILEFOSSILE信息技术总部总经理助理南京证券

1.高弹性问题:如果要实现弹性,可能只能向系统提供商租用,行情好时多租,行情差时少租。应该无法做到自建和租用同时发上的情况。当前,市场上还没有可以提供交易的云服务,券商只能选择自建方式来解决问题。

2.清算时,如果采用全闪存,肯定是快的,问题是全闪存何时能打消大家的顾虑?证券公司对清算是有时效性要求的,超时了会很麻烦。如果闪存系统的稳定性出了问题,估计短时间内是解决不了的

3.存储IO及数据库操作系统从来不是系统瓶颈,我们的压力基本都在前台业务处理中间件上,可以使用集群技术根据实际情况增减中间件。

4.我们的系统刚建设的时候,基于存储的复制和基于日志的复制都有,经过2年的运行,发现基于存储的同步意义不大,而且因网络问题还导致我们性能急剧下降,最后是废掉了储存同步;日志同步虽然可能丢失少部分数据,但这在可容忍范围内,且应用简单。

证券 · 2015-11-11
浏览5994

回答者

FOSSILE
信息技术总部总经理助理南京证券
擅长领域: 存储灾备olap

FOSSILE 最近回答过的问题

回答状态

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