我刚开始工作时做一个OA系统，业务也比较简单，用户数也很少，数据很“单纯”，一个SQL Server数据库感觉就绰绰有余了。
后来互联网大爆发，尤其是移动互联网到来以后，数据越来越多，越来越杂。
图片
单机存不下来，又得搞分布式，分库分表；不仅仅是OLTP，还需要OLAP，HTAP……
公司被迫采用各种各样的文档数据库、列式数据库、键值数据库来应对，变成了大杂烩。
我时常在想，有没有一种的数据库，把这些问题统一解决呢？
解决不了全部，能解决80%也行啊。
答案是肯定的，那就是OceanBase。
OceanBase我在之前的漫画中给大家介绍过，它最早是为了解决淘宝和支付宝中海量数据处理而诞生的，完全自主研发的原生分布式数据库。
图片
OceanBase 已连续 10 年稳定支撑双 11，创新推出“三地五中心”城市级容灾新标准，在被誉为“数据库世界杯”的 TPC-C 和 TPC-H 测试上都刷新过世界纪录。
OceanBase采用了一种一体化的设计思路来解决数据库问题，包括一体化架构、一体化引擎和一体化产品，接下来分别给大家聊一下。
图片
1.一体化架构
一体化架构的意思是单机分布式一体化，实现数据可大可小。
如果企业规模小，数据量也小，完全可以把OceanBase做单机部署。实际上，OceanBase甚至可以部署到树莓派这样简单的计算机中，实现主备库的模式。
在企业的数据变大的时候，OceanBase能实现平滑伸缩，把单机变成分布式，对用户完全透明。
图片
2.一体化引擎
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.一体化产品
3.1 一体化SQL
相比集中式数据库和单机数据库，分布式数据库有些事情很难实现，比如大事务，涉及到参与者，分区数特别多，分布式事务基本上不可能完成。
再比如锁表，如果表涉及的分区特别多，也不可能把每个分区都锁住。
本质的问题就是原生分布式数据库是一个分区一个独立日志流，使得锁表这样的操作和分区数成正比。
OceanBase则通过动态日志流的技术，把一台机器上所有分区动态融入到一个日志流，使得大事务，锁表的复杂度与机器数成正比，不与分区成正比。
最终实现分布式数据库与集中式数据库与单机数据库完全对标的SQL功能。
图片
3.2 多模融合
OceanBase数据库不但可以支持多种模型，并且支持模型之间的互操作，真正实现了多模融合。
图片
3.3 一体化产品家族
OceanBase围绕关键业务负载，提升关键生态能力。
比如OceanBase实现了很多关键核心业务要求的“变更操作可以回溯，回滚”，把企业的合规流程融入到了数据库开发者工作流程中。
很多关键应用，用户都要求新老系统长期并跑，一键逃生，不管新系统出现什么问题，都可以一键逃生到老系统。
图片
4.OceanBase 4.2.1 LTS版本
最新发布的OceanBase 4.2.1 LTS是首个长期支持、可规模化使用的一体化数据库，具备OLTP完整的核心功能。
在以上描述的核心技术支持下，它性能更强，TP性能是3.2版本的1.9倍；AP性能是3.2版本的2.7倍。
通过引入基于仲裁的无损容灾方案，通过两个副本实现RPO等于0。
在OceanBase列存实验室版本展示中，与业界业内顶流列存数据库ClickHouse跑分PK，结果不仅性能处于同一水平，甚至还快了那么一点点。
5.总结
对数据库这个产品来说，其实用户并不关注底层的具体实现，集中式也好，分布式也罢，行存也行，列存也行。用户关注的是使用体验，是不是高可用、高安全、高性价比。
OceanBase在这一点上做得很好，它在不断解决各种场景问题，尤其是关键业务处理时，摸索出了一套最佳实践，形成了一体化的解决思路，这就是OceanBase最惊艳的地方。
当然，一体化不是简单的拼装组合，也不是要解决所有的问题，就像有了手机、电视，我们还是回去电影院看电影一样，在特殊领域还是需要用专业的数据库的。
用技术让海量的数据管理和使用更简单，希望OceanBase持续打造能够承载关键业务负载的一体化数据库，不断满足客户的需求。
