在刚刚结束的年度发布会上，OceanBase正式推出一体化数据库的首个长期支持版本 4.2.1 LTS，这是面向 OLTP 核心场景的全功能里程碑版本，相比上一个 3.2.4 LTS 版本，新版本能力全面提升，适应场景更加丰富，有更全面的容灾解决方案。
自发布以来，我们陆续收到很多客户、用户对一体化的好奇与咨询，我们希望通过本文和大家更深入地探讨 OceanBase 对一体化理念的思考和探索。
OceanBase 13 年前刚成立的时候，业界有很多非常流行的开源数据库，比如大家都很熟悉的 MySQL，但是 MySQL 数据库有两个问题：只能处理简单查询，无法处理复杂查询；只能处理小数据量，很难做扩展及处理大数据量。
正因此，团队决定开始研发分布式数据库 OceanBase，用一体化的思路解决单机与分布式的难题，不仅能处理小查询，也能处理大查询，从 KV 到 TP/AP一体化，从简单查询到复杂查询，OceanBase 一直在通过应用场景不断驱动自身创新，这也是 OceanBase 设计一体化思路的初心。
从 2010 年至今，OceanBase 专注 OLTP（事务处理）场景，逐步实现了多个一体化：TP/AP 一体化、云上云下一体化、单机分布式一体化。从 1.x 发展到今天的 4.x，在用户的支持下，OceanBase 的产品能力得到了飞跃发展。作为自研数据库的一员，聚焦到“关键业务负载”的核心系统诉求，我们需要在稳定性、高性能、高兼容和性价比这几个维度上持续突破和深度打磨，这是 OceanBase 的核心竞争力，也是 OceanBase 在技术投入和产品打磨上一直以来投入的最重要的关键方向。
在一体化思路的指引之下，OceanBase 没有选择复用开源数据库的代码，选择了一条应用驱动技术创新、完全自研的发展道路。在这个路线指引之下，OceanBase 做了大量的技术创新，把分布式领域的核心技术逐步融入到关键数据库领域里。
例如：通过把 Paxos 引入到关键数据库，实现 RPO=0，RTO＜8 秒；通过“三地五中心”实现了业内首个城市级无损容灾；打榜 TPC-C，并且取得世界第一的成绩；提出单机分布式一体化架构，并且把 LSM-Tree 存储引擎引入到关键数据库里面，大幅度地降低了存储成本……
一体化的设计思路简单来讲可以分成三个层次，为了便于大家理解，我们以造房子作为举例：
首先，需要搭地基，一体化思路的地基即2022年发布的单机分布式一体化架构，主要解决数据规模的问题，数据可大可小，有了这个架构之后，不管多大多小的数据量，都可以用一套系统全部统一地解决掉。
其次，在一体化架构基础之上，进一步搭建一体化引擎，包括一体化的存储引擎、一体化的事务，一体化的 SQL 引擎，以及云上云下存储计算分离的引擎。这个层次主要解决了数据的存储与计算问题。
第三，有一体化引擎之后，进一步搭建最终的一体化产品，即房子。这个产品解决的是如何给客户提供数据服务的问题，包括如何支持多种工作负载、实现多种数据模型、实现多种数据接口、实现多种兼容模式等。
与传统的关系型数据相比，JSON、XML 等半结构化数据的处理方式更加灵活，因此在处理复杂的应用中显得尤为不可或缺。与此同时，对于处理 GIS 和 KV 等多样数据的需求也日益凸显。在此过程中，数据库经历了从事务型到分析型，再到支持 HTAP 两种类型的发展，企业通常会根据不同问题使用不同的数据库，这也导致了数据库的不断增加，数据的使用和管理变得越发复杂。而 OceanBase 今天的一体化思路核心理念是用一个数据库解决 80% 的问题，注意这里是 80% 的问题，不是百分之百的问题。
一直以来，OceanBase 专注于 OLTP 场景，从 2010 年开始逐步打造满足现代数据架构需求的多模态、多兼容模式、多租户、多工作负载、多基础设施等核心能力，推出的一体化数据库，为用户提供简化复杂性的全新可能性。
多租户：统一技术栈，极大简化数据库基础设施的复杂度。OceanBase 在早期 1.0 版本已经实现工程一体化，并提供多租户以及资源隔离能力，可将更多的数据库实例整合一个集群中。从用户业务视角不用再关心资源隔离问题，可直接通过多租户带来的统一技术栈，即可极大简化数据库基础设施的复杂度，并显著提高系统利用率。
多兼容模式：一个数据库，同时兼容 MySQL 和 Oracle。OceanBase 2.0 版本开始提供多兼容模式，高度兼容 Oracle 和 MySQL，支持存储过程、触发器等高级特性。用户无需关心兼容性问题，通过一体化 SQL 引擎同时兼容 MySQL 以及 Oracle 主流数据库，同时提供自动迁移工具，支持迁移评估和反向同步以保障数据迁移安全，支撑金融、政府、运营商等关键业务系统升级。
多工作负载：一份数据，所有工作负载中提供出色的性能和性价比。3.0 版本加速进化多工作负载能力，用户无需关系 ETL 复杂性，通过一个系统、一份数据就可以在高性能 OLTP 基础上支持实时分析能力，并从根本上保持数据一致性。
单机分布式一体化架构：一个数据库，满足用户从小到大的业务规模化诉求：4.0 版本推出，用户无需关心集中式或分布式技术路线选型，可以在业务量小的情况下从小规格单机部署起步使用完备功能的单机部署形态，随着业务压力的变化将数据库从单机平滑扩容到多机甚至超大规模的分布式集群，同时具备多机平滑缩容到单机的能力，通过一套数据库满足业务从小到大的集中式和分布式架构诉求。
多模型：一个数据库，支持多种现代数据类型：4.0 版本开始提供多模型能力，通过OBKV提供融合多模数据支持，无论应用的简单性还是复杂性，无论处理的是关系型数据、JSON、Key-Value 还是 GIS 等非结构化数据，都可以在同一个的数据库上获得卓越的支持，降低应用开发难度和运维复杂性。
多基础设施：从“云下”到“云上”，按需选择基础设施：4.0 版本开始支持本地数据中心、阿里云、AWS 等多基础设施以及跨基础设施部署，通过一致的架构和一致的管理显著降低复杂性。每一个企业的基础设施都各不相同，不论是应用还是数据库都可以部署在专有云、公有云和混合云中，选择权完全交给企业自己。
去年，OceanBase 发布了业内首个单机分布式一体化数据库 4.0 （小鱼），单机分布式一体化的核心是采用一套系统，实现从单机到分布式对用户完全透明。通过单机分布式一体化架构，可以实现可大可小，既能应用到大企业，也能应用在中小企业，甚至是一些创业公司。此外，OceanBase 单机分布式一体化架构在平滑伸缩、小规格部署、RTO ＜30s 缩短至 RTO＜8s 的故障恢复能力方面上均进行了创新。
有了单机分布式一体化架构这个底座之后，就可以进一步搭建一体化的存储引擎、一体化的SQL 引擎，以及存储计算分离的引擎。
（一）一体化存储引擎
今天，业内都在谈论 HTAP，众所周知 OLTP 需要行存，OLAP 需要用列存，如何设计一套一体化的存储引擎能够把行存和列存完全融合到一套系统里面，有两种比较经典的设计思路。
第一种设计思路，OceanBase 是一个 Shared-Nothing 的多副本架构，每个副本仍然采用相同的存储格式，都采用行存或者都采用行列混合式存储，所有的 OLAP 和 OLTP 的请求都直接由主副本提供服务，这种方式的好处很明显，它没有任何一致性的问题，也没有任何数据延时的问题，但是它的问题在于因为没有支持列存，所以 OLAP 能力相对来讲差一些，比较适合 OLTP+非常轻量的 OLAP 的场景，比如跑批，或者 OLTP 场景里面的复杂查询。
第二种设计思路，OceanBase 的多个副本可以采用不同的存储格式，主副本支持行存支持OLTP，某一个备副本用列存来支持 OLAP。这种方式的好处在于通过引入列存大幅度提升了 OLAP 的处理能力。但是，问题在于主副本与备副本之间会额外引入毫秒级的延迟，有短暂时间的数据不一致，比较适合简单的 OLTP 的场景加上中等的 OLAP 的场景。当然，今天讲的 HTAP 无法解决百分之百的 OLTP+OLAP 融合到一套系统里面的问题。
（二）一体化 SQL 引擎
谈到混合负载，就一定有简单查询，也有复杂查询。如何设计一套一体化的 SQL 引擎把简单查询和复杂查询融入到一套系统里面去？
因为简单查询，用户比较关注简单查询的延迟，所以简单查询比较好的实现方式是串行执行，并且由 SQL 层往存储层拉数据；复杂查询因为涉及的数据量比较大，用户比较关注能否发挥整个数据库所有的并行处理能力，比较好的实现方式是用并行执行，SQL 层把执行计划下推到存储层，从而降低网络上数据传输的开销。
今天 OceanBase 的一体化 SQL 引擎实现了推拉结合的模式，对简单查询拉数据，复杂查询推执行计划，通过这样的方式实现了把简单查询和复杂查询很好地融入到一套系统里。同时，OceanBase 支持了一个非常有用的功能叫 Auto DOP，自动设计并行，优化器可以根据统计信息自动地判断到底应该采用简单查询、串行执行还是并行执行以及并行执行具体的并发度。
当然，只要讲到混合负载一定面临简单查询与复杂查询 OLTP 与 OLAP 之间资源隔离的问题，之前 OceanBase 已经支持了在数据库内部的 CPU 和内存的资源隔离，今年 OceanBase 进一步增强了基于 IO 能力的资源隔离。
（三）存算分离引擎
作为一个多副本的 Shared-Nothing 架构，如何把 Shared-Nothing 架构部署到多云基础设施也是一个很大的技术挑战。这里面涉及到如何把 Shared-Nothing 架构与通常在云上的 Shared-Storage 架构融合起来。
比较幸运的是，OceanBase 的底层存储引擎是 LSM-Tree，虽然 OceanBase 采用了多个副本的存储架构，但是 LSM-Tree 把数据分成了基线数据+增量数据，OceanBase 多个副本之间的基线数据是一模一样的。
当 OceanBase 把多个副本部署到多云基础设施的时候，此时，多个副本的基线数据可以共享同样一份共享存储，最终可以做到只有接近一份数据的存储成本。当然，OceanBase 也可以通过一些日志副本或者仲裁副本的方式，进一步降低计算成本的开销，最终做到接近一个副本的存储，接近两个副本的计算，实现 RPO = 0，并且在云上实现了弹性，最终做到 Shared-Nothing 和 Shared-Storage 架构完美融合。有了一体化引擎之后，就可以在引擎之上进一步地搭建一体化的产品。
过去一年，OceanBase 在一体化的产品层面做了很多事，举三个例子：
（一）一体化 SQL 功能
一体化的设计理念有一个核心的目标，就是希望能够做到在分布式架构实现与集中式数据库与单机数据库完全对标的 SQL 功能，但是某一些 SQL 功能在分布式架构下是非常难以实现。
举两个例子。第一个例子是大事务，如果一个大事务设计的参与数、分区数特别多，比如几万个甚至几十万个参与者，分布式事务基本上不可能完成；另外一个例子是表锁，比如要在分布式系统里面锁住一张表格，这张表格设计的分区数特别多，因为要锁每个分区，所以这也基本上不可能实现。这个问题的本质在于，原有的原生分布式数据库一般来讲每个分区有一个独立的日志流，使得大事务表锁这样的操作，它的复杂度会与分区的个数成正比。
OceanBase 通过单机分布式一体化架构，通过其中的动态日志流的技术，把一台机器上所有的分区动态地融入到一个日志流里面，使得大事务、表锁这样的复杂度只与机器数成正比，不与分区数成正比，最终在 4.2 版本里，OceanBase 实现了任意大事务没有限制，以及全功能的 DDL，包括表锁在内。
（二）多模融合
这里面的多模型不仅仅在一个产品里面支持多个不同的模型，还包括如何实现多个模型之间的互相操作。
举个例子，OceanBase 经常有一些 HBase 的用户，有人说 HBase 的接口比较好用，但是 HBase 独接口特别简单，语义不够丰富，不支持 SQL。当很多 HBase 用户把他们的业务迁移到 OceanBase 之后，他们仍然使用与 HBase 兼容的方式来写入，但是读取的时候直接采用 SQL 语言。在发布会现场，很多人已经前往展台体验了多模 Live Demo，现场有很多直接用 HBase、JSON 等写入、SQL 读取的场景实例。
OceanBase 4.0 版本开始提供多模型能力，通过 OBKV 提供融合多模数据支持，无论应用的简单性还是复杂性，无论处理的是关系型数据、JSON、Key-Value 还是 GIS 等非结构化数据，都可以在同一个的数据库上获得卓越的支持，降低应用开发难度和运维复杂性。
（三）一体化产品家族
工具产品方面，我们希望围绕关键业务负载场景做工具产品核心能力的升级， 去兼容更多的关键生态，在过去一年无论是 ODC、OMS、Binlog，还是 OCP、OAS 都在面向关键业务场景做了大量的能力升级。
ODC，打造企业级协同开发平台
ODC 致力于打造企业级的开发者协同平台，把企业需要的安全合规流程融入到数据库开发者的工作流程中，使得所有的变更操作都可以做到可回溯、可回滚，这件事情对于核心业务场景、关键业务负载非常重要。
OMS，双向同步、一键逃生
所有把OceanBase应用到关键业务负载的客户一定会提两个需求：第一个，希望能够做到老系统与新系统之间的长期并跑，一键逃生。另外，希望能深度掌控 OceanBase。OMS 提供了双向同步的能力，长期并跑一键逃生，万一新系统出现问题，不管什么原因，最终都能够保证一键逃生到系统。
OCP 全场景管控+ OAS 诊断自治，一体化智能运维诊断平台
在 OCP 层面，OceanBase 进一步增强了诊断监控功能，支持全场景的管控。通过积累在蚂蚁、支付宝多年的运维、稳定性相关的经验，进一步将产品进化成 OAS 自助服务输出给客户。
Binlog，打通 MySQL生态
同时，OceanBase 也在持续完善 MySQL 及 Oracle 兼容性，在新增内核兼容功能的同时还提供 MySQL Binlog 协议的支持，帮助用户更方便地把数据库接入到下游 MySQL 生态。
今天，OceanBase 4.2.1 LTS 版本正式发布 ，其是一体化数据库的首个长期支持版本，包括三个最重要的核心能力升级：
第一，支持完整的 OLTP 功能，是面向 OLTP 核心场景的全功能里程碑版本，可以说，OceanBase 4.2.1 LTS版本的发布意味着 OceanBase 在分布式 OLTP 核心功能已经就绪，这个非常重要；第二，更是更强的性能，相比 3.2 LTS 版本，4.2.1 LTS 版本的 OLTP 性能是 3.2 版本的 1.9 倍，OLAP TPC-DS 100G 场景性能是 3.2 版本的 2.7 倍；第三，是更低的容灾成本，通过引入基于仲裁的无损容灾方案，通过两个副本实现 RPO=0。
OceanBase 4.2.1 LTS 版本有五大核心能力：
内核能力方面，OceanBase 4.2.1 LTS 版本包括三种技术特性，第一支持一体化的产品能力，包括混合负载以及多模能力，OceanBase 4.2.1 LTS 支持 Auto DOP 自动设置并行度 SPM SQL 执行计划管理，相信 Oracle DBA 和用户非常熟悉，这两个功能对于一个企业级数据库支持复杂查询非常重要，支持 KV，支持 JSON，也把 LOB 的上限提升到 512MB；第二支持一体化的 SQL 和事务的能力，实现任意大小的事务无限制，并且实现全功能的 DDL；第三实现了更好的高可用的能力，既能支持与传统的集中式数据库完全对标的组备库的方式，也实现了通过仲裁的方式，以两个副本的成本实现 RPO=0。
性能提升方面，相比 3.2 LTS 版本，OceanBase 4.2.1 LTS 版本的 TP 性能是 3.2 版本的 1.9 倍，AP 性能是3.2版本的2.7倍，导入性是 3.2 版本的 6 倍。
兼容性方面，OceanBase 4.2.1 LTS 版本进一步增强了 MySQL 8.0 的兼容，并且提升了 Oracle 的兼容性，支持 DBLink、表锁等 Oracle 常见的特性。通过兼容 MySQL Binlog 的方式直接接入到下游数据生态。
工具平台方面，OMS 支持双向同步一键逃生，ODC 打造企业级协同开发平台，OCP 支持全场景的管控，OAS 实现智能诊断自治服务。可以说，大家可以把关键业务场景非常放心地迁移到 OceanBase 4.2.1 LTS 版本，OceanBase 4.2.1 LTS 版本不管是内核能力、迁移过程以及迁移之后的运维稳定性，都能够很好地支持关键业务负载。这个版本可以让关键业务负载用得非常省心、放心，运维也非常安心。
单机模式方面，OceanBase 4.2.1 LTS 版本支持单机模式，之所以叫单机模式，意味着它可以按需升级到多机模式，按需扩展到分布式。同时相比 MySQL 单机数据库，OceanBase 4.2.1 LTS 版本能够更好地支持混合负载，提供更好的数据压缩能力，并且也有更好的高可用能力，包括前面提到的通过仲裁的方式，以两个副本的开销实现 RTO=0。
作为一体化的产品，OceanBase 的 OLAP 能力也在非常快速地迭代，当然了，作为 OLAP 领域新进入的一员，OceanBase 需要向业界一流的产品学习，包括 ClickHouse。
OceanBase 列存实验室版本与 ClickHouse 的跑分演练
通过跑分可以看到，同等硬件条件之下，OceanBase 列存实验室版本的性能在实时 OLAP 在大宽表场景已经达到了 ClickHouse 同一水平，甚至 OceanBase 的性能稍微快那么一点点。
作为从事十余年的数据库基础设施厂商，OceanBase 所提的一体化产品以及数据库基础设施，有两件事情是永恒不变的话题：性能更快，成本更低。
OceanBase 永远都在追求极致的性能与最佳的成本，一体化的产品正是能够在追求分布式架构下的极致性能和最佳产品。目前，OceanBase 的单机性能已经达到甚至超过了 MySQL 的性能，在单机形态、硬件成本以及迁移学习成本上有着显著的优势：
单机部署形态成本：在单机部署形态下，在同等硬件条件下，OceanBase 的 SQL 及事务处理性能和 MySQL 相当，部分场景下存储成本可降低至原有的1/3；
垂直/线性扩展带来的硬件成本：随着业务规模的增大，无论在云上还是 on-prem，为提升性能都需要升级硬件。在此过程中，相较于传统数据库的非线性成本增长（尤其是高速网络/SAN 存储设备的价格和单机部署时的差异巨大）， OceanBase 的水平扩展可以做到真正的线性扩展，带来的成本也是线性增长，帮助用户更好的降低数据库成本；
迁移和学习成本：OceanBase 实现了单机和分布式架构的统一，同时兼容集中式数据库的行为和使用方式。这使得用户在基本不修改业务代码的情况下，能够平滑地从单机形态扩容到分布式形态，而无需额外的迁移及学习成本。
最后，和大家分享下 OceanBase 4.x 产品路线图。去年 8 月份，也就是去年 OceanBase 产品发布会，首次发布了单机分布式一体化架构以及 OceanBase 4.0，今年 3 月份，OceanBase 发布了面向开发者的里程碑版本 OceanBase 4.1。今天，OceanBase 发布了 4.x 的首个 LTS 版本 OceanBase 4.2.1，明年 4 月份 OceanBase 4.3 版本即将发布，包含前面提到的列存功能，明年 10 月份，OceanBase 4.4 版本将会和大家见面，支持存储计算分离的能力。欢迎大家关注 OceanBase，一起打造更好的一体化数据库。