CN115129589B - A database testing method and device - Google Patents

Abstract

The present specification discloses a method and device for testing a database, which can determine the number of partition keys required to generate distributed transactions according to the number of distributed transactions across data storage nodes expected to be generated, so as to generate distributed transactions that meet the expected number of distributed transactions across data storage nodes to be generated, and then the efficiency of the database in processing distributed transactions can be effectively tested by generating distributed transactions that meet the test requirements.

Description

A database testing method and device

Technical Field

The present invention relates to the field of computer technology, and in particular to a method and device for testing a database.

Background Art

With the development of computer technology, the amount of data that databases need to store is also increasing, and stand-alone databases often cannot accommodate this surge in data. Therefore, various business platforms often split data tables into partitioned tables to store them in multiple physical nodes, and then use this distributed database to store these growing data. However, since each physical node usually only stores a part of the data, when users need to operate on the data, they may access multiple nodes, thereby generating distributed transactions. The processing of distributed transactions has a greater impact on the performance of distributed databases. Therefore, the processing efficiency of distributed databases on distributed transactions is a key point in evaluating databases.

At present, the test effect of the commonly used distributed database evaluation method is poor and cannot effectively test the processing efficiency of the distributed database for distributed transactions.

Therefore, how to effectively test the efficiency of distributed databases in processing distributed transactions is an urgent problem to be solved.

Summary of the invention

The present specification provides a database testing method and device to solve the problem in the prior art that the efficiency of a distributed database in processing distributed transactions cannot be effectively tested.

This manual adopts the following technical solutions:

This specification provides a database testing method, including:

Acquire test parameters required for testing a distributed database, the test parameters including: the number and expected number of data storage nodes corresponding to the distributed database, the expected number being used to indicate the number of distributed transactions across data storage nodes that are expected to be generated;

Determine, according to the test parameters, the number of partition keys required for the distributed transaction under the condition that the number of data storage nodes actually spanned by the generated distributed transaction meets the expected number;

Generate a distributed transaction according to the number of partition keys;

The distributed database is tested according to the distributed transaction.

Optionally, obtain test parameters required for testing the distributed database, including:

Get the configuration file sent by the client used by the user;

According to the configuration file, test parameters required for testing the distributed database are determined.

Optionally, according to the test parameters, determining the number of partition keys required for the distributed transaction under the condition that the number of data storage nodes actually spanned by the generated distributed transaction meets the expected number specifically includes:

According to the test parameters and the predetermined data association relationship, the number of partition keys required for the distributed transaction is determined under the condition that the number of data storage nodes actually crossed by the generated distributed transaction meets the expected number. The data association relationship is used to represent the association between the number of data storage nodes corresponding to the distributed database, the expected number, and the number of partition keys required for the distributed transaction.

Optionally, determining the data association relationship specifically includes:

For each data storage node corresponding to the distributed database, determining the probability that the data storage node stores data required for the distributed transaction execution;

The data association relationship is determined according to the probability that each data storage node contains data required for the distributed transaction execution.

Optionally, generating a distributed transaction according to the number of partition keys specifically includes:

Selecting the number of partition keys from the partition keys included in each data partition of the distributed database;

A distributed transaction is generated according to the partition keys of the selected number of partition keys.

Optionally, generating a distributed transaction according to the selected number of partition keys specifically includes:

The placeholders of the partition keys required for transaction execution reserved in the preset transaction template are modified to the selected number of partition keys to generate a distributed transaction.

Optionally, testing the distributed database according to the distributed transaction specifically includes:

According to a preset load balancing distribution strategy, the generated distributed transaction is distributed to at least part of the data storage nodes to test the distributed database.

Optionally, before generating a distributed transaction according to the number of partition keys, the method further includes:

Obtaining an expected distributed transaction ratio input by a user, where the expected distributed transaction ratio is used to indicate the ratio of the generated distributed transactions to all generated transactions;

According to the number of partition keys, a distributed transaction is generated, specifically including:

