【腾讯云TDSQL-C Serverless 产品测评】一文带你了解TDSQL-C Serverless版

前言

  这几年，Serverless数据库大火，被业内称为数据库的下一代变革性技术，是云原生数据库发展的必然结果。作为早在2020年就于国内率先推出Serverless数据库的腾讯云，近年来不断在Serverless数据库领域深耕探索，今年更是推出预付费资源类型资源包，Serverless集群挂载只读实例等一系列更新，为用户的降本增效以及国内云原生技术普惠提供了一份自己的答卷。

  本文将基于腾讯云TDSQL-C for MySQL Serverless版，带领大家一起，对其核心特性进行一个简单的评测。为大家在传统数据库与Serverless数据库之间的选型提供一个简单的参考。

---

腾讯云TDSQL-C for MySQL Serverless版介绍

  TDSQL-C MySQL 版（TDSQL-C for MySQL）是腾讯云自研的新一代云原生关系型数据库。融合了传统数据库、云计算与新硬件技术的优势，为用户提供具备高弹性、高性能、海量存储、安全可靠的数据库服务。Serverless 服务是TDSQL-C MySQL 版的无服务器架构版，是全 Serverless 架构的云原生数据库，其架构设计如下图：

  Serverless 服务基于计算与存储分离的理念，满足了客户在公有云计算环境下根据业务发展弹性扩展集群的刚性需求，让用户不再纠结实例资源问题，让用户像使用自来水一样使用数据库。支持按实际计算资源和存储资源使用量收取费用，不用不付费，将腾讯云云原生技术普惠用户。总结其特性，可分为以下三项：

• 自动启停(实用实付)：Serverless 服务支持自定义实例自动暂停时间，无连接时实例会自动暂停。当有任务连接接入时，实例会秒级无间断自动唤醒。集群按秒计量，按小时结算，如果没有访问，不收费，帮助业务极大程度地节省成本；
• 自动扩缩容(弹性策略)： Serverless 集群会持续监控用户的 CPU、内存等 workload 负载情况，根据一定的规则触发自动扩缩容策略。用户不需要过度关注规格，访问量上来时自动扩容，降低时自动缩容，且实现扩缩容的过程中做到业务无感知；
• 资源扩缩范围（CCU）：可调整 CCU 弹性扩缩容的范围。Serverless 集群会在该范围内根据实际业务压力自动增加或减少 CCU；

---

准备工作

1、 购买TDSQL-C for MySQL Serverless版实例

  打开并登录 TDSQL-C for MySQL购买页，完成数据库配置和基础信息设置。本文所使用的数据库配置如下图：

数据库配置参数说明(粗体项为需要重点关注的参数)：

• 实例形态：本文选择Serverless
• 数据库引擎：本文选择 MySQL
• 地域：不同地域可选的算力配置可能略有不同。像北京地区，算力配置最高只能选到16-32CCU，而广州地区则可选到32-64CCU。这里根据业务部署区域和业务所需配置进行选择即可。
• 主可用区：选择部署可用区，这个随意。
• 多可用区部署：Serverless版暂不支持多可用区部署，如果业务对多可用区有刚性需求，只能选择TDSQL-C的其他版本。
• 传输链路 ：默认高 IO 版，无其他配置。
• 网络：出于性能安全考虑，目前仅支持私有网络（VPC），云服务器需要与 TDSQL-C 在同一VPC下方可通信（保障同一个地域，不限可用区）。
• 数据库版本：本文选择MySQL 5.7，需要注意的是，TDSQL-C MySQL 版仅支持 Innodb 引擎。
• 算力配置：选择算力配置 CCU的上下限，实例会根据选择的资源范围自动进行弹性扩缩容。
  • CCU（TDSQL-C Compute Unit）为 Serverless 的计算计费单位，一个 CCU 近似等于1个 CPU 和 2GB 内存的计算资源
  • 每个计费周期的 CCU 使用数量为：数据库所使用的 CPU 核数 与 内存大小的1/2 二者中取最大值
  • 支持对读写实例和只读实例单独配置算力
• 自动暂停 ：配置实例自动暂停时间，在设定时间内无连接访问数据库会自动暂停实例，实例暂停后CCU将不再计费，存储仍然按实际使用量计费。
• 计费模式： 支持选择按量计费或资源包。如果是生产环境，建议使用资源包付费，优点是相比于按量付费模式更为划算，使用更为灵活。

数据库配置完成后，还需要进行基础信息配置，为了节省篇幅，本文暂时不做过多的描述，大家根据自己的实际情况进行配置即可。

