您可能并不了解的OceanBase厉害之处

产品定位

OceanBase是由蚂蚁集团完全自主研发的国产原生分布式数据库 ，始创于2010年，创新推出“三地五中心”城市级容灾新标准 ，是一个在TPC-C和TPC-H测试上都刷新了世界纪录的国产原生分布式数据库。产品采用自研的一体化架构，兼顾分布式架构的扩展性与集中式架构的性能优势，用一套引擎同时支持TP和AP的混合负载， 具有数据强一致、高可用、高性能、在线扩展、高度兼容SQL标准和主流关系数据库、低成本等特点。

作为一个有着10年+DBA经验的“老司机”，本文将从四个维度介绍 OceanBase（以下简称OB），同时说明其与Oracle、DB2以及TiDB的区别，不涉及技术细节，同时与大家分享我本人的一些心得体会。如有任何不妥之处，请不吝指正。本文仅代表我个人观点，不涉及公司立场，望周知。

1. 分布式架构

首先，我们来了解一下OB是否属于分布式架构？答案是肯定的。当我第一次了解到OB的时候，直观感觉这就是DPF+TSA+HADR。

从单表（非分区表）数据分布上，OB与DB2 DPF是有区别的：后者的单表数据是分散在各个机器上的，不可避免的会发生分布式事务，因此后者更适合OLAP业务，而前者更适合OLTP业务，因为OB通过表级别数据不打散实现分布式框架下的非分布式事务。

从单表（分区表）数据分布上，OB的单个分区表在分布形式上和单表是完全一致的（后续讲解）。因此，OB也适合OLAP业务。

单表（非分区表）或者分区表，从本质上来看，OB是一个主从复制结构（ OceanBase 数据库基于 Paxos 协议实现了高可用选举和日志同步协议 ），举例来讲：如果有3个节点，只要保证其中2个节点的日志落盘即可提交本事务（多数派原则）：相当于DB2 HADR的Sync模式和Oracle Data Guard的最大保护模式。因此，OB在这里节省了一次日志确认等待的时间，而TiDB使用的Raft协议需要再次确认（似乎可以实现内存级确认即可，但呵呵而已）。但在某些异常场景下，OB回滚时间相对较长（RTO<30秒，具体原因请查看：Paxos & Raft 区别）：任何分布式技术架构当前都无法做到两全，OB选择了性能，相信大家也可以理解，OLTP应用，你不要性能你要啥？ 而且leader节点机器宕机的概率在现在的技术条件下还是可以接受的。这个时候可能会有内行的同学们站出来说， 生产环境 DB2，Oracle的高可用配置方式都是：NearSync，最大可用性，是不是OB在性能上会差那么一丢丢？ 各位看官，请看如下分解。

2. OLTP能力

OB的读写分离架构精华

1）基线数据是指持久到磁盘上的数据，一旦生成就不会再修改，称之为 SSTable。

2）增量数据存储在内存，用户写入都是先写到增量数据，称之为 MemTable，通过 Redo Log 来保证事务性 。

我给大家用白话讲解一下：

增量数据用一句话来解释，就是DML（insert/update/delete）都可以在内存里完成相关操作，相比于DB2、Oracle的内存数据查找模式：Hash值->Hash链表->内存数据块->记录（DB2和Oracle在概念上可能有所不同），OB直接写内存的方式速度明显会更快。相较于传统数据库常出现的热点行、热点块、热点链，OB自然而然的都可以解决（包含如下介绍的row cache），DBA又少了一个调优的场景。读写分离架构也有缺点：读路径变长，数据需要实时归并可能带来性能损耗，需要合并减少数据文件。正常情况下数据库都是读多写少， OB又是如何巧妙的解决？咱们继续往下看。

多Cache机制

官方定义：

Cache 主要用于缓存 SSTable 中频繁访问的数据，有用于缓存 SSTable 数据的 block cache、有用于缓存微块索引的 block index cache 、有用于缓存数据行的row cache，也有用于缓存 bloomfilter 可以快速过滤空查的 bloomfilter cache。读请求来临时，首先从 Cache 中读取数据，如果 Cache 没有命中会产生磁盘 IO 读取微块数据，可以根据 Cache 命中次数及磁盘读取次数来计算逻辑读，逻辑读用于评估 SQL 执行计划的优劣。对于单行操作，如果行存在，则会命中 row cache ；如果行不存在，则命中 bloomfilter cache。

我给大家用白话总结一下：

在这里OB又回归到DB2、Oracle等传统数据库的解决方案，性能不好，内存来干。OB不仅有Block Cache, 同时还具备特有的能力： bloomfilter和行缓存，而且还是针对全部类型的表。同时OB的表为索引组织表而非堆表，这速度杠杠的。

