银行核心类业务数据库选型，重点应关注哪些指标？

社区探讨，供大家参考：

针对银行核心类业务场景数据库选型，大家重点关注哪些指标？

比如，我们可能关注如下几个方面的指标。

1、是否背靠大树，保证产品的可持续研发能力。

2、市场案例是否充足，验证数据库的成熟度。

3、与MySQL、Oracle等成熟数据库语法兼容性，可以减少改造成本。

4、配套软件是否充足，当前的数据库都不能作为独立的产品使用，需要配套的工具才能更好使用。例如，监控巡检工具、数据准实时同步工具、导出导入工具等等。

各位在选型的时候，还要考虑什么指标？

问题来自社区会员@wangzk0206 某农信数据库管理员，以下分享均来自社区同行

@Switcher 某银行 数据库管理员：

1.同业案例

确切的来说是同等规模银行相同业务系统的数据库案例，像核心系统的数据库选型，最好能多走访几家银行，坐下来聊聊技术，有些东西线下能说，网上可不能写。

另外即使规模相当，但有可能核心系统的数据量差距也很大，这个和数据保留策略有关，因此即使有了同业经验，还需要根据行内核心系统的特性来看。

2.数据库类型考量

在选择数据库类型中，可能现在多以分布式数据库为考量了，那么除了能不能满足使用，还要考虑不同分布式数据库类型对后续运维、开发规范等影响，这部分原生分布式数据库和中间件型分布式数据库差异还是比较大的。

主要是在分片规则设定、多表关联查询、轻度OLAP使用这块，单存储引擎（不考虑带入单独列存的设计）的OLAP是分布式数据库的一大痛点。

这块也决定了后续使用，要不要制定强开发规范，这也意味着是DBA用的痛苦一点，还是开发人员用的痛苦一点.....

3.数据库运维监控管理软件

这部分功能，将直接决定数据库对于运维人员好不好用，尤其是中小规模城商行使用。在这部分功能上，不同厂商产品的差距能拉开的很大。

对于中小规模城商行的运维人员，说实话TPS、QPS低那么10%、20%影响不大的，反而是运维、监控、管理能力，有时候直接决定了RTO时间。

重点关注城商行案例少的数据库厂商，他们往往这部分能力偏弱。

4.与核心系统的适配

这部分仅对于使用核心应用厂商做完全替换的新核心建设，那么你要重点和长亮、神码这种核心厂商沟通，基于不同数据库做开发，对于你的新核心应用建设有哪些阻碍。

适配么肯定都适配过，好不好用他们心里清楚。一定要问到技术细节上好不好用，比如：如果分布式数据库不建议>=2张表以上的关联查询，那么你的核心要如何设计，你的柜面逻辑要如何设计才能匹配这个规则，开发难度怎么样。

5.数据迁移同步工具

这部分不展开了，比较多：同库、异库迁移数据的工具便捷性；异库迁移对于特殊字段的兼容替换；基于日志的实时同步工具要不要借助第三方，稳定性如何，这个涉及到双库并行策略等等。

@wangzk0206：

确实如此，光靠厂商提供的案例，真的很难说明问题。有时一个非常偏远的系统，也说成核心。

@Switcher回复 wangzk0206：

全中国的国产数据库，70%在四大行都有相关案例，这和技术没关，这是四大行作为大国之行的社会责任体现。

@Acdante HZTYYJ 技术总监：

核心数据库，题主说的几个都是重点关注指标。

其实目前最为全面和丰富的数据库——Oracle，可以作为一个标杆参考。

针对不同业务场景和适配，去选择和考量一个数据库产品，另外，也是希望国产数据库厂家能够沉下心来，做好自己的技术积累，切勿急功近利，还是要借此机会，做好咱们自己的技术积累，希望能够出现我们自己的核心的数据库产品。

以下是一些还可以关注的点，作为参考：

性能：数据库系统的性能对于许多应用程序来说至关重要，应该评估其吞吐量、响应时间以及查询性能，以及大数据量和高并发场景的技术积累和沉淀，复杂事物的处理，当然目前的做法都是采用多个产品组合实现。

可靠性：数据库系统应该专注于提供高级别的可靠性和容错能力，以确保数据不会丢失或损坏，并且在发生故障时可以快速恢复，丰富的备份方案，高可用能力、恢复能力。

安全性：数据库系统应该提供强大的安全性能，包括用户管理、访问控制、身份认证、数据加密、安全防护等方面的功能。

