Database performance testing method, device and storage medium

Abstract

Embodiments of the present application provide a database performance testing method, device and storage medium. The method comprises the following steps: a database performance testing method is suitable for a testing device, and comprises the following steps: requesting a database server to create a database table for performance testing in a database run by the database server; setting a logical relationship about records in the database table; the logical relationship comprises a first logical relationship between fields in a same record in the database table; sending a transaction request for the database table to the database server, so that the database server executes a transaction corresponding to the transaction request, and the transaction request is generated based on the logical relationship; determining whether the database table meets the logical relationship according to a query result for the database table, to obtain a first determination result; and determining whether the database meets a transaction characteristic according to the first determination result. The testing scheme provided by the embodiments of the present application has high reliability.

Description

Technical Field

[0001] This application relates to the field of database technology, and in particular to a database performance testing method, device and storage medium. Background Technology

[0002] ACID refers to the four transaction properties that a Database Management System (DBMS) must possess to ensure that transactions are correct and reliable during the writing or updating of data: atomicity (or indivisibility), consistency, isolation (or independence), and durability.

[0003] The importance of ACID correctness for database systems is self-evident. When developing a new database engine, one of the most crucial tasks is to test the database's ACID properties. Currently, existing testing methods have relatively low reliability. Summary of the Invention

[0004] In view of the above problems, this application is made to provide a data processing method, apparatus and storage medium that solves or at least partially solves the above problems.

[0005] Therefore, in one embodiment of this application, a database performance testing method is provided, suitable for testing equipment, comprising:

[0006] Request the database server to create database tables for performance testing within the database it is running;

[0007] Establish logical relationships between records in the database table; the logical relationships include the first logical relationship between fields in the same record of the database table;

[0008] A transaction request for the database table is sent to the database server so that the database server can execute the transaction corresponding to the transaction request, wherein the transaction request is generated based on the logical relationship;

[0009] Based on the query results for the database table, determine whether the database table satisfies the logical relationship, and obtain a first determination result;

[0010] Based on the first determination result, determine whether the database satisfies the transaction characteristics.

[0011] In another embodiment of this application, an electronic device is provided. The electronic device includes: a memory and a processor, wherein,

[0012] The memory is used to store programs;

[0013] The processor, coupled to the memory, is used to execute the program stored in the memory to implement the database performance testing method described above.

[0014] In another embodiment of this application, a computer-readable storage medium storing a computer program is provided, wherein the computer program, when executed by a computer, can implement the database performance testing method described in any of the above claims.

[0015] In the technical solution provided in this application embodiment, a database table specifically for performance testing is created; and the logical relationships between records in the database table are configured; a transaction request is sent to the database server based on the logical relationships, so that the database server executes the corresponding transaction for the database table; then, based on the query results for the database table, it is determined whether the corresponding record in the database table satisfies the above logical relationships, thereby determining whether the database satisfies transaction characteristics. If the query finds that the corresponding record in the database table does not satisfy the above logical relationships, it indicates that the database has broken the database transaction characteristics; if the query finds that the corresponding record in the database table does not satisfy the above logical relationships, it indicates that the database maintains the database transaction characteristics. The verification scheme provided in this application embodiment has high reliability. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a schematic diagram of a database performance testing system provided in an embodiment of this application;

[0018] Figure 2 A schematic flowchart of a database performance testing method provided in an embodiment of this application;

[0019] Figure 3 Example diagrams illustrating information provided in an embodiment of this application;

[0020] Figure 4 This is a structural block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0021] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of the present application, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present application without creative effort are within the scope of protection of the present application.

[0022] Furthermore, some processes described in the specification, claims, and accompanying drawings of this application include multiple operations that appear in a specific order. These operations may be performed out of order or in parallel. Operation numbers such as 101, 102, etc., are merely used to distinguish different operations and do not represent any execution order. Additionally, these processes may include more or fewer operations, and these operations may be performed sequentially or in parallel. It should be noted that the terms "first," "second," etc., used herein are used to distinguish different messages, devices, modules, etc., and do not represent a sequential order, nor do they limit "first" and "second" to different types.

[0023] Before introducing the database performance testing method provided in the embodiments of this application, the database performance testing system involved in the method provided in the embodiments of this application will be introduced first. For example... Figure 1 As shown, the system may include: a test device 10 and a database server 20. Among them,

[0024] The testing device 10 is configured to: request a database server to create a database table for performance testing in its running database; set logical relationships between records in the database table; the logical relationships include a first logical relationship between fields in the same record in the database table; send a transaction request to the database server for the database table, wherein the transaction request is generated based on the logical relationships; determine whether the database table satisfies the logical relationships based on the query results for the database table to obtain a first determination result; and determine whether the database satisfies transaction characteristics based on the first determination result.