A distributed transaction is generated according to the expected distributed transaction ratio and the number of partition keys.

This specification provides a database testing device, including:

An acquisition module is used to acquire test parameters required for testing a distributed database, wherein the test parameters include: the number and expected number of data storage nodes corresponding to the distributed database, wherein the expected number is used to indicate the number of distributed transactions across data storage nodes that are expected to be generated;

A determination module, configured to determine, based on the test parameters, the number of partition keys required for a distributed transaction under the condition that the number of data storage nodes actually spanned by the generated distributed transaction meets the expected number;

A generation module, used for generating a distributed transaction according to the number of partition keys;

A testing module is used to test the distributed database according to the distributed transaction.

This specification provides a computer-readable storage medium, wherein the storage medium stores a computer program, and when the computer program is executed by a processor, the above-mentioned database testing method is implemented.

This specification provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the above-mentioned database testing method when executing the program.

At least one of the above technical solutions adopted in this specification can achieve the following beneficial effects:

In the database testing method provided in the present specification, the test parameters required for testing the database are first obtained, wherein the test parameters include: the number of physical nodes storing data corresponding to each data partition in the database, the expected number of physical nodes across each distributed transaction, and the number of partition keys required for generating distributed transactions are determined based on the test parameters and a predetermined data association relationship, wherein the data association relationship is used to represent the association between the number of physical nodes storing data corresponding to each data partition in the database, the expected number of physical nodes across each distributed transaction, and the number of partition keys required for generating distributed transactions, and a distributed transaction is generated based on the number of partition keys, and the database is tested based on the distributed transaction.

It can be seen from the above method that the number of partition keys required to generate distributed transactions can be determined based on the expected number of distributed transactions across data storage nodes to generate distributed transactions that meet the expected number of distributed transactions across data storage nodes. Furthermore, the efficiency of the database in processing distributed transactions can be effectively tested by generating distributed transactions that meet the test requirements.

BRIEF DESCRIPTION OF THE DRAWINGS

The drawings described herein are used to provide a further understanding of this specification and constitute a part of this specification. The exemplary embodiments and descriptions of this specification are used to explain this specification and do not constitute an improper limitation on this specification.

In the figure:

FIG1 is a schematic diagram of a flow chart of a database testing method provided in this specification;

FIG2 is a schematic diagram of a transaction template provided in this specification;

FIG3 is a schematic diagram of a process for testing a database provided in this specification;

FIG4 is a schematic diagram of a database testing device provided in this specification;

FIG. 5 is a schematic diagram of an electronic device provided in this specification corresponding to FIG. 1 .

DETAILED DESCRIPTION

In order to make the purpose, technical solutions and advantages of this specification more clear, the technical solutions of this specification will be clearly and completely described below in combination with the specific embodiments of this specification and the corresponding drawings. Obviously, the described embodiments are only part of the embodiments of this specification, not all of them. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this specification.

The technical solutions provided by the embodiments of this specification are described in detail below in conjunction with the accompanying drawings.

FIG1 is a flow chart of a database testing method provided in this specification, comprising the following steps:

S100: Acquire test parameters required for testing a distributed database, wherein the test parameters include: the number of data storage nodes corresponding to the distributed database and an expected number, wherein the expected number is used to indicate the number of distributed transactions across data storage nodes that are expected to be generated.

During the operation of a distributed database, the more physical nodes a distributed database needs to execute distributed transactions, the greater the impact on the performance of the distributed database. Therefore, it is particularly important to test the efficiency of a distributed database in processing distributed transactions across different numbers of data storage nodes.

Based on this, in this specification, the server can test the distributed database based on the test requirements, and before that, the business platform can obtain the test parameters input by the tester, and then test the distributed database according to the test parameters. Among them, the test parameters may include: the number of each data storage node corresponding to the distributed database, and the expected number, where each data storage node corresponding to the distributed database refers to the physical node storing the data contained in at least part of the data partition in the distributed database, and the expected data here refers to the expected number of data storage nodes across each distributed transaction.

