银行分布式数据库建设路径探讨？

核心诉求我觉得有以下几个：
1）一些数据库越来越大，访问量越来越高，单机已经无法承载，或者纵向扩容的成本太高，这时候就需要通过支持横向扩展、支持廉价x86服务器的分布式数据库技术来解决
2）现在很多行都开始微服务以及数据中台的建设，如果采用传统数据库技术，数据库实例的数目将会非常恐怖，DBA的运维工作将会受到极大挑战，解决这个问题我们就需要一个既能很方便的弹性伸缩，又能资源隔离（多租户）的数据库来存储数据，很多分布式数据库都提供了这样的能力

市面上的分布式数据库技术分为两个流派：
1）采用中间件的分库分表方案，比如使用mycat
2）原生分布式数据库，比如国产的有tidb、oceanbase、巨杉数据库等等

分库分表方案在市面上使用很多，尤其在互联网。这种方案的优势是底层采用成熟的传统数据库，所以数据库层面比较稳定，缺点是对应用的侵入性比较强、限制比较多，同时运维非常不方便。

而原生分布式数据库对应用非常友好，在应用看来就是一个单库，无需关心分布式事务、数据存储在哪个节点等一系列问题，同时运维也非常方便，一个DBA可以轻松管理100多台机器构成的集群。因此它的诞生其中一个目标就是替代分库分表方案，而且全球技术评级机构像Gartner、Forrester都从来不会把分库分表方案放到他们的评估列表中。原生分布式数据库同时还提供了良好的弹性伸缩容能力、高可用甚至容灾能力，这也是业界对其比较看好的重要原因。当然目前原生分布式数据库的缺点也很明显：
1）太年轻，与传统数据库相比无论从稳定性（主要指性能，发生bug的概率）和功能性上来说都有一定差距
2）对存储过程、外键、触发器等特性基本不支持

需要避免的坑，我想到的主要有：
1）如果应用大量使用oracle PL/SQL存储过程，迁移会很痛苦，个人不太建议拿这些系统做试点
2）分布式数据库一般都采用两阶段提交，因此效率上会不如单机数据库事务，为了提升两阶段提交的性能，有些数据库会采用乐观锁，乐观锁会出现一些跟悲观锁不一样的行为，因此应用逻辑可能需要调整来适应
3）在分布式数据库上跑中间结果集很大但最终结果集很小的查询效率可能不太好，主要是跨节点传输大量数据导致耗时较长，而传统数据库顶多就是从磁盘到内存这个过程，没有网络IO
4）分布式数据库和传统数据库之间如何做容灾的问题，比如分布式数据库作为主库上线运行了，但是我们担心它会出问题，想利用传统数据库做备库，两者之前的数据同步如何进行，这目前也是我们想要解决的事情