“成年人”的数据库，既要又要也要！

欢迎访问 OceanBase 官网获取更多信息：https://www.oceanbase.com/

---

3 月 25 日，第一届 OceanBase 开发者大会在北京举行，《明说三人行》访谈栏目创始人兼主持人卢东明、沃趣科技创始人兼 CEO 陈栋、DBAplus 社群联合创始人杨建荣、PostgreSQL 中文社区主席 张文升、OceanBase CTO 杨传辉在主论坛进行了 《数据库领域，有哪些最值得开发者和用户关注的创新与技术》 的圆桌讨论，共同探讨了单机分布式一体化、HTAP、多云原生等众多关于分布式数据库的热门话题。

以下为圆桌实录：

单机分布式一体化是未来趋势

卢东明：请用一句话、三个标签来介绍一下自己和所做的事情？

杨传辉： 工程师/开发者；单机分布一体化；性价比。

​

陈栋： DBA；创业；一体化。我们从数据库、软件、硬件，即整个系统一体化的方式给客户提供开箱即用的解决方案。

​

杨建荣： DBA；技术社区；技术分享。

​

张文升： PostgreSQL；开源社区；布道师。我最重要的标签就是 PostgreSQL，我认为哪里有 PostgreSQL，哪里就有我。

从左到右依次为科技访谈栏目《明说三人行》创始人兼主持人卢东明，OceanBase CTO杨传辉，沃趣科技CEO陈栋，dbaplus社群联合创始人杨建荣，PostgreSQL中文社区主席张文升

卢东明：针对 OceanBase 最新提到的“单机分布式一体化”一词，在大众印象里“单机”与“分布式”是割裂分开，为什么 OceanBase 会将他们组合起来？

杨传辉： 我很喜欢“单机分布式一体化”这个词。其实最早在 2021 年年底，它叫集中式分布式一体化。但后面我们觉得不是特别直观，所以改成了“单机分布式一体化”。

确实，很多人脑海里觉得“单机就是单机，分布式就是分布式；主流就是单机，大规模就是分布式。 ”而单机分布式把两类系统的产品特性以及技术优势融入到一个系统里面，对用户来讲很方便，用户不需要做选择。正如主持人所说，我们是成年人的数据库，这个比喻我很喜欢。

但这里有一个难点，有什么样的技术手段能够达到这样的效果。第一，当从单机到多机之后，功能不能损失，对用户来讲，它基本看起来没区别，但是仅仅功能不损失也没有用，如果性能一下子降下来的话，意味着一体化不成立。前面我在分享里面也讲了很多 NewSQL 的案例，一到分布式单机性能掉到原来的 1/5、1/10，这个没有办法既要也要。

OceanBase 能够做到性能也不损失，并且保证功能和扩展性核心的原因，在于我们做到了分布式数据库里面的每台机器没有分布式相关的 overhead，动态的单日志流技术，是动态绑定的模式。一开始每台机器只有一个日志流，数据动态绑定到这台机器的单日志流，可以做到单机性能不损失，这是我们讲的核心概念，同时我又能做到功能完全无缝兼容，性能没有损失，这就是“成年人的数据库”。

张文升： 根据过往的经验，如果把分布式系统当作单机系统去用，比如部署到一个机器上，它的性能会有大幅度的降低。这个问题如何解决？或者怎么突破这个瓶颈？

杨传辉： 早期的支付宝，有很多 Oracle 的 DBA，他们表示：当 Oracle 打开强同步时，性能降低 35%，这个数据是以前支付宝的 Oracle 的 DBA 测试出来的。而为什么分布式应用到单机会出现性能损失？因为分布式要做高可用、强同步的容灾开销。分布式做可扩展，因为扩展性带来的开销、强同步带来的开销，采取异步写 Redo Log 的模式，使得 OceanBase 强同步的方案性能损失控制在 8% 以内，其它地方做一些优化，同时具备强同步，并且不损失性能，这在以前的单机数据库基本做不到，因为底层的架构发生了变化。

采用单机分布式一体化的可扩展方案后，每台机器只有一个日志流，尽管后台需要占用一些网络、CPU 等，但对前台的交易和 TP 性能没有影响。

杨建荣：对 DBA 来说，从单机到分布式一体化这种层面来说，涉及到哪些操作上有什么变化？对整个系统有什么样的影响？

