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

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

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

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

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

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

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

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