暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

【交易技术前沿】证券行业关于数据库信息技术应用创新工作的探索和思考

上交所技术服务 2021-11-01
1000

本文选自《交易技术前沿》总第四十三期文章(2021年3月)

谢奎 兴业证券股份有限公司 xiekui@xyzq.com.cn


       数据库作为IT产业最重要的基础软件之一,是支撑各类应用系统运行的主要支柱,然而在当前金融行业尤其是证券行业,应用系统主要使用的是国外厂商提供的成熟商业数据库产品,如Oracle、DB2、SQL Server等,证券行业普遍面临国外商业数据库昂贵授权费用带来的成本问题。虽然,随着开源MySQL数据库的流行,证券行业也逐渐使用MySQL数据库构建部分应用系统,但由于MySQL的一些技术局限性,证券行业众多业务系统始终难以脱离国外商业数据库体系。与此同时,近年来国际安全事件频发、贸易争端不断,国家层面也开始倡导信息技术应用创新。正是基于这些原因,兴业证券开始探索具有更高自主权的数据库应用体系,即数据库信创工作的探索。

一、引言

       近年来,国际环境趋于紧张,贸易摩擦频发,高科技领域受到严重影响,自中兴事件以来,我国社会各界更加认识到发展具有自主知识产权,掌握自主可控关键技术具有重要意义。随着网络强国战略、信息安全战略以及大数据战略的推进,对数据的开发利用需求逐步增大,数据安全可控的重要性愈发凸显,数据库是承载信息系统的核心软件,数据库软件的信创具有重要意义。然而,长期以来由国外厂商提供的基础软件产品占据我国金融行业主流地位,尤其是在关键核心软件——数据库软件领域,基本由Oracle、IBM以及微软等国外科技公司产品垄断,国外数据库产品技术壁垒严重,核心技术不开放、不可控,版权费用高昂,存在严重隐患。
       因此,近年来国内部分行业已开始探索使用开源数据库、自主可控数据库等代替国外商业数据库支持核心业务系统运行,提升信息系统建设自主可控水平。证监会也在《证券期货业信息安全保障管理办法》中提出应当引导鼓励行业信息技术研究与创新,增强自主可控能力,促进行业科技进步。我司计划逐步开展在部分业务系统上使用开源或者自主可控数据库替代国外商业数据库,提升信息系统核心软件自主可控水平。

二、数据库的选型

       数据库作为信息系统的关键部分,数据库选型除了要满足高可靠性、高性能和高安全性等要求外,还需要能融入我司信息系统软硬件生态圈。因此,我司对于数据库的选型主要分为技术调研以及验证测试两个步骤进行。
       关于数据库产品的技术调研方面,我司主要考虑以下几个方面:

  1. 兼容性方面,兼容主流软硬件平台,尤其是基于X86的硬件以及Linux操作系统。

  2. 开发方面,兼容JDBC、ODBC、OCI等主流数据库接口,兼容主流Java开发框架,支持主流SQL功能,优化器功能足够强大性能可以满足要求。

  3.  运维方面,具有完整的解决方案,包括数据迁移、数据库备份、数据库高可用架构(主从或多活)以及数据库实时复制等方面。 

  4.  工具集成方面,具有成熟的操作及运维工具,能够与第三方监控平台进行集成。 

  5.  生产案例方面,金融行业具有众多成熟的应用案例。 

       在数据库产品的测试验证方面,我司主要考虑以下几个方面:

  1. 性能测试方面,主要包含通用场景测试以及特定业务场景测试。通用场景性能测试主要通过数据库压力测试工具进行,验证通用OLTP场景下数据库性能指标,并与成熟商业产品进行对比;特定业务场景测试主要选取我司各类业务系统的一些特定场景进行性能测试对比。 

  2. 兼容性测试方面,选取具有代表性的各类业务系统进行兼容性测试,选取的业务系统包括自研以及外购应用系统,应用系统包括使用通用开发架构轻数据库型应用以及严重依赖数据库功能的重数据库类应用。 

  3. 高可用测试方面,主要验证数据库产品高可用架构方案的可靠性,高可用主要包括当前数据库产品支持的主从架构或、双活、或多活架构。 

  4. 数据迁移验证方面,主要验证数据从当前数据库产品到所调研数据库产品的迁移方案的成熟性、效率以及是否可以回退等。   

  5. 生态验证方面,主要验证测试各类工具的可用性,包括备份恢复工具、监控工具、开发工具以及ETL工具等。 

       作为IT应用系统的核心组件,数据库软件的更替是一件需要非常审慎的事情,尤其是各个数据库软件之间的兼容性对于应用改造工作量以及生产运行稳定性的影响非常明显。为了有序的推进数据库的应用实践并保障应用系统生产运行的稳定性,确定代码修改由简单到复杂、应用系统由非重要到重要的方针,我们先对非重要系统进行试点,并规划数据库产品信创实施路径如下:

  1. 数据库快速适配,相关修改量少的应用系统先行; 

  2. 较少使用特定数据库功能,数据库品牌依赖小的应用系统先行; 

  3. 外围管理类非重要系统先行; 

  4. 待验证自主可控/开源数据库可行性并积累一定经验之后向更加复杂、重要应用系统推进。 