[0025] Database server 20 is used to: execute the transaction corresponding to the received transaction request.

[0026] The testing device can be a terminal or a server. The server can be a conventional server or a virtual server, etc., and this application embodiment does not specifically limit this.

[0027] The database server 20 mentioned above can also be a regular server or a virtual server, etc., and this application embodiment does not specifically limit it.

[0028] The internal processing procedures of the test device 10 and the database server 20 in the above system, as well as the interaction between the two, will be described in detail in the following embodiments.

[0029] Figure 2 This illustration shows a flowchart of a database performance test according to an embodiment of this application. The method is applicable to testing equipment, meaning the testing equipment is the executing entity of this method. The testing equipment can be a terminal or a server. The server can be a conventional server, a cloud server, or a virtual server, etc., and this embodiment does not specifically limit its application. Figure 2 As shown, the method includes:

[0030] 101. Request the database server to create database tables for performance testing within the database it is running.

[0031] 102. Set the logical relationships between the records in the database table.

[0032] 103. Send a transaction request for the database table to the database server so that the database server can execute the transaction corresponding to the transaction request.

[0033] The transaction request is generated based on the logical relationship.

[0034] 104. Based on the query results for the database table, determine whether the database table satisfies the logical relationship to obtain a first determination result.

[0035] 105. Based on the first determination result, determine whether the database satisfies the transaction characteristics.

[0036] In one example of the above 101, the testing equipment can determine the table structure information of the database table used for performance testing based on the performance test configuration file imported by the user; then, based on the table structure information, generate a database table creation request; and send the database table creation request to the database server. After receiving the database table creation request, the database server creates the database table used for performance testing in the database running on the database server, based on the table structure information of the database table used for performance testing carried in the database table creation request. The table structure information may include, but is not limited to, the table name, field names, field types, and indexes of the database table. Field types include: numeric types, string types, and date / time types. Numeric types can be further subdivided into integer, floating-point, and fixed-point types.

[0037] It should be noted that the database table in this application embodiment is a database table specifically used for performance testing.

[0038] In the above 102, the database table consists of three parts: table name, fields in the table, and records in the table. A row of data in the database table constitutes a record. Each record includes the values ​​of each field in the database table. The logical relationship includes the first logical relationship between fields within the same record in the database table.

[0039] The logical relationships involved in the embodiments of this application can specifically be functional relationships (or mapping relationships). The at least two fields involved in the functional relationship are the function variables in the function corresponding to the functional relationship.

[0040] A database transaction is a sequence of database operations that access and potentially manipulate various data items. These operations are either all executed or none are executed; it is an indivisible unit of work. A transaction consists of all database operations performed between its start and end. Database transactions can be categorized into write transactions, update transactions, delete transactions, and query transactions. Write transactions are used to insert new records into database tables; update transactions are used to modify existing records in database tables; delete transactions are used to delete existing records in database tables; and query transactions are used to perform query operations on database tables. As can be seen, write, update, and delete transactions all modify database tables and can be collectively referred to as modification transactions.

[0041] The database table includes multiple fields, and multiple field groups can be determined based on these multiple fields or multiple non-date / time type fields among them; each field group includes at least two fields. The aforementioned logical relationships may include: a first logical relationship between at least two fields contained in each of the multiple field groups within the same record in the database table. That is, the aforementioned logical relationships include multiple first logical relationships, each corresponding to a different field group. Specifically, the aforementioned non-date / time type fields may include numeric type fields and string type fields.

[0042] In practical applications, the first logical relationship between at least two fields in each of the above field groups can be set according to actual needs. Figure 3The table shown illustrates the first logical relationship between at least two fields in the same record. For example, the first logical relationship between field row_pk and field group_id is: group_id = row_pk / GROUP_ROW_NUM, where the size of GROUP_ROW_NUM can be set according to actual needs, and its size is used to determine the number of records involved in a transaction; another example is the first logical relationship between fields C1, C2, and C3: C3 = C1 + C2; yet another example is the first logical relationship between fields C5, row_pk, C1, C2, and C3: C5 = string(row_pk) + string(C1) + string(C2) + string(C3).

[0043] In step 103 above, a transaction request for the database table is generated based on the logical relationship. The transaction request may carry at least one statement. In this embodiment, each statement can be an SQL (Structured Query Language) statement, specifically, a DML (Data Manipulation Language) SQL statement. DML is a programming statement used for database operations, performing access operations on objects and data within the database.

[0044] The generated transaction request for the database table is sent to the database server. Upon receiving the transaction request, the database server determines the transaction corresponding to the transaction request and executes it. Specifically, the transaction request may include: a write transaction request, an update transaction request, a delete transaction request, and / or a query transaction request. The transaction corresponding to a write transaction request is a write transaction, the transaction corresponding to an update transaction request is an update transaction, the transaction corresponding to a delete transaction request is a delete transaction, and the transaction corresponding to a query transaction request is a query transaction.

