分布式数据库建立的必要性？

我们目前采用的是TDSQL（MySQL版本）数据库，其提供了分布式版本和非分布式版本，分布式版本是数据分片的，非分布式版本是数据不分片，为集中式数据库主备集群，两种数据库统一由管理平台管理，均实现自动化运维和智能运维。

我们根据我们行的业务规模，对一般业务系统，单节点的物理机性能足以满足其未来3-5年业务发展需求的，我们会采用非分布式版本；对于关键业务系统，像核心系统、互联网类、支付类、信贷类，后续随着业务的发展单节点（也受物理硬件限制）是无法满足业务发展需求的，会结合业务发展进行节点扩容的，我们通常采用分布式版本；

所以我们主要看几方面：业务系统等级、业务系统性能要求、业务系统扩展性需求、数据库所在物理设备性能极限，优先采用分布式数据库。

这里顺便提一下，2019年中国人民银行印发《金融科技（FinTech）发展规划（2019-2021 年）》（银发〔2019〕209 号）金融科技发展三年规划中提到的“加强分布式数据库研发应用”的要求，目前已经接近收关，同时人民银行目前在进行XC试点，其涉及分布式数据库的应用，所以2022年明年起的分布式数据库应用的推广的力度可以大胆的预测一下，到时候看性能和成本可能只是一方面了。

性能其实不会有提升，为了解决全局读读写一致性，会引入复杂度和更多的耗时。如果容量不是问题，一个分片挺好的

是否要建立分布式数据库，还是要基于场景和具体的业务需求，不能一概而论。
分布式数据库本质上是物理上分散而逻辑上集中的数据库系统，利用分布式事务处理、数据自动分片、数据多副本存储等技术，将分散在计算机网络的多个逻辑相关节点连接起来，共同对外提供服务，因此，具有良好的扩展性，适用于大并发和海量数据的处理。但因分布式数据库将数据分散到各个节点上，需要利用分布式事务来保证数据的一致性，因此，必然会带来额外的开销，这就要求在数据库设计时，必须充分考虑应用产生的数据特点，合理选用分区键和数据分布策略，尽量减少跨节点的分布式事务，以提高数据库性能。故对设计人员的要求也较高。所以,如果应用系统需要处理的数据量不大，可用传统的集中式数据库，而不需要分布式数据库。

这是大家在分布式转型的时候，面临的首先要问题。也就是说我们为什么要进行分布式的转型？
其实这个问题我觉得取决于两点：

1. 现有的数据库系统是不是已经无法支撑由于互联网业务转型带来的一系列需求？例如并发性，扩展性和灵活性？如果是那么分布式数据库无疑是我们应该研究的东西。
2. 传统架构下的一些平台是不是伴随着业务的不断更新，出现了新的数据类型或者数据结构变得复杂化了，比如说一些新的非结构化、半结构化影像数据？

如果没有以上问题，那么建设分布式数据库的步伐可以放缓，或者作为试验田。

主要还是业务需求和系统架构吧。业务数据量非常大，每天的计算和落库数据很多，集中式数据库的锁等待问题严重，则有必要，但是如果应用尚未支持，则单纯数据库分布式意义也不大。
所以还是得从当前数据库的数据量、并发以及吞吐等情况综合衡量，当真的集中式满足不了的时候，提前规划。

分布式数据库通过横向扩展资源来实现性能的扩展和高可用性的提升。所以看起来这项技术就是未来发展的方向，而当前也确实涌现出很多的优秀的分布式数据库产品。然而作为新兴的数据库技术，分布式到底能解决什么性能问题，是否也会存在新的瓶颈，带来新的损耗？ 分布式数据库的技术复杂性又会带来运维成本的提升，那么这些提升又是在什么方面呢？是不是预示着数据库运维已经面临一次很大的变革转型？下面仅仅代表个人的看法：

1、 分布式的性能不是万能的，但是必须的

从金融业内对分布式数据库技术的测试来看，采用不同分布式技术的数据库产品在测试里普遍出现了性能偏好。也就是使用的数据库技术主要是为了解决一类问题。面向tp的分布式数据库解决大表和热点数据等问题，通过数据分片和事务分发实现性能提升。面向AP的分布式数据库通过算子优化计算下推等方式，充分利用节点的分片计算性能来提升AP业务的速度。而部分存储计算分离的分布式数据库主推运维便利性。但是这些分布式技术可能带来延时变长，交互瓶颈和数据重分布等可能出现的分布式环境特有的问题，所以还需要搞清楚这些分布式数据库的缺点，避免踩坑。

所以面向特殊性能需求，选择合适的分布式数据库，这是最切合实际的做法。

2、 分布式数据库的复杂性对于运维带来的不仅是挑战，也是运维模式的改变。

分布式数据库的运维存在两面性，一方面新的技术复杂，另一方面运维分布式数据库的方式也在发生根本的改变。为了充分利用分布式数据库的能力，相信很多的客户更愿意使用多租户的方式来管理业务对数据库的需求。未来分布式数据库应用的分水岭不仅仅是性能，还在于这种多租户的管理能力。而分布式数据库的集中式运维，与数据库上云后的智慧运维其实是相似的。所以大家都要开始新的运维模式转变，不如从分布式数据库开始做起。

3、拥抱分布式，拥抱云，现在就开始

分布式数据库和数据库上云一定是趋势，现在正是熟悉这些技术并掌握的时候。如果等到不得不面对的时候，反而困难重重。因此不如从现在就开始挑选合适应用尝试使用分布式数据库，在实践中积累产品技术和运维经验，积硅步以至千里 积懈怠以致深渊

技术服务业务，用什么数据库架构是业务发展带来的，很多银行为了技术先进性使用分布式数据库，明明oracle等单机关系数据库能搞定的事，一定要不顾成本的改造应用去适配分布式数据库，由于自身技术欠缺，还需要购买三方的服务，这种政绩式的项目也不需要去评估成本收益性。我们需要考虑在一些海量数据、海量用户的业务场景考虑分布式数据库，是因为在这种业务场景中，分布式数据库的性价比要远远高于单机关系型数据库，适不适合采用分布式数据库架构，完全由业务场景决定的。

首先请问什么叫必要性？
如题所说分布式数据库带来不少成本上升，而关心的却是性能是否cover住成本，这个其实有一点问题，不在点上，从性能而言，分布式其实并不好
需要知道分布式解决的问题是扩展和容灾，首要考虑的是数据强一致
而不仅仅说把分布式数据库当成分片数据库。

我觉得分布式在架构方面是优于集中式的。
分布式数据库和集中式相比，性能肯定是下降的，分布式的事务成本太高了。但是在扩展性和可靠性上会比集中式好很多。这两种架构各有优劣。
分布式天然的支持DBaaS，也是一个明显的优点。可以把分布式和数据库上云这两件事一起做了。我觉得云化以后，硬件的成本应该差不多。

其实主要看有没有这个业务需求。如果单机确实跑不起来就是分布式，切忌为了分布式而分布式就纯粹是噱头了。