WO2022062593A1

WO2022062593A1 - Method for assessing database, apparatus, computing device, and computer program product

Info

Publication number: WO2022062593A1
Application number: PCT/CN2021/106618
Authority: WO
Inventors: 孔柏林; 李建峰; 窦德明; 张昆
Original assignee: 华为云计算技术有限公司
Priority date: 2020-09-22
Filing date: 2021-07-15
Publication date: 2022-03-31
Also published as: CN114253935A

Abstract

Provided in the present application is a method for assessing a database, an apparatus, a computing device, and a computer program product. In the present method, one or more candidate databases are displayed on a user interface, the candidate databases being databases determined via incorporating a feature of a source database instance; and a workload required to deploy a data structure migrated from the source database instance for each among one or more of the candidate databases are displayed on the user interface. Consequently, workloads are presented on the user interface, which facilitates a user in taking the workloads into consideration, and a target database is determined from the candidate databases via incorporating the workloads. The target database is used for deploying a data structure migrated from the source database instance.

Description

Method and apparatus, computing device and computer program product for evaluating a database

technical field

The present application relates to the field of computers, in particular to methods and apparatuses, computing devices and computer program products for evaluating databases.

Background technique

There are differences in database engines between heterogeneous databases, and there are great differences in object structure design, Structured Query Language (SQL) syntax, and authority control among various databases. How to quickly migrate heterogeneous databases becomes a difficult point for users.

SUMMARY OF THE INVENTION

In view of this, the present application provides a method and apparatus for evaluating a database, a computing device and a computer program product, which can improve the efficiency of database migration.

In a first aspect, the present application provides a method of evaluating a database. One or more candidate databases are displayed on the user interface, and the candidate databases are databases determined in combination with the characteristics of the source database instance; the one or more candidate databases are displayed on the user interface, respectively deployed from the source database instance. The amount of work required for the migrated data structures.

The workload is displayed on the user interface, so that the user can consider the workload and determine the target database from the candidate database in combination with the workload. The target database is used to deploy data structures migrated from the source database instance.

In a possible design of the first aspect, the apparatus obtains a target database determined by the user from the one or more candidate databases, where the target database is used to deploy the data structure migrated from the source database instance.

In this way, the device selects candidate databases from multiple databases in combination with the characteristics and workload of the source database, and the candidate databases after the screening are all databases suitable for carrying the data structures migrated from the source database. The device presents the optimal candidate database on the user interface, and the user can select and determine the target database as needed, which can improve the efficiency of database migration and ensure the stability of the evaluation database. In addition, the device displays the workload of the candidate database on the user interface, and the user can also select the candidate database with less workload as the target database, which can reduce the migration time of the data structure of the database.

In a possible design of the first aspect, the workload required for deploying the data structure in the candidate database is for a user to determine a target database from the one or more candidate databases in the user interface.

In a possible design of the first aspect, the workload required to deploy the data structure in the candidate database is determined based on parameters, and the parameters include one or more of the following combinations: syntax conversion rate, compatibility degree, and amount of code.

In a possible design of the first aspect, the priority of the candidate database is displayed on the user interface.

In this way, the user can know the migration compatibility degree of the candidate database at a glance, and the user can further select the candidate database with high priority as the target database, which can improve the stability and success rate of the evaluation database. Of course, the user can also select a suitable candidate database as the target database in combination with other factors (such as cost).

In a possible design of the first aspect, one or more specification configurations of the candidate database are displayed on the user interface.

In this way, the user can further select the specification configuration suitable for the business.

In a possible design of the first aspect, a specification configuration determined by a user from one or more specification configurations in the target database is obtained.

In a possible design of the first aspect, the specification configuration includes one or more of the following combinations:

Processor, memory, hard disk and input and output IO configuration.

In a possible design of the first aspect, the source database and the candidate database are databases of different types.

In a possible design of the first aspect, the characteristics of the source database instance include one or more of the following combinations:

Stored procedures, materialized views, table partitions, triggers, in-library scheduling, resource management, health monitoring, auditing, flashback, backup recovery, cluster high availability, bulk loading, concurrency, scalability, recovery point target RPO, recovery time Target RTO, deployment across data centers, storage capacity, and storage cost.

