在执行计划生成层面，我们生成执行计划的策略有两种。

第一种是规则优化（RBO），即 RULE BASED OPTIMIZER，顾名思义就是在生成执行计划的时候，是根据SQL的模式，遇到了什么条件，就生成什么样的执行计划给它。这种方式其实在实践起来比较简单，某些方面比较高效，缺点是弹性不足，对一些复杂场景，它很难去应对，没有足够的弹性。

第二种是代价优化（CBO），即COST BASED OPTIMIZER，这是用的比较多的主流优化方式。它主要会从目标SQL诸多可能的执行路径中选择成本比较小的一条作为执行计划，成本值是根据目标SQL语句所涉及到的表、索引、列等相关对象的统计信息算出来的。它的适用性会比较好，特别适合一些复杂的场景，而且在一些复杂场景下会性能表现比较稳定。缺点是复杂度比较高的，有一定的前置条件，包括我们统计信息的准确度，代价计算模型的一个精确度。TBase来讲的话，两块都会有，更多的会偏向于后面的代价优化（CBO）。

TBase在整个设计分布式执行方式的时候，我们有一个很明确的目标：希望业务的SQL不需要感知集群结构，它可以像使用单机的数据库一样来使用TBase。

也就是说客户和业务在使用TBase的时候，他不用考虑分库分表的问题，也不用考虑这个集群里面有多少个节点，SQL是怎么写的，他就可以像使用普通的单机的数据库一样来使用TBase。为了达成这个目标，我们使用了前面我们讲到的各种各样能够帮助我们解决问题的技术。比如说我们在进行查询优化的的时候，如果发现表这一列都是按照分布列来进行查询的，就走规则的优化，查询直接下推；如果我们不是按照分布列来进行查询的，是按照表A是分布列，表B是非分布列，这个时候进行查询的时候就会根据代价来进行判断。如果这个表B足够小的话，会通过广播的方式，把表B在每个节点上都形成一个完美的副本，拿表A进行查询。如果表A和表B都很大，这个时候我们就会选择一个成本相对比较低的表来进行重分布，选择的方式是表B。假如说表B相对于表A要小一点，按照表B来进行重分布，来完成整个查询。这个用在上面，我提到了包括redistribution和replication，还有push down。后面两个我们push的是PLAN。

在TBase里面，在MPP的架构下，我们具备了并行计算的架构基础。

全并行大概分几级，其中第一级是节点级的，也就是说一个SQL来了之后，我们会把这个查询的同时发给三个节点，三个节点同时开始计算。然后在节点内部的话，我们会进行算子级的并行。比如说进行一个Hash JOIN，我们会多进程的完成这样一个Hash JOIN的过程。在每一步计算的过程中，还会使用指令级的SIMD的一些指令来加速。这样其实做到了从节点级到进程级以及指令级的一个并行。

前面介绍了我们对性能进行优化的方式，这里讲一下数据库常见的容灾方式。

数据库容灾方式大概分几种：

第一种是我们传统单机数据库，包括MySQL、PG、ORACLE，常规的这种容灾方式也是通过流复制的方式，流复制的基础是基于日志，或者是基于数据块。复制方式有同步复制和异步复制，所谓同步复制是等主机返回请求之前一定要等到备机的日志可靠落地之后，它才会返回成功给客户端。异步的话是主机事务日志落盘后，异步把日志发送到备机，不用等待备机事务的可靠落盘。同步和异步对外体现的主要是业务的RTO、RPO的影响。这种方式一般来讲下，我们在主机上提供读写能力，在备机上提供只读能力。

第二种容灾方式大家看到的比较多，主要是使用一致性协议来复制日志，也就是说每个写入请求来的时候，它都会通过一致性协议进行集群内部的协商来达成最终的一致。这样的架构的好处是每个副本都可以写入，但缺点也比较明显，每个写入都需要经过若干次的网络同步，效率其实要比基于流复制的容灾方式弱一些。因为它的每个副本都有完整的一个数据，而且都可以进行导换，所以它的RTO表现会好一点。从这里其实我们可以看出来，数据库容灾的本质其实就是数据的多副本，各种方案的区别主要是在于多副本我们是怎么实现的。TBase多副本实现没有使用一致性协议。

