OceanBase 2024 年开发者大会在上海闵行艾美酒店举行，这也是我第一次近距离参加 OB 的开发者大会，很高兴见到很多老同事和曾经的客户朋友。会场设计比较多样化，苦于没有分身技能，只认真听了上午的主论坛和下午的产品内核技术论坛。OB 每一个大的新版本从来没有让人失望过。新的名词、功能太多让我短时间内无法消化。这里结合会场小册子先做一个简单的分享，具体功能点以后再深入研究测试。所有观点都是个人观点，难免有误，欢迎交流。
多租户：不用关心资源隔离复杂度。多租户从 1.0 就开始有了，是核心能力早已为人所熟悉。可能有些客户对资源隔离有疑惑，从4.0 后架构上引入了 cgroup 的资源隔离能力（CPU/IO) 其资源隔离能力更强了。这句话应该是为了打消客户疑虑，以及为云上 OB 的产品宣传做铺垫。
多兼容模式：不用关心兼容性。兼容性也是租户的核心能力，早期 1.x 只兼容 MySQL，2.x 后开始兼容 ORACLE。此后就全力在完善 ORACLE 兼容性。这次兼容性介绍了 KV ，不是新功能，应该是功能加强，早期主要在蚂蚁内部应用。
单机分布式一体化：不用关心集中式/分布式选型。这个是上次开发者大会提出的。OB 的架构具备单机、多机部署，型态可以单副本单机部署、单副本多机部署、多副本多机部署。此外还有 DataGuard 方案。不同客户的运维基础设施的差异决定了部署需求的多样性。有些场景确实对 OB 有挑战，不过这些年 OB 也都一一满足，所以提出单机分布式一体化架构。不光能部署，性能方面也在逐步提升。有不少中小企业客户，机器资源不能那么富裕或者机房只有两个，两个节点或四个节点做 OB 集群的 DataGuard 常有。跟传统数据库 DataGuard 不同的是，4.1 版本后 OB 的 DataGuard 架构里主备的粒度是租户级别的。这样两个节点里的租户主备可以交错分布，最大化机器的利用率。这种场景可能是大客户（富有）体会不到。由此也可以看出 OB 在用户场景上也是充分听取了客户意见。
多工作负载：不用关心工作负载类型。这个指的是 HTAP 。虽然往年也提了这个，但这次却有质的变化。在以前的版本里 OB 擅长的 HTAP 严格说是 OLTP + R-OLAP ，简单说意思大概是支持交易数据库上的关系型的分析处理，并不适合 M-OLAP(基于多维数据的 OLAP ）。OB 4.3 版本发布了完全的列存和行列混合功能后，M-OLAP 这种业务场景也具备了在 OB 上运行的可能性。除了这个变化外，OB 还丰富了物化视图的功能，支持实时数仓建设的多个场景（如 ODS、DWD、DWS、ADS）。OB 的物化视图功能历史很久，从第一个版本（0.4就有雏形）。淘宝收藏夹中的查询取的就是物化视图的结果，那个物化视图就是基于两张大表（商品表和收藏表，数据量百亿级+规模，OB 集群规模 80+）。以前物化视图功能比较简单，现在是朝着兼容 ORACLE 的物化视图的目标做。具体使用效果如何以后再测试。所以，OB 现在对数仓能力的描述是将分布式 TP 的能力融入到 AP 场景中，做实时数据分析（实时数仓）。这套架构可以支撑 1TB~1PB 数据规模的数仓场景。不管当前实际能力是否真的如此（还需要更多客户案例），宣布这个目标也是表达了产品的一个决心和信心。这对于大部分中小企业客户都是非常有吸引力的功能。
多基础设施：不用关心基础设施。OB 从 1.0 开始就是一个软件包，只要操作系统支持就可以部署，对硬件类型要求倒不大。技术上来说物理机、虚拟机、docker、云主机都可以部署。蚂蚁内部早就在 docker 容器上积累了很多部署经验，阿里云上 OB 公有云也是跑在云主机 ECS 上。所以这个不是什么新东西，不过将这个提升到产品核心能力之一，也是为 OB 公有云策略服务。从“云下”物理机到“云上”虚拟机，OB 都可以。云基础设施的按需分配、弹性伸缩能力加上 OB 多租户的这两类能力，更能将 OB 云数据库的特性和优势发挥出来。会上 Gartner 的分析师也分享了以后数据库象限只看云数据库，而 OB 之所以有信心做这个以及全力去做这个，就跟这个能力有关。当然，要跟现有的云数据库 PK 性能和成本，困难和挑战也是不少的，这个就拭目以待了。
多模型：不用关心数据架构。这个应该是第一次提出这个概念。意思是指 OB 不光支持关系数据模型，还支持 KV、时序、JSON、XML、GIS 、LOB 等结构。OBKV 已经有多年了，以前是不怎么宣传，应该很成熟了。JSON 、XML、LOB 类型早就有了，现在应该是相关函数更丰富了。GIS 在 PG 数据库中是一个亮点，OB 也开始补齐这个功能。个人认为是 OB 在补齐了相关非关系型数据类型的功能后正式提出支持多模型这个概念。之所以要这么久是因为在关系数据库里做多模，对 SQL 引擎、存储引擎都是很大挑战。关于多模的使用 OB 研发分享了 OB KV 跟 Redis 的选型经验。OB KV 倒不是说要替代 Redis 产品，业务场景中 有 20% 的场景是 Redis 产品才能做到的（如严格稳定的低延时要求，如微妙级别）。OB 支持多模是为客户提供了一个新的选择，有些非关系型数据库的需求也有可能在 OB 里就满足，这样客户就不用专门去部署运维一个 NOSQL 数据库。毕竟不是所有的客户需求都是要求严格的低延时。OB 突出多模能力也是为公有云策略做铺垫。所有的云数据库产品（关系型或非关系型）恰好都是按需分配（一分钱一份能力），在云上一个数据库如果能支持多模场景，客户就很可能不用买多种类型云数据库产品。
据现场 Gartner 分析师的分享，近些年全球数据库市场每年增长的份额，绝大部分是来自于云数据库市场的增长。中国有自己不一样的云环境（中国特色），云数据库蕴含着很大的机会。主论坛的多个分享都在明示 OceanBase 公有云的机会和决心。
旁路导入：性能增强，同时也支持客户端导入。以后还考虑增量数据的旁路导入。这些在 TP 场景偶尔做做，但是在 AP 场景的实时数据仓库里，是常用的操作。
事务&日志优化。除了优化事务日志量（降低跨节点同步带宽）外，还有提升 PDML 并行执行的能力。全表更新数据可以用 PDML，这也是实时数仓经常用的功能。
租户的快速克隆。就是生成一个租户的快照并复制出一个新的租户，克隆时只复制租户源数据生成新的租户元数据，数据不克隆。只有在原租户或新租户数据发生变化的时候，才会衍生出新的数据版本。这个技术在存储方案里叫 COPY ON WRITE，是存储快照常用的方案。LSM-Tree 架构的数据库做这个简直是太适合不过了。估计是排期到现在才推出这个功能。这个功能不会对 OB 现有功能带来影响，唯一的要求是为克隆出来的资源预留相应的资源（规格可以自定，不过数据容量要稍做预留。根据可能发生变化的数据量去评估，最大就是评估一个租户的完整的数据量）。容量这块属于运维要关注的，这个功能出来后，OB 的容量规划评估会变得更加复杂，对运维人员的要求会更高。
更强大的OLAP 实时分析能力。这个才是这个版本最大的变化，源于 OB 多项技术的发展，包括高级存储功能（列存和行列混合以及在线转换、索引也支持列存）、OLAP SQL 引擎性能的进一步提升、数据集成能力（旁路导入+外部表+DBOLLink）、AP计算能力（物化视图以及各种 OLAP 用到的复杂的分析/窗口/统计函数等等）。还有并行向量化技术（向量引擎 2.0 版）。这块总体上都属于新功能，后面再逐步测试了解。
兼容和易用性能力。开始考虑到MySQL 的BI 生态场景需要的功能，以及 ORACLE PL/SQL 在数据仓库建模的场景。在白屏部署时会推出 OLAP 参数模板（很多用户 OB 性能做不到官方测试的那么好 ，其困难之一就是参数不知道怎么设置）。还有一个索引使用监控功能。这个功能对开发来说还是很实用的。数据库给出的建议实用性取决于其 SQL 引擎的智能化程度。 不用严格的要求它的准确性，这个功能从无到有，对 OB 数据库的开发体验会提升很多。易用性还包括 OB 的binlog 兼容能力，提升下游生态使用 OB 的能力。
第二个是开发者做的基于 OB 和大模型开发的演示版 DB-GPT。演示的是导入一批文档文件，然后程序解析文件后很快就能构建自己的知识库，用户可以就知识库中就相关技术提问。希望 OB 社区论坛和文档产品能快点用上这个技术。
这个原理据说是使用了 OB 的向量化引擎，实现 SQL+AI 一体。不明觉厉，等以后 OB 社区团队的分享。
