融合还是分布式，这是一个问题

随着应用系统日渐微服务化，数据库被越拆越小，功能也越来越细分。前段时间和某个客户交流，原本存放在1个Oracle数据库的数据，迁移到云上之后，被拆分成了大大小小的近200个RDS数据库。

但就是在这样的背景下，Oracle最新版本的21C数据库中，引入了融合数据库的概念，将区块链、机器学习、图数据库等多种热门技术融合到数据库中，提供全栈式的综合数据库能力。

下面我们分析一下两个技术流派的优劣。

专用数据库架构中，每个数据库仅仅为了满足某一个细分的需求，这个需求可能来自于业务逻辑上的需要，也可能是整体架构上的功能需要。这些组件所承担的职责比较单一，比如Redis，在整个架构中就是为了做缓存加速的作用，可以做成无状态的，持久化的问题则交由专用的关系型数据库来完成。同时又会有ETL等工具从关系型数据库将数据抽取到其他分析型数据库，用来满足经营分析、报表查询等业务需求。

所以你看，从架构功能、业务需求这两个维度就能拆分出很多的数据库，每类数据库还需要考虑高可用、数据副本、容灾等因素，一个中大型的业务系统，被拆分成200个数据库，也是能够理解的。

在这个架构中，每个数据库所承担的职责比较单一，不需要太多复杂和完整的商业数据库产品，只需要在各自的领域满足需求即可。但是由于数据库数量太多，也会带来两方面的问题。一方面是整个架构比较复杂，数据流在各个数据库之间的流转非常频繁，产生了很多的冗余数据。这两年又兴起了数据治理的概念，就是在这样的背景下产生的。另一反面，对运维人员来说，需要监控和维护的点大大增加，需要掌握的数据库种类也更多。在分析具体问题时，需要结合多方面的知识技能进行问题的定位。所以这种环境下，往往是架构师的角色更加重要，他们能够从全局的角度去分析和解决问题，而不是仅仅聚焦在数据库领域。

再来看融合数据库，很多功能（甚至的核心的业务功能）都由数据库来提供，简单的BS架构即可以满足需求。Oracle融合数据库，官方宣称支持多模型和多负载。多模型方面支持JSON、空间、图形、文本以及区块链等，多负载方面除支持OLTP和OLAP两种传统业务类型之外，还支持机器学习、物联网和流媒体等等。这些功能均通过特定的数据结构支持和相关的DBMS包来实现，对于开发人员来说，学习成本相对较低，实现起来比较方便。而且是开箱即用的，只要在安装数据库时选择需要的组件，即可具备相应的功能。

在这种架构中，数据库是当之无谓的核心，高可用、副本、容灾等均围绕数据库来展开。也正是在这个背景下，催生了一个专门的职位 – 数据库管理员。时至今日仍然是各企业IT部门的重要岗位，只是随着开源和分布式架构的崛起，重要程度在日渐降低。

综合上述的分析，我们再来看两种架构的特点。

专用数据库的优点是

每个数据库组件只需要完成特定的功能，承担的职责单一；

部分数据库可以在一定程度做到无状态，实现故障的无感知；

能够方便的实现扩缩容，在出现瓶颈的组件上投入更多的资源。

缺点是

整个架构过于庞杂，各种数据库之间的数据交互非常频繁；

数据冗余较多，带来了数据管理的复杂性，以至于后期需要进行数据治理；

开发和运维人员需要掌握的技术点增加，学习成本高。

融合数据库的特点是，

核心功能由数据库来提供，不需要过多额外的组件，架构非常清晰；

支持多种数据模型和负载类型，开发人员需要学习的产品种类大大降低；

对于运维人员来说，仍然是传统的高可用架构和运维方式，学习成本较低。

缺点是，

深度绑定某一种数据库产品，不利于未来的改造和迁移；

对于大型的业务系统，多种业务负载混杂，运行起来较为复杂，仍然存在垂直拆分的需求；

存在数据库的中心点，不符合当前国内整体去中心化的潮流。

分布式向左走，融合数据库往右，何去何从争议不少。其实，不论是开源分布式还是商业融合方案，都有各自的优缺点，并且两种方案也在很多方面相互的学习和借鉴。比如在Oracle 12C中就引入了分布式的Sharding架构，让Oracle的数据库也能实现水平扩展；而在一些做的较好的开源数据库产品中，也融合了HTAP的概念，宣称能够同时支持OLTP和OLAP应用。

在当下这个技术快速发展的时代，各自找准自己的定位，让产品在擅长的领域里发挥出更大的价值，才是每个从业者应该考虑的。