不久前，腾讯云宣布将云数据库TDSQL-C Serverless架构升级，推出了Serverless 2.0。和上一版本相比，Serverless 2.0提供了更好的弹性扩缩容能力，可以更好地满足关键核心业务对数据库服务的要求。稍早些，另一个数据库厂商PingCAP宣布TiDB Serverless版正式GA。华为Gauss、阿里云PolarDB很早也都有对应的Serverless版本。而AWS更是早在2018年就发布Aurora 的第一个Serverless版本，2021年升级到Aurora Serverless 2.0。

应该说，目前，绝大多数云数据库都有了Serverless版本。而且，不止是关系数据库，NoSQL数据库也不甘落后，比如MongoDB的云版本Atlas也支持Serverless。随着越来越多的Serverless数据库问世，用户在数据库服务的选型时也有了更多选择，在传统托管数据库、RDS、云原生数据库之外也可以选择Serverless数据库。而问题也由此而生，何时该选Serverless数据库，它适合哪些应用场景？

自动伸缩，按使用付费

随着云计算的日益普及，数据库上云已经成为必然趋势。回看数据库上云的过程，大体可以分为三个阶段：

第一个阶段的特征是云托管。早期上云最直接的方式是购买服务器实例，然后自己部署操作系统、数据库和应用程序。此时，管理和运维和在自己的数据中心一样，唯一的区别是服务器是虚机。后来，云服务商推出了各种开源的RDS服务，用户不需要自己来部署数据库。但本质上和以前一样，都只是将数据库搬到云上，并没有发挥出云计算的优势。这个阶段称为云数据库1.0时代。

第二个阶段的特征是云原生数据库。随着云计算的普及，数据库开始享受云计算的红利。2014年，AWS率先推出了云原生数据库Aurora，随后其他云服务商纷纷跟进，2017年阿里云推出了PolarDB，后来腾讯云也推出了TDSQL-C等。和RDS相比，云原生数据库最大的特点是利用了云计算资源池化的特点，实现了存算分离，在性能、可扩展性和部署的灵活性上都有了很大的改进，被称为云数据库2.0时代。

第三个阶段的特征是Serverless数据库。相比RDS，云原生数据库无疑是一个进步，但它在成本上和运维上仍然有很大提升的空间，这正是Serverless数据库的价值所在。相比云原生数据库，Serverless数据库能提供更优的成本和更简化的运维，被称为云数据库3.0时代。

归结起来，Serverless数据库主要有以下特点：

首先是资源的解耦和池化。Serverless数据库基于云原生数据库实现，享受了云原生数据库存储和计算分离的特性，这也使得计算变得无状态化，更容易调度和扩缩容，存储和计算也得以分开计费。

为了实现资源的池化，各厂商有着不同的技术手段。比如，阿里云PolarDB Serverless在存算分离的基础上还做到了CPU、内存和存储三级分离和池化。由于CPU和内存之间不再强绑定，从而提高了资源调度的灵活性，进一步降低了成本。而腾讯云 TDSQL-C推出了可释放存储架构的Serverless服务，当实例暂停后，数据会进行归档存储，用户无需再为存储进行付费，可在原实例暂停后的存储费用上降低成本80%。

其次是自动弹性伸缩，简化运维。采用Serverless数据库后，用户不再需要为应用程序配置资源的大小，比如使用几台机器、多大带宽、多大存储空间等。用户只需要提供几行代码，剩下的都交由Serverless服务提供商处理，完全无需再考虑数据库的运维。

值得一提的是，自动扩缩容也是Serverless数据库的关键特性，而如何快速地实现冷启动，以快速拉起实例、恢复服务也是各大厂商的主要发力点，方法也各有不同：有的Serverless数据库会预先拉起部分实例，来应对冷启动，或者有的是设置阈值，超过阈值一段时间再拉起，有的则通过AI来预判和提前拉起。比如，TDSQL-C借助AI和各种监控手段做到了缩容场景无慢查询，实现了真正意义上的弹性扩缩容。而且TDSQL-C不仅可以横向伸缩（加节点），也可以纵向弹（加CPU），在缩容时不中断连接。

第三，按使用量计费。Serverless是按照服务的使用量（调用次数、时长等）计费，而不是像传统的云服务那样，按照使用的资源（ECS 实例、虚机的规格等）计费。

Serverless数据库不是万能药

看起来，Serverless数据库非常有诱惑力：用户无需关心数据库配置，既不用考虑数据库的容量，也不用担心计算性能，只需大致了解工作负载模式和事务量即可估算成本，能极大地降低数据库系统TCO。这是不是意味着我们的应用程序都可以选择Serverless数据库?

显然不是，Serverless数据库并非万能药。Serverless数据库有适用的场景，也有不适用的场景。只有在合适的场景下，Serverlesss才会体现出成本节约和高弹性的优势，否则就会事与愿违，反而多花钱。

一般而言，Serverless数据库非常适合临时的、不可预测的工作负载，例如假日或者周末的促销活动（“618”、“双十一”以及各种临时的市场活动）等，以及短时定期的任务（每天统计和清理，每月的统计和分析）和低频任务（微信小程序、博客）等。对于没有专业的数据库运维人员或者还不太了解其应用程序使用模式的开发团队以及测试环境也适用，对于那些非常看重可用性和性能，而不是非常关注成本的应用，也是一个不错的选择。

需要特别注意的一点是，Serverless数据库最大卖点是成本优势，但这是建立在正确使用前提之上，也就是你需要了解应用程序的行为、了解用户如何与之交互，并随时进行调整，有时随着应用负载的增加，成本会迅速上升。

当然，有些场景是明显不适合Serverless数据库的。与其他方式（比如RDS、云原生数据库）相比，用户将更多的数据库控制权交给了提供商。对用户而言，Serverless服务就像一个黑盒子。因此，对于那些非常重视管控能力或者高度监管的行业Serverless数据库就不适用，如果有定制需求的Serverless一般也无法满足。

总体而言，尽管Serverless数据库非常热，但目前还处于初级阶段，仍然有不少挑战。比如如何提高利用率以及尽可能降低扩缩容对用户的影响就考验云服务商。虽然用户可能无需关注资源的使用成本，但云服务商必须去考虑，它们要确保后台的数据库系统针对客户的工作负载进行了最佳调整，并且在资源利用上符合他们的最大利益。还有冷启动的问题也是Serverless数据库厂商共同面对的难题。

总之，和很多技术一样，Serverless数据库有自己的最佳使用场景，说到底，只是应用开发团队在开发应用的一个数据库服务的选择之一。