共计 11716 个字符，预计需要花费 30 分钟才能阅读完成。
欢送拜访 OceanBase 官网获取更多信息：https://www.oceanbase.com/
3 月 25 日，第一届 OceanBase 开发者大会在北京举办，OceanBase CTO 杨传辉在主论坛进行了《打造开发者敌对的分布式数据库》的分享。
以下为演讲实录：
各位 OceanBase 的开发者，大家上午好！OceanBase 在去年 10 月份公布了最新的 OceanBase 4.0 版本，4.0 版本作为单机分布式一体化架构，我认为它给开发者带来最外围的价值在于极大地升高了分布式数据库的应用门槛。
明天也是第一次开发者大会，非常高兴能在这里与咱们 OceanBase 的开发者谈谈我本人对于怎么去构建一个对开发者敌对的分布式数据库的思考。
OceanBase 整体架构演进
首先，OceanBase 宏观上三次架构的演进，有很多人可能晓得晚期的 OceanBase 是一个单写多读的架构，存在 OceanBase 的 0.1 版本直到 0.5 版本。OceanBase 在 1.0 版本公布了过后的全分布式架构版本 1.0，这个 1.0 架构也利用在 1.x 版本、2.x 版本、3.x 版本，直到 2022 年公布了最新的单机分布式一体化架构 4.x 版本，它对于用户最外围的价值方才曾经提到了—— 在于把单机的劣势也就是单机的高性能、低成本与分布式的劣势可扩大的能力、高可用的能力齐全融入到一套零碎外面。 这样的一个系统对开发者是十分敌对的，咱们也选在这样一个工夫点跟大家来谈开发敌对的话题。
稳固牢靠，很多个 0 后面那个 1
首先，数据库有很多对开发者比拟有用的个性，十分弱小的性能、很好的性能，或者可能有一些十分乏味的个性。比方可能反对 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.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，反对单机版。
4.3 版本，咱们会在 OLAP 能力上大幅度晋升，做一个十分有用的列存性能，也会进一步加强在 OLTP 场景对简单查问的反对，还会做 DBA 应该很相熟的数据库快照性能，实现数据库的闪回，这在很多时候对于 DBA 来讲是“救命”的性能。咱们还会公布黑屏的运维工具。OCP 是白屏的运维工具，性能很弱小然而白屏不够酷，我本人也是开发者，开发者会更想要一个黑屏的工具。
4.4 版本，OceanBase 会进一步欠缺 MySQL 8.0 的兼容性，实现 MySQL 8.0 所有支流性能的兼容，而且会进一步欠缺大宽表的 OLAP 在线剖析能力。并且，咱们会进一步把整个 OceanBase 外部的研发流程开发到 GitHub 外面去，当前所有的内部开发者和内部人员都能够在 GitHub 里做研发，间接看到外部的 Issue 和 Roadmap。
OceanBase 的迭代速度很快，在这个过程中咱们失去了包含明天在场各位以及加入直播的各位开发者的大力支持，你们的反馈，你们的需要是 OceanBase 可能疾速提高的最大前提和能源。
在这里，我也感激每一位与 OceanBase 独特成长的开发者，因为有你们，OceanBase 的社区变得越来越沉闷，越来越凋敝；因为有你们，OceanBase 的代码迭代的速度越来越快；因为有你们，OceanBase 的生态变得越来越欠缺，让 OceanBase 的每个用户可能应用 OceanBase 更加省心，更加释怀！
欢送拜访 OceanBase 官网获取更多信息：https://www.oceanbase.com/