OceanBase这次把我惊到了！ _OceanBase

我刚开始工作时做一个OA系统，业务也比较简单，用户数也很少，数据很“单纯”，一个SQL Server数据库感觉就绰绰有余了。
后来互联网大爆发，尤其是移动互联网到来以后，数据越来越多，越来越杂。

文章插图
图片
单机存不下来，又得搞分布式，分库分表；不仅仅是OLTP，还需要OLAP，HTAP……
公司被迫采用各种各样的文档数据库、列式数据库、键值数据库来应对，变成了大杂烩。
我时常在想，有没有一种的数据库，把这些问题统一解决呢？
解决不了全部，能解决80%也行啊。
答案是肯定的，那就是OceanBase 。
OceanBase我在之前的漫画中给大家介绍过，它最早是为了解决淘宝和支付宝中海量数据处理而诞生的，完全自主研发的原生分布式数据库。

文章插图
图片
OceanBase 已连续 10 年稳定支撑双 11 ，创新推出“三地五中心”城市级容灾新标准，在被誉为“数据库世界杯”的 TPC-C 和 TPC-H 测试上都刷新过世界纪录。
OceanBase采用了一种一体化的设计思路来解决数据库问题，包括一体化架构、一体化引擎和一体化产品，接下来分别给大家聊一下。

文章插图
图片
1.一体化架构一体化架构的意思是单机分布式一体化，实现数据可大可小。
如果企业规模小，数据量也?。?完全可以把OceanBase做单机部署。实际上，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相比集中式数据库和单机数据库，分布式数据库有些事情很难实现，比如大事务，涉及到参与者，分区数特别多，分布式事务基本上不可能完成。
再比如锁表，如果表涉及的分区特别多，也不可能把每个分区都锁住。
本质的问题就是原生分布式数据库是一个分区一个独立日志流，使得锁表这样的操作和分区数成正比。