In a possible design of the first aspect, the characteristics of the source database instance are determined based on operating parameters of the source database instance;

Wherein, the operating parameters of the source database instance include one or more combinations of the following parameters:

Transactions per second (TPS), query rate per second (QPS), input and output operations per second (IOPS), memory usage, CPU usage, active sessions, database configuration, database capacity, table complexity, and structured query language (SQL) complexity .

In a possible design of the first aspect, the one or more candidate databases are determined in combination with the characteristics of the source database instance and database compatibility, and the database compatibility refers to the degree of compatibility between the candidate database and the source database .

In a second aspect, the present application provides an apparatus for evaluating a database. The apparatus includes a plurality of functional modules for implementing the steps in the method provided by the first aspect or any possible design of the first aspect.

In a third aspect, the present application provides a computing device including a processor and a memory. The memory stores instructions; the processor executes the instructions stored in the memory, causing the computing device to perform steps in the methods provided by the first aspect or various possible designs of the first aspect, or cause the computing device to deploy the methods provided by the second aspect A means of evaluating the database.

In a fourth aspect, the present application provides a computer-readable storage medium, where an instruction is stored in the computer-readable storage medium. When a processor of a computing device executes the instruction, the computing device executes the first aspect or the first aspect. Various possible designs of the steps in the method provided, or the computing device deploying the means for the evaluation database provided by the second aspect.

In a seventh aspect, the present application provides a computer program product comprising instructions stored in a computer-readable storage medium. The processor of the computing device may read the instruction from the computer-readable storage medium, and the processor executes the instruction, causing the computing device to perform the steps in the method provided by the above-mentioned first aspect or various possible designs of the first aspect, or cause the The computing device deploys the data node evaluation database apparatus provided in the second aspect.

Description of drawings

1 is a schematic diagram of a scenario of database migration provided by the present application;

Fig. 2 is a kind of realization schematic diagram of screening candidate database;

3 is a schematic diagram of a user interface for the application to select a target database from a plurality of candidate databases;

4 is a schematic flowchart of a method for evaluating a database provided by the present application;

5 is a schematic diagram of a logical structure of an apparatus for evaluating a database provided by the application;

FIG. 6 is a schematic structural diagram of a computing device 800 provided by the present application.

detailed description

The technical solutions provided by the present application will be described below with reference to the accompanying drawings in the present application.

As shown in FIG. 1 , the source database instance 11 deploys the source database 111 . The source database instance 11 provides database services through the source database 111 , for example, for a user to query data in the source database 111 .

FIG. 1 also illustrates a database migration scenario, the source database 111 is the database of the data structure to be migrated, and the target database 211 is the database used to deploy the migrated data structure.

For example, the data structure of the source database is divided into three categories:

The first type of data structure of the source database is the data structure natively supported by the target database to the source database;

The second type of data structure of the source database, which is transformed into a data structure supported by the target database through tools;

The third type of data structure of the source database is other data structures other than the first type of data structure and the second type of data structure. For example, the third type of data structure is not supported by the target database, and cannot be transformed into a data structure supported by the target database through tools.

An implementation example of deploying the data structure migrated from the source database 111 to the target database 211. For the first type of data structure, the target database 211 can use it directly; for the second type of data structure of the source database, the target database 211 obtains the data structure through syntax conversion The tool transforms the data structure of the second type of data structure; for the third type of data structure of the source database, feedback to the user (eg feedback through the user interface) to modify the suggestion or provide an alternative data structure.

For example, the data structure can include one or more of the following combinations:

Table structure, index structure, view, materialized view, procedure, sequence, function, package, etc.

In a possible implementation scenario, the source database 111 and the target database 211 are different types of databases. The source database 111 and the target database 211 are heterogeneous databases. For example, the source database 111 is a relational database, and the target database 211 is a non-relational database; for example, the source database 111 is a non-relational database, and the target database 211 is a relational database; for example, the source database 111 and target database 211 are two different types of relational databases; for example, source database 111 and target database 211 are two different types of non-relational databases. For example, the source database 111 is an oracle database, and the target database 211 is a MySQL database or a ProsgreSQL database.