三、实践历程

       目前业内对于数据库的信创工作主要分为自主可控数据库以及开源数据库两个方向的应用,我司也从这两个方向入手分别选取合适的产品进行数据库替代的探索和实践。
       在自主可控数据库方面,通过对主流自主可控数据库厂商南大通用、武汉达梦、人大金仓提供的数据库产品进行调研对比,最终结合上述选型的技术调研和测试验证的工作,同时在生产规模部署上达梦数据库在政府、电力、航空以及银行等领域拥有较多的使用案例,因此确定选用达梦数据库作为开启我司数据库自主可控道路的产品。
       在开源数据库方面,我司已有大量的MySQL经验积累,并广泛应用于各信息系统,但由于MySQL优化器的局限性,在部分业务场景比较依赖数据库复杂查询功能的场景无法适用。而PostgreSQL作为较为流行的关系型数据库,近年来在国内使用热度逐渐提升,且PostgreSQL开源协议非常友好,有很多数据库产品是基于PostgreSQL进行的二次开发,市场前景较为明朗。基于此,我们对PostgreSQL进行了一系列调研测试,证明PostgreSQL具有较好的性能,能够补充我司在部分依赖数据库复杂查询功能应用场景的开源数据库空白。
       基于相关选型及测试要点,我司选取了四类数据库Oracle、MySQL、达梦、PostgreSQL,除了进行必要的tpcc压测外,还进行特定业务场景应用测试、数据抽取加载测试、数据迁移测试以及高可用测试等测评工作。选取的数据库在tpcc压测结果均能满足要求,在数据迁移、数据抽取加载以及高可用方面均存在成熟方案,但各数据库在特定业务场景测试中性能差异比较明显,部分场景效率对比如下图所示:

图1:各数据库场景效率对比

       基于相关测试结果表明达梦数据库以及PostgreSQL在某些复杂业务场景性能可以媲美Oracle数据库,而MySQL存在性能瓶颈;MySQL数据库比较适用于OLTP场景,且在我司已有较多使用经验。因此我司选用自主可控数据库达梦以及开源数据库PostgreSQL开始了数据库信创工作的探索与实践。
       1、自主可控数据库的探索和实践
       在达梦数据库的探索实践方面,我司首先选取了基于通用Java开发技术的ITSM流程管理平台进行试点,该应用可通过标准的SQL语法及标准的数据库接口访问数据库,可实现数据库产品的无缝切换,而且该应用为自主研发应用,不依赖厂商,代码级自主可控。

IT工作管理平台采用SSH(Struts2.0+Spring2.5+Hibernate3.2)作为开发框架,共分为4层,分别是:表现层、控制层、业务层、持久层,架构如下。
       (1)表现层负责操作人员和WEB应用程序的交互和展示;
       (2)控制层负责把从表现层传来的数据和请求转发到相对应的业务层,并把业务层返回的数据封装以特有的格式返回给表现层;
       (3)业务层负责整个WEB系统业务逻辑的实现,并调用持久层获取业务数据;
       (4)持久层主要负责和数据库的交互。

