Oracle ACE夜话--和首席-总监一起跟大家谈一谈分布式数据库发展

前言

在昨日的Oracle ACE夜话中，和薛首席、尹总监一起聊了下当前分布式数据库的内容，现将分享内容又进行了相应整理，分享给大家，也希望大家多多指正。

一、自我介绍

尚雷，公众号【尚雷的驿站】，PG ACE，Oracle ACE Associate，PG 分会 & IvorySQL 南京地区组织者，墨天轮2023年年度十大优秀作者。拥有Oracle 11g OCM、AWS及部分国产数据库等认证。

我也是TechTalk技术交流社区的创办者，TechTalk技术交流社区日常也会举办一些线上和线下技术交流活动。

平时喜欢技术分享、也喜欢健身，多次代表公司龙舟队参加南京市外企协会举办的龙舟赛，平时喜欢去健身房健身和骑行，希望能和大家多交流。

以下是我微信号和公众号，欢迎大家关注。

二、分布式数据库

2.1 分布式数据库概念

数据处理方式：集中式 VS 分布式

**集中式数据库：**是指数据库中的数据集中存在一台计算机上，数据的处理也集中在一台机器上完成。

**分布式数据库：**是指利用高速计算机网络将物理上分散的多个数据存储单元连接起来组成一个逻辑上统一的数据库。

数据库扩容：

传统集中式数据库：纵向扩容，添加CPU、内存、磁盘，随着硬件性能提升，硬件价格将远高于性能提升，当数据增长到一定程度，单纯依靠硬件无法满足需求。
分布式数据库：动态横向扩容，增加硬件数量，可使用相对便宜硬件进一步提升数据库的容量和能力。

想象一家大型公司，提供多种服务，有产品销售、技术支持、客户投诉等。公司雇佣客服来处理这些业务。

1） 集中式数据库
   集中式数据库就像公司只雇佣了一个万能客服，他什么业务都懂。所有客户问题都找他解决，虽然他能力很强，但随着业务量增加，他的工作会变得很繁重。如果他请假或生病，公司所有的业务都会受到影响。

2） 分布式数据库
   分布式数据库就像公司雇佣了一群专门客服，每个客服只负责一个领域。比如，有的只管产品销售，有的只管技术支持，有的只管客户投诉。这样，每个客服都能专心处理自己的部分，效率更高。如果某个客服请假，其他业务不会受影响。

3） 如果需要招聘新客服：

集中式数据库（万能客服）需要一个对所有业务都精通的人，找这样的人不容易，培训也很麻烦。

分布式数据库（专门客服）只需要找熟悉某个业务的人，招聘和培训都更简单。如果某个客服离职，只需替换那个领域的客服，不影响其他工作。

这个对比说明，集中式数据库虽然统一管理，但容易成为瓶颈和单点故障；而分布式数据库通过分工合作，提高了系统的扩展性和可靠性。

2.2 分布式数据库发展史

分布式数据库的发展历程可以分为几个重要阶段：起源与早期发展、初期研究、商用化、大数据和NoSQL兴起、云数据库的普及以及混合云和多模数据库的发展。

分布式数据库从诞生到今天大致经历了如下发展历程：

1） 1960s-1970s: 起源与早期发展

1960s：集中式数据库，如IBM的IMS。
1970s：E.F. Codd提出关系数据库模型，IBM的System R和UC Berkeley的Ingres问世。

2）1980s: 初期研究

1980s：研究分布式数据库的基本问题，如数据分布和一致性。典型系统：R*（IBM）、SDD-1。

3）1990s: 商用化与联邦数据库

1990s：商业分布式数据库系统推出，Oracle、Sybase、Informix支持分布式处理。联邦数据库系统如IBM DB2开始流行。

4） 2000s: 大数据和NoSQL兴起

2000s：互联网发展推动大数据需求，Google推出GFS、MapReduce、Bigtable。
中后期：NoSQL数据库如Cassandra、HBase、MongoDB应运而生。

5) 2010s: 云数据库和新型分布式系统

