对于OLTP而言，中小城商行的数据量不如大行，是否有必要引入分布式数据库?什么情况下需要引入，如何选型？

分布式数据库分为2种：存算分离的分片数据库，例如MySQL体系的。还有就是TiDB Oceanbase这样的。
一般来说，企业的重要业务系统全分布式改造，动作比较大，在国内银行中改造成功的较少。且这种替代需要3-5年的过渡期。
中小城商行可以选择一些互联网、线上营销的业务，在业务软件引入的同时，进行分布式数据库更换。如果技术力量薄弱，也可以先基于测试、开发类业务进行试用，逐渐上生产。

总之，国内大部分分布式数据库都已经开源，开源意味着运维、开发等综合能力的体现，你的、你团队的技术能力决定分布式数据库的应用范围大小。

在业务处理量及数据量小的情况下，分布式处理性能可能还达不到集中式数据库处理性能，运维工作量还高；如果自身运维技术能力不是太强的话，建议谨慎考虑

说句反潮流的话：采用分布式数据库的目的是什么？其实是更好地处理集中式的业务。银行的业务是大集中的，因此不管是分布式还是集中式，最终都是用各种方式满足大集中的业务需求。分布式和集中式只是手段不同。如果集中式可以满足业务要求首先从需求上就没了更换的必要。

另外这个业务需求除了自主可控外，主要来自于业务支撑压力，而非成本等因素。再说句反潮流的话，当前（注意这个限定）用分布式替换集中式架构多数成本会更高。

如果出于其它考虑，打算引入分布式数据库，那么说一些数据库之外可能需要考虑的东西：

1. 引入分布式数据库不只要考虑数据库，而是要将基础设施、云等IT能力综合考虑。分布式数据库往往会带来数倍甚至十倍以上的硬件增长，软件的规模和维护压力也是爆增的。那么相应的资源准备，管理，自动化运维都要跟上。
2. 应用改造、迁移的工作要重视。如果能引入大行的经验甚至能力最好，如果不能，那要评估一下大行的经验是否适合中小城商行的开发维护能力，能不能构建相应的能力。

以经济方面，实用性方面考虑吧，对于OLTIP而言，如果中小商行现在以集中化数据库就可以满足业务需求，就不需作大量变更，如果不差钱，或者为日后业务扩大而考虑，就可以用一些不太核心的业务来尝试，尝试使用分布式数据库。

没必要强制，
1、先判断数据量大小，如果合计才几个g的数据，普通一个机器甚至台式机即可满足
2、如果数据达到一定的量，可以考虑其他
3、当然这里要考虑自己公司 团队的能力，是采用分布式呢 还是购买现成的产品呢

中小行可能还需考虑其它因素，如现有维护团队技能、应用侧是否适配改造、对比集中式数据库的综合成本、分布式数据库的成熟度和技术演进等考虑吧

从投入产出的角度考虑，90%的单表数据量没有达到1T以上，可以采用分布式的关系型数据库，扩展性和性能上可以媲美大数据平台，维护性上相比hadoop的架构在成本和管理都相对较低。

判断两个点：

1.数据量和业务规模

分布式数据库解决的最核心的问题是业务规模和扩展性。

如果业务量大到集中式数据库物理机承载上限了，就需要分布式，否则并不是强要求。

我举个例子：

客户他业务规模要16C64G足够的话，就没有必要搞分布式

根据您的描述，目前传统数据库如Oracle、DB2应该是能够满足你3-5年内的需求的，所以现在这是引入分布式数据库（推荐信创产品）的最佳契机，你有3-5年的试用时间，可以现在非核心系统进行试用，逐步用到核心系统中。

现在的问题并不是集中式和分布式的区别。
小行我觉得有两种选择
1）学大行，那一定就是分布式。
2）自己探索一条国产化集中式改造道路，这类产品也是很多的，比如达梦、人大金仓等