Candidate database

The following example provides an implementation manner of obtaining the candidate database, as shown in FIG. 2 .

If the source database 111 is an oracle database, the source database instance 11 is an oracle database instance. When the user expects to migrate the Oracle database data to other heterogeneous databases, the Oracle data structure will be migrated to other heterogeneous databases first. Usually cloud platforms support multiple databases, such as MySQL database, DB2 database, SQL Server database, Postgre SQL database, MongoDB database, Redis database, Memcached database and HBse database. The screening module will screen out multiple candidate databases from these multiple databases based on the characteristics of the oracle database instance. For example, the oracle database is a relational database. Therefore, the screening module considers the compatibility between databases and selects from these multiple databases. Several relational databases (MySQL database, DB2 database, SQL Server database, Postgre SQL database) were selected as candidate databases. The screening module can further consider business scenarios to determine candidate databases. If the characteristics of the oracle database instance indicate that oracle is used for shopping websites with high concurrency, the screening module will select DB2 databases and SQL Server databases as candidate databases; If the feature indicates that oracle is used for patent search websites with low concurrency, the filtering module will select MySQL database as the candidate database.

FIG. 3 provides an example of a display manner in which the present application displays the candidate database of FIG. 2 through a user interface. Suppose the Oracle database instance deploys a patent search website, and now it is hoped that the data structure of the Oracle database instance will be evaluated for database migration. The filtering module filters out 4 types of relational databases: MySQL database, DB2 database, SQL Server database, Postgre SQL database. The screening module evaluates and sorts the business scenarios of these four types of databases combined with patent search websites. MySQL database belongs to the first priority of recommended users, Postgre SQL database belongs to the second priority of recommended users, and both DB2 database and SQL Server database belong to third priority. Migrating the data structures of an oracle database instance to a first-priority MySQL is better than migrating to a second-priority PostgreSQL database. Similarly, migrating the data structures of an oracle database instance to a second-priority Postgre SQL database is preferable to migrating to a third-priority DB2 database or SQL Server database. That is, the first priority is higher than the second priority, and the second priority is higher than the third priority. Of course, the priority is only the priority order given by the filtering module. Users can choose the target database for migration according to their needs. For example, users can choose Postgre SQL database or DB2 database or SQL Server database as the target database. It is not necessary to choose the first priority. level MySQL database.

As shown in Figure 3, for each candidate database, the screening module will give one or more specification configurations. Examples of two possible business scenarios. If the business is computationally expensive (such as a business with continuous high concurrency), you can choose a computing-based configuration (for example, 8 cores, 32G memory, 128G hard disk); if the business is storage-consuming (such as business with continuous high storage), you can choose storage-type specifications (such as 4 cores, 64G memory, 256 hard drives).

How to select a target database and specifications from multiple candidate databases will be described with reference to FIG. 3 . Users can select the MySQL database through the user interface, and then further select the specification configuration (8 cores, 32G memory, 128G hard disk) in the MySQL database line. Subsequently, a MySQL database instance will be created, which is convenient for migrating the data structure in the oracle database above the oracle database instance to the MySQL database instance, that is, deploying the data structure migrated from oracle in the MySQL database instance:

Deploy the first type of data structure migrated from the oracle database instance, deploy the data structure transformed from the second type of data structure migrated from the oracle database instance through the syntax conversion tool, and provide feedback to the user for the third type of data structure of the oracle database instance (for example, through user interface feedback) to suggest changes or provide alternative data structures.

In a possible implementation manner, for each candidate database, the screening module may also provide one or more version number selections, and the version number is not shown in FIG. 3 .