2010s：云计算推动云数据库，如Amazon DynamoDB、Google Cloud Bigtable。
中后期：新型系统如Google Spanner、CockroachDB、TiDB出现，注重高可用性和强一致性。

6) 2020s: 混合云和多模数据库

2020s：混合云和多云环境普及，多模数据库（Azure Cosmos DB、Amazon Aurora）和Serverless数据库（Amazon Aurora Serverless、Google Firebase）流行。

2.2.1 单机数据库

缺点：

可扩展性差，单机架构只能通过纵向扩展，通过增加硬件配置提升性能，硬件可配置资源存在上限
纵向扩容往往需要停机扩容，业务无法访问
硬件故障会整个服务不可用，甚至存在数据丢失风险

2.2.2 主备/从架构

缺点：

数据延迟，数据从主库同步到从库有时会有延迟，需应用能容忍短暂的不一致性，对部分一致性要求高的场景不适合
主库面临写操作的性能压力
当主库出现故障需进行主备/从切换时，人工干预需要响应时间，自动切换复杂度比较高

2.2.3 集群架构

弊端：

成本高：RAC 需要多个节点和共享存储设备，会增加软硬件成本
网络要求高：RAC节点之间需高速网络连接，以便数据读写和节点间通信，若出现网络问题，会影响RAC性能和可用性
资源争用：当多个节点同时访问共享存储时，可能会出现资源争用情况，会影响系统性能和稳定性
扩展瓶颈：RAC节点过多会导致RAC争用，过多的RAC争用最终导致性能急剧下降，影响外围应用系统的体验。

2.2.4 谷歌三驾马车

谷歌在2003到2006年，分别发表了 Google File System、MapReduce和BigTable这三篇论文，这三篇论文的重要目的就是解决分布式并行计算方面的问题，这也为之后大数据技术的发展提供了可能。

google经典的三驾马车可以说是工业界、开源界分布式系统的启蒙者，之后的 Hadoop 系列开源软件 HDFS、MapReduce、Hbase 都是参考这三篇论文设计的。之后计算机进入大数据时代，更为后面分布式数据库的发展做了前期铺垫。

谷歌三驾马车三项技术的提出，对后来的MPP（大规模并行处理）分布式架构产生了深远的影响，推动了大数据处理和分布式计算的发展。

MPP架构是一种通过多个处理节点并行处理任务来提高计算能力的架构：

MPP架构核心概念

并行处理：MPP架构通过将计算任务分解成多个子任务，并在多个处理节点上同时执行这些子任务。每个节点独立处理其任务，从而实现任务的并行处理，显著提高整体计算效率。
分布式存储：数据被分布在多个节点上，每个节点存储部分数据。这种分布式存储方式确保了数据的高可用性和可扩展性，能够处理更大的数据集。
无共享架构（Shared-nothing）：每个节点都有自己的处理器、内存和存储资源，节点之间不共享资源。这种无共享架构消除了资源争用，提高了系统的扩展性和容错能力。
节点间通信：处理节点之间通过高速网络进行通信，协调任务的执行和数据的传输。通信方式包括消息传递和数据交换等，确保节点间的协作顺畅。

谷歌三驾马车（GFS、MapReduce和Bigtable）通过提供高效的存储、计算和数据管理解决方案，极大地推动了分布式系统和分布式数据库的发展。这些技术不仅在谷歌内部取得了成功，还启发了众多开源项目和商用产品，形成了现代大数据处理和分布式数据库的基础框架。它们的影响主要体现在以下几个方面：

高效的大规模数据存储：通过分布式文件系统（如GFS、HDFS）实现。
强大的分布式计算能力：通过MapReduce模型实现。
灵活且可扩展的数据存储和管理：通过Bigtable的数据模型实现。
这些技术和理念在实践中被广泛应用，形成了今天丰富多样的分布式系统和数据库解决方案。

2.2.5 分布式数据库架构