[0045] In the above 104, the query result can be the query result for a record in a database table. Based on the query result for the record in the database table, it is determined whether the record in the database table satisfies the logical relationship, and a first determination result is obtained.

[0046] In step 105 above, if the first determination result shows that the database table does not satisfy the logical relationship, it is determined that the database does not satisfy the ACID properties of transactions.

[0047] If the first determination result shows that the database table satisfies the logical relationship, then the performance test of the database continues.

[0048] Database performance testing can end when it is determined that the database does not meet the ACID properties of transactions, when the test duration reaches a preset duration, or when the user triggers an end operation. This application does not make specific limitations on this.

[0049] In the technical solution provided in this application embodiment, a database table specifically for performance testing is created; and the logical relationships between records in the database table are configured; a transaction request is sent to the database server based on the logical relationships, so that the database server executes the corresponding transaction for the database table; then, based on the query results for the database table, it is determined whether the corresponding record in the database table satisfies the above logical relationships, thereby determining whether the database satisfies transaction characteristics. If the query finds that the corresponding record in the database table does not satisfy the above logical relationships, it indicates that the database has broken the database transaction characteristics; if the query finds that the corresponding record in the database table does not satisfy the above logical relationships, it indicates that the database maintains the database transaction characteristics. The verification scheme provided in this application embodiment has high reliability.

[0050] In one feasible implementation, the database table includes multiple fields; among these fields is a primary key field. The step 102 above, "setting the first logical relationship between fields in the same record of the database table," can be achieved through the following steps:

[0051] 1021. Determine the first field from the plurality of fields.

[0052] The first field is distinct from the primary key field.

[0053] 1022. Set a first functional relationship between the first field and the primary key field in the same record of the database table.

[0054] In the same record, the value of the first field is determined by the value of the primary key field and the first functional relationship; the first logical relationship includes the first functional relationship.

[0055] In practical applications, to facilitate subsequent queries, the test device can assign the corresponding primary key value to the record requested for each write transaction request based on the primary key auto-increment algorithm.

[0056] The number of the first field mentioned above can be multiple, and the specific number can be set according to actual needs. This application embodiment does not make a specific limitation on this. Figure 3 In the table shown, group_id, C1, C2, C3, C4, C5, and C9 are all the first field mentioned above. This is because group_id, C1, C2, C3, C4, C5, and C9 all have a direct or indirect relationship with the primary key row_pk. This direct or indirect relationship is also the first functional relationship mentioned above.

[0057] Considering that in practical applications, some databases may include fields of binary large object type (blob), and the database processing logic corresponding to different field types is different, in order to more comprehensively verify the transaction characteristics of the database, the multiple fields may also include: binary large object type fields. Accordingly, the "setting the first logical relationship between fields in the same record of the database table" in step 102 above can be implemented by the following steps:

[0058] 1023. Determine the third field from the plurality of fields.

[0059] The third field is distinct from both the primary key field and the first field.

[0060] 1024. Set a third function relationship between the third field and the binary large object type field in the same record of the database table.

[0061] In the same record, the value of the third field is determined by the value of the binary large object type field and the third functional relationship; the first logical relationship also includes the third functional relationship.

[0062] Figure 3 In the table shown, C7 is a binary large object type field, and C8 is the third field.

[0063] In addition, the above fields may also include date and time type fields. Figure 3 In the table shown, C6 is a date / time type field.

[0064] Considering that in practical applications, a single transaction often executes operations on multiple records, it is necessary not only to verify that the logical relationships within the same record are not broken, but also to verify that the logical relationships between multiple records executed by the same transaction are not broken. This is to more comprehensively verify the ACID properties of the entire database. Therefore, in practical applications, the aforementioned logical relationships may also include a second logical relationship between the fields in the database table and at least two records corresponding to the same transaction in the database table.

[0065] Optionally, step 102 above, "setting a second logical relationship between at least two records corresponding to the same transaction in the database table for a field in the database table," can be implemented using the following steps:

[0066] 1025. Determine at least one second field from the plurality of fields.

[0067] The second field is distinct from both the primary key field and the first field. The second field is also distinct from the third field. The number of at least one second field can be one or at least two.

[0068] 1026. Set a second functional relationship between at least one second field in the database table and at least two records corresponding to the same transaction in the database table.

[0069] The second logical relationship includes the second functional relationship.

[0070] In practical applications, multiple fields may also include a group field to identify the group to which the record belongs, for example: Figure 3 The table shown contains the `group_id` field. At least two records belonging to the same group are also at least two records belonging to the same transaction, or in other words, at least two records belonging to the same transaction have the same value in the `group` field.