For each candidate database, the screening module calculates the workload of deploying data structures migrated from the source database in each candidate database (such as database administrator (DBA) workload, development workload, and testing workload, etc. ). For example, as shown in Figure 3, the user interface presents: the workload (DBA workload, development workload, testing workload) required to deploy the data structure migrated from the oracle database instance in the MySQL database, and the deployment workload from oracle in the Postgre SQL database The workload (DBA workload, development workload, and test workload) required to migrate the data structure of the database instance, and the workload required to deploy the data structure migrated from the oracle database instance in the DB2 database (DBA workload, development workload) , test workload), the workload (DBA workload, development workload, test workload) required to deploy the data structure migrated from the oracle database instance in the SQL Server database. The workload is displayed on the user interface, so that the user can consider the workload and determine the target database from the candidate databases in combination with the workload and/or priority.

The following example provides a possible implementation manner of how the screening module screens out the candidate database.

First, the operating parameters of the source database instance 11 are collected. The operating parameters of the source database instance 11 include one or more of the following: transactions per second (transactions per second, TPS), query rate per second (queries per second, QPS), input/output operations per second (input/output) per second, IOPS), memory usage, central processing unit (CPU) usage, active sessions, database configuration, database capacity, table complexity, and SQL complexity.

Then, based on the operating parameters of the source database instance 11, the characteristics of the source database instance 11 are obtained through analysis. The characteristics of the source database instance 11 include two types of characteristics.

The first type of features of the source database instance 11 include one or more of the following: stored procedures, materialized views, table partitions, triggers, in-database scheduling, resource management, health monitoring, auditing, flashback, backup and recovery, cluster high Available as well as bulk loading and more. The source database instance 11 may have one or more characteristics of the first type of characteristics, that is, the source database instance 11 may use one or more characteristics of the first type of characteristics, for example, the source database instance 11 may use triggers, and then For example, the source database instance 11 may use a materialized view.

The second type of characteristics of the source database instance 11 includes one or more of the following: concurrency, scalability, recovery point objective (RPO), recovery time objective (RTO), deployment across data centers , storage capacity, and storage costs.

In a possible implementation manner, the candidate database is determined by analysis based on the characteristics of the source database instance 11 and the compatibility between the databases. For example, database instance 11 is an oracle database instance, and multiple databases are MySQL database, DB2 database, SQL Server database, Postgre SQL database, MongoDB database, Redis database, Memcached database and HBse database, then combine the characteristics of the oracle database instance and the oracle database The compatibility between the instance and these multiple databases determines that MySQL database, DB2 database, SQL Server database, and Postgre SQL database are candidate databases with good compatibility, because MySQL database, DB2 database, SQL Server database, Postgre SQL database and Oracle databases are relational databases, and there are relatively few second- or third-type data structures that need to be transformed between databases. In contrast, non-relational databases such as MongoDB, Redis, Memcached, and HBse are less compatible with oracle databases, so MongoDB, Redis, Memcached, and HBse are not screened modules. Selected as candidate database.

The method for evaluating the database provided by the present application is exemplified below with reference to FIG. 1 to FIG. 4 . Wherein, FIG. 4 provides an example of the flow steps of the method, and the steps of the method include steps 41 to 43 .

Step S41, displaying one or more candidate databases on the user interface.

The candidate database displayed on the user interface is the database determined in combination with the characteristics of the source database instance 11 . Therefore, each candidate database is relatively suitable for deploying the data structure from the source database instance 11 , less second data structure needs to be transformed during deployment, and less third data structure needs to be adjusted by the user during deployment.

In a possible implementation manner, the characteristics of the source database instance 11 are determined based on operating parameters of the source database instance 11 . The operating parameters of the source database instance 11 include one or more of the following: transactions per second (transactions per second, TPS), query rate per second (queries per second, QPS), input/output operations per second (input/output) per second, IOPS), memory usage, central processing unit (CPU) usage, active sessions, database configuration, database capacity, table complexity, and SQL complexity. In an implementation scenario, the operating parameters of the source database instance 11 may be determined by the services provided by the source database instance 11. If the source database instance 11 supports the continuous high-concurrency shopping website query service, the TPS, QPS, IOPS, Memory usage, CPU usage, active sessions, etc. are relatively high. If the source database instance 11 supports continuous low-concurrency travel website query services, the TPS, QPS, IOPS, memory usage, CPU usage, and active sessions, etc. etc. is relatively low.