得益于数据库技术的发展，特别是分布式和NoSQL的深入发展。另外也受到互联网技术的发展影响，传统的关系型数据库已经难以满足互联网业务的发展需求，特别是我国受到去IOE的影响，相对于传统集中式数据库，分布式数据库已经成为当下数据库发展主流和趋势。

分布式数据库本身分为：计算层、元数据层和存储层。

计算层就是之前单机数据库中的SQL层，用来对数据访问进行权限检查、路由访问、以及对计算结果等操作。

元数据层记录了分布式数据库集群下有多少个存储节点、对应IP、端口等元数据信息

当分布式数据库的计算层启动时，会先访问元数据层，获得所有集群信息才能正确进行SQL解析、路由等工作，另外因为元数据信息存储在元数据层，则分布式数据库的计算层可以有多个，用于实现性能扩展。

存储层用来存放数据，但存储层要和计算层在同一台服务器上，甚至不求在同一个进程中。

分布式数据库的优势是将数据打散到不同的服务器上，这种横向扩展的scale out能力，能解决单机数据库的性能与存储瓶颈。

2.2.6 HTAP技术

混合事务与分析处理(Hybrid Transactional Analytical Processing, HTAP)技术是一种基于一站式架构，可同时处理OLTP事务请求与OLAP查询分析请求的技术。HTAP 技术不仅消除了从关系型事务数据库到数据仓库的数据抽取、转换、和加载过程,还支持实时地分析最新事务数据.

HTAP面临的挑战：

分布式事务处理
事务的优先级
兼容行列存储

注：对于传统集中式数据库，当数据库达到一定体量，通常会对数据库或者表进行拆分，进行分库分表，比如MySQL数据库，通常会进行分库分表，但这种情况下，在线扩容缩容都会面临种种限制，由于数据分布在多个数据库中，在数据库内部进行联机分析处理就比较困难。
   但在分布式数据库架构下，可动态进行在线扩缩容，而且内部进行联机分析处理也依然可行，此时数据库就扮演着即做OLTP又做OLAP，即HTAP。
   
   相较于独立的OLTP和OLAP，HTAP的实现也比较困难，因为OLTP数据体量和事务通常比较小，而并发量比较大，OLAP数据体量和事务通常比较大，但并发量通常比较小，另外OLTP相对于OLAP事务一致性要求比较高，事务响应时间比较高。
   从数据存储方面看，OLTP数据库通常是行存，并且支持实时更新，OLAP通常是列存批量更新，两者之间差异巨大。
   
HTAP面临的挑战：
1) 分布式事务处理：因为分析出所需的庞大数据量和计算量，使得整个系统必须是分布式，
2）事务的优先级：分析的大查询需要消耗大量的CPU、内存和IO资源，这可能导致交易的小查询无法得到所需的资源而等待并超时，
3）行存和列存的混合存储：由于行存对交易事务处理比较友好，而列存对分析处理比较友好，HTAP系统既要行存又要列存，做到行列的混合存储。

2.3 分布式数据库主要特点

相较于传统单机数据库分布式数据库主要有如下四大优势：

高性能： 能够承受万级和百万级并发访问。传统数据库通常局限在数百或数千级并发访问，互联网时代通常要承受百万级的并发访问。
高可用： 多副本容错容灾机制，当前很多采用分布式数据库的系统通常采用两点中心、三地无中心这种多地多中心、异地多活、跨区域的分布式架构，通常采用多副本部署，避免了传统集中式数据库单点故障问题。
**高扩展：**随着互联网行业的发展，当前很多系统数据都是以PB甚至ZB级别数量增长，而传统数据库则侧重于GB-TB级别数据库容量。分布式数据库可动态增添存储节点。
**高弹性：**相较于传统集中式数据库更多只能提供纵向扩展，通过增加硬件设施来满足需求，横向扩展能力较差，比如业界传说的Oracle RAC达到8节点的瓶颈。而分布式数据库水平扩展能力较强，可单独针对计算资源与存储资源资源水平伸缩，提供敏捷弹性能力，成本更低。

2.4 主要分布式架构

2.4.1 Share-Everything

主节点提供读写服务
备节点只提供读取功能，不提供写入服务

