4 独立和分布式集成SQL引擎

OceanBase执行引擎必须根据适应性、针对的情况去优化预期来处理多种情况。在更高层次上，每个SQL执行有两种模式：串行执行或并行执行。

图7说明了独立和分布式自适应执行引擎，串行执行包括本地执行、远程执行和分布式执行。对于并行执行，有并行查询和DML操作来提高性能。详细描述如下。

4.1 串行执行、单机内并行和分布式并行

在串行执行期间，如果访问的数据在本地机器上，则远程处理与本地或独立SQL的处理之间没有区别。对于另一个节点上的数据操作，有两种访问方式：远程数据获取或远程执行。 在前者中，数据被拉到本地机器，而在后者中，事务处理和存储访问被转发到另一个节点，整个事务被返回。如果单个SQL访问多个节点的数据，则可以将计算推送到每个节点，以实现串行执行的效果，同时在单机情况下最小化开销，这也允许分布式执行能力，支持并行查询，可以是本地或分布式的，并支持并行DML写操作。

      串行执行计划是小型企业处理数据而无需进行上下文切换或远程数据访问的有效方法。然而，如果需要访问大量数据，将并行功能引入独立的OceanBase可以提高SQL处理能力和响应速度。虽然一些开源独立数据库可能不支持此功能，但可以使用多核服务器来增加并行性。分布式执行计划可以用来进一步增加数据处理的规模，从而允许在多台机器上并行，并有可能超过单机CPU的限制，达到数千个内核。

串行执行有两种执行模式：直接访问存储（DAS）执行和分布式执行。

       DAS访问执行的一种方法是拉取数据。如果数据位于远程，并且是简单的OLTP查询或索引访问回表查询，这样操作消耗最少的资源。我们将把数据和它的执行一起拉到本地。计划和本地执行计划之间没有形式上的区别，并且此操作将在执行器中自动执行。然而，推算比拉取数据更可取，因此我们也支持分布式执行。这种分布式执行不会增加额外的资源消耗。我们将确保它的并行性和之前的DAS执行是相同的。

      对于某些特定的查询或大规模扫描，我们将动态地、自适应地选择其一，这里根据性能成本。OceanBase利用执行引擎来促进混合事务分析处理（HTAP）工作负载。对于传统的在线事务处理（OLTP），OceanBase采用基于拉取的数据访问方法和自下而上的计算执行方法，用于传统的在线分析处理（OLAP）。

      并行执行框架可以自适应地处理单机内的并行性和分布式并行性，因为它们具有相同的框架。所有并行处理工作者可以在机器上形成多个线程或在多个节点上形成线程。我们在分布式执行框架中有一层自适应数据传输层。对于单机内的并行性，传输层会自动将线程之间的数据交互转换为内存拷贝。因此，两种不同的场景被数据传输层完全抽象化，并行执行引擎在单机并行性和分布式并行性的调度层实现上没有区别。

5 独立和分布式集成事务处理引擎

     由于在事务处理中实现可扩展性更困难，我们考虑了在事务处理期间同时考虑独立和分布式的原因。此外，我们提出并实现了一种名为LCL（锁链长度)的完全分布式死锁检测和解决算法，该算法具有动态可扩展性，并应用于OceanBase Paetica。

5.1 传统2PC vs. OceanBase 2PC

图8是传统分布式事务处理过程，分为事务的打开阶段和事务的提交阶段，图9对应OceanBase的事务处理过程。以前的工作试图减少2PC和同步复制的开销。OceanBase事务提交协议提出了一种新的方法，称为参与者和协调者的两阶段提交协议。

与图8中的传统2PC相比，图9中的OceanBase 2PC从事务提交到成功提交，消息处理和日志量明显少于传统2PC，这使其在延迟方面具有很大优势。这种优势还将支持OceanBase在分布式场景中的事务处理能力，这与其他几种分布式数据库的高开销不同。

有两种访问GTS的场景：

1）获取语句快照；

2）获取事务提交版本号。

对于独立事务，

1）无需访问GTS，这已经在OceanBase 4.0中进行了优化。

