结合OB Cloud区别于MySQL的4大特性，规划降本方案

任何一家企业想要获得持续性的发展与盈利，“降本增效”都是难以绕开的命题。但是“一刀切”的降本影响往往不太可控，成本的快速收缩往往会给业务带来低效运营和增长缓慢的风险。所以我们所说的降本，是指在成本降低的同时，效率不降反增，这才是企业真正意义上的降本。

在传统集中式数据库统治数据库领域的多年里，“如何实现真正意义上的降本”成为众多企业 IT 部门头疼的问题。本文根据 OceanBase 解决方案架构师高继威在「OB Cloud 公开课」的分享整理而成，通过 OB Cloud 与 MySQL 的对比，分析如何帮助企业实现“降本增效”，并结合中小型公司、大型公司的典型案例，规划可供参考的降本方案。

近年来，各个企业“降本增效”的力度在加大，很多时候企业要通过缩减资源才能达到目标。尤其是对于软件技术架构最底层的基石角色数据库来说，通过缩配来降本，意味着很大的风险。

所以，如何保证在极限吞吐量且不损失、性能稳定的前提下完成降本目标，变得至关重要。这也是 OceanBase 正在做的事——通过技术降本。我们先将 MySQL 与 OceanBase 做一个整体的比较，如下图所示：

MySQL 的第一个痛点，实例多且复杂。MySQL 不同的实例资源利用率不平等，有的资源利用率高，有的利用率低；多实例的运维难度也随之增大。而OceanBase是原生分布式数据库，可以单集群通过多租户进行实例整合，降低运维难度的同时提升集群整体的使用率。
MySQL 的第二个痛点，数据无压缩。MySQL 是 B+ 树的存储结构，这个结构已经有很多年的历史，但是有个不可绕开的点，就是 B+ 树的每个页内必然会有一定的空隙。而 OceanBase 采用完全自研的 LSM-Tree 存储结构，结合了独特的压缩算法，把原有没经过压缩的数据压缩到 MySQL 的 1/4 到 1/5，甚至更高的压缩比，从而降低存储成本。
MySQL 的第三个痛点，弹性差。因为 MySQL 的主备结构，如果要扩容的话，是要更换机器的。而换机器就必然要经过主备切换，此时应用就会发生闪断，影响比较大。为了避免这种情况，往往需要常态化维持业务高峰级别的流量。比如说，大部分时间可能一个 8C 就足够，但是因为在业务高峰有 16C 的要求，所以必须长期保持 16C。OceanBase 具备快速弹性扩容的能力，从而让你可以在需要的时候设置规格，不需要的时候就降下来，节省很多成本。
MySQL 的第四个痛点，分析能力弱。MySQL 是纯粹的 OLTP 数据库，为了应对一些分析型报表的业务，需要单独进行数据迁移，再搭建分析型的实例，实际成本也会因此翻倍。而 OceanBase 是 HTAP 的数据库，可以 All in one，让大多数不太复杂的业务都集中在上面去处理，并且无需分析实例，通过二者合一实现降本。

针对 MySQL 架构存在的一些资源利用率不高、冗余浪费较多的固有问题，OceanBase 进行针对性解决，以达成综合降本的效果。OB Cloud 通过技术能让总 TCO 下降 30%，详情可阅读《OB Cloud：如何为用户提供可持续的降本增效？》。

特性解读之前，首先，简单为大家介绍一下 OceanBase 的系统整体架构，大家关注五个关键词：OBProxy、OBServer、Partition、Zone、Paxos。

OBProxy：应用连接到 OceanBase 会通过一个名为 OBProxy 的组件，它跟大家认知中的其他中间件不太一样，是一个非常轻量的节点，所以它也不存在 SQL 去做聚合等运算的逻辑，而是只负责 SQL 转发，在 OB Cloud 上的 OBProxy 不用额外付费，所以大家在使用中可以基本忽略这个组件。

Zone：Zone 在 OB Cloud 中对应的机房/可用区，OceanBase 集群默认三机房部署。所以说 OceanBase 默认具有机房级的高可用性，一个 Zone 里面可以有一台或者多台 OBserver，一个 Zone 里有很多 Partition 组成。
OBServer：即 OceanBase 的服务节点，也就是 SQL 或者存储的主节点。然后一个 Zone 可以有一个或多个 OBServer，OceanBase 可以在横向的每个 Zone 里面去加 OBServer，来实现非常强大的横向拓展能力。
Partition：直译是分区，它是 OceanBase 的负载均衡的最小单位，如果表是分析表，那么 Partition 就是分析表的一个分区；如果不是分区表，那么 Partition 就是这个表。
Paxos Group：比如图中 P7 分区的三个副本分别分布在三个 Zone 上面，它们是对等的关系。OceanBase 跟 MySQL 的主备模型不同，它是利用 Paxos 的共识算法去实现这个副本的同步。然后 Paxos 的最大特性是自选举，不需要外界来干涉。3 个 P7 会自动选举出 leader，这时候 leader 在 Zone1。

