使用TDSQL-C Serverless服务实现数据库极致弹性原创

嗯。好，各位大家下午好，呃，那么刚刚听了冰心老师以及室友老师对在那个云函数和那个云容器的斯化的这样一个努力，那么或多或从宏观或从微观上面的程度来介绍他们的产品，那么对于我来说，我也是学习了很多呢，相信大家应该也学习到了很多，那么我来做一下自我介绍，那么我是于悦，是腾讯云数据库的研发工程师啊。呃，那么作为一个开发人员，那么可能更多的是在架构上来介绍一下我们这个TSO-C的这个数据库产品，它的一个架构，呃的一个设计，以及我们如何对它实现了一个搜化的这样一个。这样一个实现。那么我将我那个内容将从以下这几个部分展开，那么首先还是来介绍一下数据库service的现状，那么再重复说一下的这个定义吧，它其实是更多的是描述了云产品的这样一种能力，那比如说是无需运维，然后可以通过API访问，呃，可以按照调用的次数来计费，然后并且实现了高可用，那么最好还是可以实现实时的弹性伸缩，那么实际上它是按照定义来说，它是包含了fast和BUS2块，那么fasts对外展现更多的其实是一个云函数的这种形态，那么它是那个具有一定的计算能力，可以按照调用的次数来计费，那么不调用的话就不计费，那么那个在bus上面来说的话，嗯，很多的，嗯，很多的后后端云产品，比如说对象存储已经实现了bus这样的特性，那么可以说它按照存储的量计费，然后并且包呃根据用户的下载，包括带宽这等等的这种方式来计费，那么如果云数据库也实现了S化的话。

那么这右边这样一个典型的这种调用的链路就可以可能会成为一个全链路的service，但是传统的云数据库其实是很难做到这一点的，那么主要的一个原因就是说，嗯，传统云数据库还是一个就是计算和存储一体式的这样一个架构，它可能是在要在同一台机器上部署，那么就很难做到一个按需计费的这样一个需求，那么一般来说我们购买数据库产品的时候，它可能就是规格和就是计算的规格和存储的规格一般来说是呈正相关的，当然一般情况下也是呈正相关的，但是就会有用户有这样的需求，比如说我对计算的要求其实不是很高，但对存储的要求可能很高，那比如说他可能会持续的向数据库里面写日志，那么这种情况下就很难做到按需计费的这种模式，呃，因为你并不能对计算和存储分别来进行计费，那么我们在后面也将介绍我们t two-C是如何实现这样的一个特性的。

呃，那么再介绍一下这个云数据库的一个发展吧，那么按照我们这个的考虑，可能把它分为三个时期，那么1.0的时代就是云原生数据，呃，就是云数据库的时代，或者对对应我们产品就叫云数据库买SQL，那么它将传统的这种就是物理机器搬到云上，然后以租户的方式给用户提供数据库服务，那么2.0时代就是云人生数据库时代了，那么云的话本身就包含了一个尺化的这样的概念嘛，那么我们这个TSO-C这里这样的一个产品，那么就实现了一个计算和存储分离的这样的一个架构，那么可以用户可以按照自己的需求对，呃，对计算资源和存储资源进行一个考量，然后来按需购买自己的产品，那么到3.0时代，也就是service，或者说是无服务的一个时代啊，那么在云原生数据库的基础上，它使得呃资源就会更加具有弹性，那么可以在计费模式上也会更加更加的贴近于用户的使用方式来进行。

计费，然后并且也实现了无使用无计费的这样的一种模式，呃，那么。对好，那么接下来介绍一下我们T-c service服务的特点以及实现啊，那么传统云数据库刚刚也说了，它是一个同机，嗯，是同机部署的一个模型，那么它。

当然了，他呃通过租户的方式给用户提供服务，那么并且提供了一些特性，比如说高可用啊，然后包括自动备份的这样一些特性，呃在一定程度上减少了用户的运维的这样的一个痛点，那么但是它本身就是产品上还是存在一定的缺陷，或者说有些痛点需要去解决，那么第一个方面就是说它是一个存算一体的这样一个模型，那么这样的话就是计算跟存储它的规格一般来说是就是相关的，那么这样的话可能就会比较容易产生碎片，那么比如说左边左下方这个数据库实例一啊，这种情况，他可能说呃，我的计算用的比较少，但是对存储的用量比较大，就刚刚说的，可能讲不断的要写日志的这种情况，那么在这种情况下，他可能也要就新增加一个横向扩展一个节点，那么来满足他的这个存储的要求，但是这样的话，它的计算这一部分本来就浪费了，就会浪费的会更多，那么反过来也是一样，比如说可能对计算要求比较多，但对存储要求比较少，那么这种情况下也需要进行扩容。

