以一个"外行人"视角，聊聊OB开发者大会

前言

又是一年一度的 OB 开发者大会，应主办方邀约，我也前往上海参加了此次饕餮盛会，昨日满满一天的议程，全程参与下来，给我的感触是——支棱起来了，OB 越来越能打了。

成功混入O圈

首先聊聊观察团，这次"观察团"来了大概十几二十人的样子，清一色的 Oracle ACE，唯有我一个 PG 系的，看样子笔者成功打入了 Oracle 圈子！🤪

近年来，以 OB、PolarDB、TiDB 为主的国产数据库熠熠生辉，发展迅猛，笔者对 PG 系生态十分熟悉，但是其他系的生态倒是了解甚少，我对 OB 的认知还停留在"单机分布式一体化"、"小鱼"时代，因此，此次能够以一个观察员的身份参与 OB 开发者大会，实属一个难能可贵的学习机会。

此次大会除了产品技术专场、技术生态专场、创建实践专场等之外，还开设了一个特别有意思的 "O 伯乐有话说"，由盖老板、白鳝老师、林春老师领衔，一小撮人围坐在一起，听诸位前辈聊他们的履历、几十年的 DBA 从业经验，以及对于当下恶劣的大环境 DBA 如何破局等等，不管是打鸡血还好，还是纯听一乐，总之，多听听前辈们的经验之谈总是没有坏处的，可以少走很多弯路。

看我早早就占据了黄金最佳位置😎，怼脸拍

白老师戏谑地说道，最开始的 Oracle 很烂，难用、复杂、装库装半年... 那白老师又为何会从一名 C 的大牛程序员转行 DBA 呢？没错，掌握了一项别人不会的技能，我就比别人多了一个吃饭的本领，可能也是这个想法驱动着入了这一行，并且一干就是三十年，实乃佩服。

盖老板分享了一点他的经验

兴趣 + 勤奋 + 坚持 + 方法 ≈ 成功

眼光 + 坚持 + 能力 ≈ 成功

确实，兴趣十分重要，以我个人经历来说，因为我对 PostgreSQL 十分感兴趣，因此我有时会为了一个问题研究到凌晨，有时也会为了一个无法解决的疑难杂症而急得抓耳挠腮，这一切都是兴趣使然。其次，便是勤奋 (内卷) + 坚持 (唯有时间是最公平的) + 学习方法论，总之，要找到最适合自己的方式。

多模一体化

聊完了插曲，让我们回到主题，此次 OB 开发者大会正式发布了 4.3 版本，探索 TP + AP 融合、一体化、多模处理等场景，并且就未来的发展进行了展望

可以看到，现在的数据库都在向着一体化、融合的场景发展，所谓合久必分分久必合，one size fit all，旨在通过一个数据库解决用户多样的场景，将简单留给客户，降低技术栈复杂度。

其次，OB 还有一个很强大的优势在于其兼容性，既支持 MySQL，也支持 Oracle，两种形态的数据库甚至可以同集群部署，同 OCP 纳管，这就十分灵活与方便，毕竟当下，Oracle 和 MySQL 还是主流，体量也很大 (虽然不愿承认此事实，作为一个 PG 系的忠实老油条，看到 OB 的这一项能力也只能在惊讶感叹之余，竖以大拇指以表敬佩)，此项能力无疑可以大大降低使用与迁移成本。

另外，OB 还有一项很新颖的能力，租户级实例，与我们常规认知里的实例不同，一套集群下，可以部署一个 MySQL 的租户，还可以部署一个 Oracle 的租户 (租户模式，当然就可以做到资源隔离，隔壁 PG 老粉哭死在厕所)。

另外 4.3 版本还支持了租户克隆的功能！这个功能十分吸引我，比如你想快速验证一个功能，又不想影响现有业务，那么快速克隆一个租户即可；其次，类似备份、BUG FIX、升级等等，都可以使用租户克隆，十分 nice 的能力。

在 PostgreSQL 中，有一个类似的产品——neondb，支持分支功能，顾名思义，可以像 github 一样，快速拉一个分支出来，在自己的分支上做自己想做的事情，然后一样可以 MERGE，不过 neondb 的数据是放在对象存储上的，所以 neondb 的分支功能基于存储复制。那么 OB 的租户克隆是如何实现的呢？

下午的产品专场我特意去听了一下租户克隆的实现原理

大体上，租户克隆通过复制元数据 + REDO 回放到指定 GTS (Global Timestamp Service)，不过这类实现的缺点不难想象，假如克隆期间进行了大量写入，主租户会产生大量的 REDO，那么克隆租户可能一直在追赶到指定 GTS 的过程中，而无法恢复到指定时间点。当然，这个理论是基于我对 PG 的认知，不知 OB 是否有诸如并行回放、RDMA 之类的加速回放方式？

在议题结束时，我还特意问了一下这个问题，不过讲师并未有过多提及，只是说

基于生产经验，大多数三到五分钟即可复制成功

或许有什么不为人知的黑科技，亦或是目前还未解决这个痛点，希望后续有更多的内幕细节讲解。

其次 4.3 版本还支持了单机模式，不同于以往的单机分布式一体化，单机模式就很纯粹，副本也是一份，这样的话，对于纯粹极致的 TP 场景，就可以减少多副本共识协议带来的性能损耗，另外单机模式也可以实现传统主备的功能，得益于 obproxy，以及去中心化的这种实现方式，可以无需类似 VIP 这样的实现方式，当发生了 switchover/failover，对于业务来说，几乎是无感的。

当然目前的单机引擎也还是基于 LSM，现在唱衰 LSM 的声音越来越多，归根结底还是硬件发展起来了。在原先的机械盘时代，leveldb/rocksdb 的最佳实践就是一个磁盘只有一个写入源，所有的写请求都由这一个线程递交。现在的 NVME 动辄百万级 IOPS，几十 GB 的带宽，并且还在不断革新中，在产品专场也有一位讲师大概讲了一下 LSM 的优化，比如减少合并时带来的延迟和影响等，持久化的整体思路是 LSM，但在内存里其实会维持 BTree 来加速读取过程，目前很多基于 LSM 的分布式数据库往往都是依靠并行扫描的方法，多个打一个的方式，勉强和传统 BTREE 结构的集中式数据库打个平手，期望后续单机模式的存储引擎能继续深耕性能优化，以及在 SSD 时代，如何更进一步，或者支持多样化的存储可插拔引擎 (是否要求太过了？hhh，提就是了)。对于纯粹的 TP 场景，存储引擎至关重要。

OB 还有一项优势是急的我直痒痒，表组：多个表中的数据可能会分布在不同机器上，在执⾏关联或跨表事务等复杂操作时就要涉及机器间的通信，分区⽅式相同的表聚集到⼀起形成了表组，表组内每个表的同号分区成为⼀个分区组；OB 在分区创建以及之后可能发⽣的负载均衡时，会将⼀个分区组的分区放到⼀个机器，这样只要操作数据所在的分区属于同⼀个分区组，就不存在跨机器的操作，对于 Greenplum 的同学来说，对于重分布和 MOTION，真是闻者伤心。

小结

感谢 OB 主办方，提供了一个这么好的平台，既可以吃吃喝喝，又可以发散视野，了解了解其他赛道的数据库，快哉快哉，从 OB 目前的发展态势来看，OB 确实在当下国产数据库中属于佼佼者。

也祝 OB 后续能够持续精进，更上一层楼。