杨传辉： 我们很多开发者、DBA 等之所以提单机分布式一体化的概念，是因为在单机分布式一体化理念下，首先要求对开发者、对 DBA 是透明的，扩容操作由数据库后台实现，对以前的业务及应用协议没有影响。虽然数据库扩容了，但可以通过动态路由来自动找到机器原始数据。 因为底层架构是分布式，所以扩容后是全部支持上层功能的。 而原来单机的产品无法做一体化的原因是原来的 SQL 引擎是为单机设计的，换成多机的话很多功能支持不了。

陈栋： 我非常认同 OceanBase 对单机场景的关注。从我接触的用户需求来分析，单机场景更为大众化。因为对于大部分的企业用户而言，可能单机已经足够业务所需。如果一上来就用分布式系统，那么门槛相对较高， 在“软硬一体化”趋势下，硬件发展核数越来越多，可扩展性的内存、吞吐足够大，结合硬件能力，再加上数据库在单机上性能开销的优化，未来在大众化场景的适用面、接受度将更强。 因此我认为，OceanBase 往单机的思路上走是特别棒的。

陈栋：那么在单机分布式一体化概念下，OceanBase 是更注重单机还是更注重单机到分布式的扩展性？

杨传辉： 我们原来就是做分布式数据库，已经把分布式架构都搭好了，每个开发者一开始想到分布式数据库，肯定认为这个东西使用门槛比较高，我们想要做的一体化架构其实就是降低分布式数据库的门槛，所以如果回答刚才的问题，我认为是第二种， OceanBase 更多还是考虑从单机怎么扩展到分布式的扩展使用场景。

一个企业像它的发展旅程一样从小到大，今天是单机，明天乃至未来可能会去扩展。当有了单机分布式架构之后，在需要去扩展的时候，无需把数据库打包重来（应用重新写一遍），我们只需要一开始就选择像 OceanBase 这样的单机分布式一体化架构就好，这是我们最早的初衷。我也认为这种架构以后的应用场景会越来越广，成本降低的同时，做到了单机性能和分布式性能相当，与此同时又有一个额外的面向未来的能力。

陈栋：把方便留给用户，把麻烦留给自己，这个思路是用户思路，但从单机到分布式的过程是一个重大操作，不是一个高频交易，但从数据库的设计角度来说，这个投入是非常大的，你怎么看这个投入回报？

杨传辉： ROI 是 OceanBase 做单机分布式一体化架构设计里非常重要的考虑因素。成年人的数据库，没有太多需要选择的地方，OceanBase 一开始就是分布式架构，由高往低走去做优化，本来就是我们要去做的事情。但如果原来是单机数据库，要变成分布式就需要增加一个数量级的复杂度，这个方式基本是不可能的， 一个小的场景投入更高数量级的复杂度，没有任何人会做这样的选择。 比如特斯拉一开始是 Model X、Model S，后来 Model 3，从高到低这是不可能的。

分布式技术做起来的复杂度太高了，OceanBase 做了 13 年，但仍然还是有好多的用户体验需要不断优化。

张文升：假设我是一个后端开发团队现在要使用 OceanBase，在做数据库规划的时候，刚开始业务很小采用单机模式，等到业务发展到一定阶段，我会把单机模式调整到分布式，这个调整过程如果照以往使用过的产品，有可能我得去换很多驱动和更改配置等，这中间会对业务造成很大影响， OceanBase 是否有更简洁、更方便的切换方式？

杨传辉： 关于这个问题有两个方面：假设我使用数据库不追求极致性能，驱动、应用都不需要改；假设要追求极致，理论上如果后端发生变化，有可能有一些调优空间。如果不做极限调优是一样的，因为后面有更多的服务器，连接是不是改大一点，或者原来没有写自适应的连接这样的东西，可能需要做一些简单的配置，如果不追求极致，没有关系的。

一项技术它能解决很多问题，但是不会有一项技术把以前开发遇到的所有问题全部解决掉，当你想达到极致时仍然需要我们的 DBA，需要开发者对更高深的数据库知识的掌握，才能将技术发挥得更好。

数据库发展离不开场景需求

卢东明：OceanBase 已经在分布式数据库的路上做了 13 年，但从分布式做回到单机，居然比传统的单机数据库 MySQL 性能做得好，这个能否解释一下？

**杨传辉：**当分布式往单机做的时候，首先要避免没有分布式的额外开销，得站在一个水平线上跟它比；接下来是在同一个水平线上，如何做得更好，这里很多时候就是大家怎么做 CPU、单机性能优化的问题。