中，那同样的就是存储会浪费的比较多，那么我们t soq-C这款数据库实际上是实现了就是计算和存储分离的这样的一个特性，呃，那么这样这个它也是就是让我们实现service化的，就是数据库service化的一个很大的一个前提就是说呃，计算跟存储结偶，那么你计算不足的时候，实际上就直接要加计算节点，那么存储呃不够的时候呢，你就直接弹性存储就可以了，那么。因为我们这边也做到了这个就是成串分离的架构，因此就是说在故障恢复的时候，实际上就是再拉起一个计算节点就可以，速度是非常快的，可以以秒为单位，那么在横向扩展，就是说加计算节点的时候，实际上也是就像有点像故障恢复的那种情况，也是以秒的级别来增加那个计算节点，因为他们共用的是同一份存储啊，那么第二点就第二个痛点就是说，呃，它那个传统云数据库，它的规格是比较固定的，呃，就是说我们用户在购买这个云数据库的之前要提前规划，就是说可能要按照就是根据未来一段时间你的那个负载以及你的存储用量来选型，并不能说它并不能就是说根据用户所需要的规格来进行一个弹性，那么并且他也没有这种无使用无计费的这种模式，因为它的就是你购买了数据库服务之后，呃，如果你不使用数据库，那么它这个进程也是常驻的，那么同样还要进行计费，那么我们。

TSO-C数据库，然后包括他的service形态，实际上是有一个纵向弹性扩缩容的能力，那么用户在选择一个呃计那个算力区间以后，那么计算的资源就可以在这个算力区间内自由的弹性，就根据用户的的需求来用户的负载来进行弹性，那么不，没有就不需要用户提前去做手动扩容或者手动缩容的这种操作啊。

然后也支持自动暂停的功能，那么在用户没有负载一段时间之后，那么就把计算资源给拿掉，只对存储的资源进行计费。那么第三点的话就是说云云有传统云数据库，它一个痛点就是说，呃，根据那个传统MYSQL的这种B道的主从同步复制，可能会容易产生延迟，那么有的时候可能一个大事物来的时候，主从可能会差几个小时，呃，那么主要简单说一下，就可能说blog它是描述了这个物，呃，就是逻辑上他数据的一个修改的一个日志，那么从从今拿到了这个冰号以后，还是要做一和主机一样的事情，要进行回放，那么还会消耗大量的集算资源，那么我们TSO-C这款数据库是实现了用relo来，就是这种描述页面物理修改的这种日志来进行呃同步，那么这样的话就相当就不恰当，比方就是说我相当于把我算好了的东西都已经跟你说了，你告你就直接按照我这个结果去改就可以了，所以这样的话集团资源消耗会更少。那么所以这。

三点就是能表现出我们这杠C数据库以及这些so形态的这样这种优势。那么介绍完优势以后呢，来介绍一下我们TSO-C这款数据库的一个架构吧，那么从右边这张图大家也可以看出来，上半部分实际上是一个计算节点的一个横向拓展的能力，我们是支持呃艺术多层架构通过re度同步的这样一种形式，那么上下来看的话，它是计算和存储分离的这样一种形式，那么在数据库内核上，我们使用的是自研的T叉搜Q内核，那么是100%兼容买搜Q的这种数据库的，那么在存储的这个层面，我们使用的是一个分布式的一个存储，可以呃可以有极致的弹性，那么并且它是一个三副本强一制性校验呢，那么在日志的下方就是re度日志从计算层到存储层的下沉的时候，然后包括在日志回放的时候会有呃。

就会会有强一制的校验，那么保证了数据安全性可以达到九个九的这样的一个级别，那么因为刚刚也说了，就是我们这是一个存探分离的架构，所以说在横向扩展计算节点的时候，际上只要申请计算资源，然后开一个进程就可以了，实际上它的横向扩展速度以及故障恢复的速度都是很快的，大家可以以秒为单位来计算，那么就呃，这种就比传统云数据库可能要做什么数据搬迁，然后包括用B的组成同步这种方式要快的多得多啊。那么右边这张图实际上是刚刚上面那就刚刚那个页面的那张图的一个简化的一个版本吧，那么我们在这里可能主要说就是说组从吕log同步的这样一种方式，那么它的延迟可以就是主从的同步的延迟可以达到一个毫秒的一个级别，那么为了实现这种主从同用re log同步的这种方式，那么我们内核的同学和存储同学也做了很多的努力，那么一个方面就是说他在log里面加上了一些事物的信息，然后保证主从可以有一致性的一个读的视图，那么在日志下沉到存储层的时候，或者说是计算节点之间同步re log的时候，那么我们通过改造了re多log这个里面的内容，使得它的一个就是同容量的re log里面的信息密度它是更高的，那么这样的话会减少计算节点之间以及计算到存储之间的它的这样一个IO的损耗，那么那么现在我们已经实现了，就是说从计算到存储以及存储层之间的一个RD ma。