In a possible implementation manner, the characteristics of the source database instance 11 determined based on the operating parameters of the source database instance 11 may include one or more of the following combinations: stored procedures, materialized views, table partitions, triggers, In-library scheduling, resource management, health monitoring, auditing, flashback, backup and recovery, cluster high availability, batch loading, concurrency, scalability, recovery point objective (RPO), recovery time objective (RTO), cross-data center deployment, storage capacity, and storage cost, etc. The source database instance 11 may have one or more first-class features (stored procedures, materialized views, table partitions, triggers, in-store scheduling, resource management, health monitoring, auditing, flashback, backup and recovery, cluster high availability) and batch loading, etc.), the first type of characteristics may be determined by the business needs of the business carried by the source database instance 11 . The source database instance 11 may have one or more characteristics of the second type (concurrency, scalability, RPO, RTO, storage capacity, storage cost, etc.), and the value of the first type of characteristics may be the value of the service carried by the source database instance 11. decided.

Since the operating parameters of the source database instance 11 reflect the data structure requirements of the business on the source database instance 11, the operating parameters of the source database instance 11 determine the characteristics of the source database instance 11, and the characteristics of the source database instance 11 can basically also reflect the business's demand for the source database instance 11. Data structure requirements for database instance 11.

In a possible implementation manner, each candidate database is determined in combination with the characteristics of the source database instance and database compatibility, where the database compatibility refers to the degree of compatibility between the candidate database and the source database. For example, the degree of compatibility of two databases in a non-relational database is better than the degree of compatibility between a relational database and a non-relational database; similarly, the degree of compatibility between two databases in a relational database is also better than that of a relational database Compatibility with non-relational databases.

In a possible implementation manner, the screening module uses a screening model to determine the candidate database. Specifically, the characteristics of the source database instance are compatible with the database as an input to the screening model, so that the screening model can screen candidate databases from multiple databases.

In a possible implementation manner, the source database and the candidate database are databases of different types. For example, the source database and the candidate database may be two types of databases in relational databases, for example, the source database is an oracle database and the candidate database may be a MySQL database. For example, the source database and the candidate database may be two types of databases in non-relational databases, for example, the source database is a MongoDB database and the candidate database may be a Redis database. For example, the source database may belong to a relational database (eg, an oracle database), and the candidate database may belong to a non-relational database (eg, a Redis database); or, the source database may belong to a non-relational database (eg, a Redis database), and the candidate database Can belong to relational database (eg oracle database).

The present application does not limit the arrangement of the candidate databases displayed on the user interface. For example, Figure 3 exemplifies an arrangement that displays multiple candidate databases (MySQL database, DB2 database, SQL Server database, and Postgre SQL database).

A possible user interface design in which the priority of the candidate database is displayed. As shown in FIG. 3, a priority order of multiple candidate databases is presented to the user. Among them, MySQL database belongs to the first priority of recommended users, Postgre SQL database belongs to the second priority of recommended users, and both DB2 database and SQL Server database belong to the third priority. The MySQL database with the first priority is most suitable for hosting the data structure of the Oracle database instance to be migrated from, the Postgre SQL database with the second priority is better suitable for hosting the data structure of the Oracle database instance from the migration, and the DB2 database or SQL Server with the third priority The database is generally suitable for hosting the data structures from the migrated oracle database instance.

A possible user interface design where one or more specification configurations of the candidate database are displayed. As shown in Figure 3, the user is presented with two specifications for each candidate database: one specification configuration is (8 cores, 32G memory, 128G hard disk), and the other specification configuration (4 cores, 64G memory, 256 hard disks). For example, if the business is computing-consuming (such as a business with continuous high concurrency), you can choose a computing-based specification (such as 8 cores, 32G memory, 128G hard disk). If the business is storage-consuming (such as continuous high-storage business), you can choose storage-type specifications (such as 4 cores, 64G memory, 256 hard drives). In this way, the user can select the specification configuration in combination with the business, and in addition, the user can also select the specification configuration considering the cost.