2、开启数据库外网访问

  数据库购买成功后，默认只能通过内网访问，为了方便测试，我们需要先开启数据库的外网访问能力。开启后，我们就可以在外网通过系统分配的域名和端口访问数据库。需要注意的是外网访问建议仅用于开发或辅助管理数据库，业务访问请使用内网访问。

3、安装测试工具

  本文部分的测试场景基于Sysbench完成。Sysbench 是一个跨平台且支持多线程的模块化基准测试工具，用于评估系统在运行高负载的数据库时相关核心参数的性能表现。可绕过复杂的数据库基准设置，甚至在没有安装数据库的前提下，快速了解数据库系统的性能。CentOS系统下Sysbench安装命令如下：

curl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.rpm.sh | sudo bash
yum -y install sysbench

# 检查是否安装成功
sysbench --version

4、准备测试数据

  通过数据库管理工具在数据库中创建test库用于测试，使用Sysbench快速生成测试数据。测试数据规模：10张表，每张表10000条数据。

# 为了方便测试，这里将常用参数设置为系统临时环境变量。
export TDSQL_HOST="外网访问地址"
export TDSQL_PORT="外网访问端口"
export TDSQL_USER="用户名"
export TDSQL_PWD="密码"

# 开启10个线程，在test库创建10张表，每张表插入10000条数据
sysbench --db-driver=mysql --mysql-host=$TDSQL_HOST --mysql-port=$TDSQL_PORT \
--mysql-user=$TDSQL_USER --mysql-password=$TDSQL_PWD \
--mysql-db=test --table_size=10000 --tables=10 --threads=10 \
--db-ps-mode=disable oltp_read_write prepare

命令运行截图：

  到这里，我们就做完了所有准备工作，接下来，我们将通过几个场景测试，对TDSQL-C for MySQL Serverless版的核心特性进行一个深入的测评。

---

Serverless集群核心特性一：自动启停

1、自动启停简介

  TDSQL-C Serverless版的自动暂停功能由集群配置中的自动暂停项控制，开启自动暂停后，数据库在设定时间内没有连接和 CPU 使用时，将自动暂停实例，实例暂停后CCU也将暂停计费，存储仍然按实际使用量计费。

  TDSQL-C Serverless版的自动启动功能无需配置，在实例暂停的状态下，如果有数据库连接发起，系统会秒级自动启动处于暂停状态的数据库，用户不需设置重连机制。整体流程设计如下图：

由该设计图我们可以得知：暂停状态下的第一个数据库连接通过一个perceptron模块与数据库连接，该模块有两个功能，一是通过管控服务秒级恢复实例，二是当实例恢复后继续充当转发器的功能，使数据库连接不断连。集群启动后其余新增连接将自动直连到 TDSQL-C。

  官方文档中对于自动启动的耗时描述都是秒级，那么这个秒级到底是需要多久呢？毕竟1秒完成启动和5秒完成启动都可称为秒级恢复，但两者对业务的影响却相去甚远。接下来我们通过一个简单的测试，来探索下它的具体耗时。

2、测试实例自动启动耗时

  Linux系统自带的time命令可用于测量一个命令的运行时间，我们使用该命令分别测试实例在启动状态下和暂停状态下，连接数据库并查询数据库版本所需的时间。测试命令如下：

time mysql -h$TDSQL_HOST -P$TDSQL_PORT -u$TDSQL_USER -p$TDSQL_PWD -e "select version();"

• 第一步：在集群启动状态下，执行测试命令，观察命令执行时间并记录。

  

• 第二步：通过数据库控制台将实例手动暂停

  

  

• 第三步：执行测试命令，观察实例暂停状态下，命令执行时间并记录

  

• 第四步：计算实例启动时间：暂停状态下命令执行时间-启动状态下命令执行时间=实例启动时间。

  图片中本次启动耗时约为1.4S

通过重复以上步骤进行多轮测试，最终得出实例启动的平均时间在1.5S左右，最高的一次启动时间达到了1.8S左右。

注意：受测试方法、网络环境、客户端性能等因素影响，以上结论数值仅为个人测试结果分享，并不代表产品的实际性能数值。

3、自动启停应用场景

  自动启停功能带给用户最大的收益就是降低业务成本！用户不必再为闲置资源付出成本。举个典型的例子，大部分的ToB业务场景下，业务量基本全部来自工作日的白天，而工作日的晚上以及非工作日的业务量极小，此时自动启停功能就可为用户极大的节省数据库资源成本。

  软件工程中没有银弹，自动启停功能带来成本节省的同时，也带来了首次连接延时较高的困扰，但这个困扰在某些对响应延迟要求不太高的场景，或者业务量相对规律可以提前预判预热的场景下，也就显得微不足道了。

---