A的链，全链度的阿里ma，那么这样的话，IO的耗时会进一步的降低，那么我们说我们TSO-C这块数据库是一个什么？呃，日志及数据库log is database，呃，那么计算层通过这个计算存储代理的这样一个单元把re log下沉到存储层，那么存储层为了就构造一个最新的页面，它是具有一定的计算能力的，那么它会不断下放，呃，它不会不断回放，那个计算层下放到维度日志到存储层的页面上，然后使得每一次，呃，就是计算层要拿到的页面都是一个最新的一个页面啊。

好，那么刚说完我们t t soq-C的一个架构，以及它的一些优势，那么。的工作，那么TSO-cso实际上就是我们对TSO-C这款数据库呃进行了一定的就是设计，然后其实它是基于或者说是依赖于TSO-C这种存在分离的架构的，因此它也有呃计算节点秒级扩容，跨级切换也是秒级的这样一个特性，那么存储也是一个极致的迟化的这样一个特性。那么。为了实现就serviceless特性，比如说就是说按用户的使用量计费，然后不使用不计费的这种特性，那么我们的管控层会那个根据用户的，在这个是数据库实例暂停的时候，呃，可以根据用户的连接，然后那个通知我们管控层把计算节点给拉起来，呃，这个时候然后我们的监控服务会监控呃，计算资源和存储资源的消耗，然后对然后根据并且根据用户的负载进行一个秒级的监控，那么所以我们监控的力度是一个比较细的，呃，就是也计费的方式，也更贴近于用户的使用啊，然后在。

在一段时间之后，如果用户不再使用这个数据库实例了，那么我们会将计算资源回收，那么这个时候实际上用户是，呃，这个时候实际上对用户不对计算资源进行计费，只对存储计费，那么这样也实现了我们一个无使用不计费的这样的一个特性。那么首先来介绍一下我们是怎么对这个数据库计算资源进行一个弹性的，那么这里有两种方案啊，其他方案也可能是一些友商的方案，就是说嗯，那个我阶梯级别的给你限制一些计算的资源，那么这种那么并且按照他的这个当前规格来计费，那么这样的话可能就是有两个弊端，第一个弊端就是说，呃，我比如说在第一时刻，可能说用户的负载不是很高，比较低嘛，然后可以就hold得住，但是到T2时刻，用户突然来了一个高负载，那么实际上这个时候你的资源，因为你给他限制了比较小的规格，实际上你不能立即的让用户使用到他所选定的一个最大的配格，因为我们可以选定一个最小最大的三体区间嘛，他不能及时的使用到这个资源，就是呃，资源必须要等到一定的时间以后，有一个延时才会去对他对这个计算节点发起一个扩容的任务啊，然后第二个弊端也是就基于第一个弊端的，那么就是说比如。

说因为它是一个阶梯，呃，就阶梯级的限制，那么我在谈了以后，比如说在T2后面一个时刻，我谈上去了以后，到T3时刻，呃，虽然说我是上升的一个阶梯，但是可能用户的负载还是很高啊，就是还是不满足他的需求，那么我又要等一段时间以后才能把资源谈到他的一个最大值，那么这样的话用户肯定是不能接受的，那比如说首先我是你是谈了，但是谈了以后我并就是还是不能满足我的需求，那么第二个方面来说的话，可能就是这个时候过了一段时间以后，用户的负载高负载可能已经没了，或者说用户的高负载已经把实力给打挂了，使得实际不可用了，那么这样的话，对，嗯，这样的话也就是会挑战这样S对数据库实现S这样的一种形态的挑战，那么我们TSO-cso在这里的话就没有多的那么小气啊呃，就是在用户选定最小最大战力规则的时候，就直接给他一个最大块的一个资源的使用，那么在用户来到高负载的时候，可以他可以。