2）事务提交版本号将获取GTS以满足外部一致性，但这种获取只是接口调用，不会实际发送RPC，因此效率相对较高。

看了几遍后的总结（回来还的找OB专家把这块在弄明白）

传统 2PC 与 OceanBase 2PC 的比较

传统两阶段提交 (2PC) 协议和 OceanBase 的 2PC 协议都用于分布式事务处理，但 OceanBase 对传统 2PC 进行了优化，以减少消息处理和日志量，从而降低延迟。

传统 2PC

图 8 展示了传统的分布式事务处理流程：

它分为事务的开启阶段和提交阶段。

在开启阶段，协调器向所有参与者发送“开始事务”请求，并获取全局事务 ID。

在提交阶段，协调器首先向所有参与者发送“准备”请求。

参与者收到请求后，执行事务操作，并将结果写入本地日志，然后向协调器回复“准备响应”。

如果所有参与者都回复“准备成功”，协调器向所有参与者发送“提交”请求。

参与者收到请求后，提交事务，并向协调器回复“提交响应”。

协调器收到所有参与者的“提交成功”响应后，完成事务提交。

传统 2PC 的问题在于，从事务提交到成功提交的过程中，需要进行多次消息传递和日志写入，这会导致较高的延迟。

OceanBase 2PC

图 9 展示了 OceanBase 的事务处理流程：

OceanBase 的 2PC 协议对传统 2PC 进行了优化，以减少消息处理和日志量，从而降低延迟。

OceanBase 的 2PC 协议引入了全局版本号管理器 (GTS)，用于分配全局唯一的版本号。

在事务开启阶段，协调器不再需要获取全局事务 ID，而是直接向参与者发送“开始事务”请求。

在提交阶段，协调器向 GTS 获取一个全局版本号，并将该版本号和“准备”请求一起发送给所有参与者。

参与者收到请求后，执行事务操作，并将结果和全局版本号一起写入本地日志，然后向协调器回复“准备响应”。

如果所有参与者都回复“准备成功”，协调器向所有参与者发送“提交”请求。

参与者收到请求后，将事务提交到全局版本号对应的状态，并向协调器回复“提交响应”。

协调器收到所有参与者的“提交成功”响应后，完成事务提交。

OceanBase 2PC 的优化主要体现在以下两个方面：

减少了消息传递次数： 在事务开启阶段，OceanBase 2PC 不再需要获取全局事务 ID，因此减少了一次消息传递。

减少了日志写入量： 在提交阶段，OceanBase 2PC 将全局版本号和“准备”请求一起发送给参与者，参与者只需要将全局版本号写入本地日志，因此减少了日志写入量。

总结

OceanBase 的 2PC 协议通过减少消息传递次数和日志写入量，有效降低了分布式事务处理的延迟，使其在分布式场景下更具优势。

5.2 日志流和版本号管理器

如果单个事务只涉及单个日志流，一般来说，如果业务数据的量在负载均衡的可容忍粒度内，日志流不需要特别大。在独立部署模式下，通常只有一个日志流，日志流中的任何事务都不需要经过两阶段提交。

OceanBase使用事务版本号来标识已提交事务的顺序，并确定快照隔离级别下多版本数据的可见性。OceanBase的事务版本号同时考虑了独立和分布式性能。在分布式场景中，它通过全局时间戳服务获取事务版本号。在独立部署场景中，全局时间戳服务和事务上下文必须在一个节点上。可以配置为使用本地时间戳服务获取事务版本号，并通过函数调用获取版本号，从而避免RPC引起的上下文切换开销。

分布式数据库系统中的事务不是相互独立的，它们可能涉及单个或多个日志流的同步。在OceanBase中，我们开发了一种针对单日志流事务的优化，使事务能够获取本地版本号，而不会影响全局一致性。如果所有事务和工作负载都不涉及分布式事务，则整个事务处理过程类似于独立数据库中的相同过程。

6 性能评估

在评估中，我们使用不同的数据库系统和配置进行实验。

6.1 实验配置

