前段时间通过几篇文章分享了TiDB的论文感悟，相信大家对TiDB这样一款基于NewSQL的HTAP数据库其设计理念及具体实现原理有了一些初步的认识。同样属于NewSQL的OceanBase，也是国产数据库中的佼佼者，近期也是一路高歌猛进直接拿下墨天轮排行榜No.1，我们当然有必要学习一下。
如今的OceanBase已经来到了4.x版本，与最早期的0.5版本在架构上已经相差甚远。在我的另一篇文章了解OceanBase的架构演进之路中已经介绍过OceanBase从0.5到4.x的架构演变历程。下面我们具体了解一下OceanBase这个架构演变的产生根源及解决思路。
|
一．OceanBase 4.x主要想解决什么问题？
早期的OceanBase 0.5版本通过拆分存储层和计算层，产生了显著的可伸缩性。为了进一步提高性能，OceanBase又实现了3.0，解决了0.5版本的单点写入问题，具有更高的吞吐量和更低的写入延迟，同时也对产品进行了开源。然而，OceanBase 3.0版本并不适合中小型企业，这可能是由于小型机器中的日志流和分区边界所带来的开销，以及部署期间分布式组件之间的交互所带来的额外开销。
分布式数据库解决了水平扩展可伸缩性的问题，但与集中式数据库（Oracle、MySQL、PostgreSQL等）相比，其单机性能和SQL功能明显较差。早期的分布式数据库主要是NoSQL数据库，如Amazon Dynamo，他们几乎没有SQL能力。后来出现了NewSQL数据库，如CockroachDB和Google Spanner，他们完善了SQL的功能。但这些NewSQL数据库普遍单节点的性能还不到MySQL的三分之一。
通常，用户需要在单机数据库和分布式数据库之间做出艰难的选择，即到底是选择用单机数据库还是分布式数据库。最典型的决策可能就是数据量了，如果数据量较小，就选择功能完善的单机数据库；如果数据量较大，就选择分布式数据库，从而牺牲功能和单机性能，并通过修改业务或增加节点来解决问题。
OceanBase 4.x正是想要解决这样的问题，不需要用户在单机数据库和分布式数据库之间进行艰难的选择，当数据量较小的时候，可以直接采用单机模式部署，当数据量或业务量增加导致单机不足以支持的时候，可以切换到分布式模式。
二．OceanBase是如何解决上述问题的？
针对上述问题，OceanBase在4.x版本中开发了一套混合的share-nothing/share-everything的数据库系统，它是一个单机分布式一体化的架构。更具体的，OceanBase实现了以下功能相关功能项。
（1）提出了Paetica单机分布式一体化架构。Paetica在单机和分布式系统中都具有独立的SQL、事务和存储引擎，支持用户进行动态配置切换。
（2）开发了单机分布式一体化的SQL引擎。可以通过串行和并行的方式支行SQL，可充分利用CPU多核。分布式场景中也能够跨多节点并行，高效处理SQL命令。
（3）构建了单机分布式一体化的LSM Tree存储引擎。包括对单机模式和分布式模式下的多种压缩优化，如增量主压缩（major compaction）、交错轮仓压缩（roundroin compaction）等，目的是在写性能和存储空间利用率之间进行平衡。
（4）实现了单机分布式一体化的事务引擎。主要提供了一个优化的两阶段提交协议（2PC），主要优化点是减少消息处理和日志量，从而减少事务延迟。在单机模式下，不需要采用两阶段提交，而是使用单个日志流来处理事务，也不需要访问全局时间服务(GTS)。
通过以上相关的改进，OceanBase也在论文中表示和单机MySQL以及分布式Greenplum都进行了性能对比测试 ，结果是OceanBase 4.0在小规模和单机情况下的性能优于MySQL 8.0，在TPC-H场景下对比Greenplum 6.22.1所有查询中都表现出了卓越的性能。
