我们每个月都会和大家展开一次社区进展的汇报沟通会，希望通过更多的互动交流让OceanBase 开源社区更加透明，实现信息共享，也希望能营造更加轻松的氛围，让大家可以在此畅所欲言、答疑解惑。如果您对我们的社区有任何建议，欢迎在 GitHub 上提 Issues 或 PR ，也欢迎大家称为 Contributor，参与到社区建设中来。
在过去一个月，OceanBase 产生了许多新动态，其中最引发大家关注的事件是OceanBase 4.0版本的发布。因此，在本月的月报中，就和大家聊聊OceanBase 架构演进和OceanBase 4.0的功能。同时，也会向大家分享产品的未来规划。
OceanBase 架构演进
回顾2014年的 OceanBase 0.5 版本，这一个存算分离的架构（见图1），所有数据存放在 UpdateServer 或 ChunSever 中，并在 MergeSever 中计算。MergeSever 接受了所有的 SQL 且保证了无状态，在底层的 ChunSever 可以自动分裂，并做到存储水平的扩展，而 UpdateServer 则会通过Paxos来保证高可用强一致性。
图1 OceanBase v0.5 架构 （2014）
OceanBase 0.5 版本也支撑了2014年的支付宝“双11”，但当时的 OceanBase 存在一个问题——单点写，即永远只有一台机器能够提供“写”服务，也不能做到线性扩展。
随后我们用近一年的时间重构 OceanBase 架构，如图2所示，OceanBase 1.0版本到3.0版本的架构，将 SQL 引擎、事务引擎、存储引擎、RS模块放到一个单进程中，降低了架构的复杂度。
图2 OceanBase v1.0至v3.0架构
OceanBase 1.0版本至3.0版本的架构特点可以总结为如下三点。
- 对等节点：每个节点都是一个对等的节点没有共享，每个分区可以直接做数据分片扩展。
- 单机低延时：支持本地执行计划、本地执行事务的 API，所有的读写无网络开销。
- 多机低时延：可以区分远程计划和分布式计划，远程计划中事务的第一条 SQL 发到某节点，该节点会承担整个事务的所有请求，如果数据在另一条节点上，则会发起远程调用。
该阶段架构的问题是，当分区数特别高时，底层的 I/O 压力较大，对内存的消耗过大，无法把整个进程控制在非常小的单机中。而在过去最低为16c和64G的生产环境规格，对硬件的要求也比较高。
2020年初，我们开始重构整个事务引擎、存储引擎、SQL 引擎，开发 OceanBase 4.0版本，架构见图3。我们做了很大的调整，将事务提交单位和数据迁移单位分开，单机上所有分区的事务日志统一到一个日志流当中，数据迁移单位（Tablet）和原来的分区表概念稍做区分。
图3 OceanBase v4.0架构
在3.x当中，随着日志流的增多，选举及网络的开销会逐渐变大。在综合考虑架构设计后，我们在4.x 当中将日志流和数据存储单位隔开，这样就可以将数据分在多个不同的分片上，不同的分片在进行事务提交时写到一个日志流中。该方式有几个好处：一是大幅降低日志IO的并发冲突；二是降低了选举的开销，从原来的分区级降低为单机日志流级。
OceanBase 4.0版本的架构具有单机分布式一体化的特点，就是在单机环境下，系统类似一个单机的SQL引擎、单机的事务引擎、单机的存储引擎，但它可以自适应考虑SQL 的执行, 对于小数据量或单机事物时, 自动适配为单机串行执行, 如果打开并行开关, 可以自动升级为单机并行执行, 当数据跨多机执行时, SQL的执行会自动演变为分布式执行, 并且根据并行开关配置, 自动适配为分布式并行执行或者分布式串行执行。在分布式环境下，整个引擎是分布式的SQL引擎、分布式的事务引擎、分布式的存储引擎，它需要考虑更加高效的创新执行、单机的事务优化，以及轮换合并等。也就是说，OceanBase 4.0版本的每一个组件、每一个模块都要兼顾单机和分布式这两种模式。这对我们技术人员的挑战更高，也让我们考虑了更多的场景、更多的变化，我们用过去两年的时间才将这个门槛迈过去。
而对于用户来说，单机分布式自适应的架构意味着 SQL可以单机执行，也可以分布式执行，还可以并行执行。更多的详细介绍参见《从0.5到4.0，OceanBase单机分布式一体化的技术演进》。
以上就是OceanBase架构发展中的变化，下面向大家重点介绍OceanBase 4.0版本的关键特性及其对用户来说意味着什么。
OceanBase 4.0版本的关键特性解析
关键特性1 ：更多分区数
OceanBase 4.0版本的架构降低了分区维护的开销，除此之外，内存的优化不可小视。在过去的版本中，我们会为每2MB的宏块维护一个元数据，元数据和数据的比例大概是1：1000，因此，对于磁盘较大的机型，元数据开销也会增加很多。而在本次迭代中，我们将存储内存的开销做成按需加载，在内存中只维护 root 节点（内存很小）。当用户需要去访问元数据时，再去加载它的叶子节点和数据节点。这种方式降低了常驻内存的开销，带来了小规格内存优化的特性。
关键特性2：支持更多DDL
在社区版的技术答疑群，我们经常能看到用户提问：为什么不支持数据类型转换和分区变更？主要因为这部分 DDL 会对数据的分布及数据类型进行一些调整，在过去的版本中，凡是涉及底层数据变更的 DDL 都是不支持的。
在OceanBase 4.0版本中，我们将这部分的DDL能力补齐，支持用户进行分区变更，可以类型变更，也可以变更主键，方便大家延续原有的数据库使用习惯。
DDL 的实现原理比较简单。首先新建一张隐藏表，等 DDL 开启前的事务结束，并获取快照点，再对原表进行停止读写；其次，用一个 DML 语句把原表的数据插入隐藏表中进行数据补全；最后，对原表进行重命名。该过程中的数据补全涉及三个关键技术点：一是表锁，当我们做这些操作时，需要对这张表进行禁写；二是PDML，当对原表进行查询时利用 PDML 加速查询，简化流程代码； 三是Direct insert，插入数据时会直接写到静态数据，避免内存爆满，且速度较快。
目前该过程对用户来说是离线的，我们正在开发在线的版本，预计会在OceanBase 4.1 或 4.2 版本提供。
图4 DDL实现原理及步骤
关键特性3：更小的资源占用
OceanBase 4.0版本中，生产环境规格从 16C/64G降低到了4C/16G，帮助用户降本增效。我们主要做了以下几点优化。
- 线程堆栈优化：减少线程局部变量，使用 smartvar 减少栈变量。
- 优化元数据开销：从 perpartition 到 perlogstream ，存储元数据按需加载。
- 稳定性提升：默认打开导入限速，在4C/16G下会跑得更稳定。
- .......
关键特性4：租户隔离
借着OceanBase 4.0架构与OceanBase 3.x架构不兼容的契机，我们对租户耦合逻辑做了优化，主要有以下三点。
- 租户级别合并：默认的合并行为从集群整体触发改成租户触发。
- 租户级别元信息：将元信息从系统租户调整到用户租户，将 tableid 和 tenantid 解耦。
- 租户 I/O 隔离：Clog 文件拆分到租户，SSTable 支持租户级别 I/O 限速。
关键特性5：性能优化
性能优化体现在两个层面。第一，TP 性能优化，虽然我们做了很多小的优化点，基本是1%、0.5%.的迭代，但这些小的优化点堆积起来的效果是非常显著的。第二， AP 性能优化，OceanBase 4.0 将OceanBase 3.2的TPC-H打榜能力开放出来，为其 AP 性能的较大提升提供了助益。
针对TP 性能, 近期我们进行了OceanBase 4.0和MySQL8.0的性能测试对比，在256个并发及以上的情况下，OceanBase 的性能高于 MySQL; 在200并发以下， OceanBase 的性能相比 MySQL 稍差。我们会持续优化，希望明年能在100并发及以上超过MySQL。
图5 OceanBase 4.0和MySQL 8.0的性能测试对比
我们也做了一个扩展性的实验，将规格不断扩大，在 4C、8C、16C、32C、64C 的规格中，性能接近线性提升。
图6 OceanBase 4.0在不同规格机器的性能表现
将 OceanBase 社区版 4.0与OceanBase 社区版3.1.0进行 TPC-H 100GB测试对比，按照顺序执行22条查询SQL。从数据上来看，整体性能提升了5倍。
图7 OceanBase 4.0 与 OceanBase3.1 性能对比
我们将OceanBase 社区版4.0.0 与Greenplum 6.22.1进行TPC-H性能对比，从实际测试数据上可以看到，同等硬件条件下，OceanBase 社区版4.0 的AP能力是Greenplum 6.22 的5-6倍，部分场景下性能差异可达到9倍。
图8 TPC-H 100 GB Results (By Query)
图9 TPC-H 100 GB Results (Total)
关键特性6：安装部署简化
与以往版本相比，OceanBase 4.0版本的安装部署简化为了三步（见图10）：下载离线安装包、解压安装、执行obd demo。执行这三步就能获取到一个单机版的 OceanBase，也可以用该步骤部署多机版，只需将最后一步改成编辑配置一个文件，再去安装部署即可。目前，已经有很多用户正在使用该步骤，如果大家在使用过程中遇到问题，欢迎加入技术答疑群（群号：33254054）一起交流。
图10 OceanBase 4.0的安装部署流程
除了上述六个关键特性，我们还增设了很多功能：
- 通过 LOB 功能，MySQL 模式支持 4G，Oracle 模式支持 TB 级别；
- JSON 类型支持，适应更多业务场景，也正在尝试 GIS 类型的支持；
- DBLink 功能支持写入，打通与传统数据库互操作能力；
- 预计明年实现 MySQL binlog 接口，以便 MySQL 生态工具接入；
- 表锁功能，兼具单机数据库的使用体验和分布式的扩展能力；
- 租户隔离能力进一步完善，I/O 纳入隔离体系。
当然，OceanBase 4.0版本的能力远不止本文提到的这些，建议大家亲自测试，感受这些有趣的特性。在众多测试的小伙伴中，叶金荣老师反馈了data base断连的问题，该问题已经在4.0 BP2 版本被修复了。
图11 OceanBase 4.0 BP2 BUG修复
图12 OceanBase 4.0 BP1 BUG修复
图13 OceanBase 3.1.4 BP2 BUG修复
OceanBase 4.0 在开源模式的变化
除了开源OceanBase 4.0版本外，本次还开放了OceanBase master分支。其实，早在3.1版本时，我们就把 3.1 release 版本开源了，而它只是 GitHub 上的一个 master（见图5），出于开源版本应较为稳定的考虑，没有开源master 分支。
图14 开源模式的变化
OceanBase 4.0开源后，我们将最新的正处于迭代期的代码分享出来，我们期待和用户一起交流、讨论研发流程，让用户看到OceanBase 在设计方面的思考和变化，也希望有更多开发者能够参与到OceanBase 项目中, 和我们一起把OceanBase 做得更好。
我们统一了社区版和企业版的代码，包括文档、部署方式、版本号，未来将在同一个分支进行开发，实时同步代码，并支持社区版原地升级到同版本号的企业版。
此外，开源模式的变化还值得大家关注的是，MySQL 租户下的所有功能基本都开放了，功能与企业版基本一致，包括行列混存、向量化引擎、存储过程（包括自定义函数）、触发器，以及更多的字符。未来在OceanBase 4.1版本中，也会开放主备库。
未来规划
在今年11月提出单机分布式一体化的架构后，公有云上已经有30+业务正在试运行或已经上线该架构，开源社区有30+位用户试跑OceanBase 4.0（部分用户已上线），支付宝内部也有10+个业务运行OceanBase 4.0。我们在保证以上用户正常运行的前提下，再根据QA团队的评估迭代新版本和功能。如果评估通过，春节前发布 4.0 稳定版。12月中旬发布 OMS 4.0 社区版，方便用户使用 OMS4.0 将 MySQL 数据迁移到 OceanBase中。
我们也将在安装层面做出较大改进——安装白屏化，简单来说，就是用户可以在一个图形化界面上安装 OceanBase，预计2023年1月推出。同时推出 OCP 的轻量版并开源，现在的OCP是集中式的OCP，它支持很多OceanBase 集群，但存在“鸡生蛋蛋生鸡”的问题。当用户在安装 OCP的时候，要先安装一个 OceanBase，导致用户上手门槛比较高, 体验并不好。OCP 轻量版可以直接将集群管理起来，用户也可以看到很多的监控数据，并且做一些轻量级的运维工作，降低资源消耗。
最后，向大家透露一点 OceanBase 4.1版本的消息。OceanBase 4.1 除了主备库外，自动负载功能和小型化也值得关注。我们期望未来的社区月报能够让大家获取、学习到更多关于 OceanBase的动态和知识，我们也会分享更多开发者向的有趣内容。
建立一个学得轻松，玩得开心，用得放心的开放社区。
我们每个月都会和大家展开一次社区进展的汇报沟通会，希望通过更多的互动交流让OceanBase 开源社区更加透明，实现信息共享，也希望能营造更加轻松的氛围，让大家可以在此畅所欲言、答疑解惑。详情可在GitHub Discussions 版块查阅。
欢迎持续关注 OceanBase 技术社区，我们将不断输出技术干货内容，与千万技术人共同成长！！！
搜索🔍钉钉群（33254054），或扫描下方二维码，还可进入 OceanBase 技术答疑群，有任何技术问题在里面都能找到答案哦～
