网站建设方案书模板,要压实互联网企业的什么责任,鞍山在网络做推广,百度云免费做网站任何一家企业想要获得持续性的发展与盈利#xff0c;“降本增效”都是难以绕开的命题。但是“一刀切”的降本影响往往不太可控#xff0c;成本的快速收缩往往会给业务带来低效运营和增长缓慢的风险。所以我们所说的降本#xff0c;是指在成本降低的同时#xff0c;效率不降…任何一家企业想要获得持续性的发展与盈利“降本增效”都是难以绕开的命题。但是“一刀切”的降本影响往往不太可控成本的快速收缩往往会给业务带来低效运营和增长缓慢的风险。所以我们所说的降本是指在成本降低的同时效率不降反增这才是企业真正意义上的降本。 在传统集中式数据库统治数据库领域的多年里“如何实现真正意义上的降本”成为众多企业 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 不用额外付费所以大家在使用中可以基本忽略这个组件。 ZoneZone 在 OB Cloud 中对应的机房/可用区OceanBase 集群默认三机房部署。所以说 OceanBase 默认具有机房级的高可用性一个 Zone 里面可以有一台或者多台 OBserver一个 Zone 里有很多 Partition 组成。 OBServer即 OceanBase 的服务节点也就是 SQL 或者存储的主节点。然后一个 Zone 可以有一个或多个 OBServerOceanBase 可以在横向的每个 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 的流程是主生产逻辑日志binlogbinlog 同步给备机后转化成 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 的 RDS2 个 4C 的 RDS以及 4 个 2C 的 RDS这是一个非常常见的产品阵列。 16C 的 RDS最大的库用在公司核心的对外业务资源占有率也比较高 2 个 4C 的 RDS用在一些二级业务比如说库存、订单之类的系统资源占有率可能相对较低 4 个 2C 的 RDS这些比较小的零散实例用在内部的业务。 总之这些库的资源占用率会根据他们业务属性的不同有所波动所以在运维时也会比较麻烦。如下图所示16C 2*4C 4*2C 32C3TB 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 68C10TB 5TB 5TB 20TB此时如果在 OceanBase 上一套 62C 的 OceanBase 集群加上 4TB 的存储就可以承载这套集群。 关于怎么去规划成本这里简单介绍一下二者的区别。在 sysbench read-write 1000 并发场景下在 MySQL 中假设计算资源 68C 的话会有 136C 作为备机存在很大的资源浪费。而在 OceanBase 中我们有 62C 的计算资源通过主备打散的方案把所有机器利用起来总成本降低约 40%具体数据可见下图。 所以我们认为应该将“降本”、“增效”两个词合起来看OceanBase 的“降本”是通过技术手段进行降本希望数据库的总体价值得到提升不管是数据吞吐量、高可用能力、Online DDL 能力等还是运维友好度都可以不随着成本的降低而丢失。 希望随着 OB Cloud 的不断成熟能为企业带来更多实实在在的价值在降本的同时效率不降反增实现真正意义上的降本。借此DBA、运维等同学也可以有更多时间为企业创造更大的价值。