分析：

Share-Everything架构中，所有节点共享存储和内存资源，这意味着任何节点都可以访问所有数据。
这种架构的缺点是扩展性差，因为所有节点之间需要频繁的通信和同步，随着节点数量的增加，系统性能会下降。

2.4.2 Share-Disk

计算层为非对称计算节点
底层为分布式共享存储

分析：

Share-Disk架构将计算和存储分离，计算节点可以并行处理任务，底层存储系统负责数据一致性和高可用性。
这种架构的扩展性比Share-Everything好，但仍然可能在存储系统上遇到瓶颈，因为所有计算节点共享同一存储系统。当前一些云原生的系统采用该架构。

2.4.3 Share-Nothing

原生分布式数据库架构
分布式事务协议与共识协议
数据分片存储在独立的节点上，每个节点拥有自己的存储和计算资源，通过网络进行通信。
全局事务管理器负责协调分布式事务和共识协议，确保数据一致性。

分析：

Share-Nothing架构的每个节点都是独立的，没有共享的资源，这使得它具有良好的扩展性。
这种架构可以高效地进行横向扩展，因为增加新的节点只需将数据分片分配到新节点上。
典型的Share-Nothing架构数据库包括Elasticsearch、HBase、MongoDB、TIDB、OceanBase等，它们能够处理大规模的分布式数据和高并发请求。

当前Share-Disk和Share-Nothing也越来越融合，边界也越来越模糊。

2.5 分布式事务处理

分布式事务处理相对于单机式事务处理，也更加复杂。

分布式事务提交协议

– 两阶段提交协议（2pc）

– 三阶段提交协议 (3pc)

– Calvin (确定性事务提交协议)
分布式共识协议 (保证副本之间的事务一致性)

– Paxos

– Raft
分布式时钟

– 逻辑时钟

– TrueTime （基于物理的时钟）

– 混合逻辑时钟

2.6 主流分布式数据库

2.6.1 HTAP类型分布式数据库

当前很多国产数据库采用MPP架构，这类国产数据库通常是拥有OLTP+OLAP功能的HTAP数据库，以下是这些国产HTAP数据库代表。

2.6.1.1 TiDB 数据库

TiDB 是由PingCAP 公司研发设计的开源分布式 HTAP 数据库，它结合了传统的关系型和非关系型数据库的最佳特性。

TiDB是一个典型的存算分离架构，计算层由多个无状态的TiDB Server构成，存储层由多个TiKV节点以及可能包含的TiFlash组成。存算分离架构相比于存算一体的架构，其最大的优势在于计算资源和存储资源是可以独立进行扩缩容的。

作为一款优秀的国产分布式数据库，TiDB 是基于 Google Spanner 设计的分布式数据库，主要特点包括：

兼容 MySQL：支持 MySQL 语法和客户端，可直接替换现有 MySQL 数据库。
Raft 协议：保证数据一致性和可用性。
分布式存储和查询：数据分区存储于多节点，通过分布式查询优化器并行处理查询，提高性能和吞吐量。

另外TiDB的TiFlash存储引擎也借鉴了clickhouse的特性，比如，TiFlash 借鉴了 ClickHouse 的列存储技术，使用类似的列存储格式和压缩技术，以优化大规模数据的存储和读取性能。

2.6.1.2 OceanBase数据库

OceanBase 数据库采用无共享（Shared-Nothing）分布式集群架构，一个集群由若干个节点组成。这些节点分属于若干个可用区（Zone），每个节点属于一个可用区，各个节点之间完全对等，每个节点都有自己的 SQL 引擎、存储引擎、事务引擎，运行在普通 PC 服务器组成的集群之上，具备高可扩展性、高可用性、高性能、低成本、与主流数据库高兼容等核心特性。

和TiDB数据库不同，OceanBase数据库采用基于无共享集群的分布式架构，通过Paxos 共识协议实现数据多副本的一致性。

2.6.1.3 PolarDB 数据库

