一、前言
数据库作为公司软件业务应用中最重要的基础软件之一，在整个IT生态体系中具有举足轻重的作用，随着业务数据量的增大和算力的限制，单台MySQL实例越来越满足不了需求，腾讯云 TDSQL-C Serverless是腾讯云自研的云原生关系型数据库 TDSQL-C MySQL版的无服务器架构版。按实际计算和存储资源使用量收取费用，不用不付费，非常适合中小型企业。
腾讯云TDSQL-C联合CSDN推出了一款强大的数据库产品测评活动火热进行中，让我们来体验一下这个国产强大的数据库。
二、为什么有TDSQL-C Serverless版本？
TDSQL-C是腾讯云自研企业级分布式数据库，旗下涵盖金融级分布式、云原生、分析型等多引擎融合的完整数据库产品体系，提供业界领先的金融级高可用、计算存储分离、数据仓库、企业级安全等能力，同时具备智能运维平台、Serverless版本等完善的产品服务体系。
- 提供的高可靠、高可用、可弹性伸缩的云数据库服务产品的总称。
- 在公有云和专有云领域提供全行业数据库解决方案，可轻松运维主流开源及商业数据库。
- 广泛覆盖游戏、电商、移动互联网、云开发等泛互联网业务场景，可以助力新零售、教育、SaaS、广告等行业数字化升级
1. 产品系列：
我们这次选择的是MySQL版本，感兴趣的同学可以自行测试PostgreSQL。
2. 解决问题：
2.1 单机数据库瓶颈
- 面对互联网类业务百万级以上的用户量，单机数据库由于硬件和软件的限制，数据库在数据存储容量、访问容量、容灾等方面都会随着业务的增长而到达瓶颈。
- TDSQL MySQL版 目前单分片最大可支持6TB存储，如果性能或容量不足以支撑业务发展时，在控制台自动升级扩容。
- 升级过程中，您无需关心分布式系统内的数据迁移，均衡和路由切换。升级完成后访问 IP 不变，仅在自动切换时存在秒级闪断，您仅需确保有重连机制即可。
2.2 应用层分片开发工作量大
- 应用层分片将业务逻辑和数据库逻辑高度耦合，给当前业务快速迭代带来极大的开发工作量。
- 基于 TDSQL MySQL版 透明自动拆分的方案，开发者只需要在第一次接入时修改代码，后续迭代无需过多关注数据库逻辑，可以极大减少开发工作量。
2.3 MySQL版的无服务器架构版
- Serverless 服务是腾讯云自研的云原生关系型数据库 TDSQL-C MySQL版的无服务器架构版。按实际计算和存储资源使用量收取费用，不用不付费。
- 极致弹性能力，计算存储分离，根据业务负载自动扩缩容实例，开发者无需关心底层资源问题，秒级弹性能力全面提升运维效率
- 超高性能能力，支持自定义自动暂停时间，在业务不间断情况下实现秒级冷启动。基于云原生数据库底座，提供超高性能，保证关键业务的连续性
- 丰富拓展性及计费能力，按照实际使用量进行收费，不使用不付费，提供多种灵活计费方式供用户选择
3. 其它的解决方案：
选择开源或 NoSQL 产品也能够解决数据库瓶颈，这些产品免费或者费用相对较低，但可能有如下问题：
- 产品 bug 修复取决于社区进度，社区是否活跃，解决方案是否成熟，产品是否大量实际应用。
- 团队的成本加深，需要有能持续维护该产品的人，且不会因为人事变动而影响项目。
- 关联系统的改造，涉及到的逻辑需要重新对接与开发。
- 增加运维的成本，开源产品的资源管控和生命周期管理、分布式逻辑、高可用部署和切换、容灾备份、自助运维、疑难排查等都需要密切关注。
4. 应用场景：
- 大型应用（超高并发实时交易场景）
- 物联网数据（PB 级数据存储访问场景）
- 文件索引（万亿行数据毫秒级存取）
- 高性价比商业数据库解决方案
三、TDSQL-C MySQL 版提供 Serverless服务特性：
TDSQL-C MySQL 版提供 Serverless 服务以满足企业对特定业务场景的数据库服务要求，助力企业降本增效。
对于应用开发者来讲，由于引入分布式架构，最大的痛点就是数据库特性的限制，如不支持函数、存储过程等，再一个痛点是在表设计时，也需要考虑数据分布的问题。对于运维人员来说，也是需要方便的去管理集群，局部变更需要考虑整体的影响。
1. 资源扩缩范围（***U）：
- 可调整 ***U 弹性扩缩容的范围。
- Serverless 集群会在该范围内根据实际业务压力自动增加或减少 ***U。
2. 弹性策略：
- Serverless 集群会持续监控用户的 CPU、内存等 workload 负载情况，根据一定的规则触发自动扩缩容策略。
3. 自动启停：
- Serverless 服务支持自定义实例自动暂停时间，无连接时实例会自动暂停。
- 当有任务连接接入时，实例会秒级无间断自动唤醒。
四、资源扩缩范围（***U）+ 弹性策略实现“弹性收费”：
1. 计费逻辑：
***U（TDSQL-C ***pute Unit）为 Serverless 的计算计费单位：
- 一个 ***U 近似等于1个 CPU 和 2GB 内存的计算资源。
- 每个计费周期的 ***U 使用数量为：数据库所使用的 CPU 核数 与 内存大小的1/2 二者中取最大值。
因为Serverless 集群会持续监控用户的 CPU、内存等 workload 负载情况，根据一定的规则触发自动扩缩容策略。
在实际业务开发中，设置弹性范围时，最小容量可以配置为0.25 ***U，最大容量选择较高的值32、64。当然，可以根据自身的实际业务去评估一个大概的值。这样做的好处是：
- 较小的容量设置可以让数据库集群在完全空闲时最大限度地进行缩减，避免产生额外的费用。
- 较大的容量可以在数据库集群负载过大时最大限度地进行扩展，稳定度过业务峰值。
如果您的业务场景需要快速扩展到非常高的容量，请考虑将最小容量设置为稍大一些的值。
2. 测试TDSQL-C MySQL 版提供 Serverless 服务自动扩缩容策略：
基准测试，比较直接简单、易于比较，用于评估服务器的处理能力，可以不关心核心业务。
3. TP***基准测试：
TP***是由TPC推出的一套基准测试程序，一些硬件厂商会以TP***作为对比标准之一，专用于MySQL基准测试（事务处理能力、ACID验证）。
TP***-MySQL模拟了一套电商环境，用于下单、支付、查订单、发货、查库存，模拟各个环节，获取数据，评估当前的环境的吞吐量。
4. 测试机器说明：
准备了2台机器，一台是公司的测试服务器1核2G，一台是开通的2核8G的云服务器，模拟一个流量突增的场景：
- 1核2G服务器用来模拟平时的业务流量。
- 2核8G服务器用来模拟业务量突增的场景。
5. TP***-MySQL安装：
# 下载源码包
wget http://imysql.***/wp-content/uploads/2014/09/tp***-mysql-src.tgz
# 解压源码包
tar -zxf tp***-mysql-src.tgz
cd tp***-mysql/src
# 编译
make
安装过程中，出现以下错误，如果未出现，可以略过。
通过错误提示查找，说是缺少libmysqlclient-dev，在Centos中安装mysql-devel包。
sudo yum install -y mysql-devel
查看TP***-MySQL目录下的文件，会发现有一些自带的sql文件，包括建表语句、索引文件。
导入测试数据表、相关索引。
# 创建数据库
mysql -h gz-cynosdbmysql-grp-7xkd8vs6.sql.tencentcdb.*** -P 27386 -u root -p -e 'drop database if exists tp***_test;create database tp***_test;show databases;'
# 导入测试数据表
mysql -h gz-cynosdbmysql-grp-7xkd8vs6.sql.tencentcdb.*** -P 27386 -u root -p tp***_test < create_table.sql
# 导入相关索引
mysql -h gz-cynosdbmysql-grp-7xkd8vs6.sql.tencentcdb.*** -P 27386 -u root -p tp***_test < add_fkey_idx.sql
表名说 明：customer-客户表、district-地区表、history历史订单表、item商品条目表、new_orders新订单表、order_line订单状态表、orders下单表、stock库存表、warehouse仓库表。
测试创建10个warehouse，进行填充测试使用的数据。
./tp***_load gz-cynosdbmysql-grp-7xkd8vs6.sql.tencentcdb.***:27386 tp***_test root Testdb11. 10
遇到问题，server参数太长了。
没办法，只能使用比较笨的办法，搭建一个临时数据库，填充完测试数据后，使用mysqldump导出数据，再通过source导入到TDSQL-C测试MySQL数据库中。
如下为对应的表结构与数据。
压测使用tp***_start命令，执行压测，对10个数据仓库，预热200秒，200个并发连接，运行600秒，结果存放在文件tp***.log中。
./tp***_start -h gz-cynosdbmysql-grp-7xkd8vs6.sql.tencentcdb.*** -P27386 -dtp***_test -u root -p Testdb11. -w 10 -c 200 -r 200 -l 600 -i 10 ./tp***.log
这里主要几个参数含义如下：
-h：主机名称
-P：端口号
-d： 数据库名
-u： 用户名
-p： 密码
-w：仓库数量
-c： 并发线程数
-r： 预热时间，以秒为单位，默认10秒，主要目的是为了将数据加载到内存
-l： 运行时间，以秒为单位，默认20秒
-i： 输出时间间隔
6. 压测结果说明：
以下为第一台机器的压测结果，可以看到各项指标也符合要求。
- 成功(su***ess,简写sc)次数
- 延迟(late,简写lt)次数
- 重试(retry,简写rt)次数
- 失败(failure,简写fl)次数
在第一台机器运行差不多100s左右时，第二台机器模拟业务量突增的情况，以下是各项指标也符合要求，而且压测的各项指标结果都强于第一台机器。
在并行压测的同时，也会出现一些“Lock wait timeout exceeded; try restarting transaction”，可能的原因：意外处理没有关闭连接，导致连接过多、或是要更新的表的锁在其它线程手里、系统异常导致事务未提交，再次请求相同记录等。
总结：
TPC-C是业界常用的一套Benchmark，用于评测数据库的联机交易处理（偏向OLTP能力）。主要涉及10张表，包含了NewOrder（新订单的生成）、Payment（订单付款）、OrderStatus（最近订单查询）、Delivery（配送）和StockLevel（库存缺货状态分析）等五类业务事务模型。
TPC-C使用TpmC值（Transactions per Minute）来衡量系统最大有效吞吐量，每分钟事务数，该值越大越好。可以看到第一台机器的TpmC是498.600，第二台机器的TpmC是864.900，是第一台机器的1.7倍。
7. TDSQL-C MySQL 版提供 Serverless 服务监控分析：
以下是2台机器分别压测的历史趋势图，CPU在最高是6.13%。
以下为TDSQL-C MySQL Serverless 服务的弹性策略，在一开始会根据用户购买时选择的容量范围，将 CPU、内存资源限制到最大规格，极大程度降低因 CPU 和内存扩容带来的时间影响和使用限制。
当第一台机器压测后，第二台机器并发压测，集群触发到自动弹性的负载阈值后，Buffer pool 会根据监控提前进行分钟级调整。
在这个方案下用户使用数据库可以无感知进行 CPU 扩容，并且不会因为连接突增导致实例 OOM。
以下是从01：00 - 03：00这个时间段的产生的账单费用，里面会包含公式里面讲到的2种费用，一种是***U算力的费用，一个是存储空间的费用。
在01：09左右时间段，因为生成了10个仓库的压测数据，这时候，存储空间容量会产生一笔消费的数据。
在02：33左右时间段，由于有2台机器进行压测，导致有CPU、内存的消耗，使用到了***U的算力，导致产生了***U算力相关的费用。
## 8. 存储资源包：
资源包是 TDSQL-C MySQL 版推出的预付费资源类型，分为计算资源包和存储资源包，可用于抵扣 Serverless 版集群产生的计算资源和存储资源。通过资源包，可以提前预留资源，而且，相对于按量付费方式，资源包可以帮助您节省更多成本，资源包的购买容量越大，有效期越长，越划算。
为了进一步降低用户的存储成本，可以购买存储包，甚至将数据转存到对象存储COS，用户只需要付COS的费用即可。
存储资源包是 TDSQL-C MySQL 版推出的预付费资源类型，可用于抵扣 Serverless 版集群使用的存储资源。
五、自动启停实现“弹性收费”：
Serverless 服务支持自定义实例自动暂停时间，无连接时实例会自动暂停。当有任务连接接入时，实例会秒级无间断自动唤醒。
1. 上述压测失败，报错：
在第一次压测时，TP***-MySQL压测失败，显示连接MySQL服务器失败。
查看原因是因为10分钟没有操作，导致TDSQL-C MySQL Serverless自动就停止服务了。
- 在开启状态下，根据系统设定的自动暂停时间10分钟。数据库在该时间内没有连接和 CPU 使用时，将自动暂停，暂停后计算不计费，存储仍然按实际使用量计费。
- 在关闭状态下，数据库会保持持续运行，在没有连接和 CPU 使用时，按用户配置的最小 ***U 算力进行计费，适用于业务有心跳连接的应用场景。
另外，在控制台上也可以操作数据库实例进行手动暂停操作。
2. 实际测试：
六、TDSQL-C MySQL Serverless原理分析：
TDSQL-C MySQL 版提供 Serverless 服务以满足企业对特定业务场景的数据库服务要求，通过下面几个特性，助力企业降本增效。
Serverless 服务的弹性策略是利用监控计算层实现的。通过监控业务负载情况，系统对计算资源进行自动扩缩容，并对该时刻所消耗的资源进行计费。当没有数据库请求时，监控服务会触发计算资源的回收，并通知接入层。当用户再次访问时，接入层则会唤醒集群，再次提供访问。
Serverless 服务的弹性策略一开始会根据用户购买时选择的容量范围，将 CPU、内存资源限制到最大规格，极大程度降低因 CPU 和内存扩容带来的时间影响和使用限制。当集群触发到自动弹性的负载阈值后，Buffer pool 会根据监控提前进行分钟级调整。在这个方案下用户使用数据库可以无感知进行 CPU 扩容，并且不会因为连接突增导致实例 OOM。
建议在第一次设置弹性范围时，最小容量配置为0.25 ***U，最大容量选择较高的值。较小的容量设置可以让集群在完全空闲时最大限度地进行缩减，避免产生额外的费用，较大的容量可以在集群负载过大时最大限度地进行扩展，稳定度过业务峰值。
***U（TDSQL-C ***pute Unit）为 Serverless 的计算计费单位，一个 ***U 近似等于1个 CPU 和 2GB 内存的计算资源，每个计费周期的 ***U 使用数量为：数据库所使用的 CPU 核数 与 内存大小的1/2 二者中取最大值。
Serverless 服务的计算和存储独立计费：计算按 ***U 个数计费，存储按使用量 GB 计费，计费系统按秒计费，按小时结算。
七、总结：
以上是我从0到1对腾讯云TDSQL-C MySQL Serverless的了解与实践，通过对TDSQL-C MySQL的3个特性：资源扩缩范围（***U）、弹性策略、自动启停，进行了实际的测试，从计算层到存储层，得到了一些总结。
Serverless 集群会持续监控用户的 CPU、内存等 workload 负载情况，根据系统设定的可调整 ***U 弹性扩缩容的范围，Serverless 集群会根据这些规则触发自动扩缩容策略，在该范围内根据实际业务压力自动增加或减少 ***U。
另外，Serverless 服务支持自定义实例自动暂停时间，无连接时实例会自动暂停。当有任务连接接入时，实例会秒级无间断自动唤醒。
3个重要的特性充分的展示了 Serverless 支持按实际计算和存储资源使用量收取费用，不用不付费，将腾讯云云原生技术普惠用户。
初创企业、中小企业在数据库层面的最大需求就是低成本，通过腾讯云领先的技术、完整的生态以及极致的用户体验，让用户充分体验到云上 Serverless 架构的高效率、免运维、灵活扩展、降低成本等优势，从而构建起贴近用户实际业务场景的强大数据库产品和健壮完善的数据库生态。为开发者、各行各业用户更便捷、更高效率、更低成本的 Serverless 服务，助力企业降本增效。
