某大型银行手机银行等重要交易系统不做大幅改造整体去IOE最佳实践-技术路线选择篇

字数 5796阅读 5939评论 2赞 7

内容摘要：

银行成功使用PostgreSQL替换Oracle数据库，提高系统性能、降低成本，增强可靠性和可扩展性。选择依据性能、兼容性、可靠性和成本等方面分析，PostgreSQL成为首选，具有开放社区性、商业和创新能力、快速迭代更新等优势。数据迁移需要评估规划、应用程序适配和性能优化，采用微服务+多PostgreSQL数据库集群方式，整体性能高于Oracle。

当前摘要为AI生成

> 摘要：在数字化转型的背景下，该银行面临着提高系统性能、降低成本和增强数据安全性的挑战，交易类系统原先使用I OE 架构面临着诸如成本高昂、技术闭源、不适应云服务化趋势等问题，亟需寻找一种替换方案。本文将详细介绍技术路线的选择依据、实施过程、容灾方案设计以及最终取得的成果。通过这一实践，银行成功地提高了系统的性能、降低了成本，并增强了系统的可靠性和可扩展性，为未来的业务发展奠定了坚实的基础。核心通过对交易类系统从Oracle数据库替换技术路线的选择和容灾方案设计的实践经验的介绍和分享，详细阐述这一替换和容灾方案背后的思考和决策过程，以及实施过程中的解决方案。本文分为技术路线选择篇和容灾建设方案篇。
篇一： [某大型银行手机银行等重要交易系统不做大幅改造整体去IOE最佳实践-技术路线选择篇](https://www.talkwithtrend.com/Article/269203 "某大型银行手机银行等重要交易系统不做大幅改造整体去IOE最佳实践-技术路线选择篇")  
篇二： [某大型银行手机银行等重要交易系统不做大幅改造整体去IOE最佳实践-容灾建设方案篇](https://www.talkwithtrend.com/Article/269209 "某大型银行手机银行等重要交易系统不做大幅改造整体去IOE最佳实践-容灾建设方案篇")

# 一、项目背景
 15年前，金融业的关键业务系统乃至普通业务系统都使用Oracle数据库作为数据存储的解决方案， 但是随着互联网业务和数据分析类业务的兴起，金融业的业务量和数据量呈现爆发式的增长，传统的集中式架构数据库越来越难以满足当下的需求，加之业务系统上云和微服务架构的普及，对于数据库的灵活性和扩展性有了越来越多的需求。 Oracle数据库可能在超大业务场景下面临性能瓶颈，以及日常运营过程中高昂的成本压力，外加 最近几年开源数据库和国产数据库无论在性能还是稳定性上都有了长足的进步 。金融行业业务系统越来越多探索使用开源免费和国产数据库替换Oracle数据库的可行性。
#  二、项目需求分析
 在选择其他数据库替换Oracle数据库时，需要考虑以下几个方面的分析：
##  1 . 性能分析
 查询性能：在不同的业务场景下，需考虑替换的数据库与Oracle的查询性能对比。为了最好的评估出查询性能，首先需要确定评估数据库查询性能的标准，例如查询速度、响应时间、数据处理能力等。这些标准可以根据实际业务需求来确定，确保评估结果能够反映实际使用场景的需求。在确认完查询标准后，预估实际的生产交易数据量情况，根据评估标准，设计不同的测试场景。这些场景可以包括单一数据表查询、联合查询、复杂查询等操作，以全面评估数据库的查询性能。在测试的过程中需要记录每个数据库的执行时间、CPU占用率、内存使用情况等指标，以评估替换数据库在查询性能上与Oracle的对比性能表现。
 可扩展性：基于MYSQL或者PostgreSQL构建的开源国产（分布式）数据库均有较强的可扩展性，但是选择时候依旧需要根据所支持的业务数据模型、支持事务的大小和在垂直（增加CPU核心、内存容量）水平（增加节点）扩展上面与Oracle进行对比，关键指标包括扩展前后的平均响应时间、吞吐量、并发连接数等。除数据库本身的扩展性基础之外，其他周边生态的扩展性，包括插件支持、组件完备性等方面也需要纳入考量。
##  2 .兼容性分析
 虽然主流的数据库都已经支持SQL-92、SQL-99和SQL-2003等标准，在基本的SQL语法上具有较高的兼容性。但是依旧需要考虑一些特定和扩展语法特性的兼容性。
 SQL的兼容性：Oracle支持存储和触发器，我们在选型新的数据库时候，要评估是否也支持存储和触发器，以及在语法和功能实现上的差异性。对于Oracle特定的语法，需评估有无合适的替代SQL实现。例如merge合并语法和CONNECT BY PRIOR递归查询，这些语法在特定的业务场景十分高效，替换选型的时候，需要重点评估是否有对应的语法能够平替，从而减少应用改造的成本。
 数据类型的兼容性：需要评估与Oracle在数据类型上的差异，例如日期时间类型、字符串类型、数值类型等。这些差异在数据库迁移和应用改造时候时，需要对兼容和平替的数据类型进行充分的测试和验证，以确保数据能够正确地存储和检索。
 事务的兼容性：重点关注评估事务的隔离机制和事务的控制语法方面的差异性。
 说完本身的兼容性，还要提一点就是业务层上的兼容性，数据库在系统中，起了很大一部分业务校验的功能，例如唯一、非空。若业务生态中有这样的判断，那么数据库中也需要有这样的判断，因为很少有代码人员将这些检查放在数据库之前，而不是让数据库去判断是否合适。还有就是你的业务上是否有新的特性发展，例如网络地址类型、XML类型、JSON类型、UUID类型，以及数组类型等，这些是否有强大的查询语句可以匹配。
##  3 . 可靠性分析
 在数据完整性、自动故障恢复、数据备份和恢复、数据安全等方面进行评估。
 自动故障恢复：评估数据库的自动恢复能力，包括故障检测、故障转移和故障恢复时间等指标。
 数据备份和恢复：评估数据库的数据备份和恢复能力包括备份速度、恢复速度、备份策略的灵活性以及备份和恢复的稳定性。
 数据安全性：包括数据加密、权限控制、审计功能等方面。可以通过评估数据库的安全功能和性能，包括数据加密算法（特别关注是否是高级安全加密算法，256位以上的商密或者国密）的安全性、权限控制的灵活性和性能开销、审计功能的完整性等指标
 数据一致性：包括事务的隔离级别、并发控制、分布式事务处理等方面。
## 4 . 成本分析
 成本分析不能只局限于许可证的成本，还要将生态的周边支持所需的成本、运维的成本、硬件的成本及改造开发的成本进行综合考虑。 许可证只是冰山的一角，运营过程中的成本是一个业务系统成本中占比最大部分。
 Oracle提供了强大运维和分析工具，例如Oracle Enterprise Manager、Oracle Data Guard、Oracle Real Application Clusters、Oracle Data Pump、AWR日志等，方便运维人员扩展系统、高可用设置、构建集群和数据灾备恢复以及获取运行时态的建议等，节约了运维人员的成本，所以考虑选型的时候，得考虑选择的数据库是否有相应的工具和能力，满足金融业的系统稳定运行要求；而不仅仅是简单的能查询数据、免费等可见成本。
 最后还有社区的活跃度支持，毕竟实际的运维工作中，很多的问题解决需要依赖社区对版本的升级解决，社区的活跃与强大与否，直接关系到是否能提供技术支撑和服务保障。
#  三、 选择PostgreSQL替换Oracle的决策逻辑
 在选择使用PostgreSQL替换Oracle在决策上，我行主要考虑了以下的几点。
 PostgreSQL本身具有优异性。PostgreSQL的查询性能、事务处理性能在部分场景上优于Oracle。
 此外，Postgre SQL 具备与Oracle高度兼容的语法和特性、较强的安全性能和多平台的兼容性，以及较强的可扩展性。
 语法的兼容性和特性上，我们主要考虑了数据类型、SQL语法、索引及约束类型上面的兼容性。在数据类型方面上，大多数Oracle数据类型在PostgreSQL中都有相应的等价类型，这使得在迁移过程中可以保持数据类型的兼容性。例如，Oracle中的NUMBER类型在PostgreSQL中可以用DECIMAL或NUMERIC类型表示，日期类型在两者中都可以用DATE或TIMESTAMP表示。这样，在迁移过程中，数据类型的转换工作量会大大减少，同时保持了数据的一致性。大部分SQL语法在这两个数据库中是兼容的。这意味着在从Oracle迁移到PostgreSQL时，现有的SQL查询和存储过程可以基本不用修改。基本的SELECT、INSERT、UPDATE和DELETE语句在两个数据库中都是通用的。同时，子查询、连接操作、聚合函数等复杂的SQL功能在这两个数据库中也是相似的。这种SQL语法兼容性使得从Oracle到PostgreSQL的迁移变得更加简单和直接。索引和约束是数据库中用于提高查询性能和保证数据完整性的重要机制。Oracle和PostgreSQL在这方面也有较好的兼容性。在索引方面，都支持B树索引、位图索引等常见的索引类型。在约束方面，Oracle和PostgreSQL都支持主键约束、外键约束等常见的约束类型。这些可以保证在迁移过程中也可以保持一致性，从而保证了数据的完整性和一致性。
 当然也不能忽视二者之间存在的一些不同。应对这些不同则需要在开发时候，对数据库本身的语义和代码层面上进行适应性改造。例如在事务上,Oracle需要显示的begin和commit开启和提交事务，而PostgreSQL则默认每个SQL是一个事务。若要开启一组事务，则需要用begin，commit将SQL段包起来形成一个事务组。此外Oracle与PostgreSQL都有相同名称的连接语法，但是Oracle是忽视空的，而PostgreSQL并不会忽视空位。这些都需要使用者结合实际的业务场景进行适应性选择。
 在成本考虑方面，PostgreSQL是免费的开源软件，在解决掉开发的成本之后，就要考虑容灾和运维上的成本了。容灾方面PostgreSQL自带流复制能够完美的实现节点之间的容灾，后续所需要进行的就是在其上面的二次扩展。 而运维方面，在不考虑许可证费用前提下，相较于Oracle，PostgreSQL的运维成本相对较高，例如没有完整的AWR分析日志，没有对历史SQL的里程跟踪。但是相对其他的开源数据库，PostgreSQL已经提供了非常完备的性能监控和管理和运维工具，例如PostgreSQL_stat_activity、PostgreSQL_stat_statements等监控视图和PostgreSQL_dump、PostgreSQL_restore和vacuum等管理命令，再加上社区的各种插件和市面上普及的支持度，运维成本其实已经是比较低廉的了。
 此外，选择PostgreSQL也兼顾到发展方面的考虑，因其更有利于二次开发和支撑业务的进一步深入发展。
# 四、最终决策
在以上的分析之后，在最终实施替换之前，我们还实施了以下的步骤，来确保替换过程的支持性。
1、评估和规划：对现有的Oracle数据库环境和要迁移的数据量，确定迁移时间和预算。制定详细计划，包括迁移的步骤、测试和验证方法。
2、实施数据迁移：将现有的Oracle数据库中的数据迁移到PostgreSQL中。在实施后，使用工具对比核验，确保数据的完整性、准确性和一致性。数据迁移的实施，往往不能一轮就完成测试验证，需要反复进行多次，将各种类型的数据迁移场景，都能够纳入其他。
3、应用程序适配和性能优化：兼容性再好，也涉及修改应用程序代码，代码修改过程中，确认代码的开发规范，包括调整SQL查询、存储过程和触发器等。以及重新设计表结构、创建适当的索引、调整查询语句和配置数据库参数 。确保应用程序在PostgreSQL 数据库上正常运行。
4、先容易后难，先管理系统后核心系统的迁移。用生态的视角看平替，例如很多具有AA特性的磁盘就能替换很多数据库的备份工作。
结合实际的业务场景，我们采用了微服务+多PostgreSQL数据库集群的方式，数据使用一致性hash实现各个分库数据均衡。在业务实现上，我们采用数据网格的概念，让同业务场景下的所有数据，都集中于一个数据网格，减少检索范围和跨事务操作。整体性能测试结果显示，相较于Oracle RAC，虽然单集群内的单机QPS有所下降，但由于业务场景数据按照数据的区域进行了切分，整体上QPS有明显提升。此外由于采用的是开源软件，虽然在应用上和架构上实现较Oracle有所复杂，但是整体成本有明显下降，且未来的扩展性获得较大的提升。
 下表是使用Oracle12c和PostgreSQL  10.5对比测试的情况。用的是单机性能
 测试数据，采用TPC-C基准测试数据集，包含10个仓库，每个仓库包含300万条数据记录。
 查询性能测试结果
 ，可看到相同资源环境下的PostgreSQL的查询响应时间普遍高于Oracle；但是在特定场景的OLTP的查询性能测试中，PostgreSQL的查询响应时间不输于Oracle。
|   |   |   |   |
| ------------ | ------------ | ------------ | ------------ |
| 操作 | Oracle平均响应时间 | PostgreSQL平均响应时间 | 性能差异 |
| OLTP查询 | 15 | 13 | -13% |
| OLAP查询 | 50 | 80 | 30% |
| 插入 | 40 | 60 | 20% |
| 更新 | 50 | 90 | 30% |
| 删除 | 60 | 70 | 20% |
 但是在特定场景的OLTP的查询性能测试中，PostgreSQL的查询响应时间优于Oracle。
 虽然PostgreSQL性能较Oracle有所差距，但在可接受的范围内；最重要的是PostgreSQL本身的成本低廉，以及在集群模式下，数据分散程度高，整体性能是能高于Oracle的。

# 五、总结
PostgreSQL 数据库以其开放的社区性，强大的商业和创新能力，外加快速的迭代更新。已经成为Oracle替换路线中首选之路。时代在发展，我们更加要以开放包容变更的心态迎接事物的变更，况且这还是一个有利的趋势。

协作专家：  
赵志勇 某城商行系统分析师  
陈曦 某大型银行 数据库主管  
孙慧天 某城商行 系统架构师  
许维豹 某城商行 数据库架构师  
杨梦伦 某大型银行 系统工程师

顾问专家：  
陈明福 某城商行 技术经理

银行交易系统信创数据库 OceanStor Dorado Oracle

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！