A possible user interface design, the user can first determine the target database from one or more candidate databases of the user interface, and then determine a specification configuration from one or more specification configurations of the target database, and accordingly, the system will The specification and configuration determined by the user will be obtained. As an example in Figure 3, the user selects the MySQL database as the target database, and further selects the specification and configuration of the MySQL database (8 cores, 32G memory, 128G hard disk). Subsequently, the data structure of the source database 111 (eg, the oracle database) is migrated to the target database (eg, the MySQL database) configured by the user-specified specification.

In a possible implementation manner, the specification configuration of the candidate database includes one or more combinations of the following: processor, memory, hard disk, and input/output (IO) configuration. For example, as shown in Figure 3, one specification configuration can be an 8-core processor, 32G memory and a 128G hard disk, and another specification configuration can be a 4-core processor, 64G memory and 256G hard disk.

Step S42, displaying on the user interface the workload required to deploy the data structures migrated from the source database instance in the one or more candidate databases respectively.

The workload includes one or more combinations of the following: DBA workload, development workload, and testing workload.

DBA workload refers to the workload required by the database administrator to deploy the data structure migrated from the source database instance in the candidate database.

Development workload refers to the workload of developers to develop the code required to deploy the data structures migrated from the source database instance in the candidate database.

Test workload refers to the workload of the tester to test the code required to deploy the data structure migrated from the source database instance in the candidate database.

In a possible implementation manner, the workload required for deploying the data structure in the candidate database is used for the user to determine the target database from the one or more candidate databases in the user interface.

For example, as shown in Figure 3, the user interface presents: the workload (DBA workload, development workload, testing workload) required to deploy the data structure migrated from the oracle database instance in the MySQL database, and the deployment workload from oracle in the Postgre SQL database The workload (DBA workload, development workload, and test workload) required to migrate the data structure of the database instance, and the workload required to deploy the data structure migrated from the oracle database instance in the DB2 database (DBA workload, development workload) , test workload), the workload (DBA workload, development workload, test workload) required to deploy the data structure migrated from the oracle database instance in the SQL Server database. The workload is displayed on the user interface, so that the user can consider the workload and determine the target database from the candidate databases in combination with the workload and/or priority.

In a possible implementation manner, the workload required to deploy the data structure in the candidate database is determined based on parameters, and the parameters include one or more of the following combinations: syntax conversion rate, compatibility degree, and code amount .

The syntax conversion rate as a parameter refers to the conversion rate of converting the data structure syntax of the source database instance into the candidate database.

The degree of compatibility as a parameter refers to the degree of compatibility between the source database and the candidate database.

The amount of code used as a parameter refers to the amount of code required to implement the deployment of the data structure of the source database instance in the candidate database.

In addition, the parameter used to evaluate the workload required to deploy the data structure in the candidate database may also include other parameters other than the syntax conversion rate, the degree of compatibility, and the amount of code, for example, the other parameter may include the DBA knowledge base, Such other parameters may include, for example, an evaluation baseline used by historical evaluation workloads.

An example of implementation, the screening module can use a workload evaluation model, and use the parameters (such as syntax conversion rate, compatibility level, and code amount) as the input of the workload evaluation model, and the evaluation model can output workload (such as DBA workload). , development effort, and testing effort).

Step S43: Obtain a target database determined by the user from the one or more candidate databases, where the target database is used to deploy the data structure migrated from the source database instance.

After the user determines the target database on the user interface, the system obtains the target database determined by the user. Subsequently, an instance of the target database can be deployed, and the data structure migrated from the source database instance can be deployed in the target database through the instance.

Taking Figure 3 as an example, the user selects the MySQL database as the target database on the user interface, and determines that the specifications of the MySQL database are configured as an 8-core processor, 32G of memory, and 128G of hard disk. Subsequently, when the data structure of the oracle database instance needs to be migrated, the system deploys the MySQL database instance with the specified configuration (8-core processor, 32G memory, and 128G hard disk). In this way, the MySQL database instance can deploy the data structures migrated from the oracle database instance in the MySQL database.

