I. Introduction:
With the continuous development of cloud computing technology, more and more enterprises are beginning to choose to deploy their databases on the cloud to better support enterprise digital transformation and business innovation. In the process, many customers will encounter this One problem is that business will have peak periods and trough periods, and the number of database visits will also have corresponding peak periods and trough periods.
| serial number | business load | Business pain points |
|---|---|---|
| 1 | at the peak of business | ①. The small-sized database service selected by the customer cannot bear the high load of the business. ②. To avoid database service unavailability, temporary specification upgrade is required. ③. Or choose to buy a large-sized cloud database instance from the beginning. |
| 2 | During the low period of business | ①. Customers will find that large-scale database services generate high bills every day. ②. Resulting in a lot of unnecessary expenses. |
Traditional database services cannot solve this problem very well. They can only rely on repeated manual upgrades and downgrades, which is not safe and stable, but will also cause additional IT operation and maintenance costs and human resource costs. Therefore, in the face of customers' strong cost reduction and increase Amid calls for efficiency, Tencent Cloud TDSQL-C MySQL Serverless database came into being.
With the help of "Tencent Cloud TDSQL-C Joint CSDN Product Evaluation Activity", let us have an in-depth understanding and practice of the TDSQL-C MySQL Serverless database, taking advantage of the product's advantages and features such as low resource consumption, simplicity and ease of use, flexibility and flexibility, and low price. The enabling business rationally optimizes usage costs, creates value, further helps enterprises reduce costs and increase efficiency, and praises domestic cloud databases for being far ahead.
2. TDSQL-C MySQL Serverless database:
TDSQL-C MySQL Serverless database is a database launched by Tencent Cloud for small and medium-sized enterprises or individual developers. It provides real-time elasticity capabilities of CPU and memory, and builds a new form of database products under cloud architecture.
1. What is Serverless?
Serverless architecture is an Internet-based system in which application development does not use conventional service processes. Instead, they rely solely on a combination of third-party services (such as Tencent Cloud Serverless Framework services), client-side logic, and service-hosted remote procedure calls.
The development of cloud computing has ranged from IaaS, PaaS, SaaS to the latest BaaS and FasS. Serverless (de-serverization) is becoming more and more obvious in this trend. With the rapid development of container technology, IoT, 5G, blockchain and other technologies , the technical demand for decentralization, lightweight virtualization, fine-grained computing and other technologies has become increasingly strong. In the future, Serverless will shine on the stage of cloud computing.
Cloud computing has experienced the development process from IaaS -> PaaS -> Serverless/FaaS. Here is a basic introduction to these concepts.
| serial number | abbreviation | Cloud service architecture Chinese name | effect |
|---|---|---|---|
| 1 | IaaS | Service providers provide underlying/physical layer infrastructure resources | Purchase virtual resources through the service platform provided by IaaS, select the operating system, install the software, and deploy the program. |
| 2 | PaaS | Service providers provide underlying infrastructure services | It provides operating systems, database servers, web servers, load balancers and other middleware. Compared with IaaS customers, they only need to control the upper-layer application deployment and application hosting environment. |
| 3 | Boss | Service providers provide customers (developers) with services integrating cloud backends | For example, it provides functions such as file storage, data storage, push service, and authentication service to help developers quickly develop applications. |
| 4 | FaaS | Providers provide a platform that allows customers to develop, run and manage application functionality without the need to build and maintain infrastructure | Building applications according to this model is one way to implement a "serverless" architecture. |
To sum up, from IDC → IaaS, users do not need to pay attention to real physical resources. From IaaS → PaaS, users no longer pay attention to basic software such as operating systems, databases, and middleware. From PaaS → BaaS/FaaS, users can pay little or no attention to the backend. Serverless is an inevitable product of the development of cloud computing to a certain stage:
- "Green" computing (maximizing resource utilization and reducing waste of idle resources)
- "Low threshold" technology (low cost, including learning cost and usage cost)
2. Advantages of TDSQL-C MySQL Serverless database instance:
Compared with ordinary MySQL database instances, TDSQL-C MySQL Serverless database instances have the following six obvious advantages:
| Advantage: |
|---|
| ①. Since its specifications are adjusted at any time according to business needs, the overall waste of resources is very small, which improves resource utilization and reduces resource usage. |
| ②. It can fully meet business needs during peak periods, ensure that business is not damaged, and improve the stability of the system. |
| ③. Breaking the fixed resource payment model and achieving pay-as-you-go payment that truly dynamically matches load and resources can save a lot of costs. |
| ④. No manual configuration changes are required, which improves operation and maintenance efficiency and reduces operation and maintenance costs for operation and maintenance managers and developers. |
| ⑤. Supports automatic start and stop capabilities. When there is no connection, the instance automatically pauses to release computing costs; when a connection is requested, it automatically starts without any sense. |
| ⑥. The design is optimized for high-throughput writing scenarios and high-concurrency services, while providing elastic scaling capabilities, which is suitable for scenarios with large amounts of business data and typical business access peaks and valleys. |
TDSQL-C MySQL Serverless database can automatically expand and shrink instances according to business load. Developers do not need to worry about underlying resource issues. It supports custom automatic pause time, enables second-level cold start when business is uninterrupted, and provides a variety of flexible billing methods. for users to choose.
The serverless billing method does not require payment of fixed resources, but is charged according to actual usage. If you do not use it, you will not pay. It can adaptively and dynamically match resources according to business load, and elastically increase and decrease resources and billing in seconds, helping enterprises to reduce costs and increase efficiency. The maximum cost can be reduced 90% of the cost.
3. Explain the differences in life scenes:
This article uses a novel scene I read in school to illustrate the intuitive comparison between traditional databases and TDSQL-C MySQL Serverless databases. It is described from actual scenes in life, making it easier to understand and choose the appropriate product.
The National Day holiday is coming every year, and the two protagonists have arranged their own travel. Since the financial foundations of their families are different, their travel arrangements will also be different.
| Protagonist 1: Tang Yun comes from a working-class family |
|---|
| ①. In order to save costs, according to the length of the distance, the flexible ride cost (taking into account the cost and time cost) is compared with the appropriate means of transportation. The distance can be regarded as the usual configuration of the database (for example, 2km is equivalent to 2 cores and 2G). With the The size of the distance corresponds to different calculation costs. |
| ②. Therefore, for a system with 10 users, the 2km configuration is completely sufficient, but for 20 users, the system needs to use the 20km configuration, and so on. In the end, under the conditions that fully meet the travel conditions, the total cost is 1,625 yuan. |
| ③. During the trip, you do not need to bear the construction of transportation, the purchase of equipment, the maintenance of equipment, and the wages of drivers, nor do you need to bear related expenses during non-travel periods (in the case of non-use, there will be no charge). You only need to make it clear You can travel to your destination conveniently and cheaply. |
| Protagonist 2: Chu Mengyao’s family has a listed company |
|---|
| ①. In order to ensure safety, my family purchased a dedicated private jet, which can handle all regular transportation, and there is no need to worry about traffic jams at any time (concurrency is too high). The only price is that the cost is relatively expensive (high-configuration instances are fixed TOLL). |
| ②. Even if the aircraft does not take off, a large amount of expenses will be incurred, such as daily maintenance and pilot labor costs (in the case of purchased aircraft, expenses will also be incurred when not in use). |
4. Summary:
TDSQL-C MySQL Serverless database instance provides the ability to charge on-demand computing resources. It has the advantages of low resource usage, simplicity and ease of use, elasticity and flexibility, and low price, enabling users to quickly and independently deploy computing power during business peaks and valleys. Scaling requirements can be achieved while quickly responding to business changes while reasonably optimizing usage costs to further help enterprises reduce costs and increase efficiency.
3. TDSQL-C MySQL Serverless database service features:
TDSQL-C MySQL version provides serverless services to meet the database service requirements of enterprises for specific business scenarios, helping enterprises to reduce costs and increase efficiency.
1. The overall architecture of TDSQL-C MySQL Serverless:
The Serverless service is a serverless architecture version of the TDSQL-C MySQL version of Tencent Cloud's self-developed new generation cloud-native relational database. It is a cloud-native database with a full Serverless architecture. The Serverless service supports charging based on actual computing and storage resource usage. There is no need to pay, and Tencent Cloud's native technology will benefit all users.
The picture above shows the overall architecture of TDSQL-C MySQL Serverless. The core module is the central control node (svls scheduler). The central control node receives the memory/CPU/access status and other monitoring data collected by the computing layer, decides whether to expand or shrink the capacity according to the policy, starts and stops the instance, and reports to the cloud console for billing according to the billing rules.
TDSQL-C MySQL Serverless has a faker module. When the computing node is paused, the four-layer vip:vport will be bound to the faker port. After the user request comes, it is recognized as a valid MySQL protocol, and the central control module is notified to restart the instance. The advantage is that users do not need to pay for proxy nodes.
2. Resource expansion range (CCU):
The range of CCU elastic expansion and contraction can be adjusted, and the Serverless cluster will automatically increase or decrease CCU within this range according to actual business pressure.
2.1 What is CCU?
CCU (TDSQL-C Compute Unit) is the computing and billing unit of Serverless. One CCU is approximately equal to the computing resources of 1 CPU and 2GB of memory. The number of CCU used in each billing cycle is: the number of CPU cores and memory used by the database. 1/2 of the size, whichever is the largest.
Serverless services need to set a flexible range. For detailed elastic range intervals, please refer to Computing Power Configuration.
2.2 MySQL instance resource selection:
Through the computing power configuration of the TDSQL-C MySQL Serverless instance resource, you can choose a minimum of 0.25CCU, which represents a CPU of 0.25 and a memory of 0.5GB, and a maximum of 64CCU, which represents a CPU of 64 and a memory of 128G, which is enough to cover many scenarios.
It is recommended that when setting the elastic range for the first time, configure the minimum capacity to 0.25 CCU and select a higher value for the maximum capacity. A smaller capacity setting allows the cluster to be reduced to the maximum extent when it is completely idle to avoid incurring additional costs. A larger capacity setting allows it to be expanded to the maximum extent when the cluster load is too heavy, stabilizing business peaks.
By specifying the upper and lower limits of instance resource fluctuations and using CCU as a unit, the database service becomes more flexible and effectively helps enterprises achieve the goal of reducing costs and increasing efficiency.
3. Flexible strategy:
Serverless clusters will continuously monitor users' CPU, memory and other workload conditions, and trigger automatic expansion and contraction policies based on certain rules.
3.1 Automatic expansion and contraction solution in traditional serverless architecture:
In the traditional serverless architecture on the left side of the figure below, there will be a shared virtual machine pool, which stores specifications of different sizes. Assume that you need to expand from 1 core 2G to 2 core 4G, then find a 2 core 4G virtual machine from the pool. Mount the corresponding data disk to the virtual machine and switch access to the virtual machine to complete automatic expansion.
Problems with automatic expansion in traditional serverless architecture:
| Problems: |
|---|
| ①. Assuming that the user only needs 4-core 8G, the traditional serverless architecture still needs to gradually increase from 1-core 2G, 2-core 4G, and 4-core 8G, and the expansion takes a long time. |
| ②. Selecting a new virtual machine for expansion will cause BP to fail, and access will go through a cold start process, which makes the user experience not very friendly. |
3.2 Automatic expansion and contraction scheme in traditional TDSQL-C Serverless architecture:
In the TDSQL-C Serverless architecture on the right side of the figure above, users choose a minimum specification of 1 core 2G and a maximum specification of 4 cores 8G when purchasing. TDSQL-C Serverless will provide users with the maximum CPU specifications at the beginning, and the memory will start from the minimum specifications. It can be seen that the CPU resources of TDSQL-C Serverless will not be limited and can be used arbitrarily within the set maximum specifications. The advantage is that user performance is not limited, but the disadvantage is that the entire machine may be fully loaded.
Based on the following two points, TDSQL-C Serverless can handle automatic expansion and contraction very well:
| TDSQL-C Serverless automatic expansion and contraction solution: |
|---|
| ①. Since TDSQL-C adopts a storage-computing separation architecture, once it monitors that the overall machine resources exceed the threshold, it will quickly migrate and quickly restart the instance on another relatively idle machine. It can be completed in seconds, and the resource load can be accurately measured. control. |
| ②. The overall utilization rate of the cloud database is low. |
3.3 Summary:
The elasticity strategy of Serverless services is implemented using the monitoring computing layer. By monitoring business load conditions, the system automatically expands and contracts computing resources.
| Principle of automatic expansion and contraction: |
|---|
| ①. The elastic policy of the Serverless service will initially limit CPU and memory resources to the maximum specifications based on the capacity range selected by the user when purchasing, greatly reducing the time impact and usage restrictions caused by CPU and memory expansion. |
| ②. When the cluster triggers the automatic elastic load threshold, the Buffer pool will be adjusted at the minute level in advance based on monitoring. |
| ③. In this solution, users can use the database to expand the CPU capacity without any awareness, and the instance OOM will not be caused by a sudden increase in connections. |
4. Automatic start and stop:
Serverless services support customizing the automatic suspension time of instances, and instances will automatically suspend when there is no connection. When a task is connected, the instance will automatically wake up in seconds without interruption.
When there are no database requests, the monitoring service will trigger the recycling of computing resources and notify the access layer. When the user accesses again, the access layer will wake up the cluster and provide access again.
5. Billing model:
Serverless services monitor business load conditions, the system automatically expands and contracts computing resources, and bills the resources consumed at this time.
6. Misunderstandings about storing resource packages:
| model | describe |
|---|---|
| Imaginary charging model | ①. The amount of data storage you can use depends on how many storage resource packages you buy. ②. For example, if you purchase a 10TB storage resource package, you can use it for a long time until the database data reaches 10TB. |
| Actual charging model | ①. The storage resource package will be deducted and charged according to the actual storage amount used per hour. Special attention should be paid to the estimation of data volume in actual projects. ②. For example, if you purchase a 10TB storage resource package and the existing data volume is 200GB, the calculation formula is 10TB/(0.2* 24) = 2.08 days |
During the use, I found a problem related to the storage resource package. I haven’t used it for a while. I was charging for the storage resource. I remember that I had already purchased the storage resource package. Did it run out so quickly? It seems that the amount of data used in the memory is not much.
Check the actual storage usage of TDSQL-C MySQL Serverless to 224.57GB, but I purchased a 40TB storage resource package. Why is it used up so quickly?
The following is a list of purchased resource packages. It is found that the storage resource package is full.
Because I didn’t know what caused it, I had no choice but to file a work order to find out what the problem was.
The following is the reply given by a Tencent Cloud engineer. There is a 40T storage resource package, but the currently used storage is 0.2T. It is 24 hours a day. According to the formula he gave, it means that it will be used up in about 8 days.
It seems that I have misunderstood. The conclusion is thatthe storage resource package will be deducted and charged according to the actual storage amount used per hour. When purchasing, there are also notes on it when selecting the billing mode.
4. TDSQL-C MySQL Serverless automatic start and stop experiment:
1. MySQL database connection principle:
After the MySQL server instance is started, you can establish a connection with the server through the client, and then send a query/update request.
| 3 MySQL client connection channels: |
|---|
| ①. Establish a connection with the MySQL server through graphical client software (such as MySQL Workbench, Navicat For MySQL, DataGrip, TablePlus, Sequel Pro, etc.). |
| ②. 通过 MySQL 安装目录 bin 目录下的 mysql 二进制文件在终端窗口通过命令行建立与 MySQL 服务端的连接。 |
| ③. 在PHP、Go、Python、Java等后端编程语言中使用的数据库SDK建立与 MySQL 服务端的连接，只不过SDK是对数据库连接做了封装而已。 |
2. 可视化图形工具客户端连接数据库：
先将TDSQL-C Serverless服务器关掉，再在Navicat For MySQL填写完Host、Port、User Name、Password后，点击“Test Connection”后，可以看到服务器的实时监控，发现有连接进来后，马上把服务器进行恢复。因为没有有效的记录时间的方案，只能看折现图，可以发现Threads进程是在23时48分15秒左右马上启动起来了。
3. MySQL二进制文件的两种连接方式：
Linux平台环境下主要有两种连接方式，一种是TCP/IP连接方式，另一种就是socket连接：
- 通过TCP/IP连接MySQL实例时，MySQL会先检查一张权限表，用来判断发起请求的客户端IP是否允许连接到MySQL实例，该表就是MySQL库下面的user表。
- UNIX Socket连接方式其实不是一个网络协议，所以只能在MySQL客户端和数据库实例在同一台服务器上的情况下使用。
| Unix套接字连接MySQL的优势： |
|---|
| ①. 更快的连接速度： Unix套接字连接不经过TCP/IP协议栈，因此速度更快。 |
| ②. 更高的安全性： Unix套接字连接只能在本地主机上使用，因此对于需要保护数据安全的数据库应用程序来说，这是一个重要的因素。 |
| ③. 更少的网络负载： 由于Unix套接字连接只在本地主机上连接，因此不会浪费带宽和网络负载。 |
因此，本次测试会采用MySQL TCP/IP的方式进行测试。
可以使用shell脚本来操作TDSQL-C MySQL Serverless数据库自动启停，使用-e参数可以执行各种sql的(创建、删除、增、删、改、查)等各种操作。
3.1 时间命令time的shell脚本：
脚本的作用是当数据库暂停后，第一个mysql连接是模拟登录到Serverless数据库，出现自动启动数据库，看看时间是多久，然后，马上再次用mysql连接模拟一下在数据库启动的状态下，需要多久进行连接。
#!/bin/bash
# 数据库信息
HOSTNAME="gz-cynosdbmysql-grp-69gvou9h.sql.tencentcdb.com"
PORT="25950"
USERNAME="root"
PASSWORD="Mydb123."
# 执行查询数据
query_sql="SHOW VARIABLES LIKE 'version';"
time mysql -h${
HOSTNAME} -P${
PORT} -u${
USERNAME} -p${
PASSWORD} -e "${query_sql} -vvv"
time mysql -h${
HOSTNAME} -P${
PORT} -u${
USERNAME} -p${
PASSWORD} -e "${query_sql} -vvv"
mysql -v参数的作用，为了防止SQL本身执行时间影响到连接的效果，可以把SQL执行的时间也打印出来。
● 若要同时显示语句本身：-v
● 若要增加查询结果行数：-vv
● 若要增加执行时间：-vvv
3.2 时间命令date的shell脚本：
#!/bin/bash
# 数据库信息
HOSTNAME="gz-cynosdbmysql-grp-69gvou9h.sql.tencentcdb.com"
PORT="25950"
USERNAME="root"
PASSWORD="Mydb123."
# 执行查询数据
query_sql="SHOW VARIABLES LIKE 'version';"
firstStart=$(date +%s.%N)
mysql -h${
HOSTNAME} -P${
PORT} -u${
USERNAME} -p${
PASSWORD} -e "${query_sql}" -vvv
firstEnd=$(date +%s.%N)
firstRunTime=$(echo "$firstEnd - $firstStart" | bc)
echo "第一次首连命令执行时间：$firstRunTime 秒"
secondStart=$(date +%s.%N)
mysql -h${
HOSTNAME} -P${
PORT} -u${
USERNAME} -p${
PASSWORD} -e "${query_sql}" -vvv
secondEnd=$(date +%s.%N)
secondRunTime=$(echo "$secondEnd - $secondStart" | bc)
echo "第二次连接命令执行时间：$secondRunTime 秒"
4. 准备两台不同配置的机器：
评测的目标机器为TDSQL-C Serverless，使用的模式为按量收费，机房的位置在广州四区。
准备两台测试机器，一台是腾讯云的CVM云服务器，2核4G 10Mps，广州七区与Serverless实例在同一个区，一台是华为云耀云服务器2核2G 3Mps，华北北京四区，测一下不同服务器、不同区域的结果做比较。
腾讯云的CVM云服务器，可以通过orcaterm进行远程登录，可以进行如下的测试脚本执行流程：
# 复制脚本
vi query.sh
# 增加执行权限
chmod -R 777 query.sh
# 执行shell脚本
./query.sh
# 检查是否有mysql
mysql
# ubuntu安装mysql客户端
apt-get install -y mysql-client-core-8.0
5. 测试脚本分析实验数据：
通过2种查看linux执行时间的命令的shell脚本，每次执行前，先将服务器进行暂停，脚本中第1个mysql命令表示服务器暂停时默认启用，看一下执行的时间多久，这里需要注意的是因为SQL本身也会存在执行时间，比如执行一个慢查询，这里为了得到比较合理的值，增加了-vvv参数来输出SQL命令本身执行的时间，得到的公式：
命令的总执行时间 – SQL本身执行的时间 = Serverless服务器自动启动时间
每个脚本分别在2台云服务器腾讯云CVM、华为云云耀云服务器各执行5次，得出以下结果：
- 可能由于腾讯云服务器与Serverless在相同的区域广州机房，时间略比华为云服务器要短。
- 基本上在2s左右就能完成Serverless服务器自动启动。
云服务器(Cloud Virtual Machine，CVM)是腾讯云提供的可扩展的计算服务。使用云服务器避免了使用传统服务器时需要预估资源用量及前期投入，帮助在短时间内快速启动任意数量的云服务器并即时部署应用程序，推荐应用在部署时，参考以下方案：
6. Java代码连接MYSQL数据库方式：
JDBC是Java数据库连接(Java Database Connectivity)，是一套用于执行SQL语句的Java API。应用程序可以通过这套API连接到关系型数据库，并使用SQL语句完成对数据中数据的查询、增加、更新和删除等操作。
JDBC在应用程序与数据库之间起到了一个桥梁作用，当应用程序使用JDBC访问特定的数据库时，需要通过不同数据库驱动与不同数据库进行连接，连接后即可对该数据库进行相应的操作。
采用的逻辑是先将Java代码启动并且连接上数据库，这时候，程序设定延迟1分钟，此时，手动在服务器控制台进行暂停服务器后，再让程序进行SQL的操作，看看实际生产的一个真实情况能不能满足？
Java核心的代码：
@Component
public class Service implements ApplicationContextAware {
@Autowired
private ShopMapper shopMapper;
@Override
public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
try {
Thread.sleep(60*1000);
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
// 第一次首次连接(Serverless服务器自动触发启动)
long firstStartTime = System.currentTimeMillis();
System.out.println("SQL语句执行前时间：" + firstStartTime);
shopMapper.insertTest();
long firstRunTime = System.currentTimeMillis()-firstStartTime;
System.out.println("第一次总耗时："+ firstRunTime);
// 第二次连接
long secondStartTime = System.currentTimeMillis();
System.out.println("SQL语句执行前时间：" + secondStartTime);
shopMapper.insertTest();
long secondRunTime = System.currentTimeMillis()-secondStartTime;
System.out.println("第二次总耗时："+ secondRunTime);
}
}
执行结果：
- 项目启动时，要对数据库进行了实例化连接
- 程序启动后，会有一个60s的延迟设置，此时，手动暂停Serverless实例，模拟在程序启动后，在一定时间内不使用，Serverless服务器实例自动暂停
- 第一次连接，触发Serverless恢复感知器自动启动服务器，可以看到在3.127s就完成了
- 第二次连接，Serverless已经恢复了，可以看到在0.089s内完成操作
6. 小结：
通过3种MySQL客户端连接方式的进行测试，TDSQL-C MySQL Serverless自动启停实验，可以完全满足生产环境的需求。
五、TDSQL-C MySQL Serverless弹性伸缩实验：
下面将按照以下5个大的步骤进行对TDSQL-C MySQL Serverless的一个压力的测试过程。
为了可以有效的进行测试观察结果，TDSQL-C MySQL Serverless选择了一个较大的算力弹性区间范围[1，32]，即最小可以是1核2G的云数据库服务器(可能会更小，0.1都可能存在)，最大可能是32核64G云数据库服务器。
通过对压测的结果进行分析，TDSQL-C MySQL Serverless在不使用的时候，就会释放计算节点，只收取存储的费用。当服务器启动后，就会再加上计算节点的CCU费用，可以看到TDSQL-C MySQL Serverless在最开始的算力为1，可以随着压测的流量变大，同步增加到最大32个算力，当压测停止后，又自动在后面缩容到算力到0为止。
以下为分3个阶段进行TDSQL-C MySQL Serverless的测试，第一步本地进行多进程可以看到没有太多的变化，第二步使用本地JMeter，由于机器配置的原因，也是没有到达一个极限，最后第三步，在购买一台高配的云服务器使用Jmeter压测，可以达到实例的一个满核的负载。
以下为从监控平台得到压力测试这段时间内，得到各个指标参数的值，这里没有把每一分钟的变化值罗列出来，只是把一些波动变化比较大的值，在以下进行列举：
| 时间段 | CPU百分比 | 内存百分比 | Memory usage | CCU computing power value |
|---|---|---|---|---|
| 11：50 | 1.04% | 0.98% | 700.24M | 1 |
| 11：59 | 3.77% | 1.73% | 1232.21M | 1.21 |
| 12：03 | 5.41% | 3.89% | 2763.62M | 1.73 |
| 12：05 | 6.38% | 3.89% | 2766.62M | 2.04 |
| 12：08 | 8.36% | 3.89% | 2764.70M | 2.68 |
| 12：09 | 10.68% | 7% | 5332.13M | 3.42 |
| 12：10 | 15.12% | 8.87% | 6304.86M | 4.84 |
| 12：11 | 23.08% | 15.09% | 10731.04M | 7.39 |
| 12：15 | 33.33% | 18.08% | 12856.34M | 10.67 |
| 12：16 | 43.13% | 34.1% | 24250.74M | 13.8 |
| 12：18 | 37.91% | 35.29% | 25095.05M | 12.25 |
| 12：19 | 59.37% | 35.29% | 25098.40M | 19 |
| 12：20 | 65.51% | 52.72% | 37488.47M | 24.81 |
| 12：21 | 58.39% | 79.58% | 56593.07M | 27.89 |
| 12：27 | 97.81% | 80.35% | 57140.87M | 31.3 |
| 12：28 | 91.53% | 80.35% | 57140.92M | 29.29 |
| 12：29 | 100% | 80.36% | 57145.35M | 32 |
| 12：32 | 91.61% | 80.37% | 57150.45M | 29.32 |
| 12：33 | 100% | 80.37% | 57153.46M | 32 |
| 12：34 | 87.61% | 80.37% | 57151.07M | 28.04 |
| 12：37 | 1.79% | 58.81% | 41821.7M | 27.89 |
| 12：38 | 1.81% | 35.05% | 24923.48M | 12.3 |
| 12：39 | 0.93% | 15.68% | 11147.32M | 6.2 |
| 12：40 | 0.55% | 7.42% | 5278.11M | 3.14 |
| 12：41 | 0.31% | 3.39% | 2412.45M | 1.43 |
| 12：46 | 0.02% | 1.98% | 1410.64M | 1 |
| 12：48 | 0% | 0% | 0M | 0 |
| 12：50 | 0% | 0% | 0M | 0 |
Through the above indicator data, we put it into echats to view. Because the memory usage value is relatively large, it is not involved in the calculation. Through the indicator data obtained from the hourly stress test from 11:50 to 12:50, we can The following discount diagram is formed.
option = {
title: {
text: 'TDSQL-C Serverless CCU趋势图'
},
tooltip: {
trigger: 'axis'
},
legend: {
data: ['CPU使用率', '内存的使用率', 'CCU算力值', 'Direct', 'Search Engine']
},
grid: {
left: '3%',
right: '4%',
bottom: '3%',
containLabel: true
},
toolbox: {
feature: {
saveAsImage: {
}
}
},
xAxis: {
type: 'category',
boundaryGap: false,
data: ["11：50", "11：59", "12：03", "12：05", "12：08", "12：09", "12：10", "12：11", "12：15", "12：16", "12：18", "12：19", "12：20", "12：21", "12：27", "12：28", "12：29", "12：32", "12：33", "12：34", "12：37", "12：38", "12：39", "12：40", "12：41", "12：46", "12：48", "12：50"]
},
yAxis: {
type: 'value'
},
series: [
{
name: 'CPU使用率',
type: 'line',
stack: 'Total',
data: ["1.04", "3.77", "5.41", "6.38", "8.36", "10.68", "15.12", "23.08", "33.33", "43.13", "37.91", "59.37", "65.51", "58.39", "97.81", "91.53", "100", "91.61", "100", "87.61", "1.79", "1.81", "0.93", "0.55", "0.31", "0.02", "0", "0"]
},
{
name: '内存的使用率',
type: 'line',
stack: 'Total',
data: ["0.98", "1.73", "3.89", "3.89", "3.89", "7", "8.87", "15.09", "18.08", "34.1", "35.29", "35.29", "52.72", "79.58", "80.35", "80.35", "80.36", "80.37", "80.37", "80.37", "58.81", "35.05", "15.68", "7.42", "3.39", "1.98", "0", "0",]
},
{
name: 'CCU算力值',
type: 'line',
stack: 'Total',
data: ["1", "1.21", "1.73", "2.04", "2.68", "3.42", "4.84", "7.39", "10.67", "13.8", "12.25", "19", "24.81", "27.89", "31.3", "29.29", "32", "29.32", "32", "28.04", "27.89", "12.3", "6.2", "3.14", "1.43", "1", "0", "0",]
},
]
};
- In the early days, both CPU and memory were growing proportionally, and CCU was also growing proportionally.
- In the later period, the CPU dropped sharply, but the memory did not drop so fast. CCU is related to the CPU and memory. You can see that the CCU polyline is between the CPU and memory polylines.
When TDSQL-C MySQL Serverless reached its peak, the CPU reached 100%. By the way, I tested the query statement and could still access and get the results very quickly. As long as there are not a large number of slow queries in the project, the project is estimated to be able to run normally. .
6. Feasibility analysis of importing TDSQL-C MySQL Serverless into the company’s business:
The company's business is customized auto insurance. In the early stages of entrepreneurship, most companies cooperate with third-party institutions to quickly verify the business model and quickly open up the market.
With the gradual improvement of the business system, the company has also slowly introduced a self-developed system. The following is the construction system of the company's traceability system, and the scenario optimization considerations compared with the TDSQL-C MySQL Serverless database.
(1). The backtracking scenario cycle is short, and you will have to pay if you don’t use the remaining time:
A certain type of product developed is divided into an insurance period and a claim settlement period. The insurance period is generally 2-3 months. After the insurance period, it will no longer be used, which is the claim settlement stage. From this point of view, it is currently based on the annual subscription model. The purchased database will cause excess resources and should be a periodic resource purchase.
(2). After archiving, only a small number of abnormal cases need to be traced back, and the usage rate is not high:
You can save the cost of computing nodes and only use the storage cost. If COS is further integrated, the cost may be compressed and reduced again.
Other application scenarios of Serverless database:
Since traditional enterprises usually have preset a large number of software and hardware resources, and user usage habits are not easy to change, the adoption of Serverless databases in traditional enterprises’ existing businesses will require a certain process. However, in some emerging industry enterprises or emerging business scenarios as follows: , Serverless database is rapidly showing its advantages and occupying an important position.
7. Summary:
TDSQL-C MySQL Serverless database instance not only provides vertical resource isolation capabilities for network resources, namespaces, and storage spaces, but also provides the ability to charge on-demand computing resources. It has the advantages of low resource usage, simplicity and ease of use, elasticity and flexibility, and low price. , empowering users to quickly and independently expand and contract computing power requirements during business peaks and valleys, so as to quickly respond to business changes while reasonably optimizing usage costs, and further help enterprises reduce costs and increase efficiency.
In scenarios with large business fluctuations, the resource usage and specification changes of ordinary database instances and TDSQL-C MySQL Serverless database instances can be seen that ordinary instances waste more resources during trough periods, and insufficient resources during peak periods will cause customer business problems. Damage, and the TDSQL-C MySQL Serverless database instance, with its extreme elasticity, perfectly supports the customer's business load at different times, avoids the waste of resources to the greatest extent, and saves a lot of costs.