欢送拜访 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/