OceanBase 2021 年 6 月 1 日开源以来，先后迭代发布社区版 3.1.0、3.1.1 和 3.1.2。从早期只有数据库内核和最基本的一键安装部署工具的首个 3.1.0 版本，到开源半年内先后发布的 3.1.1 和 3.1.2 两个版本，再到 OceanBase 生态工具提供社区版支持（包括运维管理工具 OCP、开发者工具 ODC、数据同步工具 OMS、导入导出工具 obdumper/obloader 等）。在社区开发者的共同努力和大量客户应用场景的快速反馈下，社区版逐步具备较为完善的企业级数据库能力，目前已得到数百家企业用户的认可，并应用于关键业务的实际生产环境。

OceanBase 社区版 3.1.3 作为 2022 年首个版本，已于 3 月 30 日正式发布。

本次版本的重大更新来源于两个部分：

第一，来自企业版的重大功能引入。包括多模数据类型、JSON 支持、兼容 HBase API。

第二，来自社区用户的反馈和需求。包括提升部署便捷性、易用性、稳定性，能够更好地适配云环境。很多用户提到 OceanBase 需要支持 Kubernetes 等需求，在这个版本中得到解决。

该版本的功能亮点和用户价值：

• 支持 OBKV 能力，提供 HBase 模型和 Table 模型的 NoSQL 能力。读写综合性能超越 HBase，且能复用 OceanBase 底层的强一致和异地容灾能力，并避免了 HBase 的性能抖动问题。以蚂蚁集团为代表的多个用户已经在延迟敏感的关键业务场景中使用 OceanBase 替换 HBase。
  
  
  
• 支持兼容 MySQL 5.7 版本的 JSON 功能，提供半结构化数据支持。很多用户会使用 JSON 类型存储半结构化数据以弥补关系模型的不足，相比 TEXT 和 LOB 类型，JSON 类型存储半结构化数据时性能更好，支持高效索引和合法性校验。
  
  
  
• 支持回收站中的对象恢复，极大降低因误操作导致的潜在风险。表格删除后进入到回收站，Flashback Table 能够将回收站误删除的表格恢复出来，防止误操作。
  
  
  
• CDC 支持大事务，通过新增持久化模式，数据在同步开始前先进行本地临时存储，避免 CDC 传输大事务时因内存溢出 OOM 而导致的断开链接问题。
  
  
  
• 支持 Kubernetes Operator，用户可以通过容器的形式将 OceanBase 运行在公有云或私有化部署的 Kubernetes 集群。
  
  
  
• 部署更加便捷，面向开发者提供更加友好的使用体验。将 Docker 镜像由 2C10G 优化至 2C8G，降低开发者在个人电脑使用 OceanBase 的门槛。另外，新增了 ARM 架构支持。
  

需要注意的是，该版本还有两个行为变更：

第一，分区表默认创建的索引变更为局部索引。之前，OceanBase 分区表创建的索引默认为全局索引，在一些用户使用过程中我们发现 ，需要经常对分区表的索引性能进行调优，经过分析总结，发现局部索引更适合多数客户业务场景，因此我们将分区表默认创建的索引调整为局部索引。如果需要创建全局索引，需要加上 global 关键词，例如 create table example(c1 int primary key, c2 int, index(c2) global) partition by key(c1) partitions 32。这个变更不会影响过去已经创建好的索引，但会对未来创建索引的默认行为产生影响，DBA 需要特别关注该变更。

第二，修改创建表的默认行为变更为非严格模式。过去，OceanBase 数据库建表要求所有副本成功才算成功，这次版本调整为只要求多数派副本（3 个副本中的 2 个，或者 5 个副本中的 3 个构成多数派）创建成功即认为建表成功。如果需要使用严格模式创建表，需要将系统变量 ob_create_table_strict_mode 设置为 True 。

支持 OBKV 能力

这里所说的支持 OBKV 能力，主要包括提供 HBase 模型和 TABLE 模型的 NoSQL 能力。

为什么要支持多模型

众多 NoSQL 存储系统（如 Bigtable, HBase, Cassandra, Zeppelin, ScyllaDB, Pegasus, Riak KV），底层都是使用 LSM-Tree 结构的存储引擎来充分发挥现代硬件的能力。OceanBase 作为关系数据库已经实现了一套完整可扩展的分布式 LSM-Tree 存储引擎，具备支持多模型的先天基因，在此基础上扩展支持 NoSQL，可以帮助用户直接拥有以下久经考验的架构优势：

1. 让 NoSQL 拥有了 OceanBase 的企业级数据安全和高可用的服务

2. 支持全球部署，例如 OceanBase 的“三地五中心”多地部署

3. 支持读写分离架构，弱一致性读可无限扩展

4. 强大的弹性能力，适应“双 11 大促”快速在线扩容缩容的能力要求