[0071] To increase constraints and improve the accuracy of verification, in step 1026 above, a third functional relationship is set between at least two records corresponding to the same transaction in the database table for at least one second field. Specifically, this may include setting a second functional relationship between at least one second field and a group field in the database table for at least two records corresponding to the same transaction. For example: Figure 3 In the table shown, at least one second field includes S1, S2, and S3, and the group field includes group_id. The second function relationship is: ∑sum(S1+S2+S3)=group_id, where the summation symbol ∑ sums the sum(S1+S2+S3) of each record in the GROUP_ROW_NUM records corresponding to the same transaction in the database table. For example: Figure 3 In the table shown, at least one second field includes S4, S5, and S6, and the group field includes group_id. The second function relationship is: ∑sum(S4+S5+S6)=group_id*F1, where the summation symbol ∑ is the sum of sum(S4+S5+S6) for each record in the GROUP_ROW_NUM records corresponding to the same transaction in the database table. F1 is a floating-point number 65536 / 10000; S4=S1*F1, S5=S2*F1, S6=S3*F1.

[0072] The aforementioned "same transaction" can specifically refer to the same write transaction, which includes operations to write at least two records. It should be noted that setting the group field above facilitates subsequent determination of which records belong to the same write transaction. This allows for easier modification, deletion, or querying of at least two records corresponding to the same write transaction in the database table. At least two records corresponding to the same write transaction in the database table belong to the same group.

[0073] The following example illustrates how to generate transaction requests for database tables based on logical relationships.

[0074] To simplify the entire process, for write transaction requests, the number of records corresponding to each write transaction request (or each transaction) can be predetermined to be a preset number, for example: Figure 3 The table shown contains GROUP_ROW_NUM; and the primary key field value in each record of the database table is auto-incrementing. That is, the test device can determine the value of the primary key field of each record in the multiple records corresponding to the write transaction request based on the primary key auto-increment algorithm; and determine the values ​​of the first and second fields in the multiple records based on the values ​​of the primary key fields of each record, the aforementioned first functional relationship, the aforementioned second functional relationship, and the third functional relationship. Specifically, the value of the first field of each record in the multiple records can be determined based on the values ​​of the primary key fields of each record in the multiple records and the aforementioned first functional relationship; the value of the binary large object type field is randomly determined; the value of the third field is determined based on the values ​​of the binary large object type field and the second functional relationship; and the value of the second field of each record in the multiple records can be determined based on the values ​​of the primary key fields of each record in the multiple records and the aforementioned second functional relationship. Multiple write statements are generated based on the values ​​of the multiple fields included in each record in the multiple records; each write statement is used to write one record; and a write transaction request is generated based on the multiple write statements.

[0075] Continue Figure 3 The table shown indicates that write transaction requests may include:

[0076] INSERT IGNORE INTO table_name(row_pk,group_id,c1,c2,c3,c4,c5,c6,c7,c8,c9,s1,s2,s3,s4,s5,s6)VALUES(xxx,xxx,xxx,....);

[0077] If a set corresponds to 3 records, then the write transaction request includes 3 of the above write or insert statements.

[0078] For an update transaction request, a target update group is determined; according to the second functional relationship described above, the value of at least one second field of each record in at least two records in the target update group is randomly generated; wherein, the value of the at least one second field of each record in at least two records in the target update group and the value of the group field satisfy the second functional relationship described above.

[0079] Continue Figure 3 The table shown includes the following update transaction requests:

[0080] update table_name set s1=%d, s2=%d, s3=%d, s4=%f, s5=%f, s6=%f where row_pk=%d and group_id=%d;

[0081] If a set has 3 rows of records, the update transaction request includes 3 of the above update statements.

[0082] For delete transaction requests

[0083] DELETE FROM table_name WHERE group_id=%d

[0084] For query transaction requests, a query transaction request can be generated based on the first logical relation. (Continued) Figure 3 The table shown allows query transaction requests to include:

[0085] Query statement 1: select C1=row_pk%2&&C2=row_pk%3&&C3=C1+C2&&((C3&1&&C4=1)||(C3=(C3>>1)<<1&&C4=0))&&concat(row_pk,C1,C2,C3)=C5&&MD5(C7)=C8&&concat(row_pk)=C9 from consensus where row_pk=?

[0086] Note: This query uses the primary key index row_pk.

[0087] Query statement 2: select C1=row_pk%2&&C2=row_pk%3&&C3=C1+C2&&((C3&1&&C4=1)||(C3=(C3>>1)<<1&&C4=0))&&concat(row_pk,C1,C2,C3)=C5&&MD5(C7)=C8&&concat(row_pk)=C9 from consensus where C5=?