图2:SSH(Struts2.0+Spring2.5+Hibernate3.2)架构示意

       开发层面,由于持久层选用Hibernate技术,屏蔽了数据库技术SQL的差异性,因此仅需要配置Hibernate的达梦驱动及相关数据库连接信息,并通过兼容性和功能性测试验证,完成数据库技术的替换,且系统可以正常运转,经过准生产验证和稳定性测试后,于2018年6月正式上线生产环境。通过IT管理平台成功迁移至达梦数据库,我司初步积累了在基于Java技术的应用中数据库自主可控的经验。之后,我司继续在部分外围系统如权限稽核、流程引擎等系统推进数据库自主可控,进一步积累经验。
       无论IT管理平台还是权限稽核以及流程引擎等系统都是基于JAVA的,业务功能更多在应用里面实现,对于数据库的依赖性相对较低。为了进一步推进自主可控数据库的应用,我司进一步选取了对于数据库强依赖的投保系统进行适配,该系统的一大特点是大量使用存储过程以及函数实现业务功能,并且较多使用了db link,对于数据库的依赖性较强。此外,该系统数据量也较大,数据迁移也具有一定复杂性,对于验证大数据量情况下数据库自主可控具有一定意义。
       在高可用方面,达梦数据库提供共享存储集群以及通过日志传输实现数据守护实现高可用方案,数据守护支持异步复制以及实时复制。我司选用达梦数据守护架构,如下图所示:

图3:达梦数据守护架构示意

当主库出现故障时,在以下情况下,dmmonitor可以识别到,并自动接管:1)主库数据库实例异常终止,主库守护进程正常;2)主库硬件故障、或者数据库实例和守护进程同时故障;主库网络故障,主备库之间、主库与监视器之间连接异常。整个高可用切换过程中自动切换至备库,数据同步正常,耗时6s左右。

       2、开源数据库的实践
       在PostgreSQL实践方面,我司选取了自研的系统产品管理平台作为试点,该系统采用通用Java开发技术,存在较多复杂SQL应用场景,为比较典型的混合事务/分析处理类应用系统,对于验证PostgreSQL的可用性具有较大意义。经过一段时间的测试及适配改造,由于标准SQL无需调整,在完成存储过程及函数改造、分区表定义改造、分页功能改写、dual表引用改造等工作之后,该系统正式Oracle切换至PostgreSQL,稳定运行至今。在高可用方面,PostgreSQL也采用Pgpool-Ⅱ以及异步流复制高替换Dataguard提供数据高可用保障,通过虚拟IP将查询操作分散到各主备数据库服务器中,而主库进行写入操作。当故障发生时,可以在短时间内将备库进行激活。整个高可用切换过程中备库自动接管,数据同步功能正常,耗时在6s左右。高可用架构如下图所示:

图4:高可用架构示意

       在该系统应用取得成功之后,PostgreSQL将进一步推广至风控平台等应用系统使用。

