“成年人”的数据库，既要又要也要！
3 月 25 日，第一届 OceanBase 开发者大会在北京举行，《明说三人行》访谈栏目创始人兼主持人卢东明、沃趣科技创始人兼 CEO 陈栋、DBAplus 社群联合创始人杨建荣、PostgreSQL 中文社区主席 张文升、OceanBase CTO 杨传辉在主论坛进行了《数据库领域，有哪些最值得开发者和用户关注的创新与技术》的圆桌讨论，共同探讨了单机分布式一体化、HTAP、多云原生等众多关于分布式数据库的热门话题。
卢东明：请用一句话、三个标签来介绍一下自己和所做的事情？
杨传辉：工程师/开发者；单机分布一体化；性价比。
陈栋：DBA；创业；一体化。我们从数据库、软件、硬件，即整个系统一体化的方式给客户提供开箱即用的解决方案。
杨建荣：DBA；技术社区；技术分享。
张文升：PostgreSQL；开源社区；布道师。我最重要的标签就是 PostgreSQL，我认为哪里有 PostgreSQL，哪里就有我。
卢东明：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 是现在挺热的一个词，中国有将近 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，因为你们的支持，我们才能做得越来越好！
往期推荐
▼ 点击下方「阅读原文」，进入官网看直播回放！