多模型是怎么做的

OceanBase 目前在 SQL 层面已经支持兼容 MySQL 语法协议的关系型 SQL API；在存储引擎层面，通过 Table API 提供表模型和 HBase 模型的 NoSQL 能力，并在此之上接入多种兼容性服务，实现一个 OceanBase 数据库，支持多种数据模型。

客户端设计：OceanBase 数据库的每个表或表的分区都可能存放在不同的机器上，想要对表进行读写操作，必须先要定位到数据所属的表或分区的位置。对于 Table API 协议接口，OceanBase 不会做路由转发，只允许在本地执行。因此每一轮操作，客户端都会先根据 table name，rowkey 计算出具体的分区号，再根据分区号反向计算出对应 OceanBase 服务节点具体位置，最后把请求发送到对应 OceanBase服务节点上执行。由此可见，客户端除了基本的读写功能外，还承担着路由计算的使命。需要注意的是，当前 Table API 没有跨分区事务。

传输层设计：Table API 使用 OceanBase 自定义的 RPC 协议进行通信，这个协议是标准的 Request-Response 模型。不同的 Request 之间互相独立，服务端会并发处理多个请求。同一个客户端和服务端之间可以建立多个 TCP 连接。数据经过 RPC 层传递后到服务端后，经过数据包解析，OceanBase 服务端最后从请求包中解析出消息类型以及数据体。

服务端设计：OceanBase 服务端使用生产者消费者模型，来处理客户端的 Table API 消息请求。当服务端接收到客户端请求后，由独立线程把请求消息放到消息队列中，并且由工作线程从队列中取出消息体并处理。为了区分不同类型的消息，OBServer 采用优先级队列，对不同类型的消息（MySQL，RPC 等）进行分层处理，这样可以保证某些优先级比较高的请求不会因为超时而被饿死。

另外，Table API 复用 OceanBase 数据库的事务框架以及存储引擎。受益于存储引擎的二级分区表和 LSM 树数据组织结构，Table API 同样能够通过自动分区负载均衡来解决分区热点问题和机器热点问题，对用户完全透明。

 图1：OceanBase数据库多模架构

多模型带来哪些提升

OceanBase 采用分区组织结构，主分区可以分布在不同的 OceanBase 服务节点上，对于不同分区的写操作会分布到不同的数据节点，从而实现数据多点写入，提高系统整体写入吞吐；数据存储采用 LSM-Tree 模型，业务数据直接写入内存，可获得接近内存数据库的写入性能；同时 OceanBase 支持的多种缓存结构（块缓存、行缓存）、布隆过滤器、查询优化等最大限度的提高访问性能；相比于 SQL 接口，Table API 从宏观上绕过 SQL 语法语义解析，直接提供从客户端到服务端的访问，大大简化了访问路径。

图2：OceanBase 与 HBASE 性能对比

支持 JSON 格式数据类型

MySQL 从 5.7.8 版本开始，支持了 RFC 7159 JSON 类型， 通过使用 JSON 类型可高效访问 JSON 文档中的数据，并为用户提供三大便捷：

1. 数据合法性校验，使用 JSON 类型相比于 TEXT 或 LOB 类型存储文本数据，在数据入库时会进行语法校验，对于不合法数据进行报错处理，确保插入数据的正确性。

2. 操作便捷，避免数据在 TEXT 或 LOB 类型到 JSON 类型的转化，同时提供丰富的函数以及路径表达式来方便用户访问 JSON 数据。

3. 高效的性能，支持创建索引，同时可减少关联查询，提升性能的同时降低数据库服务压力。

因此，OceanBase 数据库在 3.1.3 版本推出 JSON 格式数据类型，对 JSON 数据类型的设计实现主要包括：JSON 类型、JSON Binary、JSON Path、JSON Function、JSON Tree 五个组成部分。其中:

• JSON 类型：用于处理 JSON 类型和其它类型的转换、JSON 类型之间的比较以及字符集相关。
  
  
  
• JSON Binary：直接存储 JSON 解析编码后的二进制，支持直接基于 JSON BINARY 进行查询遍历，以及二分查找，避免了查询过程中对 JSON 数据进行展开的开销。
  
  
  
• JSON Tree：内存辅助结构，只有在 JSON 修改的时候才会构建。
  
  
  
• JSON Path：提供以路径的方式访问 JSON 中的数据以及子 JSON 对象的能力。
  
  
  
• JSON Function：提供操作 JSON 类型数据的表达式函数，包括创建、查询、修改 JSON 数据等函数。
  

OceanBase 数据库 3.1.3 版本提供的 JSON 能力兼容 MySQL 5.7 版本的全量以及 8.0 版本的部分 JSON 函数。支持 DDL、索引创建、SQL 查询、数据类型转换等基本操作。主要能力如下：

