Article directory
Preface
In recent years, serverless databases have become popular. They are called the next-generation revolutionary technology of databases in the industry and are the inevitable result of the development of cloud-native databases. As the first company to launch Serverless database in China as early as 2020, Tencent Cloud has continued to explore the field of Serverless database in recent years. This year, it launched a series of updates such as prepaid resource type resource packages and read-only instances mounted on Serverless clusters. The cost reduction and efficiency increase for users and the inclusiveness of domestic cloud native technology provide an answer sheet of their own.
This article will be based on Tencent Cloud TDSQL-C for MySQL Serverless version and lead everyone to conduct a simple evaluation of its core features. Provide a simple reference for everyone to choose between traditional databases and Serverless databases.
Introduction to Tencent Cloud TDSQL-C for MySQL Serverless Edition
TDSQL-C for MySQL (TDSQL-C for MySQL) is a new generation of cloud-native relational database self-developed by Tencent Cloud. It combines the advantages of traditional databases, cloud computing and new hardware technologies to provide users with database services with high elasticity, high performance, massive storage, security and reliability. The Serverless service is a serverless architecture version of the TDSQL-C MySQL version. It is a cloud-native database with a full Serverless architecture. Its architecture design is as follows:
The Serverless service is based on the concept of separation of computing and storage. It meets the rigid needs of customers to flexibly expand clusters according to business development in public cloud computing environments, so that users no longer have to worry about instance resources and use databases like tap water. It supports charging based on the actual usage of computing resources and storage resources. There is no need to pay, and Tencent Cloud's native technology will benefit all users. To summarize its characteristics, it can be divided into the following three items:
- Automatic start and stop (Practical paid): Serverless service supports customizing the automatic suspension time of instances, and the instance will automatically suspend when there is no connection. When a task is connected, the instance will automatically wake up in seconds without interruption. The cluster is measured by the second and settled by the hour. If there is no access, there is no charge, helping the business to save costs to a great extent;
- Automatic expansion and contraction (elastic policy): The Serverless cluster will continuously monitor the user's CPU, memory and other workload load conditions, and trigger the automatic expansion and contraction policy according to certain rules. Users do not need to pay too much attention to specifications. When the number of visits increases, the capacity is automatically expanded and when the traffic decreases, the capacity is automatically reduced, and the process of expansion and contraction is achieved without any perception of the business;
- Resource expansion range (CCU): The range of CCU elastic expansion and contraction can be adjusted. The Serverless cluster will automatically increase or decrease CCU within this range based on actual business pressure;
Preparation
1. Purchase TDSQL-C for MySQL Serverless instance
Open and log in TDSQL-C for MySQL purchase page to complete the database configuration and basic information settings. The database configuration used in this article is as follows:
Description of database configuration parameters (the items in bold are parameters that need to be focused on):
- Instance form: This article chooses Serverless
- Database engine: This article chooses MySQL
- Region: The optional computing power configuration may be slightly different in different regions. For example, in Beijing, the maximum computing power configuration can only be 16-32CCU, while in Guangzhou, 32-64CCU can be selected. Here you can make a selection based on the business deployment area and the configuration required by the business.
- Main Availability Zone: Select the deployment availability zone, this is optional.
- Multi-availability zone deployment: The Serverless version currently does not support multi-availability zone deployment. If your business has rigid requirements for multiple availability zones, you can only choose other versions of TDSQL-C.
- Transmission link: Default high IO version, no other configuration.
- Network: For performance and security reasons, only private networks (VPC) are currently supported. The cloud server needs to be in the same VPC as TDSQL-C to communicate (guaranteed to be in the same region, not limited to availability zones).
- Database version: This article chooses MySQL 5.7. It should be noted that the TDSQL-C MySQL version only supports the Innodb engine.
- Computing power configuration: Select the upper and lower limits of the computing power configuration CCU, and the instance will automatically expand and contract flexibly according to the selected resource range.
- 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 maximum value between the number of CPU cores used by the database and 1/2 of the memory size
- Supports separate configuration of computing power for read-write instances and read-only instances
- Automatic suspension: Configure the automatic suspension time of the instance. If there is no connection to access the database within the set time, the instance will be automatically suspended. After the instance is suspended, CCU will no longer be billed, and the storage will still be charged. Actual usage billing.
- Billing mode: Supports the selection of pay-as-you-go billing or resource packages. If it is a production environment, it is recommended to use resource packages to pay. The advantage is that it is more cost-effective and more flexible to use than the pay-as-you-go model.
After the database configuration is completed, basic information configuration still needs to be performed. In order to save space, this article will not describe it too much for the time being. You can configure it according to your actual situation.
2. Enable external network access to the database
After the database is successfully purchased, it can only be accessed through the intranet by default. In order to facilitate testing, we need to enable the external network access capability of the database first. Once enabled, we can access the database from the external network through the domain name and port assigned by the system. It should be noted that external network access is recommended only for development or auxiliary management of the database. For business access, please use intranet access.
3. Install testing tools
Part of the test scenarios in this article are based on Sysbench. Sysbench is a cross-platform and modular benchmarking tool that supports multi-threading. It is used to evaluate the performance of core parameters of the system when running a high-load database. You can bypass complex database benchmark settings and quickly understand the performance of your database system even without installing a database. The Sysbench installation command under CentOS system is as follows:
curl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.rpm.sh | sudo bash
yum -y install sysbench
# 检查是否安装成功
sysbench --version
4. Prepare test data
Create in the database through database management tools test Library for testing, use Sysbench to quickly generate test data. Test data scale: 10 tables, each table has 10,000 pieces of data.
# 为了方便测试，这里将常用参数设置为系统临时环境变量。
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
Screenshot of command execution:
At this point, we have completed all the preparation work. Next, we will conduct an in-depth evaluation of the core features of TDSQL-C for MySQL Serverless through several scenario tests.
Serverless cluster core feature 1: automatic start and stop
1. Introduction to automatic start and stop
The 自动暂停 function of the TDSQL-C Serverless version is controlled by the 自动暂停 item in the cluster configuration. After the automatic pause is turned on, the database will not be available within the set time. When the connection and CPU are used, the instance will be automatically suspended. After the instance is suspended, CCU will also suspend billing, and the storage will still be billed according to actual usage.
TDSQL-C Serverless version自动启动 function does not require configuration. When the instance is suspended, if a database connection is initiated, the system will automatically start the suspended database in seconds. No need to set up a reconnection mechanism. The overall process design is as follows:
From this design drawing, we can know that the first database connection in the paused state is connected to the database through a perceptron module. This module has two functions. One is through the management and control serviceRestore the instance in seconds, and the second is to continue to function as a forwarder after the instance is restored, so that the database connection is continuous. After the cluster is started, the remaining new connections will automatically be connected directly to TDSQL-C.
The time-consuming description of 自动启动 in the official document is seconds , so what is the second level? How long will it take? After all, startup completed in 1 second and startup completed in 5 seconds can be called second-level recovery, but the impact on the business is very different. Next, we use a simple test to explore its specific time consumption.
2. It takes time to automatically start the test instance
The Linux system's owntime command can be used to measure the running time of a command. We use this command to test the instance in the startup state and in the paused state to connect to the database and query the database. The time required for the version. The test command is as follows:
time mysql -h$TDSQL_HOST -P$TDSQL_PORT -u$TDSQL_USER -p$TDSQL_PWD -e "select version();"
-
Step 1: Execute the test command when the cluster is started, observe the command execution time and record it.
-
Step 2: Manually pause the instance through the database console
-
Step 3: Execute the test command, observe the command execution time when the instance is suspended, and record it
-
Step 4: Calculate the instance startup time: command execution time in paused state - command execution time in startup state = instance startup time.
In the picture, this startup takes about 1.4S.
By repeating the above steps for multiple rounds of testing, it was finally concluded that the average instance startup time was about 1.5S, and the highest startup time reached about 1.8S.
Note: Affected by factors such as test methods, network environment, client performance, etc., the above conclusion values are only shared by personal test results and do not represent the actual performance values of the product.
3. Automatic start and stop application scenarios
The biggest benefit that the automatic start and stop function brings to users is reduced business costs! Users no longer have to pay for idle resources. To give a typical example, in most ToB business scenarios, the business volume basically comes from the daytime on working days, while the business volume at night on working days and non-working days is very small. At this time, the automatic start and stop function can greatly benefit users. Greatly save database resource costs.
There is no silver bullet in software engineering. While the automatic start-stop function brings cost savings, it also brings the problem of high first connection delay. However, this problem can be encountered in some scenarios where the response delay requirements are not too high or the business volume is low. In scenarios where relative rules can be predicted and warmed up in advance, it becomes insignificant.
Serverless cluster core feature 2: automatic expansion and contraction
1. Introduction to automatic expansion and contraction
The elasticity strategy of Serverless services is implemented using the monitoring computing layer. By monitoring the business load, the system automatically expands and contracts computing resources, and bills the resources consumed at this time. 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.
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 in advance at the minute level 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.
It is recommended that when setting the elastic range for the first time, the minimum capacity should be configured as 0.25 CCU and the maximum capacity should be a higher value. 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 your cluster is overloaded and can stably survive business peaks.
2. Automatic expansion and contraction testing
˜The description of automatic expansion and contraction in the official documentation is: imperceptible expansion and contraction. Next we conduct a simple test through a simple test scenario. In this test, we will execute Sysbench stress test commands on two servers one after another to simulate the business system's access to the database. During the stress test, use the monitoring page of the Tencent Cloud console to check the usage of the database CPU, memory, and CCU under different loads. The test commands used in this test are as follows:
# 开启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
-
Step 1: Execute the stress test command on machine A and simulate 500 connections to access the database.
-
Step 2: 120 seconds after the stress test starts on machine A, execute the stress test command on machine B to simulate 1,000 connections to access the database.
-
Step 3: After the stress test of the two machines is completed, check the stress test reports of the two machines respectively, and check the database load status through the monitoring page of the console
-
A machine pressure test report
-
B machine pressure test report
-
CPU usage
-
memory usage
-
CCU usage
Note: Sysbench stress testing is only used to facilitate simulated database access. Real database stress testing also considers the machine's bandwidth, performance, stress testing scenarios and other factors. Therefore, the above TPS and QPS data do not represent TDSQL- Real performance data of C Serverless version. Students who are interested in the stress test report can check the official document:TDSQL-C MySQL version performance white paper
-
From the above test, we can see that when we increase access to the database step by step, the database's CPU, memory, CCU and other load conditions show a step pattern consistent with our access volume. Through the stress test report of the two machines, we It can also be found that when the database is automatically expanded, the TPS, QPS and other indicators of the database do not fluctuate significantly.
3. Automatic expansion and contraction application scenarios
Thanks to the fact that the business is imperceptible during the automatic expansion and contraction process, the automatic expansion and contraction function is almost universal in all scenarios, truly achieving the ultimate in "cost reduction". Whether you are in a ToC scenario or a ToB scenario, whether you are in the IoT or edge computing business, no matter whether your business volume is predictable or not, automatic expansion and contraction can perfectly cover your scenario. The only difference may be the cost in different scenarios. Lower more or less.
Summarize
After some experience, the biggest feeling I have about the TDSQL-C Serverless version is four words: “reducing costs and increasing efficiency.” These four words are not only reflected in the reduction of database resource costs, but also in the saving of personnel costs. There is almost no operation and maintenance management work when using TDSQL-C Serverless version. There are no worries about server upgrades, operating system maintenance, database expansion, and database optimization. This allows technical staff to devote more time to strategic work, such as business logic, performance optimization, data modeling, etc. Based on the above content, I have summarized some typical application scenarios of TDSQL-C Serverless version for your reference:
- Low-frequency database usage scenarios such as development and testing environments
- SaaS application scenarios such as website building services for small and medium-sized enterprises
- Individual developer users
- Educational scenes such as school teaching and student experiments
- Uncertain load scenarios such as Internet of Things (IoT) and edge computing
- Fully managed or users who want to be completely free of operation and maintenance
- Users whose business fluctuates or is unpredictable
- Business scenarios with intermittent scheduled tasks
Finally, I hope this article can provide you with some effective help in database selection and use of TDSQL-C Serverless version.