Furthermore, in order to facilitate the storage and management of various test parameters, users can also write the test parameters required for testing the distributed database into the configuration file, and send the configuration text to the business platform through the client used by the user provided by the business platform, so that the business platform can obtain the test parameters required for testing the distributed database according to the configuration file.

In this specification, the execution entity used to implement the database testing method may refer to a designated device such as a server set up on a business platform, or may refer to a terminal device such as a desktop computer or a laptop computer. For the sake of ease of description, the database testing method provided in this specification is described below using the server as the execution entity as an example.

In combination with the above content, the server can obtain the test parameters required for testing the distributed database after monitoring the tester entering the test parameters in the terminal device or the client installed on the terminal device, and then test the distributed database according to the test parameters to obtain the test results.

S102: Determine, according to the test parameters, the number of partition keys required for the distributed transaction under the condition that the number of data storage nodes actually crossed by the generated distributed transaction meets the expected number.

After obtaining the test parameters required for testing the distributed database, the server can create a stress testing thread and, through the stress testing thread, determine the number of partition keys required for the distributed transaction based on the test parameters and the pre-determined data association relationship, under the condition that the number of data storage nodes actually spanned by the generated distributed transaction meets the expected number. The data association relationship here is used to represent the association between the number of data storage nodes corresponding to the distributed database, the expected number, and the number of partition keys required for the distributed transaction.

Among them, the partition key refers to the key based on which the database partition is based. For example, there is a student table in a certain database. The student table has three attributes: student number, name, and class. The student table stores information of six students with student numbers 1, 2, 3, 4, 5, and 6. The student number can be used as the partition key to divide the information of these six students into three data partitions, that is, the information of students with student numbers 1 and 2 is in data partition one, the information of students with student numbers 3 and 4 is in data partition two, and the information of students with student numbers 5 and 6 is in data partition three. Different data partitions can be stored in different data storage nodes. For example, data partitions one and three are stored in data storage node one, and data partition two is stored in data storage node two.

From the above content, it can be seen that the table containing the data involved in the transaction generated for testing the distributed database is partially stored in the data storage nodes that need to participate in the distributed database test. The specific distribution method can also be an equal distribution method. For example: data partition one in the above content is stored in data storage node one, data partition two is stored in data storage node two, and data partition three is stored in data storage node three.

Therefore, the number of data storage nodes that are crossed when a distributed transaction is executed can be controlled by controlling the number of partition keys. For example, when the generated distributed transaction is to query the information of students with student numbers 1 and 3, the execution of the distributed transaction will involve data partition one and data partition two. Therefore, the execution of the distributed transaction will need to cross two data storage nodes, one and two.

In the above content, the method for determining the association relationship of data can be to determine the probability that each data storage node corresponding to the distributed database contains the data required for the execution of the distributed transaction, and determine the association relationship between the number of partition keys required for generating the distributed transaction, the expected number, and the number of data storage nodes corresponding to the distributed database according to the probability that each data storage node contains the data required for the execution of the distributed transaction. For details, refer to the following formula:

In the above formula, P( _xi = 0) refers to the probability that, for any data storage node i, the data storage node does not contain the data required for the execution of distributed transactions, m refers to the number of data storage nodes corresponding to the distributed database, n refers to the number of partition keys required to generate distributed transactions, and P( _xi = 1) refers to the probability that, for any data storage node i, the data storage node contains the data required for the execution of distributed transactions.

It can be seen from the above formula that when the number of partition keys required to generate a distributed transaction is 1, it means that only one data storage node has the data required for the distributed transaction execution. At this time, for any data storage node, the probability that the data storage node does not contain the data required for the distributed transaction execution is Therefore, when the number of partition keys required to generate a distributed transaction is n, for any data storage node, the probability that the data storage node does not contain the data required for the distributed transaction execution is It can be further known that the probability that the data storage node does not contain the data required for the execution of distributed transactions is