接下来给大家介绍下TBase运维管控架构，TBase作为一个分布式系统，整体的架构是比较复杂。

我们需要一个运维管控系统来保证整个系统的可靠运行和高效的运维。整个TBase的运维管控系统如图所示，图中最上层是ETCD集群，即TBase的元数据管控集群。另外它提供一些控制中心的选主的能力。第二层是运维管控中心，它实时的监控集群的状态，同时这里也可以去触发一些故障处理逻辑。第三层是数据探活集群，这一层主要是有部署在每台服务器上的Agent来完成，它会实时的去探测每个数据库实例的健康度并进行上报，同时它也会执行上层的运维管控中心下发的一些指令。最下层是数据库实例，这一层其实是通过资源池化的方式来进行资源隔离，同时内部也进行了一些容灾的控制。

这里我提一下数据库里面比较重要的备份问题。我们为什么要进行冷备？

前一段时间发生的数据冷备被删除，导致业务中断估计大家还有印象。所谓的冷备其实也是数据库安全的最后一套防线，我们一般什么时候用到冷备呢？经常是在发生重大的误操作的时候，比如说我不小心把库删了，或者说整个机房所有的副本都挂了，另外如果说数据做了恶意的修改或者篡改之后，需要把数据恢复到一定时间以前的数据，冷备是数据库的最后一个保护伞，对数据库来讲是非常重要的。

冷备可能会存在的一些问题。

分布式场景下数据库的冷备存在的问题和分布式事务存在的问题是很类似的。我们集群内部会有多个节点在并行跑事务，最难搞的问题是在分布式冷备系统中如何找到一致性的恢复点。如图，集群里有两个节点DB1和DB2，冷备点1和4的，恢复就是一致的。冷备点2和冷备点3就是不一致的。整体一致点的选择非常重要。如果选择不当就会造成数据的损失和不一致。

分布式数据库里面，如何寻找一致的冷备点也有一些方法可以参考。

第一种是要求在做冷备的时候，通过设置事务栅栏来保证整个事务的一致性，我们会在所有的日志里面设置一致性标签，然后恢复的时候，指令说恢复这个标签就停下来，这样可以保证整个事务的一致性。但是这里有一个缺点，在进行一致创建的时候，必须得去阻塞或者延迟当前事务的执行，对系统的影响其实还是比较大的。TBase是通过时间戳的方式，每个事务都有一个时间戳，那么在选择冷备点的时候，就可以决定说要恢复到某个具体的时间戳，通过事务的时间戳我们就可以很好的保证整个冷备恢复的一致性。

前面介绍了TBase在执行和冷备及可靠性分析的设计，接下来介绍下TBase特有的安全能力，在支撑公司业务过程中摸索出来的一套比较有效的数据安全管理体系，我们管它叫MLS（multiple layer security）。

这个数据安全体系的基础是三权分立，所谓的三权分立指的是：安全管理员、审计管理员、数据管理员三个角色在系统里面相互隔离。安全管理员主要是负责安全规则的制定；审计管理员主要负责审计规则的制定；数据管理员更多的相当于我们之前的DBA的一个角色。这三个角色之间在权限上和能力上来讲是完全隔离的，相互之间在功能上没有交叉。安全管理员的安全规则会约束到审计管理员和数据管理员，然后审计管理员的审计规则会约束到安全管理员和数据管理员。接下来给大家分别介绍下：TBase的行级强制安全规则、列级的安全规则、数据脱敏和加密。

1、TBase的行级强制安全规则。

行级安全规则保证在TBase中我们可以做到数据行级安全的权限控制。安全规则三元组：一个是level（安全级别），这个安全级别是从上往下兼容，也就是说我如果具有绝密级别的安全权限的话，我就可以获取到机密、保密和公开级别的数据的一个访问权限。第二个是Catalog／compartment（目录控制Catalog／compartment，这是一个集合的概念。也就是说如果有了α、β和∑这三个对象整体的权限的话，我就可以单独的去访问只有α或者β或者∑其中一个或者几个组合的数据。最后一个是Group（组），这个概念比较容易理解，类似于公司组织关系，上级节点具有下级节点的权限。