PolarDB是阿里巴巴自研的新一代云原生数据库，在存储计算分离架构下，利用了软硬件结合的优势，为用户提供具备极致弹性、高性能、海量存储、安全可靠的数据库服务。PolarDB 100%兼容PostgreSQL 11，PostgreSQL 14，高度兼容Oracle。

PolarDB采用存储和计算分离的架构，所有计算节点共享一份数据，提供分钟级的配置升降级、秒级的故障恢复、全局数据一致性和免费的数据备份容灾服务。

除了以上数据库，还有人大金仓、南大通用、达梦、openGauss、GaussDB等等一些列分布式数据库。

2.6.2 多主集群数据库

除了上述HTAP类型的数据库，还有一类数据库采用多主架构，比如典型的clickhouse数据库和MySQL Cluster集群数据库。

2.6.2.1 clickhouse数据库

ClickHouse 多主集群架构特点：

自治性：在ClickHouse集群中，每个节点都可以独立处理查询和接收数据，不需要通过一个中央主节点来协调。
副本一致性：尽管每个节点可以接受写入，ClickHouse 使用ZooKeeper来保证跨副本的数据一致性。ZooKeeper跟踪哪些副本是最新的，并在副本之间进行数据同步，确保所有数据副本最终一致。
可扩展性：由于没有中心化的写入瓶颈，系统可以通过简单地增加节点来扩展，每个新节点都可以立即开始处理查询和接收数据。

clickhouse经常会和elasticsearch 进行对比，elasticsearch集群采用的不是多主架构，其集群中的节点拥有不同角色和职责(如主节点、数据节点、协调节点等)。

2.6.2.2 MySQL Cluster数据库

MySQL Cluster 是一个多主集群数据库，和clickhouse数据库不同是其是一个OLTP数据库，具备以下架构特点：

多主架构：所有节点均可处理读写操作，消除主从延迟，提升性能。
自动分片：数据自动在多节点间分片，支持线性扩展。
同步复制：数据变更实时同步至所有副本，确保一致性。
无共享架构：节点间不共享硬件资源，增强故障恢复能力。

三、Oracle 及其分布式数据库

在传统印象中，Oracle是集中式数据库典型代表，RAC技术更是独霸天下，至今也无数据库超越。

在很长一段时间，Oracle未在分布式数据库投入过多精力。

随着互联网行业飞速发展，分布式数据库技术发展迅猛，传统集中式数据库存在性能瓶颈。Oracle可能也意识到这点，于是在Oracle 12c版本中推出了shareding database，但12c推出的这项是为OLTP服务的，并不适用于OLAP场景，并且sharding节点高可用还要依赖于ADG。

直到Oracle 23c,Oracle推出了 Globally Distributed Database(全球分布式数据库)

Oracle ASM 利用了某些分布式存储技术的理念，如数据分布、负载均衡和高可用性

3.1 全球分布式数据库介绍

根据官网解释：Oracle Globally Distributed Database 可将一个数据集的数据段分布在多个基于不同计算机（本地部署或云端部署）的数据库（即分片）中，能够帮助用户构建可线性扩展的全球分布式多模型数据库。它不需要专门购置软硬件，不仅可以提供高度一致性，支持所有 SQL 特性、结构化数据和非结构化数据以及 Oracle Database 生态系统，还能在遵守数据主权要求的同时满足应用的低延迟和高可用性需求。

Oracle 全球分布式数据库可伸缩性强，能进一步增强数据和事务处理能力；
所有分片以单一逻辑数据库的形式为应用提供支持，可加快超大数据集的查询响应时间，加快分析处理速度；
其支持RAFT协议，支持您在节点或数据中心中断期间，只需几秒即可实现快速故障转移，确保零数据丢失，有助于形成主动—主动—主动对称分布式数据库架构，从而提高可用性、简化管理并优化全球资源利用率。
其支持多云架构部署，使用无共享架构满足数据驻留和数据邻近要求，同时保护数据库不受意外停机影响。
提供数据资源池功能，可以存储关系数据和其它类型的非结构化或半结构化数据，例如文本、JSON、图形和空间数据。