Furthermore, if the expected number is k, let the random variable represents the number of actual cross-data storage nodes for distributed transactions involving n partition keys, and _xi is an independent and identically distributed random variable that satisfies For details, please refer to the following formula:

In the above formula, It refers to the number of distributed transactions across data storage nodes that are expected to be generated. Based on this, we can deduce the relationship between the number n of partition keys required to generate distributed transactions, the number m of data storage nodes, and the expected number k. For details, please refer to the following formula.

It can be seen from the above formula that when the number m of each data storage node corresponding to the distributed database is known, the number n of partition keys required to generate a distributed transaction can be determined according to the expected number k.

S104: Generate a distributed transaction according to the number of partition keys.

S106: Testing the distributed database according to the distributed transaction.

In this specification, the server can select the number of partition keys required for generating distributed transactions determined in the above content from the partition keys contained in each data partition of the distributed database according to the number of partition keys required for the distributed transaction, and generate a distributed transaction based on the selected partition keys. In addition, the number of cross-data storage nodes of the generated distributed transaction is the expected number in the test parameters, and the distributed database can be tested through the generated distributed transactions.

There are many methods for selecting partition keys from each data partition of a distributed database. For example, according to the number of partition keys required to generate distributed transactions, a number of partition keys are selected by simple random sampling, systematic sampling, etc.

In the above content, according to the selected partition key, the method of generating a distributed transaction can be to modify the placeholder of the partition key required for transaction execution reserved in the preset transaction template to each partition key determined by the above method. For example: if the transaction template is to query the information of the student with student number i, and the partition keys determined by the above method are student numbers 1 and 4, then the student number i in the transaction template can be rewritten to query the information of students with student numbers 1 and 4, so that a distributed transaction is generated, as shown in Figure 2.

FIG. 2 is a schematic diagram of a transaction template provided in this specification.

In FIG2 , “?” is the placeholder mentioned in the above content, and “SELECT * FROM commodity WHERE s_i_id＝?” means to query all the information of the commodity whose partition key is filled in the placeholder with the commodity number (i.e., “s_i_id”) from the table named “commodity”. Assuming that the partition key selected by the above content is “10011”, that is, it is necessary to query all the information of the commodity with the commodity number 10011, then a transaction can be generated according to the transaction template here, that is, the partition key “10011” is inserted into the placeholder preset by the transaction template, that is, “SELECT * FROM commodity WHERE s_i_id＝10011”, so that the data storage node executing the transaction can query all the information of the commodity with the commodity number “10011”.

In the above content, the server can distribute the generated distributed transactions to at least part of the data storage nodes according to a preset load balancing distribution strategy, and execute the generated distributed transactions through these data storage nodes to test the distributed database, wherein the load balancing distribution strategy can be to distribute transactions according to a variety of algorithms, such as: polling algorithm, etc.

Furthermore, from the above content, it can be seen that since the number of partition keys required to generate a distributed transaction is determined based on the data association relationship obtained based on mathematical expectation, the actual number of cross-data storage nodes of the distributed transaction actually generated may be somewhat different from the expected number in the test parameters. Therefore, the server can also save and display the actual number of cross-data storage nodes of the distributed transaction during the execution process for each distributed transaction generated for developers to review.

In addition, the efficiency of a distributed database in processing transaction sets containing different proportions of distributed transactions is also different. For example, the efficiency of a distributed database in processing a transaction set containing 10% distributed transactions is only 50% of that of executing a transaction set that does not contain distributed transactions.

Based on this, in this specification, before generating distributed transactions according to the number of partition keys, the server can also obtain the expected distributed transaction ratio input by the user (the expected distributed transaction ratio is used to determine the proportion of distributed transactions included in the generated transaction set to all transactions), and generate a preset number of distributed transactions based on the expected distributed transaction ratio.

In the above content, the server can generate a transaction set according to the obtained expected distributed transaction ratio, in which the transaction set includes several local transactions and several distributed transactions, wherein the proportion of distributed transactions in all transactions included in the transaction set is the expected distributed transaction ratio.