• JSON 是一种复合数据类型，JSON 内部的数据支持四种基本类型（字符串、数字、布尔值和 NULL）和两种结构化类型（对象和数组）
  
  
• 支持在创建表、添加列时创建类型为 JSON 的列
  

• 支持基于 JSON 列的生成列创建索引
  

• 支持通过 ->、->> 操作符引用 JSON 对象
  

• 支持在 SELECT/INSERT/UPDATE/DELETE 等 SQL 语句中使用 JSON 文本
  

• 支持MySQL 5.7 版本的全量 JSON 函数以及 JSON_OVERLAPS()、JSON_VALUE() 等 8.0 版本新增函数
  

支持回收站中的对象恢复

回收站，顾名思义，就是用来存储被删掉的东西。在 Oracle 10g 数据库中，引入了一个回收站的数据库对象，它用来存储用户删除（drop）掉的 database，table 等相关信息。

回收站在原理上说就是一个数据字典表，放置用户删掉的数据库对象信息。用户删除掉的东西被放入回收站，仍然占据着物理空间，除非用户手工进行清除（purge）或者对象定期被数据库系统删除。在数据库实现中，如果一个表被删除，那么与该表有关联的对象，如索引，约束和其它从属该对象的对象也会被放入回收站。从回收站恢复时对应的从属与该对象和有关联的对象也将被恢复。

在 3.1.3 之前的社区版 OceanBase 支持了回收站的功能，并默认开启，但是没有提供将回收站对象恢复的的命令；在 3.1.3 版本中，OceanBase 数据库开始提供 Flashback Tenant/Database/Table/Index 命令，该命令可以通过修改回收站对象的元信息，将该对象恢复到原始的位置，用户也可以通过 Rename To 语法将该对象恢复到新的位置（新的名称）。

通过使用这个命令，用户可以将误删除的对象恢复，降低误操作风险。

CDC 数据同步支持大事务

CDC 能够从 OceanBase 数据库拉取数据变更提供给下游消费，支持不同粒度的数据同步（集群、租户、DataBase、table ）且用户可以通过配置黑白名单来自定义同步规则。当前 CDC 配合 Canal、Flink、OMS 可以完成数据同步。

某银行在测试 CDC 数据同步时出现大事务 OOM 导致同步链接断开，数据可能无法正常同步的问题。分析该问题产生的原因是：归属于同一个事务的变更数据在被下游消费前会全部存储在内存中，当有大事务或者超大事务出现时，会占用非常多的内存资源，即使在流控策略下仍旧超出机器内存资源限制而造成系统异常，最终影响数据同步链路的稳定性。

为了解决该问题，新版本新增持久化模式，数据在同步开始前先进行本地临时存储，事务数据按行粒度发送到下游，待消费完毕后清理本地临时存储的事务数据。用户可以根据业务场景通过 working_mode 参数灵活选择内存模式和持久化模式。非大事务的数据同步建议选择内存模式，同步效率更佳；在大批次的超大事务 DML 操作同步时，建议选择持久化模式保证数据同步链路的稳定性，满足大事务场景下的数据同步需求。

实现 OB Operator

支持 Kubernetes 容器编排

OB Operator 旨在让 OceanBase 数据库可以以容器的形式运行在公有云或私有化部署的 Kubernetes 集群上。现阶段的 OB Operator 还是一个孵化版，具备基础功能的框架，后续还需不断地迭代与完善。

OB Operator 项目设计整体分三块：StatefulApp Controller、OBServer Controller 和 Operator Orchestrator（规划中）。

其中StatefulApp Controller 负责 Pod、PVC、PV 的维护，OBServer Controller 负责 OBServer 的维护，Operator Orchestrator 负责在多个 Kubernetes 之间管理 OB Operator（该模块尚未实现，欢迎社区开发者一起共建）。

图3：OB Operator分层架构图

用户可通过 YAML 或 Kustomize 部署 OB Operator，OB Operator 以服务的形式提供如下能力：

• 在 Kubernetes 环境下独立部署 OceanBase 集群
  
• 支持集群的创建、删除、扩容、缩容和生命周期管理
  
• 支持 Zone 的创建、删除
  
• 支持 OBServer 实例的创建、删除、重启、故障转移
  
• 支持使用 kubectl 命令查看集群、Zone 和 OBServer 的状态
  
• 支持通过 HTTP API 管理 Kubernetes 资源
  

后续版本将会逐步支持租户管理、OBProxy 管理、多 Kubernetes 集群等能力，帮助用户更简单便捷的部署管理 OceanBase。

结语

本次发布的 3.1.3 版本引入多模数据类型、JSON 支持、HBase 兼容等功能，进一步增强稳定性、易用性和部署便捷性，是 OceanBase 社区版的又一个重要里程碑。