OceanBase CTO杨传辉：万字解读，打造开发者友好的分布式数据库
3 月 25 日，第一届 OceanBase 开发者大会在北京举行，OceanBase CTO 杨传辉在主论坛进行了《打造开发者友好的分布式数据库》的分享。
以下为演讲实录：
各位 OceanBase 的开发者，大家上午好！OceanBase 在去年 10 月份发布了最新的 OceanBase 4.0 版本，4.0 版本作为单机分布式一体化架构，我认为它给开发者带来最核心的价值在于极大地降低了分布式数据库的使用门槛。
今天也是第一次开发者大会，非常高兴能在这里与我们 OceanBase 的开发者谈谈我自己对于怎么去构建一个对开发者友好的分布式数据库的思考。
首先，OceanBase 宏观上三次架构的演进，有很多人可能知道早期的 OceanBase 是一个单写多读的架构，存在 OceanBase 的 0.1 版本直到 0.5 版本。OceanBase 在 1.0 版本发布了当时的全分布式架构版本 1.0，这个 1.0 架构也应用在 1.x 版本、 2.x 版本、3.x 版本，直到 2022 年发布了最新的单机分布式一体化架构 4.x 版本，它对于用户最核心的价值刚才已经提到了——在于把单机的优势也就是单机的高性能、低成本与分布式的优势可扩展的能力、高可用的能力完全融入到一套系统里面。这样的一个系统对开发者是非常友好的，我们也选在这样一个时间点跟大家来谈开发友好的话题。
首先，数据库有很多对开发者比较有用的特性，非常强大的功能、很好的性能，或者可能有一些非常有趣的特性。比如能够支持 Severless、多云原生，甚至可以跟 ChatGPT 结合。我认为对于开发者而言，对于数据库来讲，开发者最看中的特性永远是稳定、可靠。我相信在座的很多开发者应该都或多或少有过晚上 12 点处理故障的经历，我用“稳定可靠”作为今天分享的开场。
阿里巴巴的 DBA 团队有一句话，稳定可靠是数据库这样的基础软件很多个 0 前面那个 1。没有稳定可靠，数据库有再多的功能性能都是没有任何意义的。OceanBase 在 2014 年把当时支付宝的交易业务由 Oracle 迁移到 OceanBase，这是 OceanBase 第一个支撑的核心业务场景。我记得很长一段时间，其实我们睡不着觉，担心出现严重的生产事故。
这个时间我也研究了航空业几乎所有的飞机失事事件，最后发现一个法则：海恩法则，我把这个法则给大家读一下。每次严重事故的背后，必然有 29 次轻微事故，300 起未遂先兆事故，以及 1000 次事故的隐患。这就表明想避免严重事故我们需要做的是提前解决掉事故隐患，通过解决这些事故隐患从而降低未遂先兆事故以及轻微事故的概率，从而避免严重事故。
OceanBase 团队一直这么做，我们在 2010 年开始立项，并且一直在支撑蚂蚁集团所有的核心业务，支持每年的双 11。但是大家都知道，OceanBase 从来没有出现过一次重大的生产故障，没有丢过一次数据，为什么？因为我们把所有的事故隐患能够提前解决掉。
当然，支付宝应用 OceanBase 之所以做得这么稳定，也有自己的最佳实践，我分享三点。
首先，支付宝有着非常特别的设计。支付宝的业务把我们的数据库分成两类，一类状态库，一类流水库。比如在支付宝做一笔付款操作，付款的流水放在流水库里面，每个账户有多少钱放在状态库里面，这就使得当流水库发生故障的时候，应用层能做应用层面的failover，把新的流水写到全新的数据库里面，这种模式使得当OceanBase每次发布新版本的时候，我们总是先拿流水库来做试验。
第二，对于数据一致性的坚持。这里面起了一个名字应校尽校，不管多个副本之间的数据一致性，还是说每次事务的并发操作或者读写磁盘都需要做校验，即使可能增加系统复杂度，会牺牲性能，只要能够做校验就做校验。我们内部有一个钉钉群，解决数据一致性的隐患。之所以线上没有出现过一致性问题，是因为我们在群里面把这些问题提前解决掉。
第三，支付宝是非常复杂的系统。对于这样的系统我们需要通过混沌工程的方式保证它的稳定性。我们需要给这个系统引入一些混沌因子。网商银行经常做一件事情，很多开发者都听说过，断网演练。刚开始运维团队会通知业务团队，某某时间开始我们要做断网演练，请做好准备。第二个阶段，甚至我们都不通知业务团队，直接拔网线，掐电源。通过很长时间的打磨，才把我们的高可用能力、RPO、无损容灾的能力，由一个“PPT"变成生产系统里面可落地的现实。
在座很多开发者有很多来自于像支付宝、阿里巴巴这样的互联网公司，互联网公司有很强的技术能力，但是各位开发者有没有想过一个问题？你所在的公司备份的数据能不能恢复出来？我给大家说一个事情，支付宝早期使用 OceanBase 的时候，我们也做了很多备份，但是当时的备份数据是不可恢复的，以后也可以去你公司问问 CTO 到底能不能恢复？我们立了备份恢复优化的专项，经过很长时间的打磨最终做到备份恢复成功率百分之百。
开发者需要性能高，使用门槛比较低的数据库。OceanBase 早期的版本有一个被诟病的问题，很多开发者告诉我们，OceanBase 比较重。最早期的版本一台机器要求 128G 内存，之所以会有这么高的要求，要求这么高配的服务器，一个最本质的原因在于，我们这样的分布式数据库早期的架构里面每台机器需要使用大量的 CPU 和内存用于处理分布式相关的 overhead。
4.0 版本通过一体化架构避免了每台机器上的分布式 overhead，从而提升性能，并把门槛降低下来。今天我们用自己的笔记本，用树莓派就能部署 4.0 版本。
▋ 单机性能不足，使得 NewSQL 无法成为主流数据库
我们对业界主流的 NewSQL 系统做了测试，发现主流的 NewSQL 系统相比 MySQL 8.0 性能差很多，只能做到 MySQL 的 1/5 到 1/10，我一度怀疑我们的测试是不是出现了问题，直到最后在它们的官网发现它们的测试结果跟我们是一样的，我才确信不是我们的测试有问题，而是 NewSQL 系统的单机性能真的很差。
单机性能很差，使得 NewSQL 系统没有办法成为主流的数据库。今天我们看到很多的分布式数据库，比如分布式的表格系统，分库分表，NewSQL 系统，但是任何一种系统都没有办法在可扩展性、性能、功能三方面，同时满足开发者的需求。
Google 有一个系统叫做 Spanner，它里面有一个设计假设，为了做全球机的时钟同步，每个事务提交的时候需要额外等待 7-10 毫秒，Google 内部通过把应用由同步程序改成异步程序解决延迟，也许 Google 的程序员很强，但是对开发者很不友好，很多地方的程序员没有办法做到这一点。
开发者需要同时具备可扩展的能力以及单机功能和性能的单机分布式一体化数据库。这个数据库其实只要一说出来大家都想要，简单来讲既要也要，什么都好。这样的数据库到底是一个愿景，是一个乌托邦式的愿景，还是说真的可以被实现的系统？
▋ 为什么一体化架构能够同时做到可扩展和高性能？
OceanBase 4.0 也号称自己能够做到单机分布式一体化架构，我们的背后到底有没有什么魔法？
我们说我们实现了可扩展和单机高性能以及整个系统的高性能，这里面肯定有一些设计的假设。最根本的假设就在于对于所有的 OLTP 场景，虽然背后可能因为数据量很大，会是分布式数据库，但是大部分的读写操作都是单机操作，只有少部分的读写操作才是跨机操作。
大家都有自己的银行账户，假设所有的银行帐户存在一个银行的数据库里面，相信在座的各位大部分时间你是在读写自己的账户，你的少部分时间才会给别人转帐，大家给别人转帐之前应该会反复确认。对于这样基于账户的数据库，假设按照账户做了 Sharding，意味着大部分时间用户都是读写自己账户是本地单机操作，少部分时间是远程分布式操作。
我们设计一个分布式数据库要做的首先是保证主要的 80% 以上的单机操作性能不会因为分布式架构有额外的 overhead，这个事情做起来很难，只有 OceanBase 做到了。第二，优化另外 20% 的性能，使得这 20% 的分布式操作虽然因为网络有一定的 overhead，但尽可能做到足够低，最终使得整个系统不管单机还是多机层面都能够保持高性能。
分布式系统里面有一个特性——可扩展性，为了实现可扩展性，不同系统会有不同的设计选择。
▷ 集中式的数据库选择非常简单直接——“对不起，我做不到，我干脆不支持。”
▷ NewSQL 系统把可扩展性下沉到存储来解决。业界主流的 NewSQL 系统分成 SQL 层和 KV 层，这种方式解决了可扩展性的问题，但导致了新的问题——每台机器的性能特别差，因为每台机器都需要额外一次从 SQL 转到 KV 层，导致延迟。
OceanBase 1.x 版本到 3.x 版本，采取是预先分区的方案，每个分区相当于是一个 mini 数据库，有自己单独的 redo 日志，通过这样的模式也能解决一部分分布式数据库的问题，但是带来的影响就是每台机器要服务很多分区，服务很多 mini 数据库，有很多额外的 overhead，单机要求高配的 CPU 和内存。在 4.x 版本做了重构，实现单机一体化架构，每个单机有很多数据分区，但是只有一个数据流，使得单机读写没有分布式相关的 overhead，与原来的单机可以站在同一水平线上 PK 性能。
4.x 版本做到所谓的一体化，当增加新的服务器的时候，增加新的日志流，原来的分区从老的日志流里面摘出来迁移/转移到新的服务器新的日志流里面，既能保证单机的高性能，又保证可扩展。
从单机到分布式用户是没有感知的，当只有一台机器的时候，所有的数据分区绑到一个日志流里面，有点像单机的 MySQL，我们可以使用一个 MySQL 完全兼容的客户端直接访问 OceanBase 的单机模式。
当处理能力不足增加服务器，后台触发一个迁移操作，有一部分分区从原来的日志流解绑出来到另外一台机器。迁移的过程客户端做动态的路由，这意味着如果这个分区分片迁移没有完成，那还是访问原来的服务器。迁移完成之后，就访问新的服务器，原理就是这么简单。
整个迁移操作是后台的操作，也一定会占用后台的 CPU，占用后台的网络，占用后台的服务器带宽。对于任何一个数据库，这种带宽的占用非常少，一般来讲只要不是在双 11 凌晨这种极限高峰的场景，系统都是有余量做动态迁移，不影响前台正在进行的在线交易事务。
▋ 一体化架构单机性能超越 MySQL，降低开发者使用门槛
单机分布式一体架构的单机性能通过评测确实超越了 MySQL 8.0，我们对 32C 的机器做了 MySQL 8.0 和 OceanBase 4.1 性能测试。不管单行读写的性能，还是多行读写，只写，插入，读写操作，OceanBase 4.1 的性能都高于 MySQL 8.0， 并且最为综合的读写场景高出 39%。
单机分布式一体化架构能够大幅度降低开发者的使用门槛，早期的 OceanBase 版本确实因为架构设计的问题，我们需要单机用很高配的内存，128G。随着不断优化，从 128G 优化到 64G、32G、16G、8G，不断降低，现在已经能在树莓派上直接运行我们的 OceanBase 4.x 版本。其实我们还有很大的优化空间，以后还会把更好的产品带给各位开发者。
各位开发者，当你们想到一个分布式数据库的时候，你是不是一定会想到有很多的不同角色，有的角色是做管控的，有的角色是做工作机的，有的角色做 SQL 节点，有的做存储节点，但是 OceanBase 里面只有一个节点，一种角色叫 OBSever，一台机器一个 OBSever，N 台机器 N 个 OBSever，不管一台还是多台，像原来的单机数据库一样，可以使用单机数据库一模一样的方式使用 OceanBase 单机分布式一体化的数据库。
开发者选择数据库的时候会选择功能强大的数据库，很酷。大家今天都谈一个概念，HTAP，前面的报告里面包括很多其他厂商也在讲这个概念。我认为，今天国内的 HTAP 有三种不同的模式。
第一种 HTAP 又能做 OLTP，又能做 OLAP，什么都可以，这往往是很多人的理解，这个理解往往存在于“PPT”里面。
第二种 HTAP，做 OLTP 做不到极致，做 OLAP 比不过单独独立的 OLAP 数据库，那就做 OLTP 与 OLAP 的交集。这是做交集的思路，把 HTAP 做窄了。
OceanBase 讲的 HTAP 非常简单，那就是 OLTP Plus，先把 OLTP 做到极致，在 OLTP 做到极致的基础上一份数据既做交易又做在线分析，这就是我们 OceanBase 讲的 HTAP。
我们认为 HTAP 不是万能的，有它的适用场景，刚才周校长讲到，一个比较好的做法是有一个套件，这个套件里面有多个系统，其中一个系统叫 HTAP，另外一个叫离线 AP，可以共享一套引擎，内部组件可以做插件化，这是可行的思路。
仅仅针对 HTAP 的话，没有办法解决所有的场景。最典型的离线分析场景，HTAP 是不适合的。HTAP 比较适合用在在线 OLTP 场景以及在线的实时分析场景里面。对于中小企业一般来讲不会构建一个非常复杂的公司级的数据仓库，要求简单性，想要非常轻量实时分析，一个中小企业一个 HTAP 系统大部分情况下能搞定所有数据库的需求。对于大企业一定有自己独立的数据仓库，这样的数据仓库适合用单独的离线 OLAP 系统。每个大企业里面又有很多业务，业务里面有很多轻量级的实时分析，每个业务适合使用一套 HTAP 数据库，这是 OceanBase 理解的 HTAP。
HTAP 的关键在于采用一套系统，一套 schema。不能让开发者定义两张表格，使用方式太复杂了，开发者也没有办法接受。有一些不同的实现方式，对于一个分布式数据库而言，大家知道它一定会有多个副本，最简单的实现方式就是在主副本里面又做 OLTP，又做 OLAP，让 TP 和 AP 的性能都好，当然不可能把两种性能同时做到极致，这种适合比较轻量的实时 OLAP 场景。
第二种，分布式数据库里面有多个副本，主副本做 OLTP，备副本单独拉出来做实时的 OLAP，适合比较重量级的在线 OLAP 场景。
第三种，两个系统，通过表同步或者分区同步来实现 HTAP。真正的 HTAP 应该是前两种的实现方式，第三种实现方式有可能会导致一些问题，比如延迟比较大，甚至有可能因为数据不一致，导致额外的一些问题。
OceanBase 的做法是前面两种模式，现在支持第一种模式，在一个主副本里面又做 TP 又做 AP，我们正在做第二种模式，列存方案，希望 Q3 把第二种模式做出来。
讲到 HTAP，开发者肯定会有一个问题，一份数据是不是真的能够解决资源隔离的问题。OceanBase 3.x 版本支持通过 cgroup 来实现 CPU 资源隔离，有一个功能叫做 resource manager，实时生效。左边的图里面打开 resource manager 功能之后，很快 OLAP 请求的负载大幅下降，OLTP 的并发能力大幅度上升，这个操作实时生效。
我们在 OceanBase 4.x 版本进一步增加了对于 IO 隔离的支持能力。在右图的例子中，有租户 1、租户 2 权重分别是两万和一万，租户 4 的最大 iops 是 5000，租户 3 在 10 秒之后加入这个系统，最大 iops 是 10000。可以看到不管我们的系统如何增加压力，租户 4 的 iops 都不会超过 5000，等到租户 3 加入之后，使用10000 iops，租户 1 和租户 2 的 IOPS使用很快等比例下降，永远保持在 2：1 这样一个状态。测试数据表明，OceanBase CPU 的隔离和 IO 隔离做得不错，能够满足绝大部分 OLTP、OLAP 的隔离需求。
大家都吃过海底捞，原来使用单机数据库，有扩展能力不足的问题，也面临交易和分析因为链路复杂有延迟的问题，通过 OceanBase HTAP，TCO 下降了 35%，这个是 HTAP 的魅力。
我们跟开发者沟通，他会问我一个问题，OceanBase 是不是支持公有云？这个问题的背后想问，OceanBase 是不是符合技术趋势的？
今天包括前面的分享，我们也看到了公有云、多云、混合云一定是未来数据库领域最大的技术趋势，OceanBase 明显是符合技术趋势的，不仅是云原生的，我们还是多云原生，能够部署在多云平台，甚至是一些混合云平台，对用户提供完全一致的使用体验。
OceanBase 早期在蚂蚁集团的支付宝，大家可以把支付宝和蚂蚁集团想象成一个特别大的私有云平台，我们已经在支付宝蚂蚁集团部署了几万台服务器，几百万 CPU 核，早期上云其实很简单，就是把支付宝的物理服务器变成公有云上面的裸金属服务器，原来使用大规格的服务器、大规格的内存不变。我们做好产品的工具，做好云上的适配，这个阶段叫 IaaS 上云。
做了一段时间之后，开发者给 OceanBase 提了一些需求，最典型的需求有两个：第一个，开发者希望能够分别购买 CPU 和存储，并且存储需要做到按需使用按需计费，这是一个典型的存储计算分离的需求。第二个，开发者希望使用一个比较小规格的服务器，不希望使用特别大规格的，因为便宜，这是小规格的需求。
我们第二阶段主要完善了存储计算分离和小规格的方案，并且在阿里云上面做了大量生态工具的适配。去年又进一步支持了多云原生，支持了 AWS 以及其它一些国内外流行的云平台，我们的存储计算分离方案也进一步升级为开放的存储计算分离方案，并且在多云安全与多云生态做了大量投入、大量的适配工作。
我提一个观点，我认为开放的存储计算分离是多云原生的必然路径。我认为所谓的开放存储计算分离就是对于一个数据库软件一个数据库厂商来讲不要自己做存储，不要自己做分布式文件系统，不要自己做分布式 Key value，而是基于云厂商的云存储做二次开发，通过一些技术手段比如缓存、容灾方案解决云存储的延迟问题，解决云存储的稳定性问题等等。OceanBase 对于多云原生开放的存储计算分离探索了很长时间，也发现了很多问题。
这个方案的复杂度是超出我最早的想象，我们做了很长一段时间之后发现，不同的云存储虽然它的接口差不多，但是它们在功能、性能、稳定性以及成本上面都有非常大的差异。举几个简单的典型例子。
第一，阿里云有一个对象存储 OSS，能够支持追加写入，这个功能对于数据库来讲是非常有用的，大家都知道数据库要写 redo log，除了阿里云其它都不支持。
第二，我们还发现这个云存储的网络跟本地的机器网络相比带宽非常小，为了做好多云原生，需要做大量的数据压缩工作，云存储里面不同的存储成本差异巨大，对象存储很便宜，云盘非常贵。怎么把冷数据放到对象存储里面，这也是我们需要解决的问题。甚至发现让我自己都觉得很惊讶的现象，某一些云厂商是比较稳定的，但是还有一些云厂商的云存储非常不稳定，这个不稳定是持续会发生的，这就使得需要在数据库层面做更好的容灾能力。
OceanBase 在公有云上一个非常明显的优势，那就是性价比。我们的性价比领先于国内外同类产品，我对 OceanBase 的性价比在公有云上简单算一笔帐，假设在阿里云和 AWS 上分别购买 4C16G 的 ECS，分别部署 MySQL 8.0 和 OceanBase 4.1，到底大家的性价比怎么样？
性价比的衡量指标 Price/ Performace，也就是每个 tps 需要的硬件价格，这个比值越小，性价比越高。OceanBase 的单机性能高于 MySQL 8.0，OceanBase 存储成本只有 MySQL 的1/3。MySQL 部署两台机器，OceanBase 部署三台机器，我们做三副本，OceanBase 可以两台机器是全功能副本，还有一台机器只存日志可以使用更便宜一点的机器。150G、300G、500G、1TB。
无论任何一种场景，OceanBase 的性价比都是领先于 MySQL，而且随着存储容量的越来越大，OceanBase 相比 MySQL 的优势也越来越大。阿里云上是这样，AWS 上也是这样。我们做了测算，在同等性能的前提之下，相比云上的 MySQL 8.0，OceanBase可以降低 18.57%-42.05% 的整体成本。如果存储空间变得更大，OceanBase 降低会更多。
GCash 是菲律宾版的支付宝钱包，原来用的 MySQL 服务器，成本非常高，管理非常复杂。通过迁移到 OceanBase HTAP 分布式数据库之后，最终做到把所有的MySQL 整合到一套系统里面集中化管理，整体拥有成本下降了 40%，当然因为我们的存储优势，我们的存储容量压缩，存储设备甚至下降了 70%。
对于开发者来讲，前面分享的都是一些 OceanBase 系统技术特点和技术优势、产品特性。开发者也会关心一个东西，这样的产品对我来讲意味着什么？到底好不好用？它的门槛有多高？就是我们经常谈到的用户体验的问题。
OceanBase 在 2021 年 6 月份，我们正式开源之后持续地基于 OceanBase 开源社区版来持续降低开发者参与和使用的门槛。我们在刚开始开源的时候，第一个阶段非常简单，只是把内核先开源出去，当然内核开源之后找了第一批种子用户，基于种子用户的核心生产系统的需求来完善我们的生态工具。
这个过程完成之后，越来越多的用户开始把他的核心 OLTP 场景应用 OceanBase 开源的社区版本。我们搜集到更多用户的需求之后，基于他们的需求来打磨我们的易用性，让 OceanBase 从能用变得更加好用。今天为止，OceanBase 在用户体验上坦率讲我认为还有巨大的提升空间，我们在 OceanBase 4.x 版本也对用户体验层面做了大量重构和优化工作。
首先，4.x 版本安装更加简单，两分钟就能够实现一键安装部署。去年一段时间我去了一趟硅谷，发现北美的软件公司有一个特点，所有的用户对软件的需求都是自助服务，遇到问题用户自己看文档，自己用工具来解决这个问题。国内用户遇到问题，大家总是第一时间想到的是找人，最好是原厂交付，最好是原厂研发，这是两个不一样的特点。
OceanBase 开源出去之后，我们遇到了很多最初级的安装部署问题，有两类问题特别典型，第一类问题，找不到依赖包；第二类问题，很多组件配置起来特别复杂。于是我们在内部定了一个目标，两分钟——吃一包泡面喝一杯咖啡的时间，就能够实现一键安装部署 OceanBase demo 环境。最后确实实现了这个目标，在去年年底内部的产品技术总结会上让 HR 小姐姐，她是学文科的女生，通过看文档、点鼠标，实现了两分钟一键部署。
其次，OceanBase 4.0 版本文档更加有效。开源之后很多开发者就跟我讲，你们 OceanBase 团队挺用心的，你们的文档很多，但是，对不起，我看不懂，我找不到。我们态度很好，能力有限。在 4.x 版本对文档做了大规模重构，基于用户旅程和用户场景的思路来解决文档不好找和文档不好用的问题。
为了解决文档不好找的问题，我们的核心思路是两个，第一个 20% 的文档解决最主要的 80% 的用户场景问题；第二，要按照用户的使用链路和用户的旅程来重新组织文档，我们对怎么了解 OceanBase，怎么去使用，怎么开发，怎么部署，怎么迁移，怎么管理这些最基础的开发者最常用的一些文档做了重新梳理。我自己非常有信心，可能过不了多久，经过我们对文档的不断打磨，我们甚至能够基于 OceanBase 的文档写一些书，书名我都想好了《21 天学会 OceanBase》《7 天从入门到精通》。
为了解决文档不好找的问题，我换了一个思路，原先的文档告诉用户我们有什么，你来用吧，现在的思路是我们解决用户什么问题，以简单的运维功能比如隔离节点为例，为什么做这个事情，背后的原理是什么，怎么操作，操作有什么风险，有没有其它的使用建议等等，把这样一些问题从用户开发者使用的角度讲清楚。
再次，4.x 版本的工具更加轻量级。4.x 版本有一个运维管控工具 OCP，也是功能非常强大，看到 OCP 之后，开发者给我们提建议，OCP 功能非常强，但是，对不起，里面大部分的功能我不需要。OCP 很强，但是它很重，每次安装部署需要消耗特别多的资源，于是我们就干脆推出了轻量级的 OCP Express，非常轻量简单，占用的资源非常少，可以做到开箱即用。
也就是说，当我们在前面两分钟完成一键安装部署 OceanBase Demo 的时候，顺便把 OCP Expresss 启动起来，两分钟之后能够打开一个网页来直接查看OceanBase的内部运行状态。未来，OCP Express 也是一个开源软件，在六七月份也会把源代码开放出去。
最后，4.x 版本的代码共建更加简单。原来社区版代码和企业版代码是两个分支，内部定期把商业版代码合并到社区版本，这就带来两个问题。第一个问题，有延迟；第二个问题，开发者贡献代码的链路比较长，需要在社区版本里面做代码的 review 再合并到商业版本里面，在商业版本里面做完测试，整个提交才算完成。
在 4.x 版本里面把社区版代码和商业版代码合并成一个分支，以后不管内部的开发者，还是外部的开发者，大家都基于同样的分支，在同一个水平线上给 OceanBase 贡献代码，解决之前的两个问题。
经过 OceanBase 的单机分布式一体架构，在用户体验上的提升，在研发模式上的改变，我们确实也发现 OceanBase 的社区活跃度得到了大幅度提升。我们在去年 10 月份发布 OceanBase 4.0 版本以来，不管是代码的提交频率，还是代码贡献者的数量都呈现直线上升。
大家可以看到，虽然代码贡献者更多了，虽然 OceanBase 社区的问题变得更多了，但是我们 OceanBase 团队投入了更大的人力在开发者社区，我们的响应时间和 PR 处理时间反而得到大幅度下降。
今天我也借这个场合来发布 OceanBase 4.1 版本，大家都知道，OceanBase 4.0 版本是我们首次发布的单机分布式一体化架构底座，4.1 版本在 4.0 版本的基础之上进一步提升了性能，完善了功能，增强了稳定性，在内核能力上面在分布式事务和存储都做了大量优化。
同时我们也推出了很多对开发者来讲非常重磅级的功能，包括 GIS，包括 JSON，包括增强 LOB，包括租户级的主备库。大家可以看到，OceanBase 的 4.1 版本相比原来的 4.0 版本有很大的性能提升，我们在小规格的场景，相比 4.0 版本提升了 40%，在 OLAP 的场景提升了 15% 以上，在 4.1 版本还实现了在开发者群体里面呼声很高的旁路导入功能，通过旁路导入，OceanBase 4.1 版本的数据导入性能比 4.0 版本提升了 6 倍。
OceanBase 也在持续完善 MySQL 8.0 的兼容，我们还实现了一个功能，MySQL Binlog，以后可以直接把 OceanBase 4.1 版本接入到下游的 MySQL 生态。OceanBase 4.1 两分钟吃一碗泡面的时间完成一键安装，希望作为开发者能够到我们的社区跟我们一起来体验 OceanBase 4.1 版本，并且给我们提更多的反馈建议。
OceanBase 的版本迭代速度非常快，但是因为 OceanBase 的愿景是做一个像MySQL 流行的主流数据库，我认为我们的迭代还不够快，我们还会接下来调整我们的研发模式，每隔三个月就发布一个大版本，从 Q2 开始发布 4.2，Q3 的 4.3，Q4 的 4.4，明年 5.1、5.2、5.3、5.4。
4.2 版本，我们会把轻量级的 OCP Express 开源出去，同时也会把 ODC 开源出去，开发者可以通过 ODC 写一些 SQL、存储过程，做一些存储过程的调试，做一些数据脱敏等。4.2 版本还会做 Severless，支持单机版。
OceanBase 的迭代速度很快，在这个过程中我们得到了包括今天在场各位以及参加直播的各位开发者的大力支持，你们的反馈，你们的需求是 OceanBase 能够快速进步的最大前提和动力。
在这里，我也感谢每一位与 OceanBase 共同成长的开发者，因为有你们，OceanBase 的社区变得越来越活跃，越来越繁荣；因为有你们，OceanBase 的代码迭代的速度越来越快；因为有你们，OceanBase 的生态变得越来越完善，让 OceanBase 的每个用户能够使用 OceanBase 更加省心，更加放心！
往期推荐
▼ 点击下方「阅读原文」，进入大会官网！