From the above content, it can be seen that the server can generate a preset number of transactions according to the expected distributed transaction ratio input by the user, and among these transactions, the proportion of distributed transactions to all generated transactions is close to the proportion of expected distributed transactions, thereby testing the efficiency of the distributed database in processing transaction sets containing distributed transactions of different proportions.

It should be noted that in the above content, the user can write the expected distributed transaction ratio and the number and expected number of data storage nodes corresponding to the distributed database in a configuration file to send it to the server, or send the expected distributed transaction ratio to the server alone so that the server generates distributed transactions according to the expected distributed transaction ratio.

In order to further illustrate the above content, the process of controlling the distributed transaction ratio to test the distributed database is described in detail below with reference to FIG. 3 .

FIG. 3 is a schematic diagram of a process for testing a database provided in this specification.

As can be seen from FIG3 , after receiving the test instruction, the server can create a stress testing thread and read the configuration file through the stress testing thread to obtain various test parameters.

In Figure 3, the server can calculate the number of partition keys required for distributed transactions according to the configuration file through the transaction generation module, and then determine the type of each generated transaction according to the expected distributed transaction ratio. If a distributed transaction needs to be generated, partition key extraction can be performed to obtain the partition keys required to generate the distributed transaction, and a distributed transaction can be generated according to a preset transaction template. If a local transaction needs to be generated, a local transaction can be directly generated according to the preset transaction template.

Furthermore, in FIG3 , after the server generates distributed transactions and local transactions for testing the distributed database, it can distribute the generated transactions to the various data storage nodes of the distributed database for execution according to the preset load balancing distribution strategy, and collect statistics, and then display the statistical information to the developers, wherein the statistical information here can be the actual number of cross-data storage nodes when the distributed transactions are executed during the testing of the distributed database and the actual proportion of distributed transactions in the transaction set.

From the above content, it can be seen that the server can control the proportion of distributed transactions in the transaction set generated for testing the distributed database and the number of cross-data storage nodes for each distributed transaction based on the obtained test parameters. Therefore, the efficiency of the distributed database in processing distributed transactions can be effectively tested.

The above is a database testing method provided in one or more embodiments of this specification. Based on the same idea, this specification also provides a corresponding database testing device, as shown in FIG4 .

FIG4 is a schematic diagram of a database testing device provided in this specification, comprising:

An acquisition module 401 is used to acquire test parameters required for testing a distributed database, wherein the test parameters include: the number and expected number of data storage nodes corresponding to the distributed database, wherein the expected number is used to indicate the number of distributed transactions across data storage nodes that are expected to be generated;

A determination module 402 is used to determine, based on the test parameters, the number of partition keys required for the distributed transaction under the condition that the number of data storage nodes actually spanned by the generated distributed transaction meets the expected number;

A generating module 403, configured to generate a distributed transaction according to the number of partition keys;

The testing module 404 is used to test the distributed database according to the distributed transaction.

Optionally, the acquisition module 401 is specifically used to acquire a configuration file sent by a client used by the user; and determine test parameters required for testing the distributed database according to the configuration file.

Optionally, the determination module 402 is specifically used to determine, based on the test parameters and a predetermined data association relationship, the number of partition keys required for the distributed transaction under the condition that the number of data storage nodes actually crossed by the generated distributed transaction meets the expected number, and the data association relationship is used to represent the association between the number of data storage nodes corresponding to the distributed database, the expected number, and the number of partition keys required for the distributed transaction.

Optionally, the determination module 402 is specifically used to determine, for each data storage node corresponding to the distributed database, the probability that the data storage node stores the data required for the execution of the distributed transaction; and determine the data association relationship based on the probability that each data storage node contains the data required for the execution of the distributed transaction.

Optionally, the generation module 403 is specifically used to select partition keys of the number of partition keys from each partition key included in each data partition of the distributed database; and generate a distributed transaction according to the partition keys of the number of partition keys selected.