OceanBase 跟 MySQL 的主备模型不同，而是利用 Paxos 的共识算法去实现副本的同步。Paxos 的特性是自选举，不需要外界来干涉。比如图中的 3 个 P7 分区会自动选举出 leader，这时候 leader 在 Zone1。相比于 MySQL 的主从复制，MySQL 的主要把需要同步的数据转成 binlog 逻辑日志，然后再同步给备机转回物理日志。

Paxos 没有这么复杂的转换，所以时延更小，可靠性更高。任何时刻 Paxos 的三个副本里都需要两个副本同意才可以去完成leader的选举和日志的提交，所以OceanBase能够在任何机房级故障下不丢失任何数据。任意级别的故障，OceanBase 都可以在 30 秒之内完成恢复服务，在我们最新版本，这个时间甚至可以降到 8 秒，可用性相比 MySQL 大幅提升。

一、单集群多租户整合实例：提升资源利用率，降低运维难度

左图代表一个应用对应一个数据库实例，是我们目前最常用的部署方案。但下面的多个数据库实例会有个非常常见的问题，资源利用率会非常不平。举例来说：

数据库实例 1 是对内的一个 HR 系统，日常流量非常小，资源利用率可能只有常态化的个位数，5%-10%；
数据库实例 2 是交易波动比较大的系统，如秒杀、电商系统，资源利用率的波动非常大，3%-80%；
数据库实例 3 是比较危险的系统，长期处在比较危险的水位。

这些系统，无论是 DBA 还是运维同学去维护时候，都要同时在控制台上查看多套 MySQL 实例，运维复杂度比较高，风险也比较大。

OceanBase 下有非常多台机器和资源可以部署成一个资源池，然后我们在资源池里，为每个租户定向划分一部分独属于它的资源，由此在 OceanBase 中一个租户就可以承载原来的一个实例，从而让你原来运维多套 RDS 实例或者 MySQL 实例，变为运维一套 OceanBase 集群。

这带来的好处就是租户的规格可以随时随地动态调整，也不用担心业务产生影响，从而可以非常灵活的调度所有资源，提升整体资源利用率，降低成本，并且此时也无需挨个查看 RDS 实例，直接管理一套 OceanBase 集群就可以，运维难度显著降低。

二、LSM-Tree 高级压缩引擎：显著降低存储成本

OceanBase 的存储引擎是基于 LSM-Tree 自研的一套高级压缩的存储引擎，它和 B+ 树不同，其写入会先放在内存，当内存写到一定程度之后，会直接转储到磁盘，然后在每天的业务低峰时间（默认是凌晨两点），将当天的所有转储整理一遍，并且压缩好放在基线 SSTable(ROS)数据里。通过这个被称作合并的过程，LSM 树存储结构的基线数据都是无空隙的，相比于 B+ 树的每个页中都会有一些空隙，所以 OceanBase 天然压缩比就要比 MySQL 好。

此外，OceanBase 在 LSM-Tree 本身能力的基础之上，又进行了两次压缩。

第一次压缩采用行列混存的存储格式，让数据在底层的微块（对应 MySQL 页的一个层次），由行存转成了列存，这样有非常多的好处，比如可以对列存的数据进行数据编码。

看图中的例子，我们在开发过程中经常会碰到重复率很高的字段，比如 RATE_ID 这个字段，就有 4 个值重复出现。这时我们就可以对应一个字典，比如图中的 ID 列的 1901321 对应 0。将这个字典存储好的情况下，这时候每个列只要存 0/1/2 之类的值，以此极大程度地压缩存储。在实际的程序中，有非常多类似这样的案例，OceanBase 会自适应为它们设计一套适合的 encoding 编码方法。

在经过第一次压缩之后，100G 的数据就有可能压缩成 30G。在这个基础之上，OceanBase 还会对 30G 的数据再进行一次通用压缩，给它再“瘦”一次身，这时候就是 LZ4 或者其他通用压缩算法。

经过第二次压缩后，这个数据可能就变成 15G 了。也就是说，在 MySQL 中100G 的数据可能到 OceanBase 上就只有 15G。在实践中，我们很多客户已经达到小于 15% 的比例，极大程度节省存储成本。

