技术圈首页
程序员
解决方案
聚合短信
APP下载
登录
注册
首页
文章详情
如何像用自来水一样使用数据库?
腾讯云数据库
|
97
2022-08-02 10:40
0
0
0
“如果说中小企业是一片片沿溪而耕的农田,
那么我们的愿景就是建一座大坝来管理好上游的水资源,来灌溉下游企业。
”
腾讯云
数据库高级工程师杨珏吉说这是他投身数据库领域的初衷。
初创企业、中小企业在数据库层面的最大需求就是低成本
。
助力企业降本增效是腾讯云数据库一直在努力的方向,尤其在疫情冲击下的经济社会中,更是一份社会责任。
在技术上深研,突破极致弹性,让客户像使用自来水一样的使用数据库,用多少、怎么用由客户决定,计费由使用量决定,这是杨珏吉及其团队给出的答案
。
TDSQL-C Serverless 数据库通过使用计算存储分离架构,
实现
自动扩缩容
、
按使用量计费、
无使用无计费功能,从而实现大幅降低成本,下面将详细介绍功能实现背后的架构原理及应用场景。
产品特点
Serverless 分为 FaaS 和 BaaS,其中 FaaS 是函数即服务,也就是我们熟悉的云函数,可以理解成是云主机的一种抽象,免去了复杂的运维,帮助开发者自动扩缩容,实现服务的高可用,并按使用量计费。
BaaS 是后端即服务,比如对象存储,它也免去了开发者的文件存储管理的负担,能提供足够的弹性能力,实现按照使用量计费,所以它也满足 Serverless 的要求。
目前云数据库的售卖方式还是与云主机类似,开发者需要购买一个固定规格的云数据库,比如CPU 4 核内存 8G,即使开发者没有 SQL 请求,也将按照 4 核 8G 进行计费。
业界场景的云数据库,确实帮助开发者实现了高可用和自动备份,减少了运维负担,但开发者需要提前预测业务请求量,并发起扩缩容,也无法在没有使用的时候不收费。
传统云数据库同机部署计算和存储,内核进程直接写本地数据文件。当一台机器的存储使用已经接近 90%,即使整机存量实例的计算资源负载再低,也无法再分配新实例了。在这种情况下,该机器上存量实例的用户,虽然没有使用计算资源,CPU 内存都是 0,也依然要承担此机器计算资源的费用。反过来也一样,计算使用 90%,而存储使用量较少,也将导致剩余存储无法再售卖。
按实际用量付费的问题本质是按实际用量分配资源。
所以云数据库如果要迈向 Serverless 这个目标,要做的就是计算存储分离。
计算存储分离的优势很多,比如存储空间和写带宽能突破单机上限,更强的容灾能力等等,本文重点讲解
资源分配弹性灵活
的特点。
计算存储分离能使计算和存储解耦,任意计算节点能访问任务的存储节点
。计算和存储维护各自的资源池,分别最大化、最灵活地进行资源分配。存储层按存放的数据量收费,计算层按真正的负载收费。
另一方面,传统云数据库扩缩容需要搬迁数据到另一台物理设备,所以耗时长。
而计算存储分离架构,计算层扩缩容不需要搬迁存储层的数据,直接分配计算层资源即可,秒级完成扩缩容
。
在计算存储分离之上,TDSQL-C 完成了 Serverless 产品功能的设计,让我们来看看具体是怎么做的。
架构设计
上图是开发者访问的全链路,应用程序通过接入层访问计算层,计算层从存储层返回数据。
我们的 Serverless 形态是利用监控计算层实现的。通过监控,我们对计算资源进行自动扩缩容,并对该时刻所消耗的资源进行计费。当发现没有请求时,监控服务就会触发计算资源的回收,并通知接入层。用户再次访问时,接入层则会唤醒实例,再次提供访问。
从客户角度总结起来就是三大特点:
自动扩缩容
:根据业务负载扩缩容实例,开发者无需预测负载并提前扩容资源;
按使用量计费
:以实际使用的负载进行计费,开发者无需为自己没有使用到的资源付费;
无使用无费用
:无数据请求时,不对计算资源计费。
1. 自动扩缩容
自动扩缩容的目标是让客户可以像使用自来水那样使用数据库,既可以一滴一滴,也可以像瀑布一样倾泻地用。
开发者在购买一个 Serverless 实例时,需要指定扩缩容的范围,也就是最小和最大规格。比如开发者购买了一个最小 1 核 2G 最大 2 核 4G 的实例。我们对 CPU 和内存限制到最大规格,也就是说 CPU 和内存不存在扩容的时间,而 Buffer Pool 根据 CPU 负载定时调整。
这是一个我们最开始考虑的方案,也是比较业界常见的扩缩容方案。
上图纵轴表示 CPU,横轴表示内存(Mem),矩形框代表资源限制。实例闲时,就限制实例的规格为 1 核 2G,负载来临时,CPU 迅速打满,监控发现后,再触发扩容,扩成 2 核 4G,其中缓存也是 BP 大小也相应增加,可以看到在扩容发生之前,用户的 CPU 使用是受到限制的,限制的时间取决于触发扩容的阈值。
我们后来采用的方案则是一开始就限制到最大规格,负载来临时,可以一下子使用到更多的资源,然后根据 CPU 的使用量来触发缓存大小的更新。在这个方案下用户使用数据库可以无感知进行 CPU 扩容,并且也不会因为链接突增导致实例 OOM。
2. 按使用量计费
使用量计费的目标是秒级别的计费粒度,以及任意单位的资源规格,比如用到 0.7 核,就按 0.7 核收费,而不是不足 1 核算 1 核。
我们的监控室每 5 秒采集一次,采集结果统一使用 CCU(
TDSQL-C Compute Unit
)作为统一的算力单位,其计算方法为 CPU、内存的1/2以及最小规格三者取最大值。
以上图为例,闲时以最小规格 0.25 CCU 计费,负载来临时以 CPU 进行收费,即为 3;当负载结束时,内存还在释放,为内存的1/2 ,也就是 0.8。
3. 无使用无计费
问题来了,大家可能觉得闲时按最小 0.25 CCU 计费也还是多了,于是我们推出无使用无费用的功能。
10 分钟没有收到用户连接,就将回收计算节点,转为暂停的实例。暂停的实例收到用户请求后,启动计算节点,恢复为运行中的实例。
我们通过监控计算的连接数,没有连接则向管控发起暂停。
暂停后,我们回收了计算层所有资源,不再对计算资源收费,仅对存储资源进行收费。接入层收到用户请求后,管控则会启动实例,提供给用户访问。
这当中比较重要的是恢复时间,也就是冷启动时间。在恢复时间上,我们做了相当多的优化,包括找持久化的日志位点以及 BP 和事务系统的初始化。目前,恢复时间能做到仅需2秒。
有的读者可能会感兴趣计算存储分离的架构细节,接下来简要分享一下架构细节。
在计算层,我们使用的是的 TXSQL,完全兼容 MySQL 协议,能够复用社区的 bugfix 和特性。主从复制使用 redo 复制,优点是延迟低。redo 日志不落在本地,而是发送给存储层。
在存储层,我们使用的是云硬盘的 HiStore 存储平台,保障了数据安全、GB 级别的备份回档、以及性能与成本的多种存储选择方案,我们在 HiStore 中加入数据库的逻辑,实现日志回放以及算子下推。
大家如果不熟悉数据库也不要被这个这些名词吓到,我们对外其实就是提供的是与 MySQL 一致的数据库服务,
区别是内部我们做了计算存储分离,分离之后计算层的资源可以更自由、灵活地分配
。
应用场景
应用场景是广大开发者比较关心的,接下来给大家分享六类场景的实际应用。
1. 慢查询
当开发者的 SQL 优化得不够好,或者偶尔需要全表扫描分析数据时,就会出现慢查询,与慢查询相伴的往往是 CPU 使用率高(因为扫描的数据比较多)。
这也是用户能切实感知到的,从上图的监控中可以看到
慢查询与 CPU 是正相关
的
。如果用户购买一个比较大的固定规格的实例,那么将承担额外的成本;如果购买的是小规格实例,那么在慢查询到来时用户的 CPU 会被占满,进而影响业务。使用Serverless 数据库就不用担心这个问题,大部分时间Serverless 数据库以低 CCU 进行付费,慢查询来临的时候可以立刻用到额外的 CPU,所以
整体上也只是影响慢查询时刻的计费
。
2. 定时任务
与慢查询类似,有相当多的业务都有定时处理逻辑,包括定时清理旧数据、定时生成前一天的报表等。上图可以看到,用户在每天 0 点会跑非常多的请求,但平时大部分时间是一个低负载。
用户使用了 Serverless 数据库之后,也不用去对规格和费用做权衡了,和上一个例子一样,用多少就计费多少
。
3. 归档数据库
如果长时间不用数据库,就不用对 CPU 和内存进行收费。这类通常见于一些档案数据库、机器学习的样本数据库、个人家庭的历史传感器数据库等,不会经常使用,而是偶尔访问的状态。这类数据的常见的做法是直接存在 COS 里,需要的时候去下载。
而
Serverless 数据库有一个很大的优点就是需要的时候立刻能够提供索引,且拥有强大的分析功能,开发者不需要自己去写代码就能搜索到需要的数据
。
4. 低频访问的业务
对于平均每天的访问量小于 10 次的低频访问业务,例如个人博客、垂直社区论坛、微信小程序,我们与云函数、云开发、微信云托管有深入合作,
能实现访问结束后就停止计费
。
5. 开发测试环境
上图可以看到在一周时间内,用户在晚上、周末都没有访问和使用。用户通过 TDSQL-C Serverless 数据库的
自动暂停功能,节省了大量研发测试成本
。
6. 微服务场景
随着微服务越来越流行,每个单独的服务负责的功能也越来越小,随之对应的是微服务后端的数据库的负载也会变小。一种做法是多个微服务共用一个大的数据库,但这会带来相互影响的问题。
所以,Serverless 数据库提供小规格的数据库实例,来保证微服务之间的隔离性
。
总结与展望
TDSQL-C Serverless 补充了数据库领域
中
Serverless 的
空白
。
在
自动扩缩容上,可以
使 CPU 瞬间用到最大规格,按使用量计费上能够按 CPU 实时的使用量进行计费,不使用不计费上冷启动时间
是 2 秒,目前在 Serverless 数据库中是绝对
领先的。
未来我们也会在冷启动上做进一步的优化,以及帮助客户
进一步降低使用成本。
﹀
﹀
﹀
-- 更多精彩 --
腾讯云原生数据库TDSQL-C入选信通院《云原生产品目录》
新一代云原生数据库畅想
↓
↓
点击
阅读原文
,了解更多优惠
0
赞
0
收藏
×
添加附言
附加内容, 使用此功能的话, 会给所有参加过讨论的人发送提醒.
回复数量:
0
暂无评论~~
请注意单词拼写,以及中英文排版,
参考此页
支持 Markdown 格式,
**粗体**
、~~删除线~~、
`单行代码`
, 更多语法请见这里
Markdown 语法
支持表情,见
Emoji cheat sheet
@name 会链接到用户页面,并会通知他
上传图片, 支持拖拽和剪切板黏贴上传, 格式限制 - jp(e)g, png, gif
Ctrl+Enter
下载APP
腾讯云数据库
252
文章
0
获赞
关注TA
NEW
相关文章推荐
数据架构变革进行时:现代化应用需要怎样的数据策略?
云原生 Serverless Database 使用体验
初创企业的福音,还有这么贴心的云原生数据库?
20分钟能学到什么?下一代数据库
数据库的下一场“革命”
数据库春风得意,一文看尽花落何方