4.7 执行模式
前文说过，OceanBase 是一个 Share-Nothing 的分布式架构，并行执行可以满足 OLAP 场景下对单个请求的并发处理需求。但是对于 OLTP 场景，一个 SQL 请求耗时可能只有几毫秒甚至几百微秒，一般都是串行执行，因为并行执行调度的执行开销对于 OLTP 场景来说是非常大的。为了能够在分布式场景下高效地处理 OLTP 场景的请求，OceanBase 也提供了其他多种执行模式，包括本地执行、远程执行以及 DAS（Data Access Service）执行。
本地执行
对于 SQL 需要访问的数据，如果都在接收请求的节点上，并且该请求是不需要并行的，访问的表也都只涉及到一个分区。这个时候就可以使用本地执行，因为数据是不需要跨网络进行传输的。比如下图中接收请求的机器直接可以对 t1，t2 表进行 join。join 完之后直接就把数据返回给 ODP，再由 ODP 返回给客户端。
远程执行
对于 SQL 请求，如果需要访问的数据都在同一个节点上。但是 ODP 却没有路由到这个数据所在的节点，而是路由到了另外一台机器，这台机器上没有要处理的相关数据，同时这个请求不需要并行，访问的表也只涉及一个分区，这个时候就需要使用远程执行。
远程执行的过程如下：
OBServer 接收到请求之后，把执行计划或者 SQL 请求直接发送到远端数据所在的机器。
远端数据所在的机器接收到执行计划或者是 SQL 请求之后，开始对其进行执行。
远端数据所在机器把 join 的执行结果发给接收请求的机器。
接收请求的机器将结果返回给 ODP。
整个过程中只需要对结果进行数据传输，整体开销还可以接受。但是一般来说，在实际场景中会尽量避免远程执行（毕竟还是会多一个网络的开销）。
DAS 执行
还存在一种场景：数据分布在不同的机器，但是访问的数据量却很小。如果使用并行执行，那 overhead 其实是比较高的。因此就引入了 DAS 执行。DAS 执行是直接通过 RPC 的方式串行访问或操作远程的数据。
比如上图的例子，该语句的作用就是把 t2 的数据查出来之后插入到 t1 中。
接收用户请求的机器（OBServer 0 节点）上既没有 t1 表的分区，也没有 t2 表的分区。所以该机器首先会发一个 RPC 从 t2 表中获取到它所需要的数据，之后数据会返回到 OBServer 0 节点上，然后再通过 RPC 将这个数据发送给远端 t1 所在的机器，也就是 OBServer 2 节点上，直接把该数据插入到 t1 所在的表中。
这两个过程其实都是通过 RPC 来实现的，会比并行执行的调度开销小很多。但是唯一的缺点就是，DAS 执行是把所有数据直接拉到接收请求的机器进行处理。这里需要处理的数据量比较少，也比较适合处理分布式的 OLTP 的查询。
并行执行
并行执行主要是针对大数据量的并行处理场景。前文已经做了一个具体介绍，详细信息请参考 4.7 并行执行。