有人说，OceanBase 这么高的压缩比，会不会对实时的读写产生影响，实际上是不会的。因为 LSM-Tree 的数据压缩发生在每天合并的时候，合并往往在凌晨两点之类的时间，用户可以自由选择业务低峰期。对于白天高频使用的时候，不会受到压缩带来的性能损耗，而能享受到高压缩比带来的存储成本降低。

三、快速弹性扩缩容：轻松应对峰值压力

OceanBase 的多级弹性伸缩能力可以随业务的发展，动态、随时地调整集群的资源，费用也可以根据用户的需求进行灵活的动态调整，给运维提供了非常大的灵活性。OceanBase 的弹性能力分为三个层次：租户级、机器规格级、机器数量级。

◼︎ 第一级弹性伸缩：租户规格调整

OceanBase 作为分布式数据库，内部把多台机器统一规划为一个资源池，资源池中又可以进一步划分一个个隔离的资源组，每个资源组就形成了一个租户的概念。租户的存在，带来多级弹性伸缩的第一级。因为租户是 OceanBase 内部资源的划分，对租户规格的调整不涉及物理层面的资源调整，完全由 OceanBase 内核完成。这就使得 OceanBase 租户规格的调整，可以秒级生效，整个过程对应用完全无感知。

运维人员在数据库操作过程中，可以在任意时间（比如白天正常业务进行时），调整租户的 CPU 核数和内存大小，整个租户的极限 TPS 就可以得到平滑提升。

◼︎ 第二级弹性伸缩：机器规格调整（垂直扩缩容）

面对相对较大的业务流量，简单调整租户规格可能还无法满足业务需要，这时候就需要扩大机器规格。比如，把集群从 30C 的规格扩容至 62C，来应对业务大流量。由于 MySQL 的扩容过程就是一个主备切换的过程，会对业务有闪断的影响。而 OceanBase 是通过 Paxos 协议进行节点间的数据同步，Paxos 协议核心点是自选举，一份数据的三个副本投票表决出谁来当选 leader，以及该日志是否提交。

这一点相比于 MySQL 主从复制，带来了两点优势：

OceanBase 的数据同步单位更小，带来更高的性能和灵活性。OceanBase 的 Paxos 组以分区为单位，相比于 MySQL 节点级日志同步，分区粒度更小，避免了 MySQL 为保证全局顺序带来的性能影响。并且 OceanBase 支持分布式事务的能力，还允许不同分区的 Leader 不在同一个节点上，比如上图中深蓝色的 Leader 节点就分布在三副本中，实现多点写入的能力，可以充分利用多机性能，并支持下面增加节点的扩展方式。
OceanBase 的同步日志更轻量，代价更小。OceanBase 的 Paxos 协议同步的日志为 OceanBase 内部的物理日志 clog。而 MySQL 的流程是主生产逻辑日志binlog，binlog 同步给备机后转化成 relay log，再执行的过程。OceanBase 的 clog 更轻量，更高效，配合 Paxos 分区级的同步粒度，OceanBase 不会有 MySQL 令人头疼的主备时延问题。

体现在扩缩容操作中，更换机器规格时，OceanBase 也需要先挂载一台机器同步数据，但切换时 OceanBase 只需要进行一次 Paxos 的有主选举，也就是 leader 完成自己最后一个日志提交后，主动放弃 leader 身份，然后主动投票给另一个节点，完成平滑切换。相比于需要闪断的 MySQL 主备切换，OceanBase 升配的整个过程对应用基本透明无感知。

◼︎ 第三级弹性伸缩：机器数量调整（水平扩缩容）

这是 MySQL 主备架构做不到的一点，因为 OceanBase 是原生的分布式数据库，支持分布式事务，所以可以做到无感知的横向扩展。更直观的说，就是 OceanBase 集群增加机器，业务流量就会自动迁移到新增的机器中。并且在这个过程中，应用是没有感知的，可以像使用一个单机 MySQL 那样继续使用这个有多台机器的集群，这一点在很多工程实践中，被证实了是分库分表方案的更优解。

四、HTAP：一套系统完成 OLTP 与 OLAP 业务

MySQL 是一个标准的 OLTP 联机交易型数据库。所以 MySQL 的优化器能力天然比较弱，对于大表关联，结果特别大的查询支撑不足。大家可能也都碰到过，有可能 SQL 跑非常久，也跑不出结果；也没有办法做到灵活的资源隔离，往往大 SQL 会影响正常的 TP（联机交易型）业务。所以大家一般都不敢用 MySQL 去做分析型的业务。