第一，OceanBase 的存储引擎相比 MySQL 有两个比较好的点，MySQL 是 B+ 树的存储引擎，而 OceanBase 的存储引擎是 LSM-Tree 引擎，并结合了 B+ 树，可以说是站在 Oracle 和 MySQL 的基础之上全新设计的引擎。这样一来，存储成本会比较低，甚至能在 OLTP 业务里面做在线压缩，以前的单机数据库基本很少开启在线压缩，因为一开启，性能就会下来。

第二，我可以把大部分最高频的操作（LSM-Tree）全部在内存里面进行，在 B+ 树里做数据分块，使得我能将降低写入放大的技术融合在一起，最终才能在引擎层面改变，增效降本，所以 OceanBase 的存储引擎是 B+ 树结合 LSM-Tree 发展起来的东西。

卢东明：有没有跟 Oracle 去做对比？

杨传辉：对于简单的读写，MySQL 和 Oracle 在一个水平上，但在测 Sysbench 上，OceanBase 还是有优势。Oracle 有些地方比 MySQL 做得更好，比如多核扩展能力，这部分 OceanBase 也做得不错，两者在可扩展性上，处于同一个水平。

另一方面，Oracle 在复杂查询上做得非常好，坦率来讲，虽然今天 OceanBase 的多核扩展能力、简单的读写已经可以比肩 Oracle，有些地方甚至更好，但在复杂查询上我们比 Oracle 有劣势，在今年的 Q3，我们将花很大的精力优化复杂查询的性能。在当下的开发者和 DBA 中，写真正的复杂查询的人少之又少，简单查询可以覆盖大多数场景，但也不可避免很多需要进行复杂查询的场景。

在中国的一些行业应用场景下，比如运营商场景，往往复杂查询和高并发兼备，很多传统集中式数据库里的复杂查询的打磨，靠的就是中国的运营商场景，所以数据库要做好，很多时候都要靠应用的打磨，靠应用驱动技术创新。 所以在原理上，OceanBase 跟单机数据库在同一个水平上，在第一类最常见的场景上我们已经优化到较高的水平，但在其它更广泛的场景下我们还需要时间，根据具体的业务需求来打磨优化，再过几年，我们就能更有自信地说在很多场景都可以做的很好。

张文升：OceanBase 曾说站在巨人的肩膀上尊重经典架构，在新的产品 Roadmap 中也提到未来在 HTAP 概念上会往这个方向去走，如何让多表、大表关联查询的优化器做得更好，这个是不是接下来非常挑战的一件事？

​

杨传辉： 大表查询有两个方面，一是像 Oracle 只在一台机器上进行大表查询，二是在多台机器上的大表查询，后者更麻烦。虽然 OceanBase 提了一些概念，比如单机分布式一体化、HTAP，但我们做 OceanBase 十几年，想做的东西从来没有变过。阳老师曾提了一个更简单的说法—— 可扩展的 Oracle，一句话就把所有的今天我们讲的单机分布式一体化、HTAP 都涵盖进来了。

事实上，Oracle 在单机层面，就将简单查询、复杂查询的问题都解决掉了，唯一没做好的就是扩展性，以及成本还有可优化的空间。我们在它的基础之上，把扩展性做好，原来的单机变成一体化，这个就是我们的理念。虽然我们在有些方面已经超过了 Oracle，但还有很多可以进步的空间。

OceanBase 的应用场景中，比如“双 11”的高并发场景肯定比 Oracle 做得好，但 Oracle 在全球应用场景的丰富度以及一些比较少见场景的解决方案，是其它数据库都达不到的。我们说可扩展的 Oracle，它的核心是分布式、可扩展，有点像是降维的意思。比如像特斯拉做了电动车，电动车里面的电池就有点像分布式的技术。我们有了新的分布式引擎，能去做特斯拉的产品，但怎么让这个坐舱更好用、更好看、流线型等等，我们还是可以借鉴一些原来的做法。

​

卢东明： 真正能够颠覆某 Oracle 的一定不是一个更好的 Oracle，很可能是一个更好的 OceanBase。按照 Oracle 的路径去优化，试图去超越它，这点是很难的，而 OceanBase 正在跳出它的框框，这值得我们期待。

做开发者喜欢的数据库

卢东明：你认为开发者喜欢什么样的数据库？

​

张文升： 我就说一个开发者可能会很喜欢的，功能够用、简单好用。

​

