3同行回答
这个问题比较宽泛，可分为几种情况：
1.兼容性评估
这与去O的路线有关，如考虑尽量减少去O的应用迁移难度，选择兼容Oracle的产品，则兼容性需要重点评估。Oracle的功能非常丰富，目前国产化产品无法做到全部兼容，对于分布式数据库而言，这点更为突出。
2.产品评估
除去上面因素外，就是从数据产品本身维度进行测试。这里涉及的测试点很多，具体细节可参考我之前的社区文章。
选型评估是一个全方位的事情：我来帮韩老师贴一下
4） 金融业分布式数据库选型技术要素
技术为业务服务的，不能为了使用技术而使用，需要综合考虑成本和收益的平衡。分布式数据库使用场景，应当在数据大规模、高并发、高可用性等场景下有其特有优势。一般的业务场景如果能用单机数据库支撑的尽量用单机库。选择一款分布式数据库，会带来一系列的成本，如应用适配成本、运维成本、硬件成本，这方面后面会赘述。此外，在做上述判断时，还需考虑业务的发展，最好是能判断三年的数据量和交易量的增长变化。在进行分布式选型时，可重点考察下列几个方面：
- 分布式事务
分布式架构，自然会带来分布式事务的问题。由于需要跨节点的网络交互，因此较单机事务会有很多损耗。随之带来的是事务处理时间较长、事务期间的锁持有时间也会增加，数据库的并发性和扩展性也会很差。针对单笔事务来说，分布式事务执行效率是肯定会有降低的，分布式带来的更多是整体处理能力的提升。但在设计之初，就应尽量做到业务单元化，将事务控制为本地事务，这可大大提升执行效率。
- 性能
由于二阶段提交和各节点之间的网络交互会有性能影响，分布式数据库优势不是单个简单 SQL的性能，但是大数据量的SQL查询，每个节点会将过滤之后的数据集进行反馈，会提升性能，并且分布式数据库的优势是并发，大量的SQL并发也会比单机数据库强大，应用需要做分布式架构的适配，将串行执行机制尽量都改造成并发处理。对于含有需要节点间数据流动的SQL语句的事务，OLTP类的分布式数据库处理效率一般较差，事务处理时间会较长，事务期间的锁持有时间也会增加，数据库的并发性和扩展性也会很差。建议尽量改造存在跨节点数据流动的SQL语句 （主要是多表关联）的事务。 分布式数据库性能是软硬整体架构的保障，不仅在软件、S QL 语句方面做优化，硬件方面也需要重视，包括处理器、内存、网络、磁盘等等，尤其在支撑交易类业务系统时重视对基础设施选型和优化。
- 数据备份
分布式数据库一致性保证通过内部时钟机制，所有节点都会遵循一致的时钟，所以备份恢复的增量也是基于时钟，相当于单机数据，但是分布式数据库的备份解决方案最重要标志是否支持物理级的备份，物理级的备份会比逻辑的备份性能吞吐会大很多，还有就是是否支持一些分布式备份方案，比如 S3协议接口，是否支持压缩等功能。分布式数据库基本都具备备份和恢复方案，通常从备节点进行连续备份（全量+日志），恢复的时候制定节点进行恢复到指定时间点，整个过程可配置自动任务自动执行。
- 高可用
分布式数据库大多都是基于多数派协议，同城双中心不适合多数派的要求，同城数据级多活建议采用三中心部署，如果同城主备可以采用集群级的异步复制。异地建议采用集群级的 binlog异步复制。建议实例的主备节点设置在同城两个双活数据中心，仲裁节点三机房部署；异地灾备单独启实例与本地实例进行数据库间同步，也可以将本地备份文件T+1恢复到异地灾备。
- 数据一致性
NewSQL分布式数据库基本都是通过获取全局时钟时间戳，采用二阶段提交实现一致性，可以实现一致性的保证，分库分表架构对于事务的一致性，需要应用层考虑，比如通过合理的分区键设计来规避。分布式数据库对于跨节点事务目前还是实现的最终一致，对于全局一致性读，一般通过引入类似全局时间戳的组件统一管理全局事务，在数据库选型时可以重点关注厂商对这一块的实现。如果目前暂时无法提供全局一致性读的分布式数据库，对于要依赖分布式事务“中间状态”的业务，优先进行业务改造进行规避，其次通过合理的数据分片设计让其在单节点内完成。
- 其他因素
金融行业在数据库选型中，除了需要考虑上述外，还有其他一些因素的考虑。如原有系统的承载能力、是否必须进行选择等。
5） 金融业分布式数据库选型非技术要素
金融业分布式数据库选型，除了上述技术要素外，还包含如下非技术要素，主要是在成本投入方面：
- 硬件成本
一般采用 x86服务器，存储多为本地存储，推荐使用SSD甚至是NVMe SSD，网络一般 采用 万兆网络。在这部分主要成本是取决于集群规模、数据量及数据库自身架构。此外，如果涉及到灾备方案，还需要考虑灾备环境的硬件投入及主备间的专线费用。 此外，考虑很多金融单位现在机房建设空间和能耗有限，可采用配置较高的硬件设备，如基于英特尔 ®至强® 金牌处理器内核的x 86 物理机、配置 英特尔®傲腾™固态盘 等，减少服务器数量、降低耗电量。
- 软件成本
主要来自分布式数据库本身的软件采购成本，成本取决于各厂商的内部商业策略。但这部分总体来讲，是较传统数据库产品还是有优势的。此外，这部分还涉及到维保费用，针对分布式数据库来说，相对较新，企业自有能力尚不具备，还是建议购买原厂服务或其他三方公司的服务，降低风险。
- 开发测试成本
这部分是指针对数据库更换后，应用需要需要完成的必要的开发测试成本。这部分成本差异很大，跟原有系统实现有较大关系。如果原有系统重度依赖数据库（大量功能是基于数据库自身功能实现的），那么存在的改造量较大。新型分布式数据库的功能，不能与传统数据库做一一对应，很多能力是需要在应用层重构完成。针对这种情况，是建议应用开发遵循数据库标准方式进行（如采用 MySQL作为标准）开发，这样如有改型也很简单。此外，还有一类隐形成本包含在这部分，如果业务比较重要，是需要考虑双发支持或灰度迁移的方式，这会带来一部分工作量。总体来说， 这部分成本是比较高的，可能占整体成本的大部分。
- 运营维护成本
这部分成本，包括了为满足更换数据库所带来的数据迁移成本和上线后的日常维护成本。针对前者，可以在应用侧解决或者外采商业软件解决；后者更多是人员管理成本。针对这部分成本，是有个相对较长的投入，且整体成本不少。
收起