[0088] Note: This query uses the secondary index C5.

[0089] Query statement 3: `select C1=row_pk%2&&C2=row_pk%3&&C3=C1+C2&&((C3&1&&C4=1)||(C3=(C3>>1)<<1&&C4=0))&&concat(row_pk,C1,C2,C3)=C5&&MD5(C7)=C8&&concat(row_pk)=C9 from consensus where C1=? AND C2=?`

[0090] Note: This query uses a combined secondary index of C1 and C2.

[0091] Query statement 4: Select SUM(S1+S2+S3)=group_id from consensus where group_id=?

[0092] Query statement 5: select SUM(S4+S5+S6)=group_id*65536 / 10000 from consensus where group_id=?

[0093] The above query statements 4 and 5 are used to query whether (S1, S2, S3, group_id) and (S4, S5, S6, group_id) within the same group_id satisfy the above first functional relationship.

[0094] A query transaction request may include one or more of the query statements 1 to 5 described above; the embodiments in this application are not specifically limited. The value at the above symbol ? can be randomly determined based on the records in the current database table.

[0095] In practical applications, the database processes different query indexes differently. To perform more comprehensive and effective database verification, multiple query transaction requests can be generated based on different query indexes and the aforementioned logical relationships. These multiple query transaction requests are then sent to the database server.

[0096] Furthermore, the processing logic for different data types differs within the database. Therefore, step 101 above, "requesting the database server to create database tables for performance testing within its running database," can be implemented using the following steps:

[0097] 1011. Determine the data types supported by the database running on the database server.

[0098] 1012. Based on the data types supported by the database running on the database server, generate the table structure information of the database tables used for performance testing.

[0099] The database table includes fields corresponding to the data types supported by the database;

[0100] 1013. Send the table structure information to the database server so that the database server can create the database table based on the table structure information.

[0101] In the above 1011, all data types supported by the database running on the database server can be determined.

[0102] In 1012 above, the database table includes fields corresponding to all data types supported by the database.

[0103] In step 1013 above, a creation request can be generated based on table structure information. The creation request includes a creation statement, following the... Figure 3 The table shown has the following creation statement:

[0104] CREATE TABLE `consensus_001`(

[0105] row_pk int comment'primary key, auto-incrementing',

[0106] group_id int comment'row_pk / GROUP_ROW_NUM',

[0107] c1 int comment'row_pk%2',

[0108] c2 int comment'row_pk%3',

[0109] c3 int comment'c1+c2',

[0110] c4 int comment'If C3 is even, then NULL; if it is odd, then 1',

[0111] c5 varchar(100)comment'string(row_pk)+string(C1)+string(C2)+string(C3)',

[0112] c6 datetime,

[0113] c7 blob comment'As long as possible',

[0114] c8 char(100)comment'C7's checksum',

[0115] c9 char(100)comment'string(row_pk)',

[0116] s1 int comment'Within the same group, multiple rows ∑sum(S1+S2+S3)=group_id',

[0117] s2 int comment'Within the same group, multiple rows ∑sum(S1+S2+S3)=group_id',

[0118] s3 int comment'Within the same group, multiple rows ∑sum(S1+S2+S3)=group_id',

[0119] s4 decimal(16,4)comment'S4=S1*65536 / 10000, within the same group, multiple lines ∑sum(S4+S5+S6)=group_id*65536 / 10000',

[0120] s5 decimal(16,4) comment'S5=S2*65536 / 10000, within the same group, multiple rows ∑sum(S4+S5+S6)=group_id*65536 / 10000',

[0121] s6 decimal(16,4) comment'S6=S3*65536 / 10000, within the same group, multiple rows ∑sum(S4+S5+S6)=group_id*65536 / 10000',

[0122] PRIMARY KEY(`row_pk`),

[0123] KEY`idx_group`(`group_id`),

[0124] KEY`idx_c5`(`c5`),

[0125] KEY`idx_c6`(`c6`),

[0126] KEY`idx_c9`(`c9`),

[0127] KEY`idx_c1_c2`(`c1`, `c2`) )

[0129] In practical applications, when developing a new database engine, the most important task is to verify whether the database's ACID properties are broken under different extreme scenarios. For example, simultaneously applying pressure to the database and simulating network failures, will transactions fail to roll back as expected under pressure or network failures, resulting in dirty data? Or, when we make changes to the database, will concurrent read and write operations read incorrect versions of data? If these problems occur, the database definitely has fatal flaws. Therefore, this solution can be integrated with stress testing, network failure simulation, and other methods.

[0130] In one example, the step 103 above, "sending a transaction request for the database table to the database server," can be achieved using the following steps:

[0131] 1031. Determine the stress testing strategy for the database.