Optionally, the generating module 403 is specifically configured to modify the placeholders of the partition keys required for transaction execution reserved in the preset transaction template to the selected number of partition keys, so as to generate a distributed transaction.

Optionally, the testing module 404 is specifically configured to distribute the generated distributed transactions to at least part of the data storage nodes according to a preset load balancing distribution strategy, so as to test the distributed database.

Optionally, the determination module 402 is specifically used to obtain an expected distributed transaction ratio input by a user, where the expected distributed transaction ratio is used to indicate the ratio of the generated distributed transactions to all generated transactions;

The generating module 403 is specifically used for:

A distributed transaction is generated according to the expected distributed transaction ratio and the number of partition keys.

This specification also provides a computer-readable storage medium, which stores a computer program. The computer program can be used to execute a database testing method provided in FIG. 1 above.

This specification also provides a schematic structural diagram of an electronic device corresponding to Figure 1, as shown in Figure 5. As shown in Figure 5, at the hardware level, the electronic device includes a processor, an internal bus, a network interface, a memory, and a non-volatile memory, and of course may also include hardware required for other services. The processor reads the corresponding computer program from the non-volatile memory into the memory and then runs it to implement the test method of the database in Figure 1 above. Of course, in addition to software implementations, this specification does not exclude other implementation methods, such as logic devices or a combination of software and hardware, etc., that is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

In the 1990s, improvements to a technology could be clearly distinguished as hardware improvements (for example, improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the method flow). However, with the development of technology, many improvements to the method flow today can be regarded as direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that an improvement in a method flow cannot be implemented using a hardware entity module. For example, a programmable logic device (PLD) (such as a field programmable gate array (FPGA)) is such an integrated circuit whose logical function is determined by the user's programming of the device. Designers can "integrate" a digital system on a PLD by programming it themselves, without having to ask a chip manufacturer to design and produce a dedicated integrated circuit chip. Moreover, nowadays, instead of manually making integrated circuit chips, this kind of programming is mostly implemented by "logic compiler" software, which is similar to the software compiler used when developing and writing programs, and the original code before compilation must also be written in a specific programming language, which is called hardware description language (HDL). There is not only one HDL, but many kinds, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. The most commonly used ones are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also know that it is only necessary to program the method flow slightly in the above-mentioned hardware description languages and program it into the integrated circuit, and then it is easy to obtain the hardware circuit that implements the logic method flow.

The controller can be implemented in any appropriate manner, for example, the controller can take the form of a microprocessor or processor and a computer-readable medium storing a computer-readable program code (such as software or firmware) that can be executed by the (micro)processor, a logic gate, a switch, an application-specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller. Examples of controllers include, but are not limited to, the following microcontrollers: ARC625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art also know that in addition to implementing the controller in a purely computer-readable program code manner, the controller can be implemented in the form of a logic gate, a switch, an application-specific integrated circuit, a programmable logic controller, and an embedded microcontroller by logically programming the method steps. Therefore, this controller can be considered as a hardware component, and the devices included therein for implementing various functions can also be regarded as structures within the hardware component. Or even, the devices for implementing various functions can be regarded as both software modules for implementing the method and structures within the hardware component.

The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

For the convenience of description, the above device is described in various units according to their functions. Of course, when implementing this specification, the functions of each unit can be implemented in the same or multiple software and/or hardware.

Those skilled in the art will appreciate that the embodiments of this specification may be provided as methods, systems, or computer program products. Therefore, this specification may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

This specification is described with reference to the flowchart and/or block diagram of the method, device (system), and computer program product according to the embodiment of this specification. It should be understood that each process and/or box in the flowchart and/or block diagram, as well as the combination of the process and/or box in the flowchart and/or block diagram can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device for implementing the functions specified in one process or multiple processes in the flowchart and/or one box or multiple boxes in the block diagram.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory produce a manufactured product including an instruction device that implements the functions specified in one or more processes in the flowchart and/or one or more boxes in the block diagram.