立即的就是满载，或者说用到他所选定的这种最大规格啊，那么这样的话可以给用户提供呃，极致的弹性的一个性能啊，那么在这里除了就是说在one onetime就是运行时的一个弹性，那么在这里也给定一个规格弹性的这样一个能力，那么实际上来说就是可能还在用户在使用的就购入数据库之前会有这样的一个规划，可能说他觉得自己可能在未来一段时间内会在呃，一核2GB或者到八核16GB这样的一个区间去波动，那么它完全就可以选择这样的一个区间，那么购就购买了以后也会也可以随时的发起这个最大最小规格区间的一个变配的这样一个行为，那么。

啊，然后我们在这里对这个。资源进行弹性，实际上更多的还是对这个BP f pro进行一个弹性，那么BP的大小实际上在一定程度上面来说，它也是能，呃，代表用户的负载啊，包括以数据量的这样一个大小，呃，这样的一个度量啊。那么刚刚说到的我们是根据用户的使用的情况来计费，那么我们如何实现的这一点呢？就是在这里定义定义了一个叫c cuu的TD c computer unit的这样的一个计费单元，那么它的计算方式是CPU、1/2MEMORY和最小规格三者的最大值，那么我们可以看到右上角的那张图啊c cuu的变化的趋势实际上和CPU的变化以及内存的变化是这趋势是十分相近的，那么也这也从侧面证明了说我们的呃，CPU或者说是这种计量单位是可以满足就是说按照用户使用的需求来进行计费的这样一种方式。那么我们这个监控刚刚说了也是秒级监控，我们以五秒为一个五秒的频率来采样，那么这样的话，呃，采样的频率实际上是比较细的，那么这样的话也可以精准的对用户的使用情况进行一个度量，并且进行计费啊，那么最近我们也推出了一个叫资源包的这样的一种预付费的这样的一种模式。

实际上它也是就有点像我们手机流量套餐一样的这种东西，那么因为我们最近也在就是逐渐的推广service在数据库上面的的这样一种服务嘛，所以对用户的让利也是比较大的，那么根据我们团队的产品同学的一个核算，呃，大概是对一般用户可以节省50%~70%的成本，那么对极致情况下可以最多省90%的这样一个成本。

呃，那么接下来就说一下我们这个T刚C一个高可用的这样一个特性，那么就是通俗一点来说，就是说用户在访问数据库服务的时候，我希望可以随时随地就只要我来了服务你就呃，我来了请求，你就必须给我一个正确的响应。那么。刚但刚刚我们也说了，就是说在呃，在集算资源不使用，或者说用户有一段时间没有负载的时候，我们是会把集团资源给回收掉的，那么做到了无使用不计费嘛，那么但是这个时候用户如果来了恢复连接的话，那么因为数据库实力还没有起来，那不就会断掉请求，就可能要用用户重试嘛，那这种情况下我们是引入了一个资源的一个组件叫恢复感知器，那么它可以hold住就是用户的连接，并且与用户交换侵全信息，那么在恢复感知器确认了它是一个数据库的一个客户端以后，他会通知我们的管控侧去申请资源，然后包括把数据库实例就进程给拉起来，那么等数据库进程拉起来了以后，那么用户它恢复感知器在和数据库就其他之后内核进行一个建联，一个交互，那么在交换进连信息，最后如果就是健全成功的话，会把用户的连接直接就打到数据库上。那么。

那么在一段时间不使用以后，那么比如说用户这个这个T秒时，用户可以配的一个时间，比如说十分钟啊，用户不再使用了以后，那么我们的监控的组件会发现这个实例持续处于一个低负载的状态，那么就会通知管控系统去把这个数据库的就把内核所使用的这些资源给回收掉，那么这个时候监控服务只会就是会持续的监控存储的用量，然后只对存储的部分计费，对计算机部分不计费，也就是说计算部分实现了真正的使用不计费的这种特性，那么我们的这种连接方式，就说说这种或者说这种数据库的恢复方式的话，是不会断掉用户手连的，那么用户的第一个连接打过来的时候就可以直接连到数据库，那么数。

