OceanBase解析：如何将单机数据库和分布式数据库的优势结合？

在当前的数据库技术中，单机和分布式系统各有优缺点：传统的单机数据库系统通常具有较高的性能和易用性，但是无法满足大规模数据处理和高可用性的需求；而分布式系统可以通过分割数据和负载来提高扩展性和容错性，但是却增加了系统的复杂度和维护成本。

而为了满足高并发、高可用性的需求，又可以保证数据的一致性和完整性，单机分布式一体化数据库应运而生，而OceanBase无疑是最具代表性的典范。

单机部署时的高性能

OceanBase 单机分布式一体化整体的架构，说起来非常简单：每一台机器都具有自己独立的 SQL 存储事务的模块，在单机之内，SQL 存储事务之间直接通过函数调用，和单机没有任何区别；在机器和机器之间通过网络去做通讯。

上图中的架构有几个特征：第一，每个节点单进程，OceanBase 没有那么多角色区分，整个 SQL 事务存储是在单个进程内共享内存的；第二，单机内工作是没有 RPC 的，并且对于单机数据库来说，为了提升垂直的扩展性，OceanBase 还支持单机内并行，在更深层次上，每个组件的设计，OceanBase 都会兼顾单机和分布式。

在这样的设计里面，每一个功能的设计都要考虑在单机内怎么样做最好，分布式时怎么做最好，所以OceanBase的设计都会有这样两个维度。

首先看单机的两个含义，第一，每个 Zone 里面一个OBServer，所以即使一个 Zone 里面有很多个资源的单元，即 Unit，如果你的租户是单个 Unit，就等于这里所讲的单机。

为了提升单机内垂直的扩展性，OceanBase 在 SQL 引擎、事务引擎、存储引擎都会做到极致的优化：第一，单机内可以并行；第二，在事务引擎里，我们在做事务的高并发处理的时会做组提交的技术。同样在存储引擎里面，存储引擎属于准内存的存储引擎，写入的时候只需要放到内存里就可以了，并不需要像传统的 B+ 树一样，把它写到数据块里。单机内同样在 IO 层面支持很多并行。

分布式部署时的低时延

对于 OLTP 业务来说，大家用分布式数据库很担心时延的指标，那么单个操作的时延指标是不是能像单机数据库一样呢？这是 OceanBase 着力在优化的点。基本原因就是：无论你在怎么样的数据中心，做一次 RPC 就需要 0.5 毫秒，这个时间不可忽略。

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

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

此时有两种方式可以做到，第一就是降低分布式事务和分布式查询的这个比例，正如 CTO 杨传辉所说：“实际上对于很多在线型的交易，全局性的事务，他的比例往往并没有大家想的那么多。在典型的 TPC-C 场景下，TPC-C 里跨 warehouse 的交易查询只有10%”。做在线交易的时候，DBA 同学很清楚自己的业务，并不是所有的东西都要付出分布式的开销，为了能够达到这样的效果，我们做了很多的工作，其中最主要的就是 4.0 里面自适应的日志流。

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

综合来说，OceanBase将单机数据库的优势和分布式数据库的优势结合在一起，可以实现数据的快速读写、高效的数据处理和管理，同时还能够提高系统的可扩展性和可靠性，满足不同规模和需求的企业应用。

更重要的是，用户在选择产品的时候不需要再在单机和分布式中做出痛苦的二选一，这对于用户来讲是非常方便的一个事情。