我们在性能评估中使用了以下数据库：OceanBase 3.1、OceanBase 4.0、MySQL 8.0、Greenplum 6.22.1 和 RDS MySQL 8.0。首先，§6.2、§6.3 和 §6.4 中的单节点实验是在双路 Intel Xeon Platinum 8163 CPU @ 2.50 GHz 服务器上执行的。其次，§6.5 和 §6.6 中的单节点实验是在 32 核 Intel(R) Xeon(R) Platinum 8396B CPU、128GB DRAM 和三个 500GB ESSD PL1 上执行的。第三，§6.7 中的单节点实验分别在阿里云的 ecs.r6.xlarge、ecs.r6.2xlarge、ecs.r6.4xlarge 和 ecs.r6.8xlarge 实例上执行。

6.2 独立性能可扩展性

以下实验，如图10所示，在双路 Intel Xeon Platinum 8163 CPU @ 2.50 GHz 服务器上运行。 Sysbench数据集为1,000,000，压力测试为1,500并发，30个表。OceanBase通过硬件性能的提升，从4核扩展到64核，可以在64核的范围内实现基本的线性扩展，从9×104、1.8×105、3.7×105、6.9×105、1.2×106。

在点选和只读场景中，当服务器CPU核心数等于或小于32 vCPU时，CPU核心数增加一倍，性能相应增加一倍。然而，当服务器的CPU核心数超过32 vCPU时，由于缺乏物理核心，性能不再线性增长。此外，从32 vCPU升级到64 vCPU，这两个场景的性能提升了50%。在插入、更新和仅写的三种纯写场景中，当服务器的CPU核心数低于32 vCPU时，CPU核心数增加一倍，性能大约增加1.2倍，从而表现出完全的线性关系。相反，当服务器的CPU核心数超过32 vCPU时，性能变化类似于读取场景，不再显示线性增长。因此，我们观察到OceanBase可以提供线性扩展。

6.3 高并发低延迟OLTP

最初，一个独立数据库或集中式数据库可以用一台机器支持一个业务。随着分布式数据库的引入，可扩展性变得非常好。如果我们打算在基于三副本的分布式数据库系统中支持相同数量的并发，我们可能需要使用三个节点共同提供服务，以达到单机相同的性能和效率。图11说明了高并发低延迟OLTP场景。

显然，这不是用户想要的分布式数据库。关键问题在于性能方面，我们不仅要关注吞吐量的增加以及从应用程序的角度可以处理的单个SQL或单个事务的速度。虽然我们知道延迟随着分布式事务比例的增加而增加，但从单个事务处理部分的角度来看，

有两个关键点需要满足：

1）即使完全由分布式事务组成，延迟也需要足够低；

2）当没有太多分布式事务时，系统不应该产生额外的延迟。

在分布式环境中，对独立粒度事务和SQL的SQL、存储和事务层的优化也是优先考虑的。在这些组件独立分层后，用户被剥夺了相当大的控制权。因此，提供方法来减少RPC请求的数量，通过将数据放置在一个节点上是有益的。重要的是，用户和DBA对极端性能要求具有控制能力。

OceanBase利用C++提供的控制能力，可以精确地管理内存并降低延迟。此外，为操作人员提供分区数据的能力也是必不可少的，因为表组允许用户避免分布式事务的开销。表组不是物理对象，而是一个代表一组或一组表的逻辑概念。属于该组的表必须满足某些约束。所有表必须具有相同的本地性（包括副本类型、数量和位置）、主区域（领导者位置和优先级）和相同的分区方法。

请注意对比数据OB 4 vs OB 3

总结：

在分布式事务的处理的部分，还需要多关注4.0的优化方法。这里我耗费的一些时间来去处理，大约花了2个小时，但还需要深入。

1  4.0 的OB 修改的是原理性的一些部分

2  4.0 在单机部署或者较少的主机节点部署后，相对与3.X性能提高显著

3  4.0 对于OB 和对于中小企业用户是友好的。

4  CPU 数据量在32核心的以内和32核心--64核心都能线性的提高数据的处理能力，但如果可以超过32核心的单机节点更有利于分布式和分布式并行的性能。