用户在使用的时候，就像就他的感觉，就是说我们数据库实力一直没有暂停过一样，那么一般来说，从用户的第一个连，就是用户发起连接请求到数据库给他，就用户收到正确的登，就是正确的登录响应，这段时间是不超过2000毫秒的，那么这个现在业界来说就是一个很快的一个成绩了。好，那么有人可能会质疑就是说啊，你这里会就第一首连恢复的时候，后面的连接是路都会通过恢复感知器去转发到数据库，实际这样会不会有一个性能的损耗呢？呃，那么在这里我们使用这个VPC或者说是VIP的这样一个定义路由，呃，就是自定义路由权重的一个特性，那么在实例恢复之后，VBC会直接指向实例，那么用户后续的这些连接都会直接打到数据库实例上，那么然后在暂停之后，那VBC会指向恢复感知器，那么去接受恢复的呃，用户的恢复连接以及通知管控侧去拉起实例。

那么在那么在内核层面我们也做了很多的一个优化，那么首先是一个BPB型的初始化，那么可以使得这个BP初始化的速度相较于原生买搜Q的数据库相比提升18倍。然后事事务系统的并行化，就是昂昂度线程的一个呃初始化也是一个并行的，那么在恢复的时候也会并行的向存储的各个block去获得最后的持久化的那个一致性位点，那么这样的话就是从计算到存储都进行了一个呃B型化的处理，使得我们这个呃节点拉起的速度会很快，以秒级为单位，那么在扩缩BP，尤其是缩呃缩拢BP的时候，我们也进行了一定的优化，那么相较于原生的每色数据库，它的可能在缩动的时候，那个如果来了新的查询，它的毛刺数量可能最多可以减少80%。这样。好，那么最后就是介绍一下我们这个就是即将上线的一个产品形态吧，就是说一个极致的横向弹性的这样一个形态，那么我们目前对外提供的service服务还是以一个单节点，就是讲读写节点的方式对外提供这个服务，那么在即将上线的这样一个形态中，我们实现了集群级别的services节点，那么就是说对于主节点，你可以是serviceless的节点，或者说是普通的不会暂停的节点，那么对于那些只读节点来说，你可以任意的增加它的数量，然后包括他在就在纵向上，也就是说他节点自己内部也有一个弹性的能力，那么这个弹性实际上是用户不需要自己提前去申请发货这样的一个需要有这样的一个过程的，就是说这个。

呃增加节点，减少节点，然后包括节点内部的资源弹性，完全是由我们这个呃调度器来去调度的，那么在进一步的，在进一步优化我们调度器的情况下，使得就是力争达到让呃资源调度更加精准的这样的一个目的。

那此外我们也提供了一个数据库，就在此基础上我们也提供了一个数据库代理的服务，那么这个服务实际上呢，GC-C这个数据库，就是说节点不暂停的这些数据库情况下，已经提供了，提供了一个读写分离以及负载均衡的这样一种企业级的数据库的能力。好，那么刚刚介绍了一下T康c service服务的一些特点，那么接下来来介绍一下它的一个应用的一个场景，那么首先就是说一个负载不确定的这样一个场景，那比如说就是说我发的就是。呃，用户的那个用户的高负载，或者说是一些可以预见的一些活动场景，或者说是定时的任务，那么这个高负载它是一个比较偶发的，就是有的是可以预见的，但有是不能预见的，那么用户在购入就如果是传统的云数据库或者云原生数据库的话，他可能要对他未来的一段时间的一个负载要进行一个预测嘛，那么这个时候就有一个成本和性能上的考量了，那么如果他购入的是一个大规格的实力，那么平常他根本用不到这么多的负载，那么实际上他会为这些用不到的负载就浪费的计算资源，而呃付费，那么如果选定的是一个小规格的实例的话，那么可能会出现一个就是在高负载来用的时候能力不足的一个情况，嗯，严重的情况可能会打挂节点，那么影响那个用户的业务，那么如果用上了我们杠C这个service的服务以后，可以选择一个可以用户可以定义一个弹性的区间嘛，就是可以在就是低负载的时候用一个很低的一个呃集算算力区间，呃集团的。

案例么，在高负载来的时候，可以谈到一个比较高的，就是一个比较高的规格，那么满足用满足这种负载不确定的场景下的一个使用的方式，那么第二个场景就是说一个归档数据库，或者说是和就是这是两种场景嘛，一个开发测试环境，那么对于归档数据库来说的话，它可能更看重的是一个存储的能力，他平常可能并不需要使用这个集团的资源，但是用户还是更希望，就是说如果我需要使用他的集算资源的话，就相对于对象存储来说，我更希望它还有一定的计算能力，以及包括它的一个分析的一个能力。那么对于开发测试环境来说的话，呃，一般来说，我们可能周一到周五就工作日的内上班可能要用一下数据库，那么在周六周日休息的时候，可能说这个就希望数据库可以暂停，那么使用con service的服务的话。