杨建荣： 我补充一点，社区前段时间做了一个调研，开发者对于整个分布式数据库的需求，整合以后我们提炼出“4+1”模型。大家其实对于分布式数据库的选型有四个点比较看重。一是切入点，开发者比较关注可扩展性，但是对于整个分布式数据库的选型中第一看中的就是稳定性。

另外就是对于整体成本这块也是比较看重的。不光是有硬件成本，还有对于整个研发接入使用成本。第三，对产品的功能还有易用性比较关注，尽可能跟主流的技术栈能做一个兼容。第四，OceanBase 相对有优势，对 SQL 的协议，很多公司有Oracle、MySQL 多种技术栈，如果有这样一种协议的兼容，对它的研发接入更简单。

张文升：从我们接触的客户来说现在有一种趋势，由于业务越来越复杂，客户会倾向于不同的业务场景，在这个细分的业务场景下有没有更好的数据库功能或者数据库解决方方面面所有的场景需求问题，比如像图、时序、向量、多模态，在这方面 OceanBase 有什么规划吗？

​

杨传辉： 今天 OceanBase 的 HTAP 暂时还不能把离线分析 100% 解决掉。我比较认同周傲英教授讲的观点： 从“One size fits a bunch”做起，做得好再演进到“One Suite fits all”。 比如 HTAP 可能会设置 OLTP 加在线分析，但是如果在“图”的场景下就不一定完全适合，也许可以基于 HTAP 做一些 key value、多模，但太远的模型也做不了。当系统做得特别好的时候可能是一个套件，里面有多个引擎共享的产品，HTAP、离线 AP 等等，此时借用分布式、高可用的能力一次性解决了所有的需求，从而避免了额外的研发投入。

​

陈栋： 您这边是站在数据库的视角，从我们的视角来看，为了解决客户选型的问题，我们做数据库的PaaS平台，十几种数据库在这上面进行全生命周期管理，这也是一种方式。

​

杨传辉： 是的，这个方式也非常好。技术包括产品一定是有很多不同的模式，只要能满足用户需求，理论上都是合理的，而且会共存。

卢东明：数据平台这个概念提了好久，那么各种各样的数据库或者技术怎么样有机地融合到一个平台上？

​

陈栋： 从这个角度来讲我们也是一个开发者，希望数据库可以更加开放，可以包罗更多的 API、更好的文档，更友好，让类似我们这种生态公司可以使用数据库把客户服务好。

​

杨传辉： 数据库的发展很多时候不只是厂商，而是 厂商+生态+开发者+用户+应用 的场景。

卢东明：大家都知道开发者也好，DBA 也好，比较头疼的是数据库底层出故障，从开发者角度来看，别让我去懂那么多 DBA 的事，只要结果稳定、顺心，这个也是我们所说的“成年人的数据库”的一个需求，那么你如何看待这种趋势？

杨传辉： 成年人的数据库正在往多云的方向发展，把一些复杂管控的工作交给后台。多云、混合云未来肯定是一个趋势，我非常看好多云原生。

陈栋： 除了多模还有多云部署的问题，客户面临的是多种数据库和多云的乘法复杂关系。相对传统的单机非常简单，现在又有分布式又有各种场景，非常复杂。我们作为平台的开发者视角来说，希望数据库更加友好，同时我们也想基于云原生技术框架可以跟更多的云厂商去做很好的适配，来帮助数据库来解决多云部署问题。

杨建荣：从研发的视角来看有一种困扰——事务，对于 SQL 来说，事务是很核心的点，事务对于研发有一种困扰，基于中间件的分布式集群或者说一些 NewSQL，基于分片，业务又有可能多分片的需求，OceanBase 是单机分布式一体化的实现方式，在事务这块的支持上和单机上是完全兼容透明的模式吗？

​

杨传辉： 单机分布式一体化那个话题，刚才说的应用透明，不仅潜在路由、SQL 语句、语法是透明的，后面的事务处理也是透明的。当事务涉及到所有数据都在一台机器上的时候，可以想象为一个单机数据库的事务，当涉及到多台机器时就走分布式事务的逻辑，有两阶段提交的操作，这是为什么那另外 20% 有性能下降的原因，因为涉及到了远程网络。

什么才是真正的HTAP

卢东明：HTAP 是现在挺热的一个词，中国有将近 260 个数据库品牌，叫各种各样标签的都有，HTAP 标签的数据库也很多，从 OceanBase 的角度来讲，我们提的 HTAP 和广泛意义上大家提的 HTAP 是不是一个概念？

