对于追求持续发展的企业,“降本增效“已经成为必须面对的话题。然而,盲目采取“一刀切”的降本措施往往伴随着不可预测的风险,可能导致业务运营效率下降及增长变换。因此,如何在实现成本削减的同时,确保甚至提升运营效率,这才是企业实现真正意义上降本的根本所在。
在传统集中式数据库统治数据库领域的多年里,“如何实现真正意义上的降本”成为众多企业技术部门头疼的问题。本文通过 OB Cloud 与 MySQL 的对比,分析如何帮助企业实现技术上的“降本增效”,并结合中小型公司、大型公司的典型案例,提供可供参考的降本方案。
一、OB Cloud vs 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%以上。
二、OceanBase 特性解读
特性解读之前,首先,简单为大家介绍一下 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、多实例整合:提升资源利用率,降低运维难度
左图代表一个应用对应一个数据库实例,是我们目前最常用的部署方案。但下面的多个数据库实例会有个非常常见的问题,资源利用率会非常不平。举例来说:
- 数据库实例 1 是对内的一个 HR 系统,日常流量非常小,资源利用率可能只有常态化的个位数,5%-10%;
- 数据库实例 2 是交易波动比较大的系统,如秒杀、电商系统,资源利用率的波动非常大,3%-80%;
- 数据库实例 3 是比较危险的系统,长期处在比较危险的水位。
这些系统,无论是 DBA 还是运维同学去维护时候,都要同时在控制台上查看多套 MySQL 实例,运维复杂度比较高,风险也比较大。
OceanBase 下有非常多台机器和资源可以部署成一个资源池,然后我们在资源池里,为每个租户定向划分一部分独属于它的资源,由此在 OceanBase 中一个租户就可以承载原来的一个实例,从而让你原来运维多套 RDS 实例或者 MySQL 实例,变为运维一套 OceanBase 集群。
这带来的好处就是租户的规格可以随时随地动态调整,也不用担心业务产生影响,从而可以非常灵活的调度所有资源,提升整体资源利用率,降低成本,并且此时也无需挨个查看 RDS 实例,直接管理一套 OceanBase 集群就可以,运维难度显著降低。
2、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 的数据压缩发生在每天合并的时候,合并往往在凌晨两点之类的时间,用户可以自由选择业务低峰期。对于白天高频使用的时候,不会受到压缩带来的性能损耗,而能享受到高压缩比带来的存储成本降低。
3、快速弹性扩缩容:轻松应对峰值压力
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 那样继续使用这个有多台机器的集群,这一点在很多工程实践中,被证实了是分库分表方案的更优解。
4、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 理念是:在一套存储引擎、一套存储结构上,同时完成 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 云数据库现已支持免费试用,现在申请,体验分布式数据库带来全新体验吧 ~