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

分布式是大趋势，不仅体现在数据库上，也体现在应用上。
数据库有分布式数据库，应用也有分布式架构。容器、云、分布式，这些技术潮流还是要赶上的，也许目前不需要，但总要防患于未然。
并且，即使是中小城商行，业务规模将来总会增大的，现在提前把技术平台搭建好，以应对未来业务所需。

如果行里有线上交易系统，或者有系统已经开始拆分业务节点和数据库节点，那么可以换到分布式数据库。

在分布式数据库选型时，应该关注数据库的综合能力，不仅要测试对于数据库传统功能的支持度、分布式特性（如弹性伸缩、高可用、高性能），更要测试数据库运维管理能力和兼容性，后者是应用迁移最为关注的问题。此外，也要考虑成本，根据行里预算进行选型。

对于中小城商行，从性能和数据量上来说，单个交易系统使用传统数据库也可以满足要求。引入分布式数据库主要是从提高响应业务的敏捷性，弹性扩容、降低运营成本等几个方面来考虑。引入分布式数据库，由于性能一般都能满足要求，可以从数据库产品的稳定性、功能、协议支持的完备性、服务质量这些方面来选型。

在做出合适选择之前，需要以下准备工作：
1. 业务画像
针对不同的业务，做出业务侧的数据库画像，包括但不限于如下维度

• 业务指标：使用方式、使用特征（在线用户、峰值用户、并发用户等）、重要级别、可用性要求。此外，针对未来发展也要有所评估。
• 系统指标：包括应用系统来源、技术栈、开发语言、系统拓扑、与数据库交互方式等
• 数据库指标：包括数据规模、访问特征、物理环境、软件环境、数据库拓扑等
• 运行特征：场景分类（TP、AP、混合）、架构分类、数据规模、数据特征、计算规模、事务一致性要求、扩展性要求、高可用要求、应用耦合性等
  2. 产品测试
  对数据库产品进行测试，形成对产品的统一认识。这其中包括数据库内核、管理、开发、安全等多方面能力的评估。这方面可参考我之前分享的《分布式数据库评测标准》。
  3. 其他因素
  除上述外，还应包括企业内部的一些自身因素的考虑，如成本、运维、开发改造等因素。

上述因素综合考虑后，才能做出相对合理的选择。

可以迟到，但不可缺席；
走别人走过的路，少踩坑。