​

杨传辉： 今天我们说的 HTAP 甚至包括 OLAP 这个词都没有明确的定义。

我会把 HTAP 分成三类：第一类走极端的并集路线，TP 也行，AP 也行。第二类做交集，产品本身 TP 能力和 AP 能力单独去看都比较弱，交集在一起时能做一开始没有覆盖到的一些场景。第三类就是 OceanBase，一种自然衍生的思路，有点像 OLTP+在线分析的能力，即 OLTP 加上 TP 与 AP 的交集，前者是应用系统核心，如果连应用的核心能力都没有的话，这种 HTAP 不是真正的 HTAP。

卢东明：用 TP 强补足 AP 能力，或 AP 强补足 TP 能力，这两种思路是合理的路径吗？

杨传辉： 只有从 TP 开始才有可能成功，因为 TP 的门槛很高，且会涉及到核心场景，如果核心场景做好了的话，往 AP 是自然延伸，相当于由高打低；如果 AP 做好了，本身 AP 的重要程度、核心程度远远低于 TP，别人不会因为选了 AP 而选TP，但是别人可能因为选了 Oracle 的 TP 也选 Oracle 的 AP，这是一个自高往低的商业逻辑。

​

陈栋： Oracle 也是这样的思路，把 TP 做到极致后再兼顾 AP 的能力，离线的也能处理一些，但不是特别专长的地方。OceanBase非常巧妙，从多副本里拿出一个副本，做列存，既省节空间，又做到数据的一致性，不需要单独设计一个表格，这个还是挺期待的。

杨建荣： 我们现在有很多探索型的业务，它的模型会变化很快，整个逻辑相对复杂，如果像 OceanBase 这样的分布式数据库能够原生地去支持，这种业务模型经过探索之后相对会固化下来，再演变成为 TP 的业务，可能是一个更无缝的方式。

​

杨传辉： OceanBase 的探索性业务有几个方面。第一，单机分布式一体化，扩展对用户来说是透明的；第二，OceanBase 的 DDL 操作，我们会支持 Json、多模数据，DDL 在线操作无感知，对业务没有影响。通过这样的模式可以比较好得解决一些探索型业务的问题。

杨建荣：Oracle 在咱们认知里面就是 HTAP 数据库，但是在列存的方向上其实 Oracle 有一个 In-Memory 特性，NewSQL 体系中则是空间换时间的实现方式。OceanBase 在这方面能不能展开说一下？

​

杨传辉： Oracle 走的是 In-Memory 的模式，OceanBase 走的是真正的列存路线。Oracle 之所以选择这条路线是因为以前的技术债务太大了，尽管列存是更先进的方案，包括 Sybase 也是列存，Oracle 在那么大的技术栈里面只能选择 In-Memory 的模式，从技术的角度有点像打补丁。而 OceanBase 相对来讲没有 Oracle 那么重的技术债务，我们可以直接用最优的方式来做，目前，列存已经被业界证明，所以做 AP 肯定要做列存。

写在最后

最后关于 OceanBase 的发展，我来做一个总结：非常感谢包括今天到现场的以及在网上参加直播的 OceanBase 开发者，这是 OceanBase 第一次面向开发者的大会，其实挺不容易，不管从筹备、组织，安排话题，我们花费了大量的精力，我们确实想把开发者大会办好，想把我们的开发者社区做好。

对于 OceanBase 的产品而言，虽然我们今天说到全新的单机分布式一体化架构，但 OceanBase 有很多东西是不变的。

首先，对于稳定可靠的坚持，这个是 OceanBase 永远不变的。第二，对性能、功能、对内核打磨的坚持。我们知道，仅仅把分布式数据库底层的东西做好，就需要很长的一段时间。

今天，我们在一起做面向开发者的探讨，当然也有一些希望去变的东西——那就是用户体验。

OceanBase 在 4.1 版本里，做了包括 OCP Express 轻量版开箱即用的工具、文档的重构、快速的安装部署，大家只要去 OceanBase 官网或者去 Github 社区都可以看到，OceanBase 正在发生很大的变化，也相信每位开发者会对 OceanBase 的变与不变，会有更深刻的感受！感谢各位开发者一直支持 OceanBase，因为你们的支持，我们才能做得越来越好！

---

欢迎访问 OceanBase 官网获取更多信息：https://www.oceanbase.com/