3月的社区月报分享了 OceanBase 4.1 版本的五个重要特性：易用性、内核能力提升、性能持续优化、MySQL 兼容性、企业级高级特性，大家可以进入《OceanBase 4.1 更新了哪些新功能？》查看详细内容。本文将和大家分享本月发布的 3.1.5 及 4.1 版本的核心功能及社区后续规划。
OceanBase 3.1.5 版本发布
4 月 19 日，OceanBase 3.1.5 社区版正式发布。该版本着重提高内核稳定性，特性上 OBKV 支持了基于热 key 的限流，OBCDC 通过架构优化降低了对使用者机器的资源要求。同时为满足用户对大宽表的期待，将单表列限制从 512 列优化提升至 4096 列。针对用户反馈及内部测试发现的问题，该版本也重点进行了修复。
稳定性强化
自 3.1.4 版本发布以来, 迄今已经有 10 个月, 我们将企业版 3.x 过去10个月出现的严重bug 做了一次集中移植, 在稳定性上做了大幅优化, 推荐 3.x 的社区版用户升级到3.1.5. 例如, 我们在以下三个用户场景中, 做了一些修复：
场景2：在钉钉云盘场景中, 用 JSON 生成列来创建索引时，出现内存爆掉的问题。
场景3：某大型保险国企。该企业在某日对超大表进行了海量更新后, 夜间合并时出现合并卡住问题, 提示 buffer not enough。
AP 能力强化：单表支持列数上限从 512 提升至 4096列
在 OLAP 领域，越来越多的用户通过大宽表的设计减少多表之间的关联操作，来提升数据库的查询和处理能力，随着这种场景越来越多，就需要支持越来越多的列，我们也收到了一些用户的反馈：希望 OceanBase 支持大宽表。
之前贵州双龙曾反馈，当他们在迁移 ClickHouse 大宽表时，由于 OceanBase 3.X 版本只支持 512 列，而他们的数据已经远超 512 列，他们就只能通过修改业务逻辑来拆分大宽表，来满足 3.X 版本 512 列的限制。同时，在龙江银行做 POC 的过程中，也在创建大宽表时报无法创建更多列的失败.......
于是，OceanBase 3.1.5 版本支持了这种特性。将单表支持列数上限提升至4096列，通过大宽表设计，减少多表间的关联操作，提高该场景下数据库查询性能和数据处理能力。
需要特别注意的是，有主键表可以支持指定 4096 列，当无主键表时，由于系统生成隐藏主键会占用 1 列，用户只可以指定 4095 列。
生态强化&稳定性强化：对 OBKV 热 key 限流
蚂蚁集团内部有大量的 HBase 业务，部分业务下会有一些热点的商家或用户进行高频访问，我们需要对这些高频访问做限流。
具体逻辑为，增加限流阈值设置，通过统计当前 QPS 最大的 K 个 rowkey ，在很小的时间内，是否超过阈值，以此来决定是否执行限流。详细流程见图 1。
易用性改进
1、CLOG 日志文件支持按绝对值限制存储空间
早期 OceanBase clog 日志文件的存储空间阈值仅支持按照磁盘空间百分比进行限制，缺少直观性；同时当数据目录和日志目录在同一块磁盘下时, 容易引起磁盘打爆问题, 也无法准确表达使用空间水位大小。3.1.5 社区版本在之前设计的基础上，支持使用空间绝对值限制的方式，替换固定磁盘规格限制，更灵活和易用。
- log_disk_size：用于控制单台 observer 存储 clog 日志文件的最大空间使用量。
2、OBCDC 性能提升20%
- 架构进行了优化, 同步性能提升20%, 减少内存使用，从而让整个系统对资源的消耗量会变小。
3、python django 框架适配
- 新增支持 default_storage_engine 系统变量，默认“OceanBase”能够适配 django。
在 3.1.5 版本，修复了 30 多个严重 Bug，详细的特性更新，大家可以进入 GitHub Release Notes 进行查看。
OceanBase 4.1 正式发布
4月20日，OceanBase 4.1 版本正式发布，这是一个面向开发者的里程碑版本。4.1 版本在 4.0 基础上性能进一步提升，完善功能的同时增强稳定性，在内核能力上对分布式事务和存储进行了大量优化，同时我们也推出了很多对开发者非常重磅的功能，包括 GIS、JSON、增强 LOB、租户级主备库等。
图 2 OceanBase 4.1 版本功能
经测试，OceanBase 4.1 相比 4.0 版本有很大的性能提升，小规格场景 Sysbench 综合读写能力相比 4.0 版本性能提升 40%，通过优化计划生成能力、支持更多的算子下压、增强查询改写，OLAP 的场景性能提升 15% 以上。4.1 版本还实现了开发者群体期待的旁路导入功能，通过旁路导入，数据导入性能比 4.0 版本提升 6 倍。OceanBase 也在持续完善 MySQL 8.0 的兼容性，在新增内核兼容功能的同时还新增 MySQL Binlog 协议的支持，帮助用户更方便地把数据库接入到下游的 MySQL 生态。
OceanBase 4.0 版本在业界首次提出机器宕机时数据库的恢复时间小于 8 秒的能力，即 RTO < 8 秒。在数据库的实际运行环境中，出现的异常情况不仅是机器宕机，还会出现网络中断、IO 异常甚至是数据库进程被中断等。另外，出现异常的也不一定是数据库机器，还有可能是路由层 OBProxy 所在服务器。异常情况的处理不仅要考虑通常 TP 业务的并发事务执行场景，也要考虑执行 DDL、数据加载等运维场景。
新版本中，我们继续完善了故障恢复能力。以用户实际遇到的多种类的异常问题作为优化目标，打磨每个模块处理异常的细节，让上述提到的各种异常情况发生时，数据库的服务都能在 8 秒内恢复，给业务提供更强的持续可用能力。
在易用性上，OceanBase 4.1 也进行了优化和改进。提供了快速安装部署，支持白屏化安装，让用户能更简单直接的安装一套 OceanBase ，降低出错概率。支持管理工具（OCP Express），让用户以极低的资源成本完成便捷高效数据库运维管理工作，在满足数据库基础管理和数据库可观测性的同时，大幅降低了 OceanBase 数据库图形化管理的使用门槛。
这次发布的是 4.1.0 正式版, 内部做了大量的 bug fix, 对很多内部的测试场景中出现的 corner case 进行了 bug fix.
图 3 4.1正式版 Release
5 月产品规划
5 月份我们将继续强化 OceanBase 的产品力，主要表现为优化内核、升级工具。
在内核层面：OceanBase 4.1.0 BP1 版本将会在 5 月 8 日正式发布，这也是正式版后的第一个 BP 版本，该版本仅在内核上做 bug fix，不会做任何新的 Feature 开发，保证大家能够原地升级。
在工具层面：我们会提供 OBD 2.1.0 以支持大家从 4.0 升级到 4.1 版本，也对白屏安装的易用性进行了改进，同时 OCP Express 支持从 1.0.0 升级到 1.0.1 版本，考虑到安全问题，我们也对安全特性进行了整改。此外，OCP Express 发布了 1.0.1 小版本，适配 OBD 的升级，同时，在 3 月 25 日开发者大会后，我们将 OCP Express 提供给很多用户使用，根据大家的反馈，我们做了大量的 bug fix，在 5 月 8 日发布的版本中，这些问题会得到很好的解决。
出于使用体验的考虑，我们衷心建议：使用 3.X 的用户可以升级到 3.1.5 版本，对于使用 4.X 版本的用户，建议在4.1.0 BP1 版本发布后（5月8日后）再进行升级。
4 月社区进展及下月规划
4 月 15 日，OceanBase 在跨越速运总部，围绕“如何构建高效的物流行业实时数仓数据系统”开展技术交流，吸引了诸多对开源、数据库、大数据感兴趣的专家学者，并在现场就高可用＆高性能实时计算解决方案展开了激烈讨论，精彩观点频出。详细内容可以进入 OceanBase 社区博客进行了解。👉 《OceanBase 走进跨越速运，共话物流行业实时数仓系统》
我们会在五一劳动节后的每周四 19:30 举办开发者周会（如遇节假日顺延），和大家交流 OceanBase 内核及生态工具的最近进展，我们也非常欢迎大家参与到社区的建设和开发中来。同时，我们也会将每月一期的 Monthly Report 和开发者周会进行合并，每月最后一期的 Weekly Report 为 Monthly Report 。
