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

看大家也比较活跃....我再认真的重新写一下：

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

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

2.数据库类型考量
  在选择数据库类型中，可能现在多以分布式数据库为考量了，那么除了能不能满足使用，还要考虑不同分布式数据库类型对后续运维、开发规范等影响，这部分原生分布式数据库和中间件型分布式数据库差异还是比较大的。
  主要是在分片规则设定、多表关联查询、轻度olap使用这块，单存储引擎（不考虑带入单独列存的设计）的olap是分布式数据库的一大痛点。
   这块也决定了后续使用，要不要制定强开发规范，这也意味着是DBA用的痛苦一点，还是开发人员用的痛苦一点.....

3.数据库运维监控管理软件
  这部分功能，将直接决定数据库对于运维人员好不好用，尤其是中小规模城商行使用。在这部分功能上，不同厂商产品的差距能拉开的很大。
对于中小规模城商行的运维人员，说实话TPS、QPS低那么10%、20%影响不大的，反而是运维、监控、管理能力，有时候直接决定了RTO时间。
重点关注城商行案例少的数据库厂商，他们往往这部分能力偏弱。

4.与核心系统的适配
  这部分仅对于使用核心应用厂商做完全替换的新核心建设，那么你要重点和长亮、神码这种核心厂商沟通，基于不同数据库做开发，对于你的新核心应用建设有哪些阻碍。
适配么肯定都适配过，好不好用他们心里清楚。一定要问到技术细节上好不好用，比如：如果分布式数据库不建议>=2张表以上的关联查询，那么你的核心要如何设计，你的柜面逻辑要如何设计才能匹配这个规则，开发难度怎么样。

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

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

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

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

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

4，RPO,RTO的容忍度；

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

1、性能  硬指标  对于大事务的支撑  
2、可扩展性 能快速的扩容和实现三地多活灾备
3、安全性   数据存储传输和应用过程中的安全附件是否多
4、SQL鲁棒性  除了了标准SQL外其他场景的支撑力度
5、生态环境   行业应用的是否多
6、服务与支持  服务支撑是否到位

核心数据库，题主说的几个都是重点关注指标。
其实目前最为全面和丰富的数据库- Oracle，可以作为一个标杆参考。
针对不同业务场景和适配，去选择和考量一个数据库产品，另外，也是希望国产数据库厂家能够沉下心来，做好自己的技术积累，切勿急功近利，还是要借此机会，做好咱们自己的技术积累，希望能够出现我们自己的核心的数据库产品。

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

1. 性能：数据库系统的性能对于许多应用程序来说至关重要，应该评估其吞吐量、响应时间以及查询性能，以及大数据量和高并发场景的技术积累和沉淀，复杂事物的处理，当然目前的做法都是采用多个产品组合实现。
2. 可靠性：数据库系统应该专注于提供高级别的可靠性和容错能力，以确保数据不会丢失或损坏，并且在发生故障时可以快速恢复，丰富的备份方案，高可用能力、恢复能力。
3. 安全性：数据库系统应该提供强大的安全性能，包括用户管理、访问控制、身份认证、数据加密、安全防护等方面的功能。
4. 可扩展性：数据库系统应该支持水平和垂直扩展，以便未来能够满足应用程序对资源和性能的不断增长需求。
5. 社区支持：数据库系统应该有一个活跃的开源社区，以便用户能够获得支持、文档和学习资源，包括整个数据库生态的建立和配合。
6. 成本效益：数据库系统应该具备良好的成本效益，不仅在于产品本身的价格，而且还包括在每年维护和升级成本方面的考虑，以及长期的技术支持。
7. 全面性：数据库系统应该提供完整的功能集，如事务处理、备份恢复、数据存储等，尤其是现在的应用要求和需求场景下。

工信部赛迪顾问2023年2月发布了《 核心数据库升级选型参考 》，这个是比较权威的，而且对核心系统有针对性，有参考意义；
参考链接:https://baijiahao.baidu.com/s?id=1761039726492953703&;wfr=spider&for=pc


以史为鉴，数据库必然会向头部收敛，即使的当前的老二，尚且不一定能活下来；即使是大厂，产品不行，依靠多种产品夹带数据库进去，同样走不远的；
选错那就再来一次选型，可能负责人换成另一个人；

除了提到的这些点，还可以参考：
1、行业的测评数据
2、极端情况下（例如高IO、数据量超大且磁盘空间不足）的测试用例，评估数据库的稳定性和性能损失情况
3、厂商的数据仅作参考，有条件的自己搭建环境测试

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

有如下6点指标需重点关注：

1. 语法兼容性：核心业务系统通常需要与多个系统进行数据交换和集成，因此语法兼容性是一个重要的指标。国产数据库在语法兼容性方面的表现需要被考虑。
2. 可靠性：核心业务系统需要高度可靠的数据库系统，国产数据库需要能够保证高可靠性，包括系统稳定性和故障恢复能力等。
3. 安全性：银行核心业务数据安全至关重要，国产数据库需要具备强大的安全性能，包括数据加密、权限控制、审计日志等。
4. 服务及技术支持：银行核心业务系统国产数据库需要具备良好的售后服务和技术支持，包括及时响应、快速解决问题等。
5. 数据厂商能力：银行核心业务需要考量国产数据库的实力和能力，包括技术研发、市场份额、行业认可度等可以侧面反应的综合能力；
6. 成本：也要性价比，核心系统改造的费用成本需要控制在一个合理范畴，包括授权费用、硬件建设、运维管理等方面。同时，需要考虑长期使用的成本，包括升级、维护、培训等方面。

经过一周的互动评论，对大家根据实际经验列出的重点关注哪些指标做了一个汇总（共九个），可见如下链接：
https://www.talkwithtrend.com/Poll/463353

但是，这些指标中，有些是核心指标，有些是非核心指标，因此做了如上的一个投票问答，大家可以继续参与，选出银行核心类业务场景数据库选型中TOP 5的核心指标。

分享社区专家两篇相关文章，可以做个参考：

1、《国产数据库选型评估体系建设经验参考》
https://www.talkwithtrend.com/Article/262943
2、《国产数据库需求场景评估模型解析（附评估模型文档工具下载）》
https://www.talkwithtrend.com/Article/264645