These computer program instructions may also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, whereby the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and/or one or more boxes in the block diagram.

In a typical configuration, a computing device includes one or more processors (CPU), input/output interfaces, network interfaces, and memory.

The memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and/or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

Those skilled in the art will appreciate that the embodiments of this specification may be provided as methods, systems or computer program products. Therefore, this specification may take the form of a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware. Moreover, this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

This specification may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. This specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules may be located in local and remote computer storage media, including storage devices.

Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

The above are only embodiments of this specification and are not intended to limit this specification. For those skilled in the art, this specification may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this specification should be included in the scope of the claims of this specification.

Claims (10)

1. A database testing method, comprising: Acquire test parameters required for testing a distributed database, the test parameters including: the number and expected number of data storage nodes corresponding to the distributed database, the expected number being used to indicate the number of distributed transactions across data storage nodes that are expected to be generated; According to the test parameters and the predetermined data association relationship, determine the number of partition keys required for the distributed transaction under the condition that the number of data storage nodes actually spanned by the generated distributed transaction meets the expected number, wherein the data association relationship is used to represent the association between the number of each data storage node corresponding to the distributed database, the expected number, and the number of partition keys required for the distributed transaction; Generate a distributed transaction according to the number of partition keys; The distributed database is tested according to the distributed transaction. 2. The method according to claim 1, obtaining the test parameters required for testing the distributed database, specifically comprising: Get the configuration file sent by the client used by the user; According to the configuration file, test parameters required for testing the distributed database are determined. 3. The method according to claim 1, determining the data association relationship specifically comprises: For each data storage node corresponding to the distributed database, determining the probability that the data storage node stores data required for the distributed transaction execution; The data association relationship is determined according to the probability that each data storage node contains data required for the distributed transaction execution. 4. The method according to claim 1, generating a distributed transaction according to the number of partition keys, specifically comprising: Selecting the number of partition keys from the partition keys included in each data partition of the distributed database; A distributed transaction is generated according to the partition keys of the selected number of partition keys. 5. The method according to claim 4, generating a distributed transaction according to the selected number of partition keys, specifically comprising: The placeholders of the partition keys required for transaction execution reserved in the preset transaction template are modified to the selected number of partition keys to generate a distributed transaction. 6. The method according to claim 1, testing the distributed database according to the distributed transaction, specifically comprising: According to a preset load balancing distribution strategy, the generated distributed transaction is distributed to at least part of the data storage nodes to test the distributed database. 7. The method according to claim 1, before generating a distributed transaction according to the number of partition keys, the method further comprises: Obtaining an expected distributed transaction ratio input by a user, where the expected distributed transaction ratio is used to indicate the ratio of the generated distributed transactions to all generated transactions; According to the number of partition keys, a distributed transaction is generated, specifically including: A distributed transaction is generated according to the expected distributed transaction ratio and the number of partition keys. 8. A database testing device, comprising: An acquisition module is used to acquire test parameters required for testing a distributed database, wherein the test parameters include: the number and expected number of data storage nodes corresponding to the distributed database, wherein the expected number is used to indicate the number of distributed transactions across data storage nodes that are expected to be generated; A determination module, used to determine, based on the test parameters and a predetermined data association relationship, the number of partition keys required for the distributed transaction under the condition that the number of data storage nodes actually spanned by the generated distributed transaction meets the expected number, wherein the data association relationship is used to represent the association between the number of data storage nodes corresponding to the distributed database, the expected number, and the number of partition keys required for the distributed transaction; A generation module, used for generating a distributed transaction according to the number of partition keys; A testing module is used to test the distributed database according to the distributed transaction. 9. A computer-readable storage medium, wherein the storage medium stores a computer program, and when the computer program is executed by a processor, the method according to any one of claims 1 to 7 is implemented. 10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the method according to any one of claims 1 to 7 when executing the program.