分布式数据库与集中式数据库的差异

传统集中式数据库面临的挑战

我们所说的传统数据库一般指集中式的关系型数据库，典型厂商就是 Oracle、IBM DB2 等厂商的产品以及开源的 MySQL 数据库等，它们经过近 40 年的发展，应用到了几乎所有的行业，已经被打磨的非常成熟稳定，生态也很完善，围绕他们周边有大量的服务合作伙伴及应用
开发合作伙伴。对于学习者来说，可以很方便的在厂商官网和各大技术论坛找到丰富的学习资源，线下的培训机构和培训课程也非常多，一旦碰到技术问题，也有很多现成的经验可以借鉴。

但随着云计算和大数据时代的到来，业务流量和数据量呈井喷式的发展，对数据库的要求越来越高，传统数据库面临很多的挑战：

第一，它们普遍采用了基于“单点高端硬件”的架构，对硬件要求很高，部署成本也很高，后期维护这些高端硬件也需要耗费大量的人力物力。除此之外，还有一个问题，随着业务量的增大，它只能纵向扩展，无法横向扩展。比如，开始业务量增加的不多，可以通过扩展数据库
服务器的 CPU/内存/硬盘来解决，但单机容量达到上限后，那么此时再想扩容，只能将 PC 服务器替换为高端的小型机等专有的硬件。这些设备的采购及服务成本每年基本都是上亿级别，不是一般用户能够承受的，更重要的问题是，这些高端硬件也是有性能上限的。

第二，传统数据库虽然能很好的应对高并发查询场景，但一旦需要访问的并发量太大，比如双十一期间的短期的大流量，突破了单点设备所能提供的存储容量上限或者计算能力上限，剧烈的资源争抢就会导致整体性能显著下降。因此，传统数据库比较适合处理数据量和访问量
都比较平稳、比较有限的场景，比较难应对数据量和访问量都快速增长的场景。

为了解决上述问题，同时也为了降低成本，传统数据库普遍引入“分库分表”中间件的方案（比如 MySQL 数据库常用的 MyCAT 中间件），利用中间件将多个单点数据库整合在一起来实现水平扩展，但从架构上讲，各个数据库之间是相互独立的，互相感知不到对方，当要做跨
库事务的时候，必须依赖中间件。这种方法虽然暂时解决了扩展性问题，且技术难度和技术成本相对较低，不需要或者很少需要修改数据库引擎，但又引入了其它问题：

1：应用侵入性问题
为了满足中间件的使用要求，应用必须做相应的改造以实现正确的数据访问路由，这对应用具有很大的侵入性，相当于把数据库没解决的问题甩给了应用，应用开发需要做改造来适配。而每一次扩容/缩容，由于底层数据库引擎无法在线调整数据分布规则，意味着往往需要暂停业务、重新导入数据、做一次对应的路由变更，这会明显加大应用开发和运维的复杂度。

2：诸多功能限制：
如果应用比较简单，单表的规模也不大，所有的操作均在一个单点数据库完成，是没有太多功能的限制，应用开发者依然可以像使用单机数据库一样使用这种分库分表的中间件数据库。但一旦一些操作需要跨越不同的数据库，涉及的数据分布在多个不同的单
点数据库，比如多表关联的复杂 sql，由于中间件不具备分布式并行计算能力，导致它不能跨越多台机器协同执行任务。所以，很多数据库中间件会告诉应用开发者一些不支持的 SQL，需要应用通过其他方式解决，影响了应用的迁移和开发。

3：不能保证数据一致性：
当一个事务中处理的数据跨越多个不同的单点数据库时，由于数据库引擎没有分布式能力，只能通过中间件来完成分布式处理，中间件无法 100%保证多台机器之间的数据一致性，尤其是中间件在执行分布式事务过程中遇到异常的时候，无法 100%保
证分布式事务的 ACID。

造成这些问题的根本原因是这种架构的“先天不足”，“分布式”、“扩展性”等关键能力并没有内嵌在数据库引擎里实现，而是在数据库之外的中间件层面间接实现，因此当某些操作要求底层数据库具备这些能力时，中间件就显得无能为力了。

分布式数据库基本特点及对比分析

既然传统数据库有这样那样的问题，接下来我们看下，分布式数据库的基本特点，以及分布式数据库是如何解决了上述问题的。
原生的分布式是把中间件做的很多事情下移到数据库引擎中，一般采用多副本一致性的架构。对应用来说，分布式数据库是给传统关系型数据库插上了一个分布式的翅膀，应用可以像用传统集中式数据库一样使用分布式数据库，业务不用关心其底层的分布式架构，迁移改造成
本较低。
首先，我们看下它是如何解决了传统数据库的高成本和扩展性问题。分布式数据库可以使用普通的标准 PC 服务器，可以很方便的在市场上买到，服务器自身无需外挂高端存储，也可以不使用 Raid 等可靠性技术。所以原生的分布式数据库在硬件上可以摆脱对小型机、高端存
储等高价格产品的依赖，成本较低，同时也避免了用户被个别硬件厂商绑架的问题。随着业务的发展,当需要扩容时,只需将新服务器加入到数据库集群中即可,集群会自动的将业务数据迁移到新机器，等新机器追平数据后，系统自动的将流量切到新服务器，这个过程对业务是完全透明的。当需要缩容时，只需将服务器移除集群，系统会自动做反向操作，这个过程对应用也是完全透明的。如果是为了促销期间，应对短期的大流量，也可以使用阿里云公有云资源。

