结合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%，具体数据可见下图。

所以，我们认为应该将“降本”、“增效”两个词合起来看，OceanBase 的“降本”是通过技术手段进行降本，希望数据库的总体价值得到提升，不管是数据吞吐量、高可用能力、Online DDL 能力等，还是运维友好度，都可以不随着成本的降低而丢失。

希望随着 OB Cloud 的不断成熟，能为企业带来更多实实在在的价值，在降本的同时，效率不降反增，实现真正意义上的降本。借此，DBA、运维等同学也可以有更多时间为企业创造更大的价值。

文章转载自公众号：OceanBase