那么业务有AP（分析型）的需求，该怎么办呢？传统的做法一般是通过异步传输，也就是 ETL 过程，打造一个专用的分析型数据库，去做 OLAP 的业务。这必然会导致多出两部分的成本：传输过程，分析实例。

OceanBase 是 HTAP 的数据库，可以把 OLTP 和 OLAP 的请求都放在集群里完成。那么为什么 MySQL 不能做到而 OceanBase 却可以呢？主要是OceanBase在四个方面强化了 AP 方面的能力：

OceanBase 的优化器是对标 Oracle 的企业级优化器。哪怕多复杂的多表关联 SQL（实际生产中有碰到过 10+表的 join），无论何种 SQL 写法，都可以优化成最优的执行计划，保障了 SQL 执行的代价最低；
前文提到过，OceanBase 在底层微块层面是列存储，而列存储对按列进行的分析型业务有一定的加速；
OceanBase 支持并行执行，可以将一个较大的 SQL 执行计划切分为多个较小的任务，启动多个线程来并行处理这些小任务。目前对于查询、DML、DDL 都可以通过并行执行来加速查询；
OceanBase 有向量化执行引擎，相比于火山模型按行读取数据，向量化引擎可以按批次读取数据，对大量分析的 SQL 更友好。

OceanBase 的 HTAP 理念是：一个系统、一份数据，All in one 解决所有问题，无需额外付费，无需增加专用的分析节点。在一套存储引擎、一套存储结构上，同时完成 AP 和 TP 的请求，以此来实现降本增效的诉求。

你可能会担心，在 TP 和 AP 都能做的情况下，怎样避免分析型的业务影响实时在线交易。针对这一问题，OceanBase 提供了多种资源隔离方式：

使用多个租户进行物理隔离——搭建专用分析租户
同一租户，使用不同可用区（副本）进行物理隔离——只读地址，实时分析
同一租户，使用不同资源组进行隔离——同一机器，资源隔离，实时分析

作为一个企业或运维人员，如何通过 OceanBase 的这些能力，站在应用者的角度去使用 OceanBase，为大家带来实实在在的“降本”呢？

整体而言，可以按照原有 MySQL 实例规格之和的 80%-95%，存储容量之和的 15%-20%，估算 OceanBase 集群的规格大小。下面我们通过两个例子，来具体看一下 OceanBase 降本方案的制定和降本效果的判断。

Eg.1 中小型公司

对于中小型公司，比如图中的例子，该公司有一个 16C 的 RDS，2 个 4C 的 RDS，以及 4 个 2C 的 RDS，这是一个非常常见的产品阵列。

16C 的 RDS，最大的库，用在公司核心的对外业务，资源占有率也比较高；
2 个 4C 的 RDS，用在一些二级业务，比如说库存、订单之类的系统，资源占有率可能相对较低；
4 个 2C 的 RDS，这些比较小的零散实例，用在内部的业务。

总之，这些库的资源占用率会根据他们业务属性的不同，有所波动，所以在运维时，也会比较麻烦。如下图所示，16C + 2*4C + 4*2C = 32C；3TB + 2TB + 1TB = 6TB，如果将其迁移到 OceanBase 上，一套 30C 的 OceanBase 集群，1.5TB 的存储就可以完全支撑所有业务，并且将原来的零散资源变到一个比较健康的水位。

在 MySQL 中，OceanBase 高可用版本对标 MySQL 的集群版，然后也要多可用部署，并且是独享规格。由于 OceanBase 是技术降本，所以这里将二者的总吞吐量进行了对比，在 sysbench read-write 1000 并发场景下，降本约 30%，具体数据见下图。

Eg.2 大型公司

某大型公司，该公司有 32C 的 RDS 支撑核心业务，16C 的 RDS 支撑二级业务，5 个 4C 的 RDS 支撑内部小业务。总体资源利用率与上个案例相差不大，总计算资源 32C + 16C + 5*4C = 68C；10TB + 5TB + 5TB = 20TB，此时如果在 OceanBase 上，一套 62C 的 OceanBase 集群加上 4TB 的存储就可以承载这套集群。

关于怎么去规划成本，这里简单介绍一下二者的区别。在 sysbench read-write 1000 并发场景下，在 MySQL 中，假设计算资源 68C 的话，会有 136C 作为备机，存在很大的资源浪费。而在 OceanBase 中，我们有 62C 的计算资源，通过主备打散的方案把所有机器利用起来，总成本降低约 40%，具体数据可见下图。