那么它是否会像中间件架构一样带来很多问题么？不会的。原生的分布式数据库是在数据库引擎层面解决了分布式的问题，对应用而言是透明的，应用可以像使用传统数据库一样使用分布式数据库，不用担心是否存在跨库操作，是否有全局一致性的问题等等，这些都由数据库
内部解决了。
这种架构典型的代表，国外就是谷歌的 Google Spanner 数据库，国内就是 OceanBase数据库。它们一般都采用了 Paxos 协议保证了数据高可靠和服务高可用，每一份数据都有多个副本，分别存储在集群内的不同服务器中，单个服务器的故障不影响整个业务的，以OceanBase 为例，OceanBase 可用性可以达到 RPO=0，RTO<30 秒，意思是少数节点的故障后，系统可以在 30 秒内自动恢复，且恢复后，不丢失任何数据。

OceanBase和传统数据库的对比

最后我们再来对比下 OceanBase 与集中式数据库的区别，做个小结。

• 在产品架构方面：
  集中式数据库是单点集中式，构建在高端硬件基础上，比如 IBM 高端服务器和 EMC 高端存储，OceanBase 是原生的分布式架构，并采用业界最严格的 Paxos 协议，基于普通 PC 硬件设计。
• 数据可靠性和服务高可用性方面：
  集中式数据库的高可用需要依赖高端硬件，普遍采用主从复制模式，主节点故障的情况下，会有数据损失的可能性（RPO>0）；且不能自动恢复服务，需要人工去判定主节点已宕机，并手工启动备节点，恢复时间通常以小时为单位计算。
  OceanBase 使用普通 PC 服务器，主副本故障的情况下，剩余的从副本可以自动选出新的主副本（通常在 30 秒以内），而且剩余的两份副本依然可以进行强同步，保证 RPO=0。
• 扩展性方面：
  对数据库来说，扩展性主要体现在 2 个方面，数据存储和计算能力。集中式数据库数据存储只能在单点内实现纵向扩展，在这个大数据的时代，最终必然会触达单点架构下的容量上限。计算节点通常无法扩展，少数模式下可做计算节点扩展，比如 Oracle 的 RAC，但扩展数量也有限，且多个计算节点之间仍需访问单点共享存储，依然解决不了存储这个瓶颈。
  OceanBase 在 MPP 架构下，每台普通的 PC 服务器都有自己的计算能力和存储能力，扩展时只需要扩展普通的 PC 服务器，可实现数据节点和计算节点的水平扩展，在网络带宽足够的前提下，可以扩充至任意数量。
• 应用场景：
  传统数据库主要面向企业客户核心系统（金融、电信、政企等），互联网应用案例少。OceanBase 已经应用阿里和蚂蚁内部众多系统，逐渐由内向外，迈向更多行业。使用成本：传统数据库依赖高端硬件，需要支付高端基础硬件的设备费用、高昂的软件授权费用以及产品服务费用。OceanBase 依赖普通 PC 服务器，成本较低。
• 国产化程度：
  主流的传统数据库均来自国外，全部研发人员在国外，中国的定位是市场和本地服务，存在安全风险。
  OceanBase 是 100%自研产品，研发人员均在中国，可以提供更加便捷全面的服务。

小结

传统集中式数据库经过近40年的发展，已经非常成熟。但在当前这个大数据的时代，传统数据库依然面临较多挑战，分布式数据库可以有效解决这些问题，是未来数据库发展的重点方向
1、传统数据库往往对硬件基础设施有较高要求，同时只能纵向扩展，无法横向扩展，容易达到性能上限;
2、分库分表虽然可以横向扩展了，但也有带来了不支持复杂SQL、较难保证分布式事务的ACID等新问题;
3、分布式数据库可以有效解决这些问题，应用可以像使用集中式数据库一样使用分布式数据库，分布式数据库具有低硬件成本、高可扩展性、高可用性等特性。

模拟题

1.【判断题】分库分表的架构虽然解决了集中式数据库的扩展性问题，但也带来了新的问题（不支持复杂SQL，较难保证分布式事务的ACID等)。(T)

2.【多选题】传统的集中式关系型数据库面临哪些挑战?(AC)
A:成本高:运行在高端服务器、小型机、高端存储等专有硬件上;
B:生态欠缺:文档、培训、应用等都不足;
C:扩展性差:无法摆脱单机的架构，只能纵向扩展，无法横向扩展;
D:性能差:任何时候，传统集中式数据库的性能都比分布式数据库较差;

本文内容来自于：OceanBase的OBCA内容。