一体化架构的意思是单机分布式一体化，实现数据可大可小。

如果企业规模小，数据量也小，完全可以把OceanBase做单机部署。实际上，OceanBase甚至可以部署到树莓派这样简单的计算机中，实现主备库的模式。

在企业的数据变大的时候，OceanBase能实现平滑伸缩，把单机变成分布式，对用户完全透明。

2.1一体化存储引擎

大家都知道，交易型应用（OLTP）和分析型应用(OLAP)对存储的要求是不同的。

但是现在很多系统既要支持OLTP，又要支持OLAP，即混合负载(HTAP) 。

OceanBase是一个Shared Nothing的多副本架构，这就有两种设计思路：

（1）每个副本都用相同格式（如行存/行列混合），所有请求都直接由主副本提供服务。

这种方案没有数据延迟的问题，但没有支持列存，OLAP差一些，适合OLTP+非常轻量的OLAP场景。

（2）副本采用不同的存储格式，主副本行存支持OLTP，某一备副本用列存支持OLAP。

这种方案通过引入列存大幅提升了OLAP的能力，但是主副本与备副本之间会额外引入毫秒级的延迟，适合简单的OLTP的场景加上中等的OLAP的场景。

对于这两种方式，OceanBase通过一体化的存储引擎都会进行支持，通过一套数据库内核，同时实现OLTP和OLAP两种业务。

2.2一体化执行引擎

在混合负载下，肯定既有简单查询，又有复杂查询，对于简单查询，数据量小，那就由SQL层把数据从存储层拉上来。

复杂查询涉及到的数据量比较大，所以要并行执行，SQL层需要把执行计划推到存储层，降低网络开销。

这种推拉结合的方式，让执行引擎把简单查询和复杂查询很好地融入到了一套系统中。

2.3存算分离引擎

OceanBase是Share Nothing架构，但云端是Share Storage，两者之间似乎存在矛盾，如何融合呢？

OceanBase采用了LSM-Tree做底层存储，数据分为 基线数据+增量数据，在多个副本之间，基线数据是一样的，所以可以共享一份存储。

通过日志副本和仲裁副本的方式，进一步降低计算开销，最终用一个副本的存储，接近两个副本之间的计算的极小代价，在云端实现了弹性。

3.1一体化SQL

相比集中式数据库和单机数据库，分布式数据库有些事情很难实现，比如大事务，涉及到参与者，分区数特别多，分布式事务基本上不可能完成。

再比如锁表，如果表涉及的分区特别多，也不可能把每个分区都锁住。

本质的问题就是原生分布式数据库是一个分区一个独立日志流，使得锁表这样的操作和分区数成正比。

OceanBase则通过动态日志流的技术，把一台机器上所有分区动态融入到一个日志流，使得大事务，锁表的复杂度与机器数成正比，不与分区成正比。

最终实现分布式数据库与集中式数据库与单机数据库完全对标的SQL功能。

3.2 多模融合

OceanBase数据库不但可以支持多种模型，并且支持模型之间的互操作，真正实现了多模融合。

3.3 一体化产品家族

OceanBase围绕关键业务负载，提升关键生态能力。

比如OceanBase实现了很多关键核心业务要求的“变更操作可以回溯，回滚”，把企业的合规流程融入到了数据库开发者工作流程中。

很多关键应用，用户都要求新老系统长期并跑，一键逃生，不管新系统出现什么问题，都可以一键逃生到老系统。

最新发布的OceanBase 4.2.1 LTS是首个长期支持、可规模化使用的一体化数据库，具备OLTP完整的核心功能。

在以上描述的核心技术支持下，它性能更强，TP性能是3.2版本的1.9倍；AP性能是3.2版本的2.7倍。

通过引入基于仲裁的无损容灾方案，通过两个副本实现RPO等于0。

在OceanBase列存实验室版本展示中，与业界业内顶流列存数据库ClickHouse跑分PK，结果不仅性能处于同一水平，甚至还快了那么一点点。

对数据库这个产品来说，其实用户并不关注底层的具体实现，集中式也好，分布式也罢，行存也行，列存也行。用户关注的是使用体验，是不是高可用、高安全、高性价比。

OceanBase在这一点上做得很好，它在不断解决各种场景问题，尤其是关键业务处理时，摸索出了一套最佳实践，形成了一体化的解决思路，这就是OceanBase最惊艳的地方。

当然，一体化不是简单的拼装组合，也不是要解决所有的问题，就像有了手机、电视，我们还是回去电影院看电影一样，在特殊领域还是需要用专业的数据库的。

用技术让海量的数据管理和使用更简单，希望OceanBase持续打造能够承载关键业务负载的一体化数据库，不断满足客户的需求。