[0132] 1032. In accordance with the stress test strategy, send a transaction request for the database table to the database server.

[0133] The testing equipment can acquire user-inputted stress test tasks and determine stress test strategies based on these tasks. Stress test strategies may include, but are not limited to, request concurrency, the proportion of each type of transaction request, time intervals, and stress test duration. Specifically, the request concurrency is Q; the proportion of write transaction requests is a%, the proportion of update transaction requests is b%, the proportion of delete transaction requests is c%, and the proportion of query transaction requests is d%, where a+b+c+d=100; the time interval is t; and the stress test duration is T.

[0134] Based on the stress test strategy and logical relationships, multiple concurrent transaction requests can be generated and sent concurrently to the database server.

[0135] For example: the above request concurrency is 100; the proportion of write transaction requests is 40%, update transaction requests are 5%, delete transaction requests are 5%, and query transaction requests are 50%; the preset time interval is 1 minute, and the stress test time is 2 hours. The test device can generate 100 concurrent transaction requests at the first moment and send these 100 transaction requests concurrently to the database server; these 100 transaction requests are all generated according to logical relationships; among these 100 transaction requests, there are 40 write transaction requests, 5 update transaction requests, 5 delete transaction requests, and 50 query transaction requests. If the query results of the query transaction requests do not determine that the database does not meet the transaction characteristics and the stress test time has not yet reached 2 hours, then 1 minute after the first moment, another 100 concurrent transaction requests will be generated and sent concurrently to the database server.

[0136] In practical applications, database rollback operations frequently occur for various reasons. Therefore, it is necessary to verify whether the database still maintains its transactional characteristics under various rollback operations. Specifically, the above methods may also include:

[0137] 106. According to the first preset ratio, the multiple transaction requests are divided into a first group of transaction requests and a second group of transaction requests.

[0138] 107. For each transaction request in the first group of transaction requests, send a commit request to the database server so that the database server can perform the corresponding commit operation.

[0139] 108. For each transaction request in the second group of transaction requests, send a rollback request to the database server so that the database server can perform the corresponding rollback operation.

[0140] Among them, there are multiple transaction requests, and multiple transaction requests can be concurrent transaction requests.

[0141] In the above 106, the size of the first preset ratio can be determined according to actual needs, and the embodiments of this application do not specifically limit it.

[0142] In the above 107, the first group of transaction requests includes a first transaction request. For the first transaction request, a commit request is sent to the database server. After receiving the commit request, the database server executes the commit operation of the transaction corresponding to the first transaction request.

[0143] In the above 108, the second group of transaction requests includes a second transaction request. For the second transaction request, a rollback request is sent to the database server. After receiving the rollback request, the database server executes the rollback operation of the transaction corresponding to the second transaction request.

[0144] Optionally, the above method may also include:

[0145] 109. Based on the second preset ratio, determine at least one target transaction request from the plurality of transaction requests.

[0146] 110. Before the target transaction request is sent to the database server, a query statement is added to the target transaction request.

[0147] 111. Based on the query result of the query statement, determine whether the modification result of the transaction corresponding to the target transaction request on the database is visible to the transaction corresponding to the target transaction request.

[0148] When the database server executes the transaction corresponding to the target transaction request, the execution order of the multiple statements originally contained in the target transaction request takes precedence over the aforementioned query statements. If the query result shows that the database table satisfies the logical relationship or the query result itself satisfies the logical relationship, it is determined that the modification results of the transaction corresponding to the target transaction request on the database are visible to the transaction corresponding to the target transaction request; if the query result shows that the database table does not satisfy the logical relationship or the query result itself does not satisfy the logical relationship, it is indicated that the modification results of the transaction corresponding to the target transaction request on the database are not visible to the transaction corresponding to the target transaction request.

[0149] In practical applications, the database must ensure that modifications made to the database by uncommitted transactions are not visible to other transactions, i.e., transaction isolation; however, the database must also ensure that modifications made by uncommitted transactions are visible to the current transaction. If modifications made to a database table by an uncommitted transaction are not visible to the current transaction, it indicates a serious database problem, requiring testing to be paused, the cause investigated, and improvements implemented.

[0150] In one feasible solution, the transaction request is multiple; the multiple transaction requests include modification transaction requests and query transaction requests; "determining whether the database table satisfies the logical relationship based on the query results for the database table" in step 104 above includes:

[0151] 1041. Based on the query results corresponding to the query transaction request, determine whether the database table satisfies the logical relationship.

[0152] Since transaction query requests are generated based on logical relationships, the query statement within a transaction query request can specifically be a query conditional statement. This conditional statement contains the first logical relationship and / or the second logical relationship mentioned above, and its query result is either yes or no. When the query result is no, it is determined that the database table does not satisfy the logical relationship. When the query result is yes, it is determined that the database table satisfies the logical relationship.