四、总结及思考

       在各业务系统迁移适配过程中,除了应对一些已知差异进行的必要性调整之外,主要遇到了以下几个方面问题(语言需要调整):
       1)兼容性问题
       兼容性问题一方面是由于应用不恰当的开发习惯,如不恰当使用数据库关键字以及使用非公开函数等问题造成。在Oracle数据库切换到达梦数据库时,应用系统部分SQL语句不恰当的使用了比较通用的关键字如break、end之类,由于达梦对于关键字处理机制不一致,导致迁移中由于语法问题报错,需要对部分代码进行改写。在Oracle数据库切换至达梦数据库过程中,应用不恰当使用wm_concat进行结果拼接,由于Oracle和达梦机制不完全一致,导致执行结果存在差异,需要改用listagg函数实现。
       兼容性问题另一方面是由于数据库本身功能的差异造成的,如JDBC驱动、字符集以及语法支持等方面的差异。在进行达梦数据库适配中遇到了多线程并发调用同一个连接,由于达梦JDBC驱动对此保护机制不足,导致驱动假死,从而影响业务正常运行。Oracle与达梦支持的字符集不一致,导致迁移过程中遇到特殊符号占用空间不一致导致字段长度超限问题。在使用Oracle时,数据库探活以及函数调用等场景出现较多对dual表的引用,而PostgreSQL数据库本身没有dual表,需要手工创建类似dual表或者改写SQL语句。Oracle与PostgreSQL在存储过程和函数的编写方面存在一些差异,尤其是PostgreSQL不支持类似PLSQL包的概念,在使用存储过程和函数,尤其是PLSQL包的场景需要进行大量的改写工作。
       2)性能问题
       由于各数据库优化器机制以及底层物理存储存在一些差异,部分SQL语句性能存在差异,尤其在一些复杂SQL语句方面容易出现性能问题,需要针对性优化。
       性能问题一方面是由于数据库机制差异造成的,需要通过SQL改写、调整逻辑结构(如调整表结构或索引)、调整参数等方式解决。
       性能问题另一方面是由于数据库切换遇到优化器bug触发,需要通过数据库升级或者变通处理等方式解决。在达梦数据库中使用db link时,遇到了多次由于优化器bug导致过滤条件无法发送至远端数据库造成SQL执行效率缓慢的问题。在切换至达梦数据库的过程中,也遇到了由于优化器机制问题导致的相关查询表达式转换为函数方式实现,导致执行计划不正确。
       总结数据库替换过程中出现的问题,除了产品差异带来的必要调整之外,更容易在开发不规范以及使用特定数据库功能等场景遇到不可预知的问题。
       数据库作为IT应用系统的核心组件之一,新数据库产品的引入不能仅解决选型的问题,更重要的需要考虑数据库技术应用问题,在数据库产品确认使用之后还需要从技术选型、应用开发、运维等方面去规范数据库的使用问题。
       技术选型方面的规范需着重考虑以下几个方面:

  1. 数据库选型范围,确定公司信息系统可用数据库产品范围。 

  2. 数据库选型原则,根据应用场景在范围内选型数据库产品。如在OLTP场景可以使用MySQL、PostgreSQL以及达梦等数据库;而在HTAP以及OLAP等场景不建议使用MySQL数据库,更倾向使用PostgreSQL以及达梦等数据库。

       应用开发方面的规范需着重体现在以下几个方面:

  1. 数据库模式设计规范,包括对象命名、字段设计、索引设计等; 

  2. 数据库SQL编写规范,保持良好编码风格,遵循通用SQL规范,尽量不将常见的数据库关键字用作它途。 

  3. 尽量限制使用数据库特殊功能依赖性较高的解决方案,包括存储过程、函数、触发器以及db link等。 

       运维方面的规范需着重体现在以下几个方面:

  1. 数据库部署架构,主要考虑数据库的高可用及容灾方案; 

  2. 数据库安装配置规范,包括版本管理、权限管理、参数配置等; 

  3. 数据库运维规范,包括变更管理、数据库备份及验证、应急演练等。 

五、展望

       我司数据库产品多元化应用实践旨在通过引入自主可控、开源等数据库,制定公司可用数据库产品池,确保各类应用场景对数据库产品具有可选择性,降低对单一厂商或数据库产品依赖,提升全司信息系统核心软件的信创水平。目前我司已经初步完成了部分数据库产品的替换实践,而且相关系统运行稳定,后续我司将根据情况继续推广相关数据库产品的使用,持续完成对其它数据库产品的调研,并在恰当的时机启用相关数据库产品的应用实践。在数据库技术层和应用开发层完成信创的探索和实践基础上,后续将在服务器、网络设备、存储、操作系统、云计算等基础设施层面进行信创的探索和实践,逐步实现从底层到上层全方位实现信创工作的探索和实践。



 
  免责声明   

本公众号内容仅供参考。对任何因直接或间接使用本公众号内容而造成的损失,包括但不限于因有关内容不准确、不完整而导致的损失,本公众号不承担任何法律责任。如有问题请反馈至tech_support@sse.com.cn。

-------------------------
上海证券交易所为证券公司、基金管理公司等市场参与者及相关行业机构提供交易技术支持与服务,包括日常交易技术支持、技术交流研讨、市场调查反馈、证券信息技术知识库、测试等服务。

文章转载自上交所技术服务,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论