00:00
各位线上的朋友们大家好,欢迎参加腾讯云中小企业在线学堂系列直播活动,我是本次会议的主持人张小平。中小企业在线学堂围绕中小企业业务需求,聚焦企业经营管理、应用工具、技术创新、安全底座四大需求场景,推出系列直播课程,全面助力中小企业数字化升级。面对复杂的数据库技术和波动剧烈的业务需求,您是否时常感到捉襟见肘?作为开发者,如何能够聚焦业务创新而不受基础设施的束缚?迎接S时代,将数据库技术的复杂度降至最低,自动调整资源,既兼顾性能又节约成本,帮助企业it人员释放更多精力于业务创新,让数据库成为业务创新事半功倍的得力助手。即刻行动,向更简单、更高效的业务创新之路迈进。首先有请今天的第一位分享嘉宾,腾讯云数据库产品总监、中国计算机行业协会开源数据库专业委员会副会长、北京航空航天大学特聘讲师刘迪。刘老师拥有着视频、游戏、金融、电商等行业的多年数据库架构设计和优化分析经验,曾担任腾讯视频、腾讯新闻、腾讯体育等业务的数据库管理和运维负责人,对外推出了迪B课堂我说等一系列数据库实战课程。
01:39
加入腾讯云后,主导了腾讯云数据库my circle的企业化转型、云原生数据库TD circle c的孵化以及AI与数据库自制等核心项目。今天刘老师分享的主题是解放生产力腾讯云原生数据库TD circle c的变革与创新,有请今天为大家带来的分享议题是解放生产力腾讯云原生数据库TD circle口C的变革与创新。我是今天的演讲人刘迪,来自于腾讯云数据库团队,之前也参与过大量的腾讯云MYSQ的企业型转型的,呃,一些战战役啊,现在在负责我们的腾讯云原生数据库的产品和研发工作。
02:23
而今天的整个的演讲,我们将围绕着腾讯云原生数据库t circle c的演进之路,以及核心技能,核心的呃,这个产品性能的讲解,以及我们的客户案例,以及今天我们还会在重磅的去发布腾讯云原生数据库t c service的三大形态啊。首先给大家分享我们腾讯云原生数据库这十年的一个发展的一个历程,来给大家介绍一下为什么我们要去做腾讯云原生数据库这样一个产品形态,我们知道在云计算发展之初,我们经历过了云数据库时代,所谓的云数据库时代就是我们将传统的IDC部署的云数据库,通过这个上云的模式搬迁到了云上,让我们的客户享受到了云上数据库带来的便利。
03:09
但这个我们仅仅解决的是我们的可运维性的问题和资源的这个利用率的问题,但是对于传统的数据库的软件设计架构并没有突破,那这就带来了一个问题,就是我们的随着业务的发展,业务的冲击,对于数据库的一些软件设计方面的瓶颈,我们依旧没有办法突破。举个简单例子,就比如说MYSQL,传统的一主多从架构,它的主从延迟依赖于我们的日志逻辑,日志的同步的延迟依然很大,我们很难在云上啊,通过传统的架构去解决这样的问题。包括我们的,呃,流量洪峰到来之后,我们的扩缩容的问题。那一组多重的架构依赖于数物理机的部署模式,我们在扩缩容的时候会大量的去进行数据的搬迁,那随着数据量不断的增大,我们的搬迁时间是与我们的数据量成正比的,那么这一系列的问题其实都是我们传统数据库软件设计架构面对于当前当下的数据的这个组织模式,或者说我们业务形态所带来的一个问题。
04:13
那么腾讯云原生数据库团队在云数据库的基础上,或者我们把它定义为云托管数据库的基础上,我们首先孵化出了一个我们的云原生架构,我们的存算分离的架构,我们通过log is database,也叫日志及数据库的方式去实现了这个呃,存算分离的架构来进行了三层资源的结耦,包括内存资源。这个我们的呃,计算资源,我们的这个呃,存储资源进行结耦,来进行弹性的足够的灵活化。那么在后面的几年,我们其实是通过了网络架构的升级,包过我们的这个内核和存储上面的不断优化来去解决了我们引入了存算分离架构所带来的性能瓶颈,使得我们的性能能够比传统的数据库,比我们的。云原生其他产品类的数据库,它的性能能够高出40%~200%的一个这个范围。
05:05
那么如今我们已经形成了一个企业级的云远程数据库的矩阵,让我们的数据库在数据的可靠性、可用性、安全性、service自制化的服务等方面具备了商用数据库的稳定和功能的丰富程度,也兼具了开源数据库的敏捷迭代的能力。那么首先我们来跟大家一起认识一下云原生数据库架构,这个话题其实很有意思啊,就是我们在呃,经常在外面在分享的时候,呃,大家会来问什么叫做云原生,那今天我们在这个场合上面,我们不对云原生做太多的定义啊,我只简单的跟大家分享一下腾讯云数据库团队对于云原生的这个一些呃思考,呃,我们在很多的这个呃客户的这个交流中啊,大家会对云原生认知可能跟我们的容器跟我们的虚拟化会成为对等,认为说我们把传统的数据库从云下搬到云上,原先用物理机部署变到由我们的虚拟机也好,容器化部署,利用了虚拟化跟网络云盘方式解耦资源来实现云原生,那其实我们想象一下这个叫真正的云原生吗?它会有什么样的问题?
06:10
那我觉得首先最大的问题就是传统数据库一组多重架构,虽然它在灵活性上、扩展性上有大量的问题,但是它的性能上是非常友好的。我们的数据库的本地IO,除了访问数据库,除了访问我们的这个内存数据以外,大量的持久化数据,我们要利用我们的IO进行这个呃查询,那么我们从云下到云上这样子的一个呃阶段呃一个这个部署模型的一个呃变更,会使得我们的本地IO放大为网络IO,那这个是个数量级的一个变化,那么对于一个数据库性能来说是一个严重的影响。那么我们的云原生架构在设计之初,我们既要考虑到算存分离带来的资源解耦的灵活性的变化,也要考虑到我们的性能的影响。那我们对于这样一个情况。啊,我们进行了一个呃,重构,重构什么呢?重构MYSQL的数据流,我们把MYSQL原生的数据流进行了重构。
07:06
那么我们要选择怎样的数据流去进行重构呢?我们来看一下MYSQL的这个整个的一个呃数据流有哪几种,第一个叫做逻辑日志,第二个叫物理日志,第二个第三个叫数据页面,这三个是能够代表MYSQL的数据流的,那我们究竟要选择怎样的数据流去作为我们的呃持久化的数据流的这个更改的一个模式。那我们的考虑点是有两个,第一个啊,我们要用密度最高的数据流,为什么要用密度最高的数据流,只有用密度最高的数据流,我们的传输的效率啊,在网络IO的情况下,我们才能够做到最好啊,才能最节省我们的这个传输的带宽。那么第二就是我需要解析难度最低的,因为我们做了存算分离,所以我们希望我们的存储层能够是一个可计算的存储。什么叫可计算存储?就是说它能够独立的完成数据页面的回放,能够独立完成数据页面的解析,能够独立的完成数据页面的一个查询的一个请求,不依赖于我们计算引擎。那么基于这两点考虑,我们首先来看逻辑日志,逻辑日志我们说它是密度最高的,它就是用户执行circle的一个集合,但是呢,它的解析难度太大。
08:10
它需要利用数据库引擎层进行回放,要多组建的联合才能够实现数据页面的回放和持久化,那么对于我们的架构其实是不友好的。那我们再来看解析难度最低的,那无非就是数据页面,它已经是SQL应用的结果,那它的这个整个的回放其实是不依赖于我们的这个计算层的引擎的。那么这种情况下,我们为什么不选择数据页面啊?它的问题就在于它的数据密度太低。可能我们的IO要放大十几倍来去进行这个数据流的传输。那么基于这种模式,我们最终选择了我们的物理日志,物理日志它其实是一个S增量的一个呃体现我们利用存量的快照和存储信息,以及增量的物理日志,我们就能够实现我们的数据页面的持久化和我们持续页面的一个更新。那最终腾讯云算存分离的架构选择了物理日志作为我们计算层和存储层进行数据持久化的一个日志,同样我们在多个只读节点之间,就刚刚上一页集提到的,我们的主从延迟原来用逻辑日志非常的慢,那我们也用了日物理日志去代替了我们的逻辑日志。
09:17
那它的收益呢,除了我们刚刚说的这个第一个点以外,那还有一个很明显的点,就是原先我们写一个1KB的页面,往往我们需要可能16KB的一个,呃,页面的刷盘啊,甚至有很还有会产生很多的日志的一些刷刷章的一些IO请求,但是对于我们改造过后的这个页面。那我们写个1KB的页面,那我们的IO请求就是1KB加上几个字节就能完成了,不管对于带宽的节省还是对性能的提升都有很大的帮助。那么除了我们在软件设计上,我们在算存分离的架构模型上的思考,那么我们在计算节点的引擎上面的自主可控和自主研发上面也做了大量的工作。腾讯云的自研数据库引擎T叉circle不仅有多种首创的内核特性,同时我们也大量的去回馈社区,不仅把我们的内核里的特性啊贡献给我们的开源社区啊,增加一起去贡献我们的开数据库的开源生态,同时我们也大量在线网运行中发现的。
10:16
Bug做了一些fix版本啊,也贡献了给我们的社区,然后在我们的云上,对于我们的用户来说,我们能够去避免,不管是官方的这个数据库软件产生的bug,还是我们呃新引入特性产生的bug,我们会也会在做及时的一个更新。那么其中我们也根据现网用户的实际情况啊。推出了多种我们的核心特性,第一个就是我们所说的秒改列的一个特性,针对海量的一个数据库的一个呃库表,我们能够进行毫秒级别的变更,它的数据库结构跟它的数据量完全没有关系。我们看到这样的一个对比就是。大概有100亿条的一个数据,在传统的MYSQL数据库上,我们需要的大概是三个多小时,将近四个小时的一个变更,那么这个变更期间会产生大量的锁。
11:01
以及对于我们的读写请求都有一些阻塞和影响。那么对于用户来说,或者对于我们的业务侧来说,这完全是一个不可用的时间段。而使用了我们的这个秒改列的功能以后,我们能够在一毫秒之间进行这个变更,对用户的影响和我们的效率有大大的提升。那么第二个特性就是我们的热点更新保护,什么叫热点更新保护呢?就随着这几年我们的这个电商行业,或者我们的这个网络直播行业的兴起,我们会大量出现一些随机的热点,包括我们的商品。的一个库存,包括商品的一个这个呃销量啊等等这些数据会有一些热点商品的出现,那么传统的TP数据库在于热点商品或者热点数据字段的一个呃变更上面会存在大量的热点行,热点数据,热点表啊,那么它的性能会随着我的所机制的这个一个堆积,包括我这个线程的堆积,导致我的这个性能急剧的下降,那么通过我们热点更新保护来增加了一些热点缓冲区,包括识别热点以后做了一些我们的这个呃,根据代价的一些定制化的一些自定义的一个呃释放和可调度的一个过程来去实现,在这个过程中我们能够加大数据这个库表的一个执行的一个效率。
12:12
那么除此之外呢,我们还提供了诸如像呃,数据库审计,像这个re in blog,以及这个flash query的这个呃,闪回查询等等一些内核特性的一些请求,成为一个真正的自主可控的多特性、多功能、高性能的数据库。计算引擎啊,那么上面跟大家分享了一些呃云原生数据库的一些我们的核心的架构设计和内核设计,那么第二章跟大家去着重去介绍一下腾讯云原生数据库t t circle c在核心关键能力上面做了哪些,大家现在看到的就是我们云原生数据库t t circle口C的一个呃完整的一个架构图,我们分为三层,第一层叫做呃数据库代理层,主要是提供了像我们的安全防护,自定义的路由转发,以及我们的可用性的一个提升,就是我们的叫零运维时间的这样的一个概念,就我们之前在做一些这个运维操作的时候,可能会出现一些网络顺断啊,甚至还会是呃触发一些这个事务级的中断等等,那再通过这个数据库代理服务,我们能够做到零感知的一个场景。
13:14
啊,那么以及一些安全呃类的一些功能,还有一些一致性毒的能力,那么这个是我们的数据库代理层,那么在计算节点我们做到了算层分离以后,计算节点的无状态,既实现了我们快速的启停,也实现了我们弹性的扩容,对于用户来说,呃无感我们的呃数据库升降配不再需要迁移我们的数据。那么对于用户的价值来说,就是我1T的数据,10T的数据,100T的数据,如果是只升级我们的计算节点,我都能够到毫秒级,最差我们到秒级就能够完成这个弹性。而我们的计算节点不仅做到了预制的规格,就是呃,传统大家认为说独占的,比如说两核4G的资源,我们可以独占给我们某个用户,我们也做到了一个我们的serverless弹性的混合部署,那所谓的serverless啊,就是我们自适应负载,可以进行这个根据用户实际的负载请求去做弹性的一个过程。
14:07
啊,不需要用户再干预,我们可以根据实际的请求量,访问量来进行,呃,整个资源的一个纵向和横向的一个伸缩。那么底层就是我们的。数据库的存储层,我们所谓的可计算存储,利用分布式的存储的方式来去实现我们整体的存储的一个横向的扩展,像突破了传统的这个单机部署数据库,可能它的单个实例的存储上限只有单机的一个存储规格瓶颈,比如说10T20T啊,我们现在可能最多的单机能做到30T就已经很不错了啊,但是我们分布式的这个存储,现在我们能够实现PB级的一个扩展。啊,能够保证我们单个实例不再需要分库分表,我们都能够存下我们海量的一个数据。那么中间其实大家也能看到,我们其实还有一层叫做加速层,叫缓存加速层啊,通过我们利用了我们的这个呃,可持久化的这个内存的一个呃,这个硬件的一个特性,来去实现我们的计算节点和存储值节点之间的呃。
15:06
数据页面的缓存,它的一个加速来提升我们整体的一个性能。啊,那么看完这个架构,其实我们也会被用户提到一个问题,就是说我们现在存的更多了,这个系统到底可不可用,到底作为一个核心的生产系统,它是不是一个称职的一个系统?啊,我们是不是只能做归档,因为之前大家对于原生数据库的一个定义,可能往往都在一个归档上面,就是我只能存冷数据,热查询起来很慢啊,那针对这个呃观点其实在呃这两年我们也做了很大的一些这个技术的演进和技术的一个突破,我们能真正的让用户不仅能够存的更多,也不需要分布分表来去降低我们的数据集的大小,来提升数据库的性能,我们能够使得用户在海量数据库的存储和检索上面都能够得到很好的一个这个效果。那么首先基于海量数据的检索,我们提出了两个关键的特性,那第一个就是呃,现在大家看到的这个并行查询,什么叫并行查询?我们知道传统的MYS狗,它为什么被诟并它是一个TP强AP弱的一个系统,就是因为它的单个circle只能利用到单核CPU核心,这个我们怎么去理解,就是不管你这个circle多复杂。
16:13
啊,我这个系统有多闲,我们往往买了一个,比如说我买了一个32核,64G的一个数据库,我32个核心都能够对我们的用户提供服务,但是我单条circle我只能用到其中一个核心,这个核心哪怕跑到了百分百,那我其他的31个核心依然没有办法去处理这个circle的这个计算的一些消耗。那就会导致我的单个复杂circle,它的上限永远在单个CPU核心的计算的能力上。那么并行查询呢?我们要解决就是我的单条circle可以利用到超过一个核心。的计算资源,那也就是可以翻译为我的单个复杂S进来,我原先单个核心可能要算32秒,那我现在可以并行的32个核心都可以为他提供计算的资源的帮助,那它的执行效率一定会大大的提升。
17:00
啊,那我们的这个机制上面来看,就是我们会利用我们的这个单核心和这个呃,单个circle用户的主线程和我们自己的叫做工作的子线程之间的一个数据的拆分,数据的交换啊,以及我们多个线程共同协同进行完成这个呃,一个我们的这个SQL计算的工作。呃,来去实现这个加速,那么经过我们的TPC-H的标准的AP级的呃压力测试,我们会发现整体的不管是呃聚合查询排序,还是我们的函数计算等等的这些这个。高复杂度的计算circle上面,我们都有15倍到20倍的一个性能提升,来大大去提升了这块复杂circle的运算,那么除此之外,我们针对一些复杂的AP场景,在我们单个搜狗可能没有办法去完成计算场景上面,我们也做了一些这个架构上的升级,之前行业里面传统的方案就是我们要基于AP系统去实现我们的这个业务场景的时候,往往我们的数据来源还是TP,那怎么办呢?
18:00
那传统方案其实就正如图上我们看到的,就是通过AP和TP之间自己去搭建一个呃抽取的链路,一个这个数据同步的通道,我们叫做DTS啊,就是这种通道或者叫ETL的抽取。来去实现数据实时的同步,能够让AP请求在AP系统上面查询,TP请求在TP系统上查询,那我们同时要运维两个系统,它中间的数据的一致性,数据同步的效率等等都有大量的一个损耗,那么云原生数据库TBC基于这种场景,我们提供了一个行列混存的一体化的h tab的。啊,架构。来实现我底层同一份存储,我上层引擎能够自适应自识别我们的SQL类型来去分发到我们的行存索引和我们的列存索引上去执行,如果我们的这个circle它的代价分析下来更适合我们的这个行存索引啊,那我们就会正常的以行存索引的方式去执行,那么如果我们的代价开销分析以后发现它的执行效率在列存引擎上面执行效率更高,那我们会自动的啊转发到我们的列存的引擎上,但对于用户来说,它其实行列是同一个计算节点提供的服务,行列是可以相互转换的。
19:09
那么用户不再需要维护我们的传统的数据库同步链路,我的同一份数据也能够保证我们的数据一致性,减少我们链路的复杂度带来的一个系统维护的一个开销,同时我们的列存的索引的这个效率的提升比也能够达到将近20倍的一个提升,能够使得原先行存的TB系统也能够支撑我们列存AP系统的。SQ请求,那么作为一个核心的数据库系统,除了我们说能够存的更多,查的更快以外,那第三点其实我们也要去考量,在一些可用性,或者说数据可靠性和数据库可靠性这个方面能不能够支撑我们业务的核心系统。那么衡量这个指标最关键的一个特性就是备份和回档,因为往往在出现故障的时候,我们需要快速的去回档到一个故障前的一个时间点,来让我们的用户在一个很高效的时间点内进行回滚。
20:05
那么随着数据量增大,其实回复的难度和回复的时间点,包括备份的难度和备份的时间点,往往它是跟我们数据量级是成正比的。那我们看一下传统的备份方式,就是物理备份或者是逻辑备份,它的时间就逻辑备份其实更久,大概30兆每秒的一个速度,那么物理备份我们说它即使到了一个十倍的一个效率,它也是到三四百兆每秒,那么对于一个100TB或者说PB级的数据库,那它的备份时间。是相当长啊,几乎到了一个业务无法去接受的一个情况,那么这个云原生数据库TTC,对于这类场景,我们因为底层其实是借助了我们分布式可计算存储的这个,呃,架构的一个特点,我们已经打散成了N个我们的2GB的一个小表。那么我们的备份第一个采用了快照备份显示重定向的技术来提升我们的备份的效率,那第二个既然我打散成了N个我们的可计算的一个,呃,存储单元就我们的小表,那么它的一个备份的这个最终的一个效率,或者说我们大家说木桶效应啊,我最慢我取决于单个2GB的小表的备份的时间,那我不管它的数据是10T20TPB,那我的整个备份的时间最慢,最慢就是单个2G的小表备份的时间。
21:18
那么针对这个技术,其实啊,大家也会问说我分布式了啊,我分拆分成了这么多个小表,我怎么去保证每个小表它的这个备份时候的时间一致性,那么这个方式上,我们通过这个增加了一些逻辑日志的方式去写入在我们的这个物理日志的这个呃阶段啊,写入逻辑日志啊,记录他的时间戳,那么每一个小表回放到同一个具备相同特征时间戳的一个逻辑日志的时候,我们就认为它是达到了一个一致性,那么除了备份以外,我们的分布式架构的存储也为我们的回档提供了。强有力的一个帮助,就我们的回档能够达到比传统的回档大概到五倍以上的一个效率,我们拿到GB级每秒的恢复,那么大家看到这里是不是觉得说回档已经很快了啊,我们就说已经比我们的呃传统的逻辑备份物理备份也快很多了,但是实际上我们也在想说有些场景我们还能不能再做的更深一点啊,这也是我们一直在呃付之努力的,就就是呃在一些场景上,我们可能呃会遇到就是100TB的表,但我只改了一行数据,那我难道要需要要把这100TB的表都恢复出来,我才能够。
22:23
呃,完成这些恢复吗?那虽然说我拿到GBG每秒的一个恢复速度,但是100GB表,毕竟它的量级很大,我只需要我只修改了一个字段啊,或者说我只修改了一个这个几K的数据,那这里其实就是出现了一个呃,极端的场景下,我们怎么去提升它的回档效率的问题啊,那么腾讯云原生数据库的那个团队及基于这个我们也是孵化了一个特性,叫做闪回查询啊,叫做query的这个能力,那闪回查询在业内其实大家有很多种实现方式,像用触发器实现。啊,像用我们的blog反解析,但其实都有各种各样的这个限制和一些呃问题,那我们采取的方式其实类似于空间换时间的一个呃这个思路采用昂度日志和呃MYSQL自身的MVCC的这个呃特性啊来去做一个最基本的它的一个回复的基础,这个采用昂度的日志的一个回环,它的一个这个链表指针,反向指针的一个呃指向的方式,能够恢复出历史时间段或者历史时间点内的这个数据的快照,那么这种方式其实我们改造了一些,比如说呃这个呃查询请求,我们增加了一些历史的read的一些视图,包括我们每一个这个历史视图,我们的延删机制啊,也做了一些呃修改,可以看到我们在当前时间点,我们可以查询到历史多个时间点,我们秒级别力度的一个历史时间点的一个数意情况。
23:41
那么基于这种查询,我们就可以实现一个如果我只修改了某一行数据,那么我对这一行数据,我能够精确查到那个时间点这一行数据的值。比如说当时是B值,现在是A值,那我查询那个时间点,我就会在呃秒级响应,告诉你那个时间点它这个B值,我们能够很快速的进行这个回档,不需要再等到整个的这个数据集都恢复以后,我才能够提供这个回档的能力。那么在数据高可用方面呢,还有一个点就是大家经常提到的金融级的两地三中心,那同样对于云数据库来说,我们也提供了一个多地多中心的容灾方案。
24:15
既能够实现同城双活的强同步的切换,和我们的这个数据一致性的校验,也提供了我们的多地多中心,也就是说我们跨城,像比如说在北京的数据中心和在广州的数据中心来实现一个跨城的一个同步。如果在北京的两个数据中心,跨机房的数据中心都出现了异常情况下,我们能够快速的切到广州的数据库中心,提供一个跨地域的一个呃服务,那么对于三个多点的一个或者说多个多点的服务之间,我们提供了快速的基于维度的一个呃数据复制,来提升它的复制效率的同时保证了它的数据的一致性,好。那么最后一个我们要跟大家讲的特性就是我们会关注一个数据库的安全,因为企业级的数据库不仅我们要做到性能存储。
25:02
做到我们的可用性、可靠性有保障,数据安全也是不可忽视的。那么腾讯原生数据库TTC提供了多种数据库安全的解决方案,比如说SL加密。透明的t de加密。备份的日志和备份的数据文件的加密、数据库的脱敏等等特性,最近些年来被大家提到最热点的一个功能就是今天我们要介绍的这个数据库审计。啊,什么叫数据库审计啊,就是记录数据库执行circle口以及其消耗信息的日志集合,那记录的就是我们这个用户所有执行的circle,那它有什么用呢?就是用处其实比较多,第一个典型的场景就是我们可以通过这个审计记录完整的去来去看到。我们这个数据库,它自身它的这个整体的运行访问的一个情况的一个全局的一个视图。那么对于一些金融行业,它还有一些车企。他的国家的等保的三级要求,包括行业内的各种这个呃,等级保护的要求,它都是能够满足的,因为腾讯云的数据库审计的这个服务是通过了公安部的安全产品的认证的的程序资质上面保证是没有问题,那么第二个。
26:10
场景就是我们可以为用户提供一个我们性能分析的一个平台,既然记录了所有的SQL执行,那么一旦我在某个节点出现了故障,是否在这个节点上,我有抓到这个故障节点的这个执行的语句,我只要回放,或者说我要查询反查询到这个节点,我可能够找到他所有的SQ执行的轨迹来协助我们定位问题。那第三个就是来提升我们企业内不管是风控还是我们内审对于整个数据资产的一个保护的一个效率,那么腾讯云税务审计除了刚刚提到的他在资质上面满足了公安部的一个要求以外,它在实现方式上其实有别于我们行业内的一些通用的审计,那我们其实通过内核的插件式的方式实现,它的好处在于。他在内核侧的实现比外置式的实现,它的机制上是不同的。外置的一个实现上面更多的是通过解析网络包的流量来进行回放,那么会出现网络丢包的情况,而且它能够获取到信息非常有限,只有像circleq,像执行的呃um,包括执来源的IP地址等等这些较少的一些信息,那么通过内核测的这个插件式的审计,我们能够完成对于circle。
27:19
我们的这个刚刚说到的一些基本信息以外,我们还能对于它S口任执行期间的行左等待扫描行数,返回行数,CPU消耗,内存消耗等等这一类的性能分析数据都能够记录,同时我们能够保证它的记录和这个circleq实际的执行能够一一匹配,不存在漏审啊,或者说这个审计数数据丢失的啊,这样子一个情况。而且整个在插件式的审计上面,对性能的影响,对带宽的影响是最小的,我们已经做到了行业内最领先的,整个最复杂的场景上面,我们也对性能的损耗不超过5%。好,那么第三个章节呢,我们给大家去分享一些案例啊,一起来看一下我们的云原生数据库TTC,它在真正的用户场景中怎样去助力用户成功的。
28:01
啊,经过这么多年的打磨,腾讯云原生数据库,其实在腾讯内的各个这个明星产品,比如像微信,像QQ,像我们的腾讯会议,腾讯音乐和腾讯视频核心系统都已经使用我们的云源数据库进行替换,从这个业务线来说,其实呃行业属性来说其实也比较丰富了,像有内容线的,像有微信类的这种社交属性的,包括我们的支付类的,账单类的,金融类的,以及像呃文娱这些场景,其实大量的都已经在这个云生数据库上面取得了各种各样的成功,那对于外部用户来说,像呃近几千年来各呃一些金融行业,包括一些银行。这个一些政务。一些保险、券商等等客户也逐步开始去使用。与远程数据库作为它的核心系统的替换,那么像近年几年来兴起的新能源行业,一些自动驾驶,像未来汽车,广汽、一汽。长安长城等等这种车企,它的整个核心系统也开始从原先的传统IDC到云生数据库进行了改动,那么对于这个适应互联网浪潮,亲和心最高的这个,这个泛互联网类的像电商,游戏这些行业,其云营数据库对他们的业务场景的助力是呃显而易见的这个成效啊。所以像我们的这个头部的教育客户,好未来啊,包括B站小红书啊,法大大,包括瑞信咖啡等等这些新零售的客户,包括像游戏的游族,畅游啊,心动啊这些,呃,不管是国内还是海外的这种游戏客户也大量的在使用云数据户作为他们的核心系统的数据库支撑。游戏行业是对云数据库它不能说最爱啊,但是其实会比他用用传统的数据库有太多太多的这个呃,收益了,但今年上半年的一个新游,实际时代游戏的一个首发。
29:44
之前我们跟他的主动团队沟通的时候,他们其实提出了一个最核心的点,就是也是,呃,我们可以代表是游戏行业其实普遍存在的一个现象,就是他们会频繁的大量的要去做游戏服的升级,那么这个升级时间耗在哪里呢?耗在。
30:00
测试放在包的部署啊,这些其实都是小头时间啊,更多时间是在他的发版之前,他要去做数据的备份。如果它的发展出现了问题,它要进行这个基于数据备份,要进行回滚,那么传统的数据库在备份上面耗时是非常大的,那可能就带来一个现象,就是我的所有的包的部署,我的所有的这个呃,研发的工作都完成了,我要去等待数据库的备份时间。那么这个转化为玩家的代价就是在那个时间段,反正上午我要损失两个小时,三个小时,四个小时的时间,我这个服务是停服的,我没有办法进行进行这个,呃,游戏的体验,那么如果一旦出现了一些小概率事件,这个需要回滚。那么它的回档时间也会随着数据库的数据的量的上涨而线性的增加,那么经常会出现,也会体现到有些游戏可能它的维护时间是两个小时,突然说我又延长了三个小时啊,这就是我们在回档这个游戏,回档场景游戏的这个维护场景中。遇到的传统数据库,呃,没有办法去助力我们现在的这个呃业务的一个发展的一个明显的例子,那么还有一个例子就是其实他组装团队也提到过,就是说可能会遇到一些被盗号的情况,被删号的情况,有一些呃被黑掉了账户,那客户会来去跟他们客户来提起申诉,我能不能快速的去回档这一个玩家的数据。
31:15
那么这个时候其实第一个玩家心情是非常着急的,第二个如果我们要涉及到整个数据库的回档,那他的时间也是不可控的,那通过我们提供的这个云原生数据库的能力,我们在并行备份,并行回档上面已经帮助用户缩短了70%的这个数据库维护的时间,反向来推导就是整个它的这个停服时间是大大的缩缩短了,那么第二个针对刚刚说的,呃。装备宠物丢失的场景,我们通过秒回能够让一秒钟我们的这个用户就能够经过核实以后啊,我们的这个数据就能够进行恢复,来避免对玩家的这个出现这种情况下对于这个公司的一些投诉,那么今天最后一个章节呢,是跟大家去来呃,重磅发布一下腾讯云原生数据库service在今年我们做的三个核心重要的特性。
32:00
啊,首先花一分钟时间跟大家简单介绍一下service啊,Service它这个概念呢,其实我们在一些云开发的一个场景,或者是在一些这个呃,我们的容器化的场景中,大家可能经常会见到,但数据库的场景中,可能大家听到这个词啊,都会比较陌生啊,那首先什么叫service,我们定义的service其实就是一个极致弹性啊,极致成本,极致效率的一个数据库,原云原生的,下一代的这个整个形态的一个,眼镜的一个,呃,特性的一个。总和,呃,我们来说一下,就传统的预制数据库会有什么样的问题啊,就是比如说刚刚说的预制,我买两核4G,我不管我的流量是不是进来,我的负载压力是不是一个恒定的时候。我依依然这个两核4G的这个资源是用户独占的啊,大家听到独占这个词可能说,诶那不是很好吗?那其实你的独占是要付出成本代价的啊,就你时刻都要为这个两核4G买单。那么这个场景我们就可以理解为我一个餐厅,我在人很多的时候,我要付出成本,但是我已经没有客户消费的时候,我依然要付出这个成本。那我们希望是把这一部分。
33:03
你不使用的这一部分成本能不能够再帮用户省下来啊,或者是说我们在超过用户预知资源的那部分,一些这个配置能够不让用户以降级或者以性能无法满足作为代价,我们也能够满足。那么这个service的形态就应运而生了,它会根据用户实际的负载的波动情况去调整数据库的资源,换句话说,你的这个请求很多,你的压力很大的情况下。我会提供更高规格的计算配置去来支撑你的业务访问,来使得你的业务访问在洪峰期也能够平稳的提供这个高效的SQL查询。那么在你没有访问的时候,我甚至能够降低你的数据库配置自适应的方式,而不需要人工任何的这个介入降低我们的计算规格的配比。你在没有请求的情况下,我能完全释放我的计算资源。那完全释放对于用户的价值在于,用户不需要再为这个没有请求的这个时间段去付任何的成本费用。
34:05
那么之所以能做到这一点,其实离不开我们底层的云原生架构上面的弹性和灵活性,因为我说刚刚说这个策略好做,但是对于用户来说,我既要成本低,又要弹性高,还要谈的稳,我在弹性过程中一定不能够影响用户正常的业务访问。这个其实是在service架构上面,我们实现的一个,呃,突破的一个最重要的一个技术难点。那么1.0架构发布一年后,我们大量已经支持了超过50万的。微信小程序的用户来去使用我们的service的架构,那么在此之上,我们现在这个也做了一个2.0版本的一个迭代,那么今天也给大家最后在这个发布一下我们2.0版本的三大核心特性啊,首先第一个就是我们的service2.0,从1.0的升级版本开始,从单节点的纵向的弹性已经可以支持到一个集群级别的弹性。主实力只读实例,横向纵向数据库代理等等三层,甚至说我们说再分析一点,我们四层都能够做到,根据负载资讯的弹性。
35:07
啊,能够使得不管是读请求写请求都能够,呃,进行这个很快速的横向扩展和纵向扩展。那么第二个特性,也是腾讯我们在这里全球首创的一个能力,就是可释放的存储。这两年大家听到数据库service,可能不仅是腾讯云在去推广,对于这个其他的厂商也有大量的一个露出。但是大家往往的焦点都仅仅还停留在计算资源的service。它的弹性。那腾讯这次发布的这个2.0版本,我们已经实现了全链路的service,不管是计算资源还是存储资源,我能够实现存储资源没有访问的时候,我也能够释放掉。这部分的这个存储的数据不需要用户承担任何成本。这个点他乍一听诶,好像也没有什么了不起的啊,就是我存储不用了,我归档啊,就就可以实现啊,但是实际上他的这种难点在哪呢?就是我们可以归档。
36:04
但是大家只想到了一个没有请求的情况下,但是我们反过来想,如果我需要快速的恢复,我能不能够做到秒级的恢复?不管是我们的回档还是备份,它都需要时间。他再快,比如说我400T的数据,我以一个GB去回恢复,那我也需要小时级甚至天级别的恢复,那么对于用户来说,你的归档是没有任何意义的,因为我的请求我不知道什么时候来,我来了以后我要等一天两天才能够恢复,那我的业务完全属于一个不可用的状态,那我们的可释放存储其实就提供了,不管你的冷数据如何归档,只要用户请求来,我能够在秒级响应。这个请求内容能够基于配置级别的恢复,优先恢复用户请求的配置来使得我的访问能够秒级拉起。第三个就是我们实现了一个绝对平滑的弹性扩容。刚刚在上面一页中也跟大家提到了,我们在扩容和缩容中最难攻坚的一个就是它的抖动。
37:00
它的不管是它的这个性能毛刺,还是它的网络毛刺,都会对用户的实际生产业务带来很重的影响。而腾讯原生数据库service2.0。的架构,而我们通过改变它的这个,包括re的一个优化算法,包括改变了他的创客的一些这个预先分配和延后删除的机制等等来去实现了我们在扩容、缩容。的时间、用户的感知,我们可以做到零感知。不会出现任何的毛刺,能够让我们的真正的这个service服务于我们的核心系统的稳定性能够很大很大程度上提升好。以上就是我今天对于云云中数据库TBSC的发展和变革为大家带来的分享,谢谢大家,谢谢刘老师的精彩分享。接下来我们有请到的是好未来数据库技术专家李金威,李老师有着十年以上数据库管理经验,经历了好未来数据库规模由零到多的整个过程,目前负责好未来某核心事业部的数据库管理工作。接下来我们有请李老师带来教育行业数据库降本分效最佳实践,大家欢迎,朋友们下午好,我叫李金威,来自好未来,我今天分享的主题是教育行业数据库降本增效最佳实践,本次分享主要分为四个部分,重点讲一下第四部分,TC助力数据降本增效。我先看一下公司简介。
38:25
呃,豪威莱纳其实是一家以科技和创新为基础的教育公司,目前主要的业务是素养类教育,包括一些智能出版、智能教育、智能教辅,然后还正在目前正在进行数学大模型mast的研发。MASGBT是什么呢?是一个面向。全球数学爱好者和科研机构以解体和简体算法为核心的大模型。然后第二部分降本增效,机遇与挑战,大家可以看一下这张图。一个高等耐的研究显示呢,平均来说企业上云呢,会节省40%的费用,但是到2020年调查显示呢,大概80%的企业云资源上云之后,云成本大幅提高,是为什么呢?因为在迁云的过程当中呢,大概都会超超买55%的资源,然后并且呢,在云上的第一个18个月呢,大概会多花费70%的费用。
39:25
这是行业的一个现状,然后再接下来呢,看一下我们公司集团内部的现状,然后呢,举业内调查,正常情况下,数据库的产品费用呢,应该占企业云上费用的12%左右,但是我们集团内部呢,数据库的费用呢,严重超超出了行业的平均值,反映出呢,我们数据库的资源的浪费比较严重,既然数据库浪费比较严重呢,我们就去想办法去解决它。嗯,首先去找到数据库浪费的严严重的原因是什么,总结成两个方面,第一就是成本运营能力不足,另外一个方面呢,就是技术治理能力不足。
40:00
成本应用能力不足包括哪个方面呢?第一资源申请,资源申请呢就是比较粗放,然后申请流程过于简单,这是流程的问题。第二部分是资源分类,就是缺少标准规范的,呃,资源分类包包括的标签管理,第三呢是成本分摊,因为你没有做好呢,标签管理呢,就最终造成那个呃成本分摊不清,然后账单分摊不清,这些东西呢,你拿个业务去看的时候呢,业务是不认这个账单的。第二是技术治理能力不足,技术治理能力呢,就包括产产品种类,就是一开始你做数据库选型的时候,你的选型可能就是不对的,你可能是只选贵的,而没有选择更适用于业务的数据库类型。第二步是那个产品规格,产品规格呢就是一般作为一个DV来讲,可能最开始去开配置的时候,你可能开的都是过于偏大的,为什么开过于偏大呢?是因为你没有一个好的容量模型去评估去开多大是合适的。
41:01
第三呢是实力管理,因为我们集团内部呢,那个公有云账号比较多,然后呢,采购呢,权限比较分散,就是。大概有好几千个实力可能分摊在嗯,十多个部门,20多个部门之间去去管理,这样的话呢,就造成了,呃,就是管理比较分散,没法集,没法统一集中去做降配监控这些工作。然后既然找到了那个资源浪费的原因,接下来就看一下优化的思路与方法。然后大家可以看一下这张图,这张图呢是O,也是最近比较流行的一个概念,它的核心思想是什么呢?其实就是把it部门,业务部门,包括财务部门就是协同起来,一起去推进这个降本增效这个工作。就是基于这个理念呢,我们。部门内成立了一个类似这样的拟组织,里边就包括S,包括包括产品,包括然后呢,我们会以项目制的形式去推进这个降本增效解决方案,怎么去做呢?就是首先因为有业务部门的参与呢,我们作为技术人员就希望能拿拿到一些比较准确可信的数据,能够让业务部门看得懂,主要是两个可视化的能力建设,第一是利用率的可视化,第二个是成本的可视化。
42:27
利用率的可视化就比较好理解,就是各个资源的使用情况,包括一些黄金指标,然后一个就是成本的可视化,成本的可视化主要是以成本分摊,还有账单的管理,这个要做好了,这个最终要做到什么样的程度呢?我可以按不同的维度去看利用率的使用情况,还有那个成本的使用情况,然后这些不同的维度包括什么呢?包括我可以按照事业部的维度,按照业务线的维度,甚至按照小到。最小模块微服务那个,那就是微服务那一层那个维度去看各个资源的使用情况,包括他们的费用使用情况,这两个可视化结合起来以后,然后才能辅助我们去做决策,看是哪些业务线是存在浪费的情况,哪些实力存在一个浪费的情况,然后我们针对这些业务线,针对这些实力去做。
43:23
成本的降低,然后第二个就是提升技术治理能力的建设。刚才说就是因为旋行不规范嘛,然后我们就。另一个产品选型规范的SOP,对吧,然后呢,从源头上去控制产品选择不合理的情况,然后避免后期成本和产品费用过高,第二个呢,是建立科学的容量评估模型,这个评估模型主要是包依据是什么呢?就是。鸡。CPU、内存。LPSTPS这呃这些指标,然后呢,对每个实例呢,建立一个画像。
44:03
然后我们有上千个实例,我们给每一个实力都建一个画像,然后再根据这些画像呢,利用聚聚例的算法,对每一对每一个实例给他打上一个标签。比如说这一类的实例,我们。它适合什么样的配置,这类的势力,它适合什么样的配置,我们就把它统一的去规规范化的去管理起来,然后呢,嗯,我们就是利用这个容量模型,对我们现存存量的一些实例呢,去逐个的去对它进行降配。第三个呢,就是拥抱云原生,就是利用那个云原生的技术红利嘛,然后助力降本增效,然后看一下这两者的关系,技术治理能力和成本运用能力。的关系是什么呢?他们是关系是相辅相成,相互驱动的。就是。技术能力。降本增效的驱动支撑呢来自什么?来自资源利用率,还有账单的情况,然后呢成本运用数据信息,并依此为依据推动制推动资源治理架构的升级,同时呢联合财务团队和业务团队持续调整预算,最终目标是提升ROI,然后接下来看一下是那个TC是怎么助力我们公司那个做本增效的,大家可以看一下这张图,这张图就是我们教育行业一个典型的一个。
45:19
呃,明显的流量超袭的特征,那什么特征呢?就是每天晚上它峰值就上来了,到白天峰值就下去了,从周一到周日基本上都是这样,这样的话呢,其实你做一个DV来讲,你肯定想到的是我,我不断的要去对这个数据库进行那个升配和降配的操作。在之前我们这些数据库呢,都是用的分布式数据库,不是数据库大家也知道它。基本上都是传统型的嘛,它进行升配降配操作的过程中呢,就特别慢,因为它那个你那个升配降配的时间完全依赖于什么呢?完全依赖于它那个存储量的大小,如果说你的数据存储量特别大,那么它升配的时间就就越长,你数据量小的话,可能就几十分钟,如果数量大的话,可能长到几个小时,这样的话呢,我们就需要。
46:09
在。高峰前就要提前留给自己足够长的时间去做升配的操作。这是一个痛点,另外另外一个痛点就是我们担心就是什么呢?它高峰来的时候呢,它数据库性能扛不住,我们需要临时对它进行升配,然后进行升配的过程中也是很慢的,可能我们升配完以后,业务高峰已经过去了,这时间呢,肯定会造成一个比较大的故障。然后针对这种情况呢,我们呢,就是迫切需要一个可以快速谈货的数据库产品,这间我们就会进行去调研。然后又发现了什么?TC这个数据大家可以从它右边那个右边那个架构图可以看,它是那个分的架构,然后呢。代理节点呢,是无状态的,这个就是很好的一个云云远云远程数据库的一个特性啊,第一它分算分离,第二就是计算节点没有状态,这样的话呢,其实就意味着什么,意味着存酸分离,就意味着它数据库盘扩非踌。
47:10
然后呢,同时呢,还有兼容MYSQL5.75.8版本,正好那我们那个业务,目前那个在现场的业务都是都是基于5.7这个版本去去做的,对。所以说呢,接种性能是完全没有问题的,然后呢,再去调研调研调研的性能问题,因为大家都知道分布式数据库,为什么会用分布式数据库,因为它就是为了支撑高高并发,然后呢,还有一个解决那个单表数据量过大的问题。比如说你数据单表上百亿了,你查询可能就会就会慢一些,然后呢,嗯,大家看一下TTC的使用场景TTGOC呢,它那个是也是支持高并发吞吐的,也是支持海量存储数据的,但是呢,它可能没有分布式数据库支持的并发量更大,但是呢,它目前是适合我们的业务场景呢,因为我们的业务场景相对于相比较于之前来说呢,的业务量并发量呢,是没有那么大了,是降低了一些,然后刚好我们利用这个机会呢,就想把一些分布式数的数数据库去转成TTCC。
48:15
同时我们业务上单表也没有过百亿的表,所以说呢,这时间我们觉得把分布式数据库转成TTC是比目前是一个比较好的时机。然后呢,我们既然要去转,我们就要想好兜底方案,如果说T不能支撑。那么大的并发或者或者查询的时候。造成一个查询变慢了怎么办,我们的兜底方案呢,就是。如果出现性能问题的时候呢,我们可以快速的谈扩,就是利用CPU。去扛去扛高并发。然后呢,如果它单条so的单条so变慢的话,怎么办呢?我们就开启并行查询,甚至我们把TSOC的一个。
49:04
特性就是限流这个功能给它打开,然后经过调研,他觉得这个TC是完全合适的,当然如果你在真是,如果你想做这种中数据库到t Co OC远程数据库去做转换的情况下呢,一定要做好详细的压测方案,还有一些兜底方案,你才能去做这些这这些工作,但是我们这些东西前期都经过详细的调研,然后决定没问题之后,我们才把这个分布式数据库。往那个TTC上去转,然后转完之后的收益是什么呢?大家可以看下这张图。最开始分布数据库就是类似左图左边那个蓝色的,它上边核心业务去走分布式中间件,然后到下边那个数据库的节点。都是传统型的,不是不是存在分离的,然后下边是有铜库。
50:02
然后呢,还有聚合库,还有分析型数据库,分析型数据库是给那个o lap用的。这个架构就很复杂。它复杂在哪呢?它复杂它不单是有分布式中间件,还有计算节点,还有那个存,还有那个MYSQL节点,然后它还需要把数据呢。通过链路同步到分行数据库里边一份就也就意味着你前边有多少个节点,就需要开多少个链路。然后呢?它还要需要一个聚合库,这样的话你还需要用数据同步工具呢,把数据同步到那个聚合库里边一份,这样的话呢,就特别好,那个数据库的节点,还有那个数据同步链路,而且性能上可能还不太稳定。然后我们当我们把它转到那个TDCC之后呢,就发现我们把原来多个节点的数据,然后。同步到那个TOC那个呃,共享存储盘上之后呢,它是完全可以支撑业务上的流量的,然后呢,发现它那个数据结构也数据架构呢也简化了,原来有多个节点到这儿之后呢,我们只需要开三个计算节点,然后共用一存储就够了,然后那个同步链路呢,原来有多条,现在就变成了一条,对吧?然后呢,同时呢,我们还利用那个TC的那个并行计算能力呢,把我们原来的那个分行数据库。
51:28
也给替换掉了,这样的话做完以后呢,我们发现收益又很大,首先呢,它数据节点减少了,减少了75%,然后同步电路呢,也减少了87%以上。然后呢,同时呢,还助力业务提高开发效率,为什么会这么说呢?因为原来我们用分布式数据库的时候呢,其实是对那个研发的要求比较高的,因为你需要保证每个查询,包括更新一些操作都必须都必须要走走那个分片件,为什么必须要走分片件的,因为你不走分片键的话呢,可能就会所有舰单全部扫一遍,性能就特别的慢。
52:03
但是我们用上TC之后呢,你就像像用原来的,呃,就是传统型的那个MYSQL一样,然后去去去用就行了,对。然后另外一个就是用那个远程数据库TT4C呢,去替代那个传统型的惯性数据库,这个是为了充分利用到了那个TT4C的那个高性能,而且完全兼容能力,然后把多个实力合合并到一个实力里边,这个合并的时候呢,应该注意注意一个一个一个细节,就是你需要合并那些实例呢,尽量他们的高峰时间呢,尽量不在同一时刻,就比如说一个实例它上午高峰,另外一个实例中午高峰。然后另外一个实力下午高峰,这样的话呢,你就把三个实力合并在一个T实力里边,这样呢是没有什么问题的,如果说真有性能问题,你就可以利用T4C的快速弹扩能力,把实力在十秒左右就可以弹扩上去,对也是没问题的,做完这个之后的收益呢,我们那个实力那个数量就是大幅减少,而且自用使用率呢大幅的提升,就是通过刚才我们把云远程数据库,还有那个传统性的数据库转到TC之后呢,你会发现我们发现那个什么,我们发现我们那个数据库的成本降低了很多,其实降低了很多,已经完全达到达达标了,达到业务的要求了,也达到我们自己数据库在那个运营商数据库产品费用那个比例了。
53:32
这个做完之后呢,我们并没有停下来,我们还要继续往前走,去去去了解什么东西呢,去了接下来的东西呢,就是TCTTC呢这个产品呢,它和TC一样的地方呢,是什么呢?这个它是完全按照使用量收费,就像你用自来水一样,你接多少用多少。它不像传统的按量付费,你原来是四核8G的配置,你就会一直用四核,一直按照四核8G的配置去收费,但是呢,这个呢,比如说你。
54:06
是按使用量收费,你把这个规格呢,也你就开到它有一个下限,你下限给它开成一个CCU也就是一一个一核2G,它在低峰的时候呢,就按照一个C收费。它的上限呢,如果你给它开在四个C,如果它高峰上来的时候呢,比如说四个C大概相当于四核8G,它的大概用了有十分钟,他就只收你十分钟四核8G的钱,其他的时间呢,就按照一核2G的。资源去收费的。这样的话,看起来其实是。很省钱的。然后接下来呢,我们对它的性能进行了一些对比,因为我们要想把一些业务转到那个,我们就担心,我们就担心它是不是像。官网上所说的。嗯,性能上没有什么问题呢,我们对它进行了一些压测,就是在压测的过程中呢,CC呢,我们是开的是一到四,就是下线是一个c Co上线呢是四个C。
55:06
然后呢,就类似于就是下限是一核2G,上限呢是四核8G,然后TD4OC8.0呢,我们直接开到四核8G,然后就就对它进行压测,发现在压测的过程中呢,它那个CCUCCU的个数呢,完全是按照负载去升的,最开始是一个CCU,等它压力上去了,然后他就直接弹到四个C,弹到四核8G,然后压了有十分钟,大概它有四核8G持续了十分钟,然后呢,这时间呢,你就看它右边的性能对比就发现。它那个性能和那个正常版的呢,性能是差不多的,性能是差不多的,就说明了这个性能本身是没有什么问题的,然后接下来就看一下成本的对比。成本的对比,刚才也说了,成本的计算呢,主要是看你按照实际的使用量收费的,这个实际使用量就看照,就看你那个具体的业务高峰的时长,如果你一天的业务高峰的时长是越短,那肯定是越省钱的,如果你的高峰时时长越长,可能用这个so就不太不太省钱,我们根据我们那个测试环境,我们测试环境我们基本上平均高峰时长是两个小时,生长环境呢,平均高峰时长啊,也是两个小时,但是我们的上限。
56:21
生产环境的是CCU的上限开的高了一些,然后还有一个生产的环境的核心库,我们的是那个平均高峰市场呢,大概是四个小时,生产环境的核心库那个,呃,上线的个CCU呢我们开到了八个,就类似于是八核16G,这样的话,整体算来大家可以看一下,就是常数据库呢,大概包年包月测试环境大概是230,然后呢,用solvele之后呢,大概是180,然后生产环境呢,正常情况下是四核8G,大概是正常是1000多块钱,然后我们用那个solash之后呢,是600多,一些核心的库呢,大概是正常是2000多,但是我们用soulla以后是1000多,然后通过这个对比呢,你会发现我们用so用完之后呢,它数据库的成本呢,大概降低了40%以上。
57:08
然后这个算完之后呢,我们接下来就去做了,我们怎么做呢?我们就把测试环境的库,还有生产的离线库呢,全面使用那个TT了,为什么?因为测试环境,咱看一下测试环境的特点,测试环境什么特点呢?它并发比较低对吧,因为它是测试环境嘛,它的低并发比较低,而且呢,测试环境夜间一般测试环境都是公司内部人去做测试使用的,它夜间呢是没有业务访问的。如果说你正常情况下,你开一个四核8G的,放着它,它晚上也是四核8G,就比较浪费,如果你用soul的话,白天可能是四核8G几个小时内,但是大量的时间,它基本上就维持维持在一核2G那个状态,然后还有一个就是离线库,什么离线库呢,就是我们去基本上每个月初就会大量的去跑一些。抽取的计算可能大概就就用两天的时间。
58:00
这两天内呢,可能会把CPU和内存就比较高一些,然后平时呢,它知识做一些增长的同步,做增长同步的时候其实是不耗CPU的,它耗到CPU就比较这时间我们它就特别适合使用场景。然后呢,这个我们把那个测试环境和数据库呢,还有那个生产离线库呢,转到surfaces之后呢,发现它是有些收益,什么收益呢,就是简化又没了,我们不用再再对一些,呃,离线库进行月初的时候进行手动或者自动的去给它升配了,就完全靠service自己去解决了,然后测试环境呢,减少了荣誉的资源,可能原来我们一直让它保持在四核8G,这样的话呢,我们就。就一直让他。大概晚上保证它一核2G,白天可能偶尔四核8G,就这样跑着,我们不用太关心它对这个这个在我们公司内部的应用。就是这整个东西做完之后。我们那个数据库的费用真的是大大幅度减少,目目前呢,我们那个数据库的费用呢,基本上比如说之前相对于之前呢,就降低了很多很多了,已经。
59:09
以上就是我今天分享的全部内容,谢谢大家聆听观看。谢谢金威老师的精彩分享。接下来有请到的是今天最后一位分享嘉宾,腾讯云数据库产品经理陈浩。陈老师作为腾讯云数据库service产品负责人,曾参与多项数据库国标、航标、团标起草工作,曾负责腾讯云数据库培训认证体系、生态服务体系建设。欢迎陈老师带来TD circle c server助力企业降本增效的主题分享。大家好,我是腾云数据库产品经理陈浩,今天给大家带来的分享是TTSO-cso助力企业降本分效,那么今天呢,我会从这几个方面去给大家带来我的一个分享,首先呢,想给大家去整体去介绍一下数据库service的一个市场现状,其次呢,我将会对我们整个TSO-c service的一个架构设计去给大家带来一个分享啊,那最后呢,我会去分三个方面啊,去给大家去讲一下整个TTSO-C在弹性过程中是如何去保证的,如何去面对这种负载不确定的场景,去做一个比较稳定性的一个弹性啊,那最后呢,我会委屈大家带来几个典型的业务场景,去给大家去讲一下什么时候啊T所有杠C是比较去适合企业去使用的啊,那首先呢,让我们来一起看一下t t soq-c service啊,它整个一个数据库的一个市场现状,我们首先来了解一下什么是service,一般呢,很多网上都会是说啊,Service它是一种云计算的架构啊,还有一种说法呢,是说servicer,它是一种云服务的体验方式。
60:45
啊,其实对于我个人来说呢,我其实更想教他一种服务方式,那传统意义上来说呢,Service它是一种fast加bus,一种服务提供方式,那bus呢就是函数及服务啊,Bus呢就是后端及服务的一种方式,那么首先让我们来一起看一下啊,Service它的一些技术特点啊,它都有哪些共性,那一般service来说呢,我们都是通过这种API的方式去提供服务的啊,那通过API提供服务的方式呢,对于用户来说,我不需要去关心我后端的一个运维情况啊,我什么时候要用啊,我只要去用就行了,如果说我不用了,那我今天就不去调用这个。
61:19
API就好了,所以他一般来说呢,往往都是以这种API的方式去提供服务的啊,如果说我现在要去使用,我对我使用的部分去进行一个收费,如果说不使用的话,就不去进行一个收费,那serve呢,还要去保证一个特点,就是我们正常的啊,不管是数据库也好,还是其他服务也好,都要去保证我们这样一个高可用能力啊,比如说我们的函数计算啊,比如说我们对象存储,他们就是具有很典型的这样一个server,一些通用技术特点的,那数据库呢,作为一种bus服务,它其实很难像函数计算啊,包括我们对象存储去提供出像so这样一些技术特点啊,那比如说我们的cos啊,比如说我们对象存储啊,如果说我多少多多少存储数据,比如说我10GB啊,那我只要存到了cos头去就行了,我按照我这10GB去进行一个收费,如果说我今天不不去存了,那我不去对这部分进行一个收费就好了,所以说函数计算呢,和我们对象存储,它本身其实就具备这样一个serverize一些技术特性啊,那为什么说我们的数据库呢,很难去以这种serveize方式去提供呢?
62:19
因为一般来说,我们都会把我们的计算资源,还有我们这个存储资源啊,都放在一台整机上面去,我们计算资源和存储资源呢,很难够去用同比例的方式去进行一个使用,它往往都会有一个不确定的这样一个负载使用情况,所以它很难去做到像呃函数计算,还有包括对象存储,去按照我们实际使用量去进行一个付费,包括通过API的方式去进行一个调用啊,那后面我会给大家去详细展开,我们是如何去把数据库去做成server这样一个服务的一个提供方式,那么其实对于server技术来看呢,其实在整个业内呢,都去呈现出这样一个繁荣发展的一个态势啊,如果说我们把数据库的时代去进行一个划分,我们可以把它划分为啊三个时代,那1.0时代呢,我们称之为云托管数据库时代,那在这个时代呢,我们往往是把这种开源数据库,比如说我们的MYSQL,我们CDB这部分啊,我们以这种租户的方式去提供给用户,这也是传统的云厂商啊,以最初的开始去给大家去进行一种方式的提供,那以这种方式的提供呢,可以很好的去帮助用户。
63:19
去降低我的一个运维成本,同时呢,能够去把我整个底层的资源去进行一个最大利用率的一个最大限度的一个提升啊,合理的去分配给用户不同的一个资源使用率,所以能够去帮助用户在很大程度上能够去降低我的一个使用成本,那2.0时代呢,我们称之为云原生数据库时代啊,云原生数据库时代的最大的一个技术特点就是我的计算和存储去进行一个解耦啊,中间可能通过一些高速网络,比如说rdma去进行一些网络的连接啊,通过这样的一个存算仅有的方式,能够最大程度的去把我们数据库的性能去发挥出来啊,比如说我们数据库,一般来说,我的传统云数据库,我的主图同步要通过blo方式进行同步,但是我存在分离之后啊,我还可以去采用维度的方式去进行一个组成同步,这样很大程度的去降低了我们blo组成同步的一个延迟啊,所以2.0数据库时代呢,其实我们可以简单理解为它是对性能的一个很大的一个提升,更加。
64:17
充分的去把我们的资源啊调用起来,给用户去进行一个分配啊,那在追求完性能之后,在一定程度上追求完我们的极致的一个运维之后,那其实进入了我们3.0数据库时代啊,我们称之为serveless数据库时代,在这个时代呢,我们可以尽可能的去把我们的资源利用率去发挥到我们的最大的一个限度,能够进一步去帮助用户去降低成本啊,所以我们进入了下一个时代,就是我们现在的数据库时代,那技术呢,在整个调研报告中啊,我们也可以看到它以这样一个稳定上升的这样一个状态去进行呈现啊,那预计到2024年的时候呢,也将会达到140亿美元的这样一个高度啊,那为什么我们说云原生数据库service呢,是我们发展的一个必然性呢?那么下面我们先来看一下左面左下角这张图啊,它是传统云数据库的一个架构啊,刚才也就提到了,就是我们的计算资源和我们的存储资源往往都是部署在一台机器上面去的,那举个例子,比如说我今天我的存储资源已经使用了90%了,但是我的计算资源可能今天只占用了我的。
65:18
10%,那这个时候呢,我的传统单机它已经达到了我整机的这样一个资源的一个最大的限度,所以我需要去横向的加机器啊,那这个时候呢,就造成了一种计算资源的浪费,反之亦然,如果说我的计算资源今天已经使用到了90%,但我存储之使用了10%,我也需要去横向加机器,就在这样的情况下呢,我存算一体就很难。去把我的资源最大程度的去发挥出来,而且是极易产生碎片的啊,那我们serverla呢,本身是基于这样一个存算分离的一个整体架构的,如果说我今天存储资源不够的,我只需要去横向的去加我的机器就行,加存储机器就行,整个的存储呢,我们是使用这种三副本的这样一个方式去共享处理一个分布式的一个存储池啊,它这种存算分离的架构下呢啊,我如果计算资源不够啊,我很想去加计算机器,如果说存储资源不够呢,我只需要去扩展我的存储资源就好了,所以在这种架构下面去发展我们serve呢,它更好的去解决了我这些产生的这种碎片资源,可以把这种碎片资源去用serve的一个方式去给用户去提供出来,把我们底层的资源的利用率啊,最大程度的啊发挥出来啊,那下面呢,我们一起来看一下TSO-cso整体的一个架构啊,刚刚也已经提到了,整个TTSO-cso,它是依托于TTSO-C的啊,TTSO-C的架构啊,前面我们已经讲过了,那我们现在不再去赘述啊,我们主要看一下。
66:41
的整体一个架构,那计算层和我的存储层呢,是整体去依赖T-C的啊,能够去做到这样一个秒级弹性存储池,也可以做到秒级扩缩容的一个能力啊,这里管控资源呢,我们主要是管控层主要是去做一样一个资源的一个监控,同时他去触发我们资源的一个调度,触发我们的扩扩缩容啊,如果说我的计算资源不够了,我要通过我的管控层去加我的机器啊,如果说我的存储层不够,也要去通过我的管控层去横向的去拓展我的存储资源啊,同时呢,我们还要去通过管控层去做一个资源的一个监控,能够去把我们整个使用的实际的使用量去上报给我们的一个计费。
67:20
那在这里呢,可能有一个很不太一样的地方,就是在我们肌肉层,肌肉层呢,我们增加了一个啊恢复感知器,这个恢复感知器呢,主要是用来去保证当实力暂停之后啊,如何去快速的把实力拉起,同时保证我手连是不断的啊,那在后面呢,我也会给大家去详细去讲一下整个恢复感知器的一个工作原理,再往下呢,就是我们去具体去分析啊,在不同的场景下,Serve是如何去做到一个稳定性的一个弹性,那首先来我们让我们看一下我们如何针对这种负载不确定的场景去做到一个灵活性的一个弹性,那其实对于业界来说呢,其实大家都常用一种弹性方式呢,就是左边这张图啊,它相当于会给用户提前去分配啊一块资源,比如说我现在流量很低,我可能提前给你分配一个最小的规格,1C2G的这样一个规格,当你的负载来临之后,我通过我的资源的一个监控,你触发到我这个阈值之后,我再去给你分配一个更高规格的这样一个资源,比如说你的CPU已经打满了,那这个时候呢,会有。
68:21
一个监控的一个时长,比如说30秒,有可能是五分钟啊,在这样持续的一个高负载情况下,我去触发我的一个空操作,那这种方式呢,其实明显有一个缺陷啊,就是我很容易去发生宕机,或者我内存OM的一个现象,因为我的负载高峰来的时候,它是非常突然的,如果我还需要长时间的一个监控才能去触发我的一个扩容操作,其实这个时候可能流量都已经过去了,或者说它流量可能已经更高了,所以很难的及时去触发我的一个扩容操作,所以这种方式呢,其实在一定程度上对业务是有损的,所以TSO-C在设计的时候就摒弃了这种。架构的一个设计方法,我们反而是采用这种一种事前弹性的一种方式,提前去把最大规格的资源能够预先分配给用户,根据CPU的使用率呢,我们动态去调整我们的buffer po啊,根据我们buffer po呢,能够不断的去调整你这样的一个访问速度,所以对于用户的感知层面上来说,就是当你的负载来临之后,你可以立马去用到最大规格的资源啊,可以做到这样一个秒级伸缩的一个能力啊,对业务是完全无感的啊,在这种方式下呢,也能够保证在高负来临时候,我们能够马上拉起我们的资源,保证对业务是整体一个无损的方式啊,那整个弹性规格呢,我们在一开始也会去让用户去设定一个规格区间啊,比如说你的最小资源是1C2G啊,最大资源是四核8G的,这样情况下,那我们就会在这个范围区间去进行一个弹性啊,但是我们会预先去把这部分资源都会分配给用户啊,因为是按照你最大的规格上限去谈的,所以对于用户来说,它是一种事前弹性的方式。我们可以快速的去把所。
70:00
所的资源能够充分的去利用起来,能够达到这样一个准秒级扩缩容的一个能力啊,刚才提到的都是我们极致的一个纵向弹性,那么今天我们也发正式发布了我们集群版的server,那集群版的server呢,其实它更重要的是整个一个横向弹性的一个能力啊。整个集群集的so呢,我们最高支持一些啊八读这样的一个场景啊,那RO的这个节点呢,我们是怎么谈呢,我们会分为两种弹性,哎,第一种呢,就是刚才提到的我的一个垂直弹性,第二种呢,就是我一个横向弹性,就是我根据我每一个指数节点的一个负载情况,如果说我这个指数节点达到了我们一开始设定的一个阈值流量阈值之后,我们可以快速的去拉起一个新的计算节点啊,能够去做到这样一个横向的一个弹性啊,同时呢,能够通过这样资源混的形式呢,把我们的normal和我们的service充分的去混合到一起,解决我们整个normal版本的一个碎片化的一个资源啊,再往上一层呢,我们是增加了通过这样一个policy的方式去保证我的整个。
71:01
链路啊,是完全业务无损的,就是当我们比如说要去动态的横向去加我的只读啊,或者说我去缩减少我的指数节点的一个数量啊,包括对时际拉起,能通过process去保证一个链接不断一个能力啊,包括我们如果说底层资源会发生一种跨机扩容的一个时候的时候,也通过process去保证今天的链接是可以不断种不断的啊,能够去做到这样的一个精准的一个调度,整个调度方式呢,也通过我们内部的一个调度优化去去把我底层的资源充分的去调动起来,通过normal和service的一个资源混部的一个方式,能够去把这部分的资源最大程度的去给用户。提供出来啊,同时保证业务的一个安全稳定性。那下一个场景呢,就是说我们刚才提到了这种疯狂的弹性啊,就可能弹上弹下,那我们在弹性过程中是如何保证对业务无损,如何去保证这个稳定性的呢?啊首先我们去讲第一个场景,那第一个场景呢,就是当我们的负载今天如果说不用了啊,比较低的时候,可能会触发到实力的一个暂停啊,当业务如果再要去访问,有负载再进来的时候,要去把暂停的实例去恢复过来,那这个时候呢,就需要用到我们刚才提到的在接入层中的恢复感知器了啊首先呢,当链接访问进来的时后,它会与恢复感知器去做一个TCP的这样一个握手连接啊,当恢复感知器接收到请求之后,它会立马与管控层再建立这样一个TCP的。
72:26
一个安全的一个访问连接啊,通过内核去,呃,通过管控去把我们的内核去拉起来啊,那这个过程中呢,我们整个可以通过恢复感知器去保证一个用户的连接是一个稳定性的啊,能保证这样手连是不断的啊,保持用户连接通过测试呢,我们整体的这样一个冷启动时间呢,最长不超过啊2000毫秒,那这里也有人会去问了,那我们在接入层增加了这样一个恢复感知器,它是不是在一定程度上使我的IO访问就变得长了,那这个时候呢,我们会通过VIP路由权重的一个方式去保证每一条连接都是走正常的这样一个链路,比如说我今天实力是暂停的,那我今天恢复感知器的VIP权重它就为最大啊,就为100啊,那这个时候呢,我们就会首先通过恢复感知器去把我们的实例进行一个恢复啊,那这个时候呢,是必须这条连接去访问通过恢复感知器的啊,那第二个如果说我当我的实力恢复了之后,我当我的实例拉起来之后,第二条第三条,包括后面很多条链接进来之后,这个时候的VIP路由的权中会。
73:27
把恢复感知器设置为零,所以新的连接进来都会直接去连到我们的数据库实例上面去啊,这样就保证了在后面一个新的连接无需要再去通过恢复感知器啊,这样的话就保证了我们整个IO是一个很健康的,那下面也要再去讲一下,就是我们弹性过程中是如何去保证稳定性的,一般的厂商来说,它其实用我们的库斯龙都会去用到这样一个参数,就是ESBP啊BP这个情况,但是如果我只用传统BP的话,很有可能会发生慢茬啊,会发生一些毛刺的现象,那发生毛刺的现象呢?为什么会发生毛刺,我们一般会调研有三种情况,第一个呢,我们会出现IO瓶颈,这个IO瓶颈呢,是因为我在缩拢过程中,我需要去刷脏,我持有化配置的时候呢,可能会存在这样一个IO的瓶颈啊,第二瓶颈点呢,是在于我要去持有锁啊,我如果要去访问,我在搜问过程中,如果要去访问我的回收区的这样一个block的情况下,我可能会去频繁的去便利我的l ru list,还有包括我的free list,它便利的过。
74:27
程中呢,我们也有可能持续的去持有这个MU锁,一旦MU锁持续的时间比较长的长的话,那我的IO访问就会变长,就会出现慢查询的一个情况,那第三个瓶颈呢,就是我在整个诉讼过程中,我可能会去持有BP的这样一个全局锁,如果BP的全局锁执行时间过长,也会一定程度上出现慢查询,那针对这三个瓶颈呢,我们也是做了三个优化,首先第一个是IO瓶颈的优化,因为TDSO-cso本身依托于TD-C的这样一个架构TSO-C呢,它是采用维度的方式啊,去把我的存储层去异步的去生成配置,所以计算节点,节点呢,我不需要去刷脏,直接去丢弃,我淘汰了这样一个配置页啊。第二个呢,瓶颈点就是mutic锁的一个瓶颈啊,我们是通过减少池锁的这样一个范围和时长,同时呢,按照地址去便利我们的。
75:18
被回收区的创的这个block啊,整个加锁区间呢,由我的LRU的链表去变成我单个的一个block啊,这样呢就可以从整个回收区到非回收区的时候,我不需要多次去便利我的LRU链表啊,在这样的情况下呢,我就可以减少我MUT锁的持锁时长啊,那第三个呢,就是我的全局锁的一个平行点,全局锁呢,我们会采用这样一个延迟释放啊,创还要包括提前预分配创的这样一个策略啊,通过优化这个recess哈希的这样一个算法啊,能够把这个整个算法的模式我们改为异步模式,在这样的程度下呢,我们把三个平行点都进行了一个优化,所以整体测试下来,我们把整个毛刺问题啊,就是这个慢查询的现象啊彻底根治掉了啊,整个慢查询的数量呢,降低了100%啊,现在是完全没有毛刺的一个情况,那下面呢,我们给大家一起来呃,演示一下我们是如何在整个负载不确定情况下去做到一个秒级弹性啊,扩松人的这样一个能力的,还有当我的。
76:18
慢查询啊,可能会出现的时候啊,我的原先内核和现在这样一个内核的一个对比啊,大家可以看到啊,最左上角这张图就是CCU,我们CCU这个指标呢,大家可以简单理解为它就是我们的一个啊计费指标啊,整个计费指标是按秒级去进行采样的啊,是我们按照实际的使用量去对大家去进行一个呃,一个收费。那左上角第二张图呢,是我们整个数据库的一个规格,这张图我们可以看到,根据左下角这个CCPU的使用率啊,包括CPU的一个情况,我规格的一个变化,可以看到跟他们是一个几乎是一个比较完全一致的一个曲线啊,所以这个就证明了在负载来的时候,我们可以做到一个秒级的一个弹性能力,完全不需要去做一个等待,如果它是一个事前弹性的方式的话,那这里CPU的使用情况,它一定是要提前与我规格的一个变化弹性的啊,这里我们可以通过时间可以看到它是一个完全同步的一个时间,当你的CPU使用率上升来之后啊,或者说你的内存提高了之后啊,它的整个qta就是我们的规格啊,也会及时的发生这样一个弹性啊,那我们再看下面这张对比啊,整个下面这张图的对比一个情况,我们可以看到下面这张慢查询的表呢,可以看到当所有人情况下,它发生一个很明显的一个慢查询啊,明显的这样一个很多数量的一个慢查询现象啊,尤其是在当我们。
77:39
从一个比较大规格突然去送到一个比较小规格的这样一个BP的时候啊,发生毛塞这种现象是最为明显的啊,所以在每次缩人过程中,它可能都会去触发这种毛刺的一个现象啊,随着我这样的BP的内存可能越来越少,我的毛刺可能数量也越来越少,但是不管怎么说它都是有一种毛刺的啊,那上面这张图呢,就是我们在内核优化之后的一个监控图,我们可以看到毛刺现象已经完全去解决了啊,上面已经完全没有毛刺的这样一个情况了啊,那最后一个呢,我们来去再去从成本上面去为大家去分析一下我们TSO-c service是如何去帮助企业去极致的去降低成本,那首先呢,就要去提一下我们的一个计费的一个单位,那c cuu呢,是serve对独特的一个计费单单位,大家可以简单理解为它是我CPU后的1/2内存取最大值的这样一个规格啊,比如说我今天实际使用量,我的CPU可能使用的是一核啊,我的内存可能使用的是也是1G,那这个时候呢,我们会去按照这个去计算啊,那。
78:39
我们现在明显看到啊,1GB除以二,那是0.5,那我们还是要去CP最大的一一的这样一个规格,所以C今天是按照我对应的等比例的12G的这样一个规格去进行收费的,那我们采样呢,是按照每五秒去进行一个采样的一个频率,取五秒平均的一个C的消耗量去对用户进行一个收费的啊,可以做到这样一个准实时的一个收费的区间啊,那同时呢,我们在整个计费模式上呢,也支持这种资源包的一种方式,资源包大家怎么去理解,我们可以把它想象成一张储蓄卡,就是提前去购买好的CU资源,就比如说我的店,提前把我的店存到我这张资资源包里头,存到我这张储蓄卡里头,当我使用的时候,只需要去抵我这张资源包里头的度数就行了啊,就是抵扣我资源包里头的CCU的这个量啊,在这种资源包的模式下呢,我们可以测算,通过同呃同比可以看到同比我们同规格的这个。
79:32
包年包月的规格,它可以最高去降低25%的这样一个成本啊,那其次呢啊,我们说我们做到了这样的一个业内首创的可释放存储,进一步去帮助用户去降低我存储的一个成本,其实现在很多的厂商我们都在提service不使用不付费啊,对于数据库来说,大家其实提的可能都是我的计算节点啊,因为计算节点呢,我今天如果说我不用了,我回收,我对用户来说我不收费了,但是存储的成本其实还是很高的,因为我计算节点回收了,但是我的存储资源可能还放在那里,所以我们的service今天大部分大家都没有去讲我存储是怎么去帮助用户去降低成本的,那比如说我一些归档类的场景,比如说我有很多呃,实例有可能就是比如七天可能才用一次,或者一个月才能用一次,那这个时候呢,我就要去为我额外的存储资源去付我高昂的一个费用,那通过可释放存储的这个逻辑呢,我们可以去进一步去降低用户的存储成本,我们会把数据从分布式存储中,当实例暂停之后,我们把它归档到我们的归档存储中。
80:32
啊,那在这里头呢,可能会有一个技术难点,就是当我的实力如果唤醒的时候,我怎么能够去快速的去恢复数据,使用数据,那这个技术点呢,也会有后面的同事给大家去详细的去讲解,我们如何去做到快速的去把我们的归档存储的数据啊,恢复到我们分布式存储中来,那简单来说呢,就是在用户首次访问的时候,我们会优先去访问我们的这样一个归档的这部分的一个表啊,能够去做到对业务是完全无损的秒级去访问到数据,用户无需担心啊,是不是我今天归档存储数据必须全部恢复到我的分布式存储之后啊,我今天才能访问到数据啊,这个是不需要担心的,所以在归档存储这种模式下呢,我们可以进一步去帮助用户去降低我们今天的一个存储成本啊,最高呢,同比可以看到比分布式存储还能降低80%的这样一个费用,那最后呢,去给大家去讲一个,呃,Server的一些应用场景,刚才也提到了很多原理和一些架构,那么什么样的场景才适合去使用TTC呢?啊,那我们来看首先有这样几个。
81:32
列举了有三个场景,那第一个场景呢,就是我们这样一些低频访问的场景,比如说我一些个人博客啊,比如说我一些垂直论坛社区,可能我不知道我今天有个博客,包括我的社区啊,什么时候有一天成为爆款了啊,就比如说我前段时间呢,我们羊了个羊的游戏啊,那可能他一开始用的数据库规格比较低,但是突然有一下他爆爆火了,那访问特别大,那这个时候呢,如果我没有做到及时的扩容,那这个时候就很有很有可能发现宕机的这样一个情况,那用service呢,无需关心扩充的时候,如果流量过来之后,那我们可以迅速的去扩大一个更大的一个规格,那第二呢,就是我们开发测试场景,那这部分场景呢,一般的业务情况呢,就是对于企业来说,我可能周一到周五的工作日啊,包括白天时间,我可能采用这部分资源,那这个时候呢,就会比如说我周中的晚上,或者说周六日,那我不使用的,这个时候呢,其实就一定程度上造成了一定资源浪费,所以这部分的业务场景呢,也很适合用service去进行一个承载啊,那最后一个呢,就是我们的一个活动类的场景,比如说我们的6181大促啊,比如说我们。
82:32
一些比赛类的活动啊,对于一些企业来说啊,都需要提前的去预判我今天的高负载可能到那种资源,我去提前的去做一个运维,提前的去扩缩容,那这部分呢,其实很浪费人效,那使用serve呢,对于用户来说,完全无需要去关心我什么时候要去扩容,什么时候要去加机器啊,只需要它自动的,它就会能够完成这样一个扩容扩容操作啊,当然了TSO-C呢,也不局限于这些场景,那当我们的整个集群版的正式发布之后呢,其实对于我们来说,Service已经可以完全的去覆盖所有的数据库使用场景了,包括一些业务很核心的一些场景,包括我们可能要去做一些读写分离的业务场景,都可以去使用service,如果我们的企业有降本增效的诉求的话啊,我觉得都可以去尝试去使用一下service,那下面呢,分享我们几个客户的一个典型的案例,那首先呢,一个比较经典的案例呢,就是我们的微信云托管,做小程序开发的人可能都比较清晰这个,呃,这个产品啊,那整个TSO-C呢,是支撑了微信云托管这样的一个技术架构。
83:32
我们已经为50万小程序开发者提供了这样的一个一站式的平台,那其次呢,就是我们的腾讯乐享平台,那这个平台呢,其实一开始找到我们,他有一个很大的一个痛点,因为他的用户呢,可能都是一些中小的用户啊,他对资源的消耗率也不高,所以他一开始采用的办法是什么?通过一个大账号买了一个大实例啊,多个用户去共享这样一个实例,但是这样的方式呢,其实对于一些资源的隔离性是很差的,而且很有可能会发生一些冲突性的问题,那使用TSO-c service呢,一方面啊,既保证了我资源一个良好的隔离,可以为每一个用户都会去提供一个servicer实力,那其次呢,也能够去帮助腾讯乐享去进一步的去降低成本,把这些小的资源都分配到我整机资源的一个碎片化的程度上面去啊,能够最大程度的去把我的成本去进行一个。
84:18
降降低啊,经过测算呢,整个我们帮助腾讯乐享降低了80%的一个成本。后面呢,还有很多客户,包括我们的好未来,包括富图啊,这些客户现在都在逐步的去使用TSO-C去完成企业降本增效的一个这样一个目标,那最后呢,我想说啊,作为TSO-C呢,我们希望能够像大坝一样去管理好水资源啊,我们就把数据库资源去比喻成一个水资源,通过不断去建设好大坝,能够去帮助企业去用好我们的水资源啊,什么时候想用你就可以去用,同时呢,在用的过程中能够保证你的业务是完全无损的啊,那这就是我今天一个分享啊,最后谢谢大家,谢谢陈老师的精彩分享。刚刚,三位专家从云原生数据库的变革创新、核心特性、云成本优化思路、典型应用场景等多个层面为我们分享了腾讯云原生数据库为企业带来的数据价值,希望能给屏幕前的观众朋友们带来一些启发,释放更多精力于业务创新,让数据库成为业务创新事半功倍的得力助手。
85:25
时间过得很快,本期活动也进入到了尾声,再次感谢大家的参与与关注,我们下期活动再见。
我来说两句