Take Figure 3 as an example to illustrate a possible implementation of deployment. For the first type of data structure migrated from the Oracle database instance, the MySQL database instance can be used natively, that is, the MySQL database instance can deploy the first type of data structure in the MySQL database. ; For the second type of data structure migrated from the oracle database instance, the MySQL database instance transforms the data structure of the second type of data structure through the syntax conversion tool, and deploys the transformed data structure in the MySQL database; for the second type of data structure migrated from the oracle database instance. Three types of data structures that provide feedback to the user (eg, through user interface feedback) to suggest modifications or to provide alternative data structures.

The present application also provides an apparatus for evaluating the database, and the apparatus can be deployed on the computing device (such as a server) of the present application. The apparatus includes functional units for implementing the above method for evaluating a database; this application does not limit how the functional units are divided in the apparatus.

The division of a functional unit of the apparatus for evaluating the database is exemplarily provided below, as shown in FIG. 5 .

As shown in Figure 5, the device 50 includes:

The candidate database display module 51 is used to display one or more candidate databases on the user interface, and the candidate databases are databases determined in combination with the characteristics of the source database instance;

The workload display module 52 is configured to display, on the user interface, the workload required to deploy the data structures migrated from the source database instance in the one or more candidate databases respectively.

One possible design of apparatus 50 comprising:

The obtaining module 53 is configured to obtain the target database determined by the user from the one or more candidate databases, where the target database is used to deploy the data structure migrated from the source database instance.

In one possible design of the apparatus 50, the effort required to deploy the data structure in the candidate database is for the user to determine the target database from the one or more candidate databases in the user interface.

In one possible design of the apparatus 50, the effort required to deploy the data structure in the candidate database is determined based on parameters including one or more combinations of the following: syntax conversion rate, degree of compatibility, and code quantity.

In a possible design of the apparatus 50, the candidate database display module 51 is configured to display the priority of the candidate database on the user interface.

In a possible design of the apparatus 50, the candidate database display module 52 is configured to display one or more specification configurations of the candidate database on the user interface.

In a possible design of the apparatus 50, the obtaining module 53 is configured to obtain the specification configuration determined by the user from one or more specification configurations of the target database.

One possible design of device 50, the specification configuration includes one or more of the following combinations:

Processor, memory, hard disk and input and output IO configuration.

In one possible design of apparatus 50, the source database and the candidate database are different types of databases.

As a possible design, FIG. 6 schematically provides a possible basic hardware architecture of the computing device of the present application.

Referring to FIG. 6 , computing device 800 includes processor 801 , memory 802 , communication interface 803 , and bus 804 .

In the computing device 800, the number of processors 801 may be one or more, and FIG. 6 only illustrates one of the processors 801. Optionally, the processor 801 may be a central processing unit (central processing unit, CPU). If the computing device 800 has multiple processors 801, the multiple processors 801 may be of different types, or may be the same. Optionally, the multiple processors 801 of the computing device 800 may also be integrated into a multi-core processor.

The memory 802 stores instructions and data; the memory 802 can store the instructions and data required to implement the method for evaluating the database provided by the present application, and the memory 802 can also store the instructions for implementing the steps performed by the apparatus for evaluating the database in the method for evaluating the database . The memory 802 may be any one or any combination of the following storage media: non-volatile memory (eg, read only memory (ROM), solid state disk (SSD), hard disk (HDD), optical disk), volatile memory.

The communication interface 803 may be any one or any combination of the following devices: a network interface (eg, an Ethernet interface), a wireless network card, and other devices with a network access function.

The communication interface 803 is used for data communication between the computing device 800 and other computing devices or terminals.

Figure 6 represents the bus 804 with a thick line. A bus 804 may connect the processor 801 with the memory 802 and the communication interface 803 . In this way, through the bus 804, the processor 801 can access the memory 802, and can also use the communication interface 803 to perform data interaction with other computing devices or terminals.

In the present application, the computing device 800 executes the instructions in the memory 802, so that the computing device 800 implements the method for evaluating the database provided by the present application. Alternatively, the computing device 800 executes the instructions in the memory 802, so that the computing device 800 implements the apparatus 50 of the evaluation database of the present application.

