开发者学习笔记【阿里云云数据库助理工程师（ACA）认证：从云托管到云专属-MyBase数据库专属集群（一）】
课程地址：https://edu.aliyun.com/course/3112080/lesson/19070
从云托管到云专属-MyBase数据库专属集群（一）
课程目标
学习完本课程后，你将能够：
1. 了解中大型企业数据库面临了哪些挑战
2. MyBase 数据库专属集群的特性以及如何解决中大型企业面临的挑战
内容介绍
一、中大型企业数据库面临的挑战
二、MyBase 数据库专属集群特性
三、使用MyBase 集群
一、中大型企业数据库面临哪些挑战？
云数据库服务
优势
1. Ali 内核，淘宝大促验证过的云数据库；
2. 高可用，99.99%可用性；
3. 全托管，简单易用；
4. 完善的备份、恢复、回档；
5. DAS，DMS 工具支持；
劣势
1. 贵，成本是ECS自建的1.4——2倍；
2. 灵活性差，不开放主机和数据库权限；
3. 底层运维依赖于阿里支持体系，不能自主操作；
ECS 自建
优势
1. 成本低；
2. 自主运维，从 OS 到 DB，掌控力强；
3. 从头到尾体现 DBA 价值；
劣势
1. 开源内核，不稳定，依赖社区做 bug 修复；
2. 自主搭建高可用，存在数据一致性漏洞；
3. 生态支持工具不完整，需要自主搭建；
4. 运维管理投入成本高；
数据库的使用方面，可以选择比如云数据库服务或可以通过ECS 自建完成，这两种产品有各自的优缺点。首先云数据库服务很明显的优点是内核是经过淘宝大促验证的，是一个非常稳定的内核，云上有几十万用户在使用。所以是特别稳定的，然后同时内置了全生命周期的管理的一些能力。劣势，贵一点，同时更明显的短板是不能开放主机和数据库的超级账号的权限，因为它是一个服务。 ECS 自建的好处与之相反，成本低，同时自主可运维， DBA 可登录到操作系统去管理。可以自建自己的运维平台。劣势，使用自建可以使用开源的内核，开源的内核可能不稳定。依赖社区去做 bug 的修复，这个时间是完全不可控的。同时要自己管理整个数据库的生命周期，在不同企业里面的管理水平参差不齐，特别是开源管理的工具也存在比较多的漏洞，可能会导致数据一致性的问题以及数据安全的问题，所以这是一个优缺点。
云托管数据库产品带给 DBA 的困惑
1.用了云数据库之后，DBA/运维人员的日常工作就少了，是不是就要失业了？
2.原来积累的一系列工具和自动化脚本用不了？
3.云数据库出了问题，因为没有权限，没有办法及时登录操作系统去手工干预解决，干着急？
4.运维的习惯全部被打破了，无法命令行操作，特别不习惯？
5.业务复杂度很高，云数据库没有办法个性化，不如自建灵活方便？
云托管数据库可能会给 DBA 带来一些困惑，比如企业如果用了云数据库， DBA 的运维工作就变少了。是不是会失业，原来企业里自己的一套工具，还有自动化的运维脚本是否可以使用？以及整个运维习惯都被打破了，不能用 mini 行去进行一些操作变得不习惯，业务复杂度也特别高，云数据库又不能定制化。可能没有自建那么灵活，那怎么办呢？来看一下 MyBase 数据库专属集群。
二．什么是 MyBase 数据库专属集群？
首先 RDS 是全托管数据库，全托管数据库里面有一个通用的规格，也叫入门级规格。可以当做高铁里的二等座。 RDS 的独享规格也就是企业级。这种规格可以理解是一等座。 RDS 专属规格，可以理解是商务座。
中大型企业上云催生了 MyBase 数据库专属集群
共用资源池 RDS 
独占资源、相互隔离 MyBase
MyBase主机级别独享，可以开放更多接口，同时杜绝客户间干扰最低配置：8c16g
RDS 不管是入门级还是企业级，其实都是共用资源池的，在同一个物理机里面会创建多个实例。这多个实例可能给客户 A 用，也可能给客户 B 用。所以物理机是不会暴露给用户的，因为如果用户能登录物理机，那用户就可以看到不是用户自己的实例的数据，这具有安全问题。其实对用户来讲只能看到这个实例自己。而且这个实例超级用户也是没有的，那就是 RDS 的这种状态。那么 MyBase 就把整个权限往下层了一层。给用户的是物理机，物理机上面创建实例全部都是客户自己的实例。因此自己的物理机可以暴露给用户。那么整个的权限还有管理都是可以给到用户的。所以整个使用可能会更加的灵活，资源之间可以相互隔离也会更好。因为 A 用户和 B 用户是不会有物理机之间的冲突的，像在左图共享池状态， A 用户可能会影响 B 用户或者 B 用户会反过来影响 A 用户，那么使用了 MyBase 这样的一个形态相互之间就没有影响了。因为物理机都是用户自己的。
MyBase 三大核心能力
自主可运为
灵活智能能力
高性价比
MyBase 核心能力一：自主可运维
客户现状：
客户的数据库实例较多，有专职 DBA ，自有运维体系，但是一般企业没有数据库内核研发能力，一旦遇到内核 BUG 将无法处理，严重时可能给企业带来灾难性经济损失。
RDS 现状：
RDS 有阿里云兜底数据库内核，但 RDS 是黑盒，没有登录主机的权限，没有开放 DBA 权限，无法满足用户的可自主运维诉求。遇紧急问题需要等 aliyun 工单处理周期长。成为用户弃用数据库服务的理由。
MyBase ，鱼和熊掌可以兼得：
MyBase 是RDS升级版本，拥有 RDS 的所有功能，同时开放 OS 权限，数据库 DBA 权限，内核兜底，还能满足客户的自主可运维诉求。（ PS ：既能自动驾驶，也能手动模式）
自主可运维的能力看客户现状就是客户自己的实力很多，有专职的DBA ，有自己的运维体系，有自己的一些乐藏的一些运维的脚本等。但企业里通常没有内核研发人员，所以一旦遇到 bug 的问题就有麻烦，严重可能会带来大的经济损失。比如数据库的 bug 导致数据丢失，这非常危险。 MyBase 是个黑核，灵活性不高，但数据库内核是很稳的，刚好与之相反。 MyBase 结合 RDS 的两个特点，使得它既能自动驾驶也能手动模式。内核层面使用的是阿里云非常健壮的内核，同时把权限开放出去这样能用户的 DBA 和用户自己的运维系统都可以与之相融合成为一个鱼和熊掌可以兼得的系统。所以第一个是自主可运维的能力。
用户画像
MyBase（ RDS 专属规格）用户画像：
自有 DBA 团队，并且希望掌控数据库和操作系统（有超级权限），
例如：
1. 在遇到问题时，用户可以直接登录 OS 排查，不需要等 aliyun 工单处理。
2. 用户不满足于 RDS 自带的监控指标和展示方式，需要部署企业原有的监控和 dashboard。
3. 某些应用系统需要数据库超级账号权限。
比如用户画像，在自由 DBA 的团队希望能够连到数据库的超级账号能够满足场景的需求。比如第一个，遇到问题的时候可以直接登录 OS 去操作，不需要通过工单去做交互，想要延迟会更好。第二个是用户比如有自己自带的运维体系，要去定制一些监控指标，整合企业里面自己的这种监控和 dashboard 这个也可以直接到 MyBase 主机上面进行部署。最后，有些应用程序也会用到数据库超级账号，那么也可以进行支持。
MyBase特性1：开放 OS 权限
因为开放了操纵系统，可以通过堡垒机来登录，也可以通过 Webshell 来登录。这个是用户自己来选择的。
MyBase 核心能力二：灵活智能
MyBase（ RDS 专属规格）用户画像：
1.业务发展迅速，高峰期不可预知，经常资源被打满影响业务。
2.等 DBA 扩容数据库需要时间，而且突发时间可能出现在半夜，影响DBA 休息。
希望高峰可以自动弹性升级和缩容功能。
为什么会出这样一个场景呢？很多业务会有突发的高峰，一旦遇到这种高峰的话，资源就会被打满。比如数据库资源被打满，打满可能会影响业务。特别是用户在搞促销的时候，业务量猛增。因为数据库没有弹性的能力，就导致这个促销没有达到实际的效果。可能还会损失业务的口碑，这就非常困难。第二，如果看到资源的使用率已经上升，然后去做扩容可能时间已经来不及，因为扩容本身也是需要时间同时响应也要时间。这种突发情况如果发生在半夜，其实也会影响 DBA 休息。看上图就可以看出， MyBase 实际上提供了自动弹性升级能力。左图是没有这种能力的发现业务 IQPS 到达了峰点之后就变平了没有办法飙上去。 MyBase 提供这个能力之后，这个数据库的使用资源比如超过了80%，持续一段时间后，立马又把规格从原来的比如是4 G和8G，就弹到8 G和16 G。这样能够快速的扛过这样一次洪峰，也不会影响 DBA 的休息，同时业务也不受损是一个非常灵活的功能。
MyBase 特性2：智能调度策略
紧凑分布
日常态：
优先填满一台主机后使用其他主机
均衡分布
高速发展态：
平均分布到主机组下的所有主机
• 提供灵活的调度策略，大促时利用均衡性策略分散业务压力，平时利用紧凑型策略成分利用资源，最高节省60%的整体成本。
• 灵活的资源弹性策略可解燃眉之急，本地快速弹升 CPU、IQPS 等资源，DBA 干预系统资源分配解决业务问题。
实际通过了这个数据库提供的一个调度的策略。提供紧凑型的调度策略以及提供均衡分布的调度策略。比如乐常态使用业务不会有突发的高峰的时候就可以使用紧凑型的分布。这样来压缩整个主机的数量提高性价比。如果业务是在高速发展状态，时不时有一个不可预期的高峰。这个时候可以使用均匀的分布。每个主机上面都有一定的可以弹的空间，这时一旦遇到高峰就可以有足够的空间弹上去。可以根据自己的业务这种发展的周期选择用紧凑分布还是均衡分布的策略。
用户画像
MyBase（ RDS 专属规格）用户画像：
1.教育或类似行业，有非常明显的业务周期，寒暑假业务量趋近于0.
2.按正常业务来配置资源，寒暑假资源利用率低下，成本高。
希望压缩成本。
第二个场景是教育行业，教育行业里面有寒暑假。到开学时，业务正常使用。到寒暑假实际是一个可能业务基本上趋近于0的状态。那么以往的用户使用 IBC 去构建系统，会发现 IBC 到寒暑假机器基本都是空转的状态。但它占着机房，还是要给机房付费，还是要给网络带宽付费就非常的不划算。
使用 MyBase 到了寒暑假的时候就可以用紧凑型的分布，然后把多余的主机替出来只保留少量主机。这样到开学的时候使用均衡的分布，然后实例做了一个腾挪。这样使得业务做好，做非常灵活的调配。既能够降低成本同时又能满足弹性的要求。
MyBase（ RDS 专属规格）用户画像：
要求主机级别安全隔离，不能容忍一台主机上有其他客户实例引起的安全风险。
要求主机级别资源隔离，不能容忍一台主机上有他客户实例引起的抖动。
那么在智能这块还有一个场景比如有一些用户，他对主机级别安全隔离的要求非常高，或者对性能隔离级别的要求非常高。他不能容忍其他的客户带来的安全风险，其他的客户使用带来性能的抖动。
MyBase 特性3：独立主机资源，安全隔离，杜绝干扰
MyBase 物理机级别的隔离使得 A 用户跟 B 用户完全没有资源使用的冲突或安全方面的冲突，完全杜绝安全风险以及性能抖动的风险。
MyBase 核心能力三：高性价比
MyBase（ RDS 专属规格）用户画像：
• 对新业务预估过于乐观，导致 DB 预分配资源过剩，造成资源浪费
• 小应用较多，大量时间基本不耗费资源，每个应用一个数据库实例浪费资源。
• 小应用也有高峰期，给小实例又无法满足高峰期需求。
• 测试、预发、开发环境不需要性能保障，每个应用一个数据库实例浪费资源。希望压缩成本。
高性价比能力首先如果有很多用户，比如一些企业里面会有资源的管理员。资源管理员在业务申请资源时，业务通常可能会比较乐观。根据业务的未来的一种发展的预期提出需要分配数据库几和几 G 的资源？通常预期偏高，会导致业务上线之后 DB 资源造成浪费可能它的使用率不足10%。第二个就是有很多企业里面这种小业务、小应用，比如微服务化之后小的应用很多。大量时间基本不耗时间，每一个应用都分配一个数据库实例资源造成了浪费。小业务也可能会有一些偶发性的高峰。如果是给小业务，给特别小的实例又没办法满足高峰期的要求，业务一标会影响业务。最后还有像测试、预发、开发环境不需要性能保障，每一个应用都给一个数据库实例也是浪费资源。
MyBase 特性4：CPU，内存，存储资源超分配能力
8 core CPU ，设置200%超卖比，相当于可以开出16 core CPU 的实例，客户单 core 成本降低一半，除了 CPU ，还支持磁盘超卖设置
超配能力
银行可以发放贷款的原因是：储蓄客户不会同时去取款。同一时间有人存钱也有人取钱。
因为有这样一个背景，来看一下做了什么。在 MyBase 产品里面提供了一个超配能力。这个超配能力就是给到用户的，比如说一个64核的主机可以超配到128核或者192核，这样使得在分配的时候就有很多余力。为什么会能够提供这样的能力？可以看一个事件。比如银行，为什么可以提供贷款？比如银行的存款一百个亿但可以贷出八十亿，为什么会做到呢？因为不会同一时间所有人都去银行去取现、去提款。因此银行可以以钱生钱。MyBase 也是如此，因为刚提供的那几个场景，比如小实例不会每时每刻都有那么多资源。包括开发、设置环境都不会每时每刻都会有那么多资源就可以提供超配。从8核超到最多24核，从16核超到最多48核。这样整个主机资源利用率可以提高，同时还可以满足用户的需求。那么第一类超配能力来提高性价比。
用户画像
MyBase（ RDS 专属规格）用户画像：
业务波峰波谷明显，而且不重叠。
例如：私家车只有在上下班用，其他时间停在车库闲置，利用率非常低。
希望不同业务的 DB 可以按需求混搭，提高资源利用率，压缩成本。
第二类是混部的能力也是可以提高性价比。
MyBase 特性5：实例混部能力
报表类业务通常凌晨执行，正常业务白天执行。混搭效率高。
因为在一个企业里面业务有不同的波峰、波谷。比如 BI 类的业务，可能是凌晨大量使用资源，到上班之后 BI 类业务需要做的大量计算只需查一下报表的结果，资源消耗少。在线的业务，上班时间特别耗资源到下班之后不耗资源。这两类资源的时间上面的波峰是完全错开的可以混部到同一个主机提升主机的利用率从而降低成本。
用户画像
MyBase（RDS 专属规格）用户画像：
Redis 用户，由于ECS 网卡限制带宽，网络经常被打满，影响业务。
Redis 都是内存操作，由于内存速度快，根据木桶原理，网络就变成系统瓶颈。
还有一类高性价比的情况。在使用一个产品的时候，使用一个数据库的时候。就像木桶原理，因为一个实例是由 CPU、内存、io、网络组成。对于 Redis 这种实例，因为它都是在内存里计算，那么 IO 不是瓶颈。那什么可能成为瓶颈？网络可能会成为瓶颈，因为它可能大量成为交互。在 ECS 上面网卡做了带宽限制，所以通常 Redis 用户的瓶颈都会出现在网络上，它的 CPU 可能耗的不多。
MyBase 特性6：主机资源独享，不限网络宽带
独占资源、相互隔离 MyBase
造成这样一个现象，所以为了解决这个问题。 MyBase 因为主机都已经给到用户了。这个时候，其实应该主机前是没有带宽限制的，原来用 Redis 很容易被打满这种实例。在 MyBase 下面是完全没有问题的。
Redis 专属集群助力 CC 视频 轻松应对业务洪峰
业务高峰时单实例顺利支撑峰值1200MB/s的消息传输
客户简介
成立于2005年的获得场景视频（原 CC 视频），深耕视频服务已经15年，长期服务于教育、金融、IT 互联网、政府企业、在线医疗等垂直行业，为140000+家企业提供基于云计算的直播、点播、互动、加速的场景化视频应用解决方案。
客户痛点
疫情期间，直播业务场景内聊天、课件、进出日志等信息实时数据量剧增，几百万的在线并发，传统的 Redis 实例在 CPU 和带宽流量方面无法承载。
采用自建 MQ 等工具不仅使得管理和运维成本增加，也使得整个数据链变长。
随着在线教育的发展壮大，核心业务数据库压力越来越大，需要性能优化和支撑。
解决方案
采用16台 MyBase 主机承载直播业务消息分发业务。
业务高峰，将核心 Redis 实例进行独占主机部署，独享整机的CPU和带宽资源；
业务低峰，资源超分配，降低整体成本。
客户价值
对标传统的自建 MQ 工具和 Redis 实例，大大减少了在管理和运维上面的成本，真正的做到了降本增效。
业务上无需改造，解决了高在线并发下的 Redis 带宽资源不够的问题，直播效果更加流畅，质量也更稳定。
在“停课不停学”期间，业务高峰时单实例顺利支撑峰值1200MB/s的信息传输，无消息丢失，直播平台质量保证提到新的高度。
专属集群在不改变客户 DBA 现有运维模式的同时，构建在之上的Redis 提供了自动 HA、快速扩容的能力使得客户更聚焦在业务本身。
有个用户叫 CC 视频，从原来这么 ECS 迁移到 MyBase 支撑了他这个业务的洪峰。这个到16台 MyBase 主机达到了1.2G每秒消息传输的能力。