对于企业核心的应用，建议根据不同的等级和复杂程度使用不同的OB集群规格。而企业里70-80%的应用其实并不复杂，而且数据库里单表容量大多小于100G（大部分单库容量小于100G），如果这类系统大于15+套，在这种情况下，可以考虑选择搭建OB集群，利用OB提供的tablegroup和设置Primary Zone的能力，将类似应用的表绑定在一个OB节点上，避免分布式事务，速度飕飕的。就如刚才所说， 一套OB集群就搞定这么多套系统，这堪比DB2的大机和Oracle的一体机。所以可以在硬件，软件的维护上大幅度降低成本，提升效率。DBA看到这里是不是心里凉凉，开始想后路在何方？ 如果您仔细看了OB的操作手册和OCP的白屏化运维功能，可以发现OB这么做简直就是不给DBA活路。

3. OLAP能力

分区表和复制表

传统数据库都有分区表的概念，但对于OB来说，每个分区表都会被OB调度至合适的节点并作为leader角色对外提供服务，OLAP应用是最考验数据库架构师能力的地方，尤其是DB2 DPF、OB这样的架构，您需要最大程度的保障参与计算的表按照合适的分区规则均衡的分布到对应的机器上，避免数据倾斜（高超的逻辑设计能力），充分发挥多节点并行计算的优势。作为DBA，OLAP可能是你可以最后一战的地方。但随着200+内核，T+级别大内存以，内存直接访问技术，SSD和万兆网络的普及，DBA最大的价值：性能优化还剩几分？

同时如果您使用过DB2 DPF，对于OB的复制表概念肯定不陌生，本质就是小的关联表放置于参与计算的所有节点，这样可以最大程度的避免分布式事务，最大限度的提升多节点并发处理的能力，从而实现分而治之的架构理念。

数据文件顺序读

对于OLAP应用来说，大部分场景都是大数据量的读+多表Join运算（事关优化器以及逻辑设计），由上可知，OB的

SSTable本身就是顺序写入以及IOT特性，数据块内记录较内聚，关联性较强。在相同的业务情况下，相比Oracle、DB2堆表（数据块或者页大部分30%空间空闲）和表空间设计, OB可以做到：

1）更快的顺序读取数据文件；

2）更少的数据块读入内存，并减少内存占用；

3）更少的内存块内扫描运算。

因此OB在大数据量运算场景下 Plus 高压缩能力使得整体计算速度更快。

对比于DB2 DPF，在架构上OB与其难分伯仲，但在可扩展性上，DB2 DPF则大大的不如OB。

相较于Oracle、DB2等商业数据库，再厉害的优化器如果存在架构的限制（想当年Oracle的优化器也是很差劲的，老DBA应该最深有体会：这该死的Hint），如何才能与OB的大集群去PK呢？

相较于TiDB，存储与计算分离的架构虽好，但OB的计算和存储一体化，在性能上，个人认为OB更胜一筹，因为数据就是需要就近处理的。很浅显的道理，TCP/IP网络交互的时延问题会拖慢交易的速度，尤其是高并发的时候。

4. 超高性价比

多租户

这简直就是OB的大杀器，如上所述，OB可以整合小应用和大应用（严格的资源隔离控制，避免租户间相互影响），可以为企业大大的节约成本。

目前OB对租户进行严格的资源隔离控制，即使某个租户出了问题，也不影响其他应用。但从我的角度来看，反而待优化的点在于目前OB租户资源管理上更加智能化，根据租户的使用情况自动调整，正如DB2所做到： 1） 支持向OS申请获取更多的内存资源； 2） 支持bufferpool空间的自动转换。亦或是Oracle目前做到的SGA自动调整的方式。我相信这个能力OB迟早会推出，如同当年Oracle推出的Automatic Undo Tablesapce(懂的都懂哈)。

高压缩

事物都具有两面性，前面谈到了读写分离架构的缺点，那下面再来说说优点：

官方说法：

读写分离架构的优点：因 基线数据是静止状态，方便对其进行压缩，减少存储成本和提升查询性能；做行级缓存不用担心写入带来的缓存失效问题。

个人理解：

DB2使用字典压缩，Oracle则对数据块内数据压缩，SAP HANA则是根据列进行数据压缩，OB做到了三者的融合。

数字说话：

Oracle、DB2以及MySQL迁移到OB之后，大部分可以实现5到10倍的压缩比（场景不同，压缩效率可能稍有不同）。

节约的隐形成本

1. 运维和硬件投入成本

1） 硬件更换