The present application provides a computer-readable storage medium, where an instruction is stored in the computer-readable storage medium. When the processor 801 of the computing device 800 executes the instruction, the method for the computing device 800 to execute the foregoing evaluation database is executed by the coordinating node or the computing device 800 implements the functions of the apparatus for evaluating the database of the present application.

The present application provides a computer program product comprising instructions stored in a computer-readable storage medium. The processor 801 of the computing device 800 can read the instruction from the computer-readable storage medium, and the processor 801 executes the instruction, causing the computing device 800 to perform the steps performed by the coordinating node in the above-mentioned method for evaluating a database, or causing the computing device 800 to implement The function of the means of evaluating the database of this application.

The above embodiments are only used to illustrate the technical solutions of the present application, but not to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that: The technical solutions recorded are modified; and these modifications do not make the corresponding technical solutions deviate from the protection scope of the claims.

Claims

A method for evaluating a database, the method comprising:

Displaying one or more candidate databases in the user interface, the candidate databases are databases determined in combination with the characteristics of the source database instance;

The effort required to deploy the data structures migrated from the source database instance in each of the one or more candidate databases is displayed in the user interface.
The method of claim 1, wherein the method comprises:

A target database determined by the user from the one or more candidate databases is obtained, the target database being used to deploy the data structure migrated from the source database instance.
The method according to claim 1 or 2, wherein the workload required for deploying the data structure in the candidate database is for a user to select from the one or more candidate databases in the user interface Determine the target database.
The method according to any one of claims 1 to 3, wherein the workload required for deploying the data structure in the candidate database is determined based on parameters, and the parameters include one or more of the following Combination: Syntax conversion rate, degree of compatibility, and amount of code.
The method according to any one of claims 1 to 4, wherein the method comprises:

The priority of the candidate database is displayed in the user interface.
The method according to any one of claims 1 to 5, wherein the method comprises:

One or more specification configurations of the candidate database are displayed in the user interface.
The method according to any one of claims 1 to 6, wherein the method comprises:

A specification configuration determined by a user from one or more specification configurations of the target database is obtained.
The method according to any one of claims 6 or 7, wherein the specification configuration includes one or more of the following combinations:

Processor, memory, hard disk and input and output IO configuration.
The method according to any one of claims 1 to 8, wherein the source database and the candidate database are databases of different types.
A device for evaluating a database, characterized in that the device comprises:

A candidate database display module, configured to display one or more candidate databases on the user interface, the candidate databases are databases determined in combination with the characteristics of the source database instance;

A workload display module, configured to display, on the user interface, the workload required to deploy the data structures migrated from the source database instance in each of the one or more candidate databases.
The apparatus of claim 10, wherein the apparatus comprises:

The obtaining module is configured to obtain the target database determined by the user from the one or more candidate databases, where the target database is used to deploy the data structure migrated from the source database instance.
The apparatus according to claim 10 or 11, wherein the workload required for deploying the data structure in the candidate database is for a user to select from the one or more candidate databases in the user interface Determine the target database.
The apparatus according to any one of claims 10 to 12, wherein the workload required for deploying the data structure in the candidate database is determined based on parameters, and the parameters include one or more of the following: A combination of: syntax conversion rate, degree of compatibility, and amount of code.
The apparatus according to any one of claims 10 to 13, wherein the candidate database display module is configured to display the priority of the candidate database on the user interface.
The apparatus according to any one of claims 10 to 14, wherein the candidate database display module is configured to display one or more specification configurations of the candidate database on the user interface.
The apparatus according to any one of claims 10 to 15, wherein the acquiring module is configured to acquire the specification configuration determined by the user from one or more specification configurations in the target database.
The device according to any one of claims 10 to 16, wherein the specification configuration includes one or more of the following combinations:

Processor, memory, hard disk and input and output IO configuration.
The apparatus according to any one of claims 10 to 17, wherein the source database and the candidate database are databases of different types.
A computing device, characterized in that the computing device includes a processor and a memory; the processor executes the instructions in the memory, so that the computing device executes the method in any one of claims 1 to 9. step.
A computer program product, characterized in that the computer program product includes instructions, the instructions instructing a computing device to perform the steps in the method of any one of claims 1 to 9.