[0153] In another feasible solution, the phrase "determining whether the database table satisfies the logical relationship based on the query results for the database table" in step 104 above includes:

[0154] 1041. Generate a query transaction request for the database table.

[0155] 1042. Send the query transaction request to the database server so that the database server can perform a query operation to obtain the query result of the query transaction request.

[0156] 1043. Determine whether the query result of the query transaction request returned by the database server satisfies the logical relationship.

[0157] 1044. If the query result of the query transaction request does not satisfy the logical relationship, it is determined that the database table does not satisfy the logical relationship.

[0158] In this embodiment, the query transaction request is used to obtain the values ​​of fields in the target query record in the database table. Thus, the testing device can determine whether the query result satisfies the aforementioned logical relationship based on the values ​​of the fields in the target query record. If the query result of the query transaction request does not satisfy the logical relationship, it is determined that the database table does not satisfy the logical relationship.

[0159] Optionally, "sending a transaction request for the database table to the database server" in step 103 above may include:

[0160] 112. Determine the network fault simulation strategy.

[0161] 113. In accordance with the network failure simulation strategy, send a transaction request for the database table to the database server.

[0162] The aforementioned network fault simulation strategy may include fault intervals, fault durations, and simulation parameters corresponding to various types of network faults; among them, at least two types may include network latency type and / or network packet loss type; the simulation parameters corresponding to network latency type network faults may include preset latency durations; the simulation parameters corresponding to network packet loss type network faults may include preset packet loss rates.

[0163] Multiple transaction requests targeting database tables can be generated based on logical relationships. In one instance, multiple transaction requests can be delayed according to a preset delay duration. Specifically, when the preset delay duration is reached, multiple transaction requests are sent to the database server. In another instance, multiple transaction requests can be processed for packet loss according to a preset packet loss rate, and the remaining transaction requests are sent to the database server. For example, if the number of multiple transaction requests is 100 and the preset packet loss rate is 20%, then 20 transaction requests will be deleted from the 100 transaction requests, and the remaining 80 transaction requests will be sent to the database server.

[0164] In practical applications, the stress testing strategy and network fault management strategy described above can be used simultaneously. Specifically, multiple concurrent transaction requests can be generated according to the stress testing strategy and logical relationships; according to the network fault management strategy, multiple transaction requests can be delayed or have packets dropped.

[0165] In addition, to verify the effectiveness of the verification scheme provided in the embodiments of this application, the following experiments can be conducted based on Sysbench:

[0166] Multiple records can be generated in the database table beforehand based on the above logical relationships. After starting the stress test, exceptions can be manually simulated.

[0167] 1. There is a problem simulating the same row of data:

[0168] Continue Figure 3 The table shown shows that the value of C3 in the records where the primary key field value is 1 in the database table was manually modified to an incorrect value, making it impossible to satisfy c3 = c1 + c2.

[0169] Subsequently, the system reported the error: ERROR: table->consensus_1pk-->1 not consensus!!, and the program exited.

[0170] 2. Simulate data errors between multiple rows

[0171] Continue Figure 3 The table shown shows that the value of s3 in a row of records where the value of the group field in the database table is 0 was manually modified to an incorrect value, so that the ∑sum(s1+s1+s3)==group_id under the same group_id cannot be satisfied.

[0172] Subsequently, the system reported the error: ERROR: table->consensus_1group-->0 not consensus!!, and the program exited.

[0173] Based on the experimental results, it can be confirmed that the verification scheme provided in this application embodiment is effective. After confirming the effectiveness of the verification scheme, formal stress testing and ACID verification will be performed on the database.

[0174] In summary, the stress generation algorithm for automatically verifying database ACID properties provided in this application embodiment can promptly identify database ACID issues during database stress testing. Furthermore, the stress in the verification scheme provided in this application embodiment can be used in conjunction with various extreme database stress tests and fault simulation stress, greatly aiding in verifying database correctness and stability. In general, the testing scheme provided in this application embodiment can achieve ACID verification while performing stress testing, thus providing a better assessment of the database's support for transaction ACID.

[0175] Figure 4 A schematic diagram of the structure of an electronic device according to an embodiment of this application is shown. Figure 4 As shown, the electronic device includes a memory 1101 and a processor 1102. The memory 1101 can be configured to store various other data to support operation on the electronic device. Examples of such data include instructions for any application or method used to operate on the electronic device. The memory 1101 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0176] The memory 1101 is used to store programs;

[0177] The processor 1102 is coupled to the memory 1101 and is used to execute the program stored in the memory 1101 to implement the database performance testing method provided in the above-described method embodiments.