可扩展性：数据库系统应该支持水平和垂直扩展，以便未来能够满足应用程序对资源和性能的不断增长需求。

社区支持：数据库系统应该有一个活跃的开源社区，以便用户能够获得支持、文档和学习资源，包括整个数据库生态的建立和配合。

成本效益：数据库系统应该具备良好的成本效益，不仅在于产品本身的价格，而且还包括在每年维护和升级成本方面的考虑，以及长期的技术支持。

全面性：数据库系统应该提供完整的功能集，如事务处理、备份恢复、数据存储等，尤其是现在的应用要求和需求场景下。

@jillme CIO：

1.性能：硬指标，对于大事务的支撑  

2.可扩展性：能快速的扩容和实现三地多活灾备

3.安全性：数据存储传输和应用过程中的安全附件是否多

4.SQL鲁棒性：除了标准SQL外其他场景的支撑力度

5.生态环境：行业应用的是否多

6.服务与支持  服务支撑是否到位

@yangjunfeng 联通 数据库架构师：

楼上几位大佬已经说的不少，我个人还会考虑：

1.压测数据，同等配置下，MySQL，Oracle，以及所选数据库的压测数据。包括基准压测，性能压测，疲劳测试等。

2.变更流程与新数据的打通，日常变更需求，自动、人工怎么适配新数据库。

3.投入，产出比。比如开发对该SQL的了解程度，以及硬件成本这块的。

4.RPO、RTO的容忍度。

5.备份恢复是基于块跟踪的，还是传统的逻辑备份。备份恢复保命大法的易用度。

@大禹 数据库架构师：

以史为鉴，数据库必然会向头部收敛，即使是当前的老二，尚且不一定能活下来；即使是大厂，产品不行，依靠多种产品夹带数据库进去，同样走不远的。

选错那就再来一次选型，可能负责人换成另一个人。

@waring_id  技术经理：

除了提到的这些点，还可以参考：

1、行业的测评数据。

2、极端情况下（例如高IO、数据量超大且磁盘空间不足）的测试用例，评估数据库的稳定性和性能损失情况。

3、厂商的数据仅作参考，有条件的自己搭建环境测试。

@Ethan_Yang 某金融司 技术架构师：

语法兼容性：核心业务系统通常需要与多个系统进行数据交换和集成，因此语法兼容性是一个重要的指标。国产数据库在语法兼容性方面的表现需要被考虑。

可靠性：核心业务系统需要高度可靠的数据库系统，国产数据库需要能够保证高可靠性，包括系统稳定性和故障恢复能力等。

安全性：银行核心业务数据安全至关重要，国产数据库需要具备强大的安全性能，包括数据加密、权限控制、审计日志等。

服务及技术支持：银行核心业务系统国产数据库需要具备良好的售后服务和技术支持，包括及时响应、快速解决问题等。

数据厂商能力：银行核心业务需要考量国产数据库的实力和能力，包括技术研发、市场份额、行业认可度等可以侧面反应的综合能力；

成本：也要性价比，核心系统改造的费用成本需要控制在一个合理范畴，包括授权费用、硬件建设、运维管理等方面。同时，需要考虑长期使用的成本，包括升级、维护、培训等方面。

@匿名用户：

各位发言讲得非常全面，我这里只补充一点建议，即核心数据库选型要参考现实的数据体量和业务量，在此基础上确定数据库相关的质量属性。数据体量和业务量的大小对数据库的性能要求是有差别的，会决定服务的及时性、稳定性等。

  您怎么看？

欢迎来探讨

欢迎点击文末 阅读原文 到社区阅读和讨论交流，发表您的看法

觉得本文有用，请 转发 或点击 赏 ，让更多同行看到

社区专家组织针对数据选型的课题研究成果，供同行参考：

• 重磅！中小银行非核心交易系统国产数据库选型评估报告 | 4维度19指标·7数据库·实践用户投票评价

• 中小银行非核心交易系统国产数据库选型评估框架→

• 国产数据库选型评估体系建设经验参考

• 国产数据库需求场景评估模型解析（附评估模型文档工具下载）

欢迎关注社区  “数据库”技术主题  ，将会不断更新优质资料、文章。地址： https://www.talkwithtrend.com/Topic/597

下载 twt 社区客户端 APP

长按识别二维码即可下载

或到应用商店搜索“twt”

长按二维码关注公众号

*本公众号所发布内容仅代表作者观点，不代表社区立场