可以使用它的这个自动启停，无使用不计费的这样的一个能力，那那么在有连接来的时候，呃，把数据数据库实例拉起，并且进行计算，那么在。呃，在那个周六周日这种休息日的时候，就直接用它的自动暂停的功能，使得实例暂停，这样在这段时间内计算是不会计费的，那么这样的话也可以急着降低用户的成本。那么最后一个就是说一些微服务，他开发者的需求可能就是说无使用不计费，然后并且可以使用这个就是按照调用的次数计费，因为他们的调用次数也比较少嘛，可能就是说这样的话更贴近于他们这个对成本的这样的一个考量，那么这样的话其实也可以使用我们刚C呃service服务，因为我们也对外集成的一些data API，然后也根据这种方式，也根据调用的次数来计费的，这种方式我们其实有提供的，那么这样的话也可以满足用户的这样一些需求。

那么最后来介绍一下我们与微信云托管的一个合作，那么这可能小程序开发者和那个服务就是公众号的服务的提供者可能会比较熟悉这一点，那么他们就微信云托管官网上说的这个MYSQL的数据库服务，实际上就是由我们tdsq c service这个服务来提供的，呃。那么他一方面选择我们是因为我们可以提供一个独立的数据库实例的服务嘛，它的这个隔离性也是比较好的，并且在不使用的时候可以自动暂停，那么这样的话会使用户更愿意去使用我们的数据库，因为你不使用的时候实际上是不计费的，那么他们可能之前也考虑过使用一个大数据库，就是一个大数，就是大数据，大数据库实例对外多租库提供，就分库分表的形式呃来提供，最后也是放弃了这种方案，呃，因为可能就是刚刚所说的数据的隔离性不足，可能有安全性的问题，然后并且维护一个比较大的实例，实际上也是一个比较令人头疼的一个事情。

呃，那么另外我们也与CF就那个无服务器，呃，无服务器函数服务，然后包括lighthouse DB，然后包括物联网平台等等，呃，其他的一些部门一起做了，就是那个大做了一个一键部署多端上云的这样的一个服务，使得就是开发者可以呃。更容易的，或者说更轻易的就是来使用我们公司提供的这些云的一些服务，给用户，给用户极致的一个性能，一个体验。好，那最后来总结一下，我们总结一下今天所说的一些内容，那么首先我们就是TSOTSO和杠CSOS，一直其实对外宣传的可能是一个低成本啊，就是说不使用不计费，然后按照用户的使用量来计费的这样一个特性，然后包括可以迭代试错，因为有GBG每秒的回档的这样一个速度，然后包括极大的能降低运维的成本的这样的一个角度，就是说可能是对于中小企业用户，或者说就是个人开发者是更加的友好的，但是其实我们TSO，杠cso数据库是基于TSO-C的嘛，这个数据库实际上是企业级数据库，是具具有面向大型业务的能力的，比如说我们有呃机制的弹性，就是说可以秒级的增加减少计算节点，以及那个计算以及存储资源的。

的极致的迟化，然后包括我们也提供了数据库代理规则审计，然后基于每秒的备份，以及跨可用区容灾的这样一系列企业级特性，其实我们就是不仅适合，就是这款产品不仅适合中小型企业用户使用，也适合也可以面向大型企业的大型的业务，呃，比如说我们公司内部业务的一些金融服务，然后包括刚刚所说的微信云托管，是分别代表了大小两个类型的业务，我们都是有支持的。

那么我们的愿景实际上是想做一个优秀的资源管理者，那么建就像建一个水坝一样，那个管理好上游的水资源，精可以精细的灌溉下游的企业，那么我们在这个之后的一段时间内可能会做如下的这几件事情，首先就是做一个AI加DB这个领域的一个探索，那么实现这个参数智能调优，然后包括搜Q分析，然后包括。然后包括这个刚刚说的斯这个弹性，一个提前的一个调度，那么不依赖事后的弹性，然后使得用户的体验可能会更好，然后第二点的话，主要还是想再进一步的压缩使用成本，那么对于存储可能想直接下到cos这种冷杯上面去，真正的做到一种无使用不计费，然后最后可能就是说要在那个提升性能，一个是优化能启动时间，因为刚刚说的两秒，其实我们还是可能有一些优化空间的，然后另一步，另一点就是说和内核同学一起持续的做一些优化，然后包括我们管控流程上做优化，使得就是对力争为用户提供更及时的数据库服务，好，那么我今天介绍就到这里，谢谢大家。