[0178] Furthermore, such as Figure 4 As shown, the electronic device also includes: communication component 1103, display 1104, power supply component 1105, audio component 1106, and other components. Figure 4 The diagram only shows some components and does not mean that the electronic device includes only these components. Figure 4 The components shown.

[0179] Accordingly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a computer, can implement the steps or functions of the database performance testing methods provided in the above-described method embodiments.

[0180] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0181] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0182] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A database performance testing method, suitable for testing equipment, wherein, include: Request the database server to create database tables for performance testing within the database it is running; Establish logical relationships between records in the database table, wherein the logical relationships include a first logical relationship between fields in the same record in the database table and a second logical relationship between at least two records corresponding to the same transaction in the database table; A transaction request for the database table is sent to the database server so that the database server can execute the transaction corresponding to the transaction request, wherein the transaction request is generated based on the logical relationship; Based on the query results for the database table, determine whether the database table satisfies the logical relationship to obtain a first determination result; Based on the first determination result, determine whether the database satisfies the transaction characteristics.

2. The method according to claim 1, wherein, The second logical relationship includes the logical relationship between at least two records in the database table corresponding to the same transaction.

3. The method according to claim 2, wherein, The database table includes multiple fields; among these fields is a primary key field. Setting the first logical relationship between fields in the same record of the database table includes: A first field is determined from the plurality of fields; the first field is distinct from the primary key field; Set a first functional relationship between the first field and the primary key field in the same record of the database table; In the same record, the value of the first field is determined by the value of the primary key field and the first functional relationship; the first logical relationship includes the first functional relationship.

4. The method according to claim 3, wherein, Setting a second logical relationship between at least two records in the same transaction of the database table for a field in the database table includes: At least one second field is determined from the plurality of fields; the second field is distinct from the primary key field and the first field; Set a second functional relationship between at least two records corresponding to the same transaction in the database table, based on at least one second field of the database table; The second logical relationship includes the second functional relationship.

5. The method according to any one of claims 1 to 4, wherein, Sending a transaction request for the database table to the database server includes: Determine the stress testing strategy for the database; According to the stress testing strategy, a transaction request for the database table is sent to the database server.

6. The method according to any one of claims 1 to 4, wherein, The transaction request is multiple; According to a first preset ratio, the multiple transaction requests are divided into a first group of transaction requests and a second group of transaction requests; For each transaction request in the first group of transaction requests, a commit request is sent to the database server so that the database server can perform the corresponding commit operation; For each transaction request in the second group of transaction requests, a rollback request is sent to the database server so that the database server can perform the corresponding rollback operation.

7. The method according to claim 6, wherein, Based on the second preset ratio, at least one target transaction request is determined from the plurality of transaction requests; Before sending the target transaction request to the database server, add a query statement to the target transaction request; Based on the query results of the query statement, determine whether the modification results of the target transaction request corresponding to the database are visible to the transaction corresponding to the target transaction request.

8. The method according to any one of claims 1 to 4, wherein, The transaction request may be multiple; the multiple transaction requests include modification transaction requests and query transaction requests. Based on the query results for the database table, determine whether the database table satisfies the logical relationship, including: Based on the query results corresponding to the query transaction request, determine whether the database table satisfies the logical relationship.

9. The method according to any one of claims 1 to 4, wherein, Based on the query results for the database table, determine whether the database table satisfies the logical relationship, including: Generate a query transaction request for the database table; The query transaction request is sent to the database server so that the database server can perform a query operation to obtain the query result of the query transaction request; Determine whether the query result of the query transaction request returned by the database server satisfies the logical relationship; If the query result of the query transaction request does not satisfy the logical relationship, it is determined that the database table does not satisfy the logical relationship.

10. The method according to any one of claims 1 to 4, wherein, Sending a transaction request for the database table to the database server includes: Determine the network failure simulation strategy; According to the network failure simulation strategy, a transaction request for the database table is sent to the database server.

11. The method according to any one of claims 1 to 4, wherein, Request the database server to create database tables for performance testing within the database it is running, including: Determine the data types supported by the database running on the database server; Based on the data types supported by the database running on the database server, generate the table structure information of the database tables used for performance testing; wherein, the database tables include fields corresponding to the data types supported by the database; The table structure information is sent to the database server so that the database server can create the database table based on the table structure information.

12. The method according to any one of claims 1 to 4, wherein, Also includes: If it is determined that the database does not meet the transaction characteristics, the test for the database shall be stopped.

13. An electronic device, wherein, include: Memory and processor, among which, The memory is used to store programs; The processor, coupled to the memory, is used to execute the program stored in the memory to implement the database performance testing method according to any one of claims 1 to 12.

14. A computer-readable storage medium storing a computer program, wherein, When the computer program is executed by a computer, it can implement the database performance testing method according to any one of claims 1 to 12.

Images