目前市场上大部分X86机器的推荐使用年限为3年（Power机器大部分在5年，甚至部分能够达到10年），OB的架构体系允许您在不影响业务的前提下通过简单的节点替换操作即可方便完成，无需传统运维中对系统管理员，DBA甚至于业务的影响。这就是数据库云原生的魅力所在。

2) 硬件缩容

OB通过简单方便的缩容操作释放“大促阶段”临时到加入集群的硬件，从而使这些硬件资源在企业层面得到更有效的利用。

3) OB通过系统化思维改变了数据库的运维模式：

(1）1个DBA可以管理10+套OB集群，一套OB集群处理10+业务：1个DBA即可处理中型企业的大部分数据库业务，这将极大降低人力资源成本；

(2）DBA从数据管理转向业务数据管理，更好的服务于业务，为业务赋能，这个才是DBA的最终价值；

通过自身对业务的认知，

合理规划OB集群资源（主要指租户资源），提升资源的使用效率，最终提升ROI；

合理规划业务数据布局（主要指业务类型），提升系统吞吐量，满足业务诉求。

2. 开发成本

1）OB支持标准的SQL语法，程序员无需再次学习，学习成本几乎为零；

2）依托于OB的高性能，无需引入缓存方案（Redis,MemCache等），程序员可以更关注于业务自身逻辑，提升开发效率（这同样也将减少开发人员和其他硬件资源的投入）。

3. 业务改造成本

1）OB提供MySQL和Oracle两种模式，业务仅需极小改造甚至无需改造即可轻松适配OB；

2）OB提供OB CDC（OMS），您可方便快捷的迁移历史数据和增量数据至OB以及同步OB的数据至下游系统。

4. 提升业务处理效率

1）依托于OB HTAP能力，业务再获得更高性能的同时，可以更高效的获取业务分析数据，从而最快速的做出决策（这同样也可以减少其他分析类产品的投入）

2）依托于Procedure/PL SQL的成熟应用，您可以更快的响应业务变化，使企业适应的快速持续的变化（这同样减少了开发资源的浪费）。

您可能并不了解的OB惊人之处

1. OB 1.4.X版本MySQL模式的表（分区表）具有高达3000亿+记录（目前OB的最新版本为3.2.3）；
2. OB 2.X版本，3.X版本MySQL模式的表（非分区表）具有高达150亿+记录；
3. OB的单个文件已高达150T+；
4. OB创建索引速度超快（3列非唯一索引），150亿+记录的表在40+分钟内创建完成 -OB专有 ；
5. 回收站可以做到租户级别（相当于Oracle的实例级别） -OB专有 ；
6. 可方便的进行缩容操作，不必进行Rehash或者Rebalance操作 -OB专有 ；
7. 数据库内核级限流能力 -OB专有 ；

8 . 在线灰度集群升级能力 -OB专有 ；

9. 事务级打标的能力，防循环复制的利器：OB做到了表级别，真的逆天 -OB专有 （稍后介绍OMS会说明这点）；
10. 支持灰度切流的能力 -OB专有 （稍后介绍OMS会说明这点）；
11. 超预期的大表 在线DDL能力：毫秒级 -OB专有；
12. 同一集群租户支持Oacle和MySQL模式，OB与MySQL, Oracle兼容性做得越来越赞了 -OB专有 ；

特殊说明一下：OB仅仅是做语法兼容，底层体系架构完全不同：PS: 没有完美的技术，只有会使用的人。

13. 在OB集群上层搭建分库分表方案（如果您的业务超级庞大） -OB专有 ；
14. 链式数据校验，是传统数据库和基于国外开源的魔改库不具备的，库 >> 表 >> 分区>> 微块 >> 宏块 ，即使数据块被外部采用源码级修改，仍可借助链式数据校验 -OB专有 ；
15. 定期校验--- 防静默错误，PC Server相比Power机器，其硬件标准下降很多，这意味着静默错误将影响数据的质量 -OB专有 ；

16 . 支持 弱一致性读（即备节点读能力，相当于HADR的ROS 以及ADG的备机可读）;

17. 多线程模型（简洁之美，无语言表：目前Oracle在Linux/AIX上还是多进程模型）；
18. 相比其他数据库，OB在客户侧POC之强势，简直不要太震撼；
19. 原生分布式和非原生分布式数据库对比表：

有图有真相

强架构优势示例

暂不显示

提效降本示例

强大深厚的技术功底示例

客户之声

DBA的焦虑

数据库目前的整体趋势是分布式+大内存，对于OB而言，以前某些数据库常规的操作：降低表空间高水位，使用表压缩，Reorg table，调整表的PCTFREE和重构表组织形式等大部分运维操作在OB上您根本无需作此操作。您的最大价值就是，从DBA的角度，尽快熟悉业务，让公司的业务顺畅的运行在OB上，为业务赋能。

我为什么这么讲？主要有一下三点考量因素：

1．大内存模式下可能让您的SQL优化技能大打折扣（稍后解释于SQL优化之我见）；

2．原生的多副本能力让您无需考虑容灾架构，无需关心底层技术细节：Oracle的DataGuard，DB2 的HADR，MySQL的主从等等，可以统统丢掉了；

3．专业的DBA还需要懂网络，懂存储，懂服务器，懂操作系统，那么现在您仅需懂得网络+数据库即可，您的技能优势又被削弱了一半。试想，如果有其他同学想进入DBA领域，其学习时长将大大缩减，您的先发优势又剩几何？

SQL优化之我见

本人在Oracle 10G，11G，12C&DB2 LUW 8.1，9.5，9.7，10.5上做过SQL性能优化，最终发现性能不好的原因主要有以下三点：

1．数据库使用不当（未收集统计信息、未正确收集统计信息以及表结构设计和物理设计等）；

2．数据量太大（未做表分区）；

3．硬件资源不足（与2有关联性）。

大部分情况下还是硬件资源不足。举两个案例，这次不说OB，只说传统数据库。本人之前有幸参与了某公司大部分核心系统的改造：U(AIX)/W(Windows) to L(Linux)，我举两个案例进行说明：

1．一套Oracle RAC系统（12T+，AIX），未迁移前，其中最关键的Job需要跑15-16个小时，有时候跑到24个小时，这个时候应用同学就跑过来“兴师问罪”，因为报表出不来，业务已经开始骂人的；迁移至Linux服务器后（机器内存 700G+，SGA给到：260G+，不敢设置过大，我的担心您懂得，谁知道碰着啥Bug），这个Job正常运行时间均在10个小时之内，完全满足业务需求，而我仅仅是迁移了这套系统，还未开始做优化。其中一个小插曲，这个系统迁移前一年业务方已经规划要将其迁移至Hadoop（业务已经无法忍受如此缓慢的系统），在迁移之后，业务方找到我说要把这些关键任务迁移到Hadoop上（搭配上服务器+服务费等等，预算2000万+），在和各方讨论后，我们否决了这个方案，因为：

1）架构设计复杂，后期维护困难;

2）链路稳定性无法得到保障；

3）再满足业务要求的前提下搞重复建设浪费公司资金。

2．一套ECC DB2系统（42T+，AIX），主要问题就是EMC存储资源不够用，后续扩容难度太大。迁移至Linux服务器后（机器内存 2T，数据库内存给到：360G+，还是不敢设置过大）, TPS直接由以前的400，飙升至800，数据量通过压缩降至12T，大部分核心Job平均节省时间30%起。在迁移过程中我们重新进行了表空间/容器设计和开启数据库表压缩，但也仅此而已。还有一个小插曲，这套系统后来想迁移至SAP HANA(6T内存), 结果连HANA也hold不住。

通过以上两个案例，我想说的是提升硬件资源上述三个问题大部分都会得以解决。那我们回到OB， OB通过准内存处理可以更好的解决上述问题（SQL优化器以及“理解业务”同样重要）。

未来在何方？

架构设计是IT行业重中之重，古语有云：三岁看老，个中缘由，请各位看官自行体会。

OB的技术架构在目前来看已经远超同时代所有关系型数据库产品。以产品以及商业化视角来看，目前其处于类似Oracle 10G时代，虽然还存在不足之处，但这也正是DBA可以发挥作用的时候。重申一次：所有技术架构都不能覆盖所有场景，必须以组合拳的形式设计系统，同时，尽量不要给系统做加法，而是做减法，尽可能减少Redis，MemCache的使用（没性能问题别乱用），甚至是Mongo，Hadoop的使用，否则今后的日常运维，问题诊断，ETL及同步链路等问题会将消耗大量的人物财。个人仍然认为（老DBA的“朴素想法”）您还需要善于利用Procedure/PLSQL等数据库高级功能，根据业务需求，降低企业在此类应用的开发成本，即使后续业务发生变化，Procedure/PLSQL也能方便的进行变更。因此未来的关系型分布式数据库须具备完善的HTAP能力。因此现在数据库选型至关重要，一旦确定之后再进行变更，就无异于再次换血。

说个闲话

在某公司的工作结束之后，后来我了解到：他们已经做到了赋能业务，已经从单纯的成本中心成功转型成了盈利的业务中心。您呢？如果真如我所言，您的未来在何方？

术语表

参考资料：

OB 3.2.3文档: https://www.oceanbase.com/docs/oceanbase-database/oceanbase-database/V3.2.3/what-is-oceanbase