-
一、集中式与分布式之争
分布式和集中式数据库，谁才是未来之主？真的有必要上分布式数据库么？此类争论在近日又被频繁提起，每个人都有充分的论据，甚至引用权威机构的调查数据，支撑各自的观点。
集中式场景。小型企业的数据量小、并发低，大型企业依然存在超过半数以上的中小业务系统，以及一些边缘计算场景，集中式数据库无论从性能、成本还是开发运维复杂度上都具有更强的优势，毋庸置疑的将是首选产品。
分布式场景。海量数据、高并发的大型业务系统，可靠性要求极高的核心系统，负载随时间呈剧烈波动的互联网业务等；尤其是在当前国产设备性能和可靠性达不到大型机、小型机水平的情况下，分布式数据库高可用性、扩展性将更有优势，此时分布式也是必须的选择。
基于“两类业务场景将会永恒持续”的事实，所有人争论来、争论去，最终的结论无非就是集中式、分布式两者各有优劣，同样会跟随业务场景长久并存下去。
这样的结论看似不可动摇。然而，结合数据库发展历程，技术架构的不断更迭，当我们预见未来架构如何演变时，此刻的争论都将显得徒劳无功！
-
数据库的未来，将不再有分布式和集中式
1，市场重叠、竞争激烈，能力趋同性是必然结果
数据库从1961年GE的IDS算起，已经发展60年。1970 年6 月，Edgar Frank Codd正式掀开了关系型数据库的面纱，之后Oracle、Informix、DB2、Sybase等一众先驱者将数据库软件推上了IT系统核心技术的高度，此后的世界一直是这些集中式的天下，那时候可没有分布式。
数据库被应用到越来越核心的场景，系统的安全性被提高，于是在集中式数据库基础上，推出了主备复制高可用；又通过读写分离临时解决并发高下单机性能不足的问题。而后又进一步出现了多实例外接共享存储架构（其实这已经算是早期的分布式架构了），集中式数据库此时已经发展到顶峰。
如果业务需求和数据库技术就这样互相迁就、相扶相持的走下去，今天就没有原生分布式的事情了。可惜二者关系终于还是出现了破裂，互联网崛起了、紧跟着移动互联网也普及了；以前人们要等机构白天开业以后，聚集到门店才会对数据库产生压力；现在不一样，人们在任何时间、任何地点都能连接机构的业务系统。
互联网时代数据处理压力无处不在，数据并发由几百、几千迅速增长到几十万、百万，数据容量由GB迅速增长到TB、PB，然后又是EB。20年的时间了，信息化时代让数据处理的业务需求不断登上新的阶梯，然而数据库此时略显老态龙钟，完全跟不上业务需求跳跃的速度。为了解决新的问题，分库分表架构短暂的出现过，又因为应用改造、扩展能力不足、运维困难等问题被抛弃。
直到现在完全不依赖传统数据库的原生分布式数据库崛起，支撑起了新业务需求。一开始，分布式的市场目标仅仅是高并发、海量数据，以及核心业务，集中式与分布式二者的市场目标彼此不同，并不产生冲突。但随着原生分布式技术的不断完善，集中式数据库能力的稳步提升，二者之间的市场目标重合范围越来越大，于是造成的冲突也愈演愈烈。前面所说的是否有必要用分布式数据库的争论，其实就是发生二者重合的业务场景中。
不管是集中式架构，还是分布式架构，其实不过时一个时代的过渡产物。在不产生额外突变（如数据量、数据模型、硬件设备等再次骤变）的情况下，二者为了在有限的空间内生存，不得不竞争原属于对方的业务场景，那么必然要解决自己产品在对方场景中的痛点问题。所以，能力的趋同性是无法避免的。这里的能力包括部署架构、成本、产品功能、性能等方方面面。最终经过市场选择的产品必然是一类同时支持集中式部署（成本、简单、性能），也能支持分布式部署（可扩展性、高可用性）的数据库。那时，纯粹的分布式和集中式数据库将彻底消除，至少在OLTP场景中必然会走向这样的结局。
在未来，不同的用户碰到一起，不会问“你们xx系统用的分布式还是集中式”因为这样的提问已经不再时尚，那时的对话应该是这样的：
A：你们xx系统的数据库用了多少节点？
B：嗨，我们那是小系统，就部了1个节点，你们呢？
A：我们用了5个节点，前两天碰到了C，他说他们用了500个节点。
2集中式与分布式“架构一体化”技术上可行性
这样架构一体化的数据库大概率不会是一个从0到1的全新产品，而是从现有产品中进行升级迭代的产物，毕竟这个市场已经足够卷了，短期不会有新的厂商加入。那么，只要集中式能实现分布式部署，或者分布式支持集中式部署，那么架构一体化就基本形成了（其实这样的产品已具雏形）。
集中式数据库是否能够彻底扩展为分布式？
以最强大的集中式数据库甲骨文为例，从其官网信息中看Oracle RAC共享存储已经能够支撑100节点了，这样的算力在TP类业务场景中已经能够支撑大部分业务需求。但是从真实的交付案例中看，一般不会超过4个节点，因为受限业务模型，RAC架构在3、4节点以上时，性能已经很难提升；而且当共享存储的数据量过大时，也一样存在性能瓶颈难以逾越的问题。另外，像Oracle RAC那样的技术还仅仅局限在非常少的集中式厂商中，没有得到广泛普及；而且，当初也是因为RAC解决不了这些问题，所以才有了现在的分布式架构。所以集中式实现成百上千节点的分布式部署困难程度是巨大的，核心架构需要调整的内容将太多，这不异于重写一个新产品。
那么，分布式数据库是否能实现单机部署？
从功能上，近年来分布式数据库基本已经达到集中式数据库水平，无论是SQL的覆盖程度、事务的ACID特性、周边生态等，在高端业务市场中虽然还没有达到Oracle的水平，但也能做到替换Oracle的能力。
那么，现在只剩技术架构上，看看分布式是否能实现单机部署。大多的分布式数据库中包含管理节点（元数据管理、全局事务管理）、计算节点、存储节点等多角色。这就让人产生了分布式数据库从架构上就必须由多个节点角色组成，难以收缩为单机运行的错觉（多角色都部署到一个节点上，总让人觉得不伦不类）。
但实际在技术上，这些管理角色单独部署，仅仅是为了便于理解、易于实现、资源隔离。去除多角色、对等部署，是分布式数据库实现单机部署的首要条件，其次是灵活的在线可控性，例如数据副本的数量能从1到多在线调整。国内实现对等部署的分布式数据库已经有多家，其中 OceanBase虽然还拥有rootserver集群管理服务、GTS全局时钟服务等单一组件，但这个组件已经集成在计算节点内部，算是基本实现了对等部署；而另一款分布式数据库QianBase做的更加彻底，通过HLC混合逻辑时钟、时间戳排序等，去掉了全局时钟服务，把集群管理能力分担到每一个计算节点内部，彻底的对等。
所以，对于此类分布式数据库，当部署在单机上，然后把数据副本数量设置为1，其分布式架构下的全部功能（除了高可用）依然能够保留，这也就基本上实现了单机部署。接下来要做的就是对事务处理的持续优化，使其达单机部署性能与集中式持平，那时“架构一体化”就彻底实现了。从目前的技术架构、云原生、跨地区部署、AI大模型等创新市场需求发展的趋势看，由原生分布式数据库衍生出未来“架构一体化”相对更容易一下。
3集中式与分布式的平衡破镜难原
集中式与分布式会不会成为“好朋友”一起互补走下去，答案是不可能的！如果二者没有场景冲突，是可以的，但现在不能了。二者重合的场景越来越大，增长的速度甚至超过了市场空间整体的增长速度。二者重合的场景是不会消失，而这类场景的用户既想要集中式的低成本、简单运维，又想要分布式的高可用和扩展性，那么最终在激烈竞争中，就会导致这样“既能又能”的一体化数据库产品出现。
而且，如果“架构一体化”不会出现，那么随着硬件的性能和稳定性提升，集中式能力将不断增强，也同样会吞噬分布式的场景，直到分布式丧失所有生存空间。所以目前从两个类型的立场出发，二者都在拼看谁先突破对方的架构优势。而集中式还有一个期望，那就是在分布式完成架构一体化以前，硬件产生了巨大的质跃，集中式场景得到巨大拓展，但这看起来概率有些太小了。
目前的分布式与集中式的争论不过是临时且短暂的。在这临时阶段里，A与B都满足需求，各有优劣，而更好的C还没有真的出现，所以用什么都没有错，就看使用的人更喜欢哪些产品特点了。而在集中式和分布式共同覆盖的场景上，无论下定论应该用哪一个都是相对片面的观点。
以一个数据库从业人员的角度看，未来在5年时间内，“架构一体化”的数据库就会真正出现，并快速攻占市场，预计10年后，那些纯粹的集中式和分布式数据库恐怕就没有新增市场空间了。