单机分布式一体化的OceanBase，分布式部署时性能究竟如何？

随着大数据、5G 和 AI 的发展，目前市场上的许多数据库产品已经十分成熟。就拿单机数据库来说，如果数据量不是特别大，性能较好的单机数据库足以应付。

但当数据库数量变大以后，一些产品的缺点就暴露出来了：他们虽然采用了可扩展、灵活伸缩的分布式架构，但有些却连 SQL 都不支持；还有些虽然支持一部分 SQL 功能，也支持一些分布式的能力，但是这些 SQL 在设计时都牺牲掉了某些单机性能，用户在面临数据库选型时就会陷入困扰——没有一款数据库融合了集中式和分布式的双重技术优势。

基于这样的需求，OceanBase 研发团队首次采用了单机分布式一体化架构，在保证数据库可扩展、高可用的分布式特性后还不会牺牲集中数据库的优势。但对此也有不少人提出疑惑：在此架构下，分布式部署时如何能实现和确保高性能、低时延呢？针对这个问题，OceanBase首席架构师杨志丰于日前给出了答案。

分布式下的高性能、低时延

下图是在某个特定的负载下面，随着分布式事务比例的增加，单机数据库和两种分布式数据库的性能表现，绿色是单机数据库。

随着某种分布式事务的增加，对于比如 TPC-C 来说，即跨 warehouse 交易的增加，和单机数据没有什么差别。如果有两种数据库，OceanBase 的设计目标是变成下面 DB1 的性能曲线，随着分布式事务增加，肯定有开销，但当使用者还没有分布式事务的时候，DB2 的性能就比 MySQL 差非常多，这并不合适。

此时有两种方式可以做到，第一就是降低分布式事务和分布式查询的这个比例，正如 CTO 杨传辉所说：“实际上对于很多在线型的交易，全局性的事务，他的比例往往并没有大家想的那么多。在典型的 TPC-C 场景下，TPC-C 里跨 warehouse 的交易查询只有10%”。

做在线交易的时候，DBA 同学很清楚自己的业务，并不是所有的东西都要付出分布式的开销，为了能够达到这样的效果，我们做了很多的工作，其中最主要的就是 4.0 里面自适应的日志流。

OceanBase 做了很多自适应的策略，去自动化的根据表的设计去做自动的负载均衡，自动的做数据排布减少分布式事务和分布式查询的比例，如果这些自动化的措施都达不到这个目标，用户同样可以用我们提供的分区表和表组的功能自己去控制、降低分布式事务。

如果以上的要求都做不到怎么办呢？就必须硬碰硬地降低分布式事务和分布式查询整个的开销，这块 OceanBase 有很多独特的设计。

分布式下的高效经济

回到单机分布式一体化架构，在这个架构下面我们看看分布式场景下它是怎么工作的。

对于上面这种分层的设计来说，如果 SQL 层、存储层、事务层是分层的设计，无论自己怎么操作，这个 SQL 和本地的事务之间是没有感知的，所有的东西都是全局的，本地的交易数据还是远程的交易数据对于 SQL 层都没有差别

OceanBase 不是这样，我们显式的就区分了这两者的区别，所以 OceanBase 的 SQL 层可以直接访问到另外一台机器的存储层。如果需要访问另外一台机器存储层的时候我做 RPC，如果我访问的存储是在本地，就不需要做 RPC。

整体设计的时候有几个不同的粒度，本质上设计时要做得更加精细化，精细化是说单机分布式并不是简单的概念，而是多个粒度的单机：

租户。是分布式的租户还是单机的租户。

第二，会话。OceanBase 会通过 Proxy 路由协议使得在很多其他数据库里面分布式的做一件事情，在 OceanBase 会变成单机的事情。最典型的就是开发者会根据这条 SQL 的特征，把它路由到存储所在的节点上，这样即使整体上看起来好像是分布式，但是对于那条 SQL 的执行，它就变成本地执行。

第三，事务。在事务层面上，OceanBase 如果在单个事务内只操作一个日志流内的分区，分布式事务提交的协议和单机的协议也是有区别的。

第四，SQL。如果是一个单机的 SQL 执行和需要远程访问 SQL 的执行，OceanBase有两种独立的执行路径。在此基础之上，为了使分布式的执行更加高效，整个 SQL 引擎在 OLTP 上面做串行执行的时候会有自适应的策略。

对于 LSM-Tree 来说，合并是非常消耗资源的后台任务，但是如果在分布式的部署场景下，使得每台机器的合并和它的服务可以错开，实现“轮转合并”，就是如果一个副本在提供服务就先不合并，但让 follower 副本去做合并，这样使得后台的 LSM-Tree 合并对于前台的操作在这台机器上没有影响。

分布式下的查询性能

如果没有办法优化业务来减少分布式 SQL，对于分布式 SQL 这部分该怎么去执行？OceanBase 整体的 SQL 自适应执行引擎，分为串行执行和并行执行。

并行执行可以在单机内并行，这一点相对于一些开源的单机数据库是有优势的，早期的 MySQL 版本单机内并行是没法做到的，又可以利用多机，如果一台机器 CPU 还不够，我可以把整个集群的 CPU 用起来去做并行执行。串行执行我们就显式地去区分了，它到底是一个大数据量的访问，还是一个小数据量的访问。

如果是一个小数据量的访问，可以把数据拉到本机来执行；如果是一个大数据量访问，可以把整个 SQL 的执行计划下压到那台机器上去做数据过滤，整个过程是优化器自适应去选择的。

总之，针对大家担心的分布式数据库时延指标，OceanBase 已经着力优化，也期待其之后能给大众带来更加出色的性能体验。