Serverless集群核心特性二：自动扩缩容

1、自动扩缩容简介

  Serverless 服务的弹性策略是利用监控计算层实现的。通过监控业务负载情况，系统对计算资源进行自动扩缩容，并对该时刻所消耗的资源进行计费。当没有数据库请求时，监控服务会触发计算资源的回收，并通知接入层。当用户再次访问时，接入层则会唤醒集群，再次提供访问。

  Serverless 服务的弹性策略一开始会根据用户购买时选择的容量范围，将 CPU、内存资源限制到最大规格，极大程度降低因 CPU 和内存扩容带来的时间影响和使用限制。当集群触发到自动弹性的负载阈值后，Buffer pool 会根据监控提前进行分钟级调整。在这个方案下用户使用数据库可以无感知进行 CPU 扩容，并且不会因为连接突增导致实例 OOM。

  建议在第一次设置弹性范围时，最小容量配置为0.25 CCU，最大容量选择较高的值。较小的容量设置可以让集群在完全空闲时最大限度地进行缩减，避免产生额外的费用，较大的容量可以在您的集群负载过大时最大限度地进行扩展，稳定度过业务峰值。

2、自动扩缩容测试

  官方文档中对自动扩缩容的描述是：无感知扩缩容。接下来我们通过一个简单的测试场景对其进行一个简单的测试。本次测试我们将通过两台服务器先后执行Sysbench压测命令，模拟业务系统对数据库访问。压测期间通过腾讯云控制台的监控页面看看不同负载下，数据库CPU、内存、CCU的使用情况。本次测试所使用的测试命令如下：

# 开启500个连接对数据库进行压测，持续时间300S
sysbench --db-driver=mysql --mysql-host=$TDSQL_HOST --mysql-port=$TDSQL_PORT \
--mysql-user=$TDSQL_USER --mysql-password=$TDSQL_PWD \
--mysql-db=test --table_size=10000 --tables=10 --threads=500 \
--events=0 --time=300 --percentile=95 --report-interval=1 \
--db-ps-mode=disable oltp_read_write run

• 第一步：在A机器执行压测命令，模拟500个连接对数据库访问

  

• 第二步：在A机器压测开始120S后，在B机器执行压测命令，模拟1000个连接对数据库访问

  

• 第三步：等待两台机器压测结束后，分别查看两台机器的压测报告，并通过控制台的监控页面查看数据库负载情况

  • A机器压测报告

    

  • B机器压测报告

    

  • CPU使用率

    

  • 内存使用率

    

  • CCU使用率

    

  注意：使用Sysbench压测仅为了方便模拟数据库访问，真实的数据库压测还要考虑机器的带宽、性能、压测场景等多种因素，因此以上TPS、QPS数据不代表TDSQL-C Serverless版真实性能数据。对压测报告感兴趣的同学可以查阅官方文档：TDSQL-C MySQL 版性能白皮书

  通过以上测试我们可以看到，当我们阶梯性的增加对数据库的访问时，数据库的CPU、内存、CCU等负载情况呈现出与我们访问量一致的阶梯性，通过两台机器的压测报告我们也可以发现，在数据库进行自动扩容时，数据库的TPS、QPS等指标也未出现明显的波动。

3、自动扩缩容应用场景

  得益于自动扩缩容过程中业务的无感知，自动扩缩容功能简直是全场景通吃，真正的将“降本”做到了极致。无论你是ToC场景还是ToB场景，无论你是IoT还是边缘计算业务，无论你的业务量是否可预测，自动扩缩容都能完美的Cover住你的场景，唯一的差别可能就是不同场景下成本降低的多与少。

---

总结

  一番体验下来，TDSQL-C Serverless版给我最大的感受就是四个字：“降本增效”。这四个字不仅仅体现在数据库资源成本的降低上，还体现在对人员成本的节省上。使用TDSQL-C Serverless版几乎没有运维管理工作。没有服务器升级、操作系统维护、数据库扩容、数据库优化的烦恼。这使得技术人员能够将更多的时间投入到战略性工作，如业务逻辑、性能优化、数据建模等方面。结合以上内容，个人总结了一些TDSQL-C Serverless版的典型应用场景供大家参考：

• 开发、测试环境等低频数据库使用场景
• 中小企业建站服务等SaaS应用场景
• 个人开发者用户
• 学校教学、学生实验等教育场景
• 物联网（IoT）、边缘计算等不确定负载场景
• 全托管或希望完全免运维的用户
• 业务有波动或不可预测的用户
• 具有间歇性定时任务的业务场景

最后，希望本文能够为大家在数据库选型及TDSQL-C Serverless版的使用上提供一些有效的帮助。