Hybrid database deployment method and apparatus

Abstract

Disclosed in the present invention are a hybrid database deployment method and apparatus. The method comprises: acquiring a first request, which is used for requesting an application for creating a first database service on a database platform, wherein the database platform comprises at least one server cluster, and software images supporting a plurality of chip types, and each server cluster comprises servers supporting at least one chip type; during database software deployment, for each database node, on the basis of a chip architecture selected by a user for the first database service, selecting from a database cluster a server that supports a chip type corresponding to the database node, and select from the database platform a software image that supports the chip type corresponding to the database node; and on the basis of a first software image, deploying a database node on a first server. Thus, in a scenario where servers supporting a plurality of chip types are simultaneously used, a database service is deployed by means of a chip architecture selected by a user on the basis of user requirements, thereby quickly meeting service requirements.

Description

A method and apparatus for hybrid database deployment

[0001] Cross-reference to related applications

[0002] This application claims priority to Chinese Patent Application No. 202411710914.7, filed on November 26, 2024, entitled "A Database Hybrid Deployment Method and Apparatus", the entire contents of which are incorporated herein by reference. Technical Field

[0003] This invention relates to the field of cloud platform technology, and in particular to a method and apparatus for hybrid database deployment. Background Technology

[0004] The current server market offers a variety of chips with different instruction sets, such as those based on the x86 architecture from Intel, Zhaoxin, and Hygon; those based on the ARM architecture from Phytium and Kunpeng; and those based on the MIPS architecture from Loongson and the Alpha architecture from Shenwei. Traditional cloud environments, container cloud environments, and database cloud environments all face scenarios where multiple servers with different chipsets are used simultaneously. Servers containing Intel chips have been widely deployed in production, while servers containing other types of chips, such as Hygon or Kunpeng chips, are gradually increasing in number.

[0005] Currently, servers with different chip types are generally deployed independently due to differences in instruction sets, computing power, and supported software types. This means that only servers of one chip type are deployed within a single cluster, and different nodes within the same database service can only run on servers of the same chip type. For logical clusters, since a cluster currently only deploys servers of one chip type, when resources for that chip type are insufficient, even if other chip types have sufficient resources, they cannot be used together, resulting in resource waste. Creating new clusters with other chip types requires additional resources; for example, a database cluster requires a proxy cluster and corresponding network resources. In such cases, it is often impossible to quickly meet database deployment requirements. Summary of the Invention

[0006] This invention provides a database hybrid deployment method and apparatus for quickly meeting database deployment requirements in scenarios where multiple chip type servers are used simultaneously.

[0007] In a first aspect, embodiments of the present invention provide a database hybrid deployment method, comprising: obtaining a first request, the first request being used to request the creation of a first database service on a database platform, the first database service including at least one database node; the database platform including at least one server cluster and a software image supporting multiple chip types, each server cluster including servers supporting at least two chip types; for each database node in the first data block service, performing: selecting a first server supporting the chip type corresponding to the database node from the at least one server cluster of the database platform according to the chip architecture selected by the user for the first database service, and selecting a first software image supporting the chip type corresponding to the database node from the database platform; and deploying the database node on the first server according to the first software image.

[0008] In the above technical solution, during the database software deployment process, based on the chip architecture selected by the user for the first database service, servers that support the chip type corresponding to the database node and software images that support the chip type corresponding to the database node are selected in the database cluster. Thus, in scenarios where multiple chip type servers are used simultaneously, the database service can be deployed according to the chip architecture selected by the user according to their needs, thereby quickly meeting the database deployment requirements.

[0009] In a second aspect, embodiments of the present invention provide a database hybrid deployment apparatus, comprising:

[0010] A receiving module is used to obtain a first request, the first request being used to request the creation of a first database service on the database platform, the first database service including at least one database node;

[0011] The processing module is configured to perform the following for each database node in the first database service: selecting a first server that supports the chip type corresponding to the database node from at least one server cluster of the database platform, based on the chip architecture selected by the user for the first database service; and selecting a first software image that supports the chip type corresponding to the database node from the database platform; and deploying the database node on the first server based on the first software image.

[0012] Thirdly, embodiments of the present invention also provide a computer device, comprising:

[0013] Memory, used to store program instructions;

[0014] The processor is used to call program instructions stored in the memory and execute the above-described database hybrid deployment method according to the obtained program.

[0015] Fourthly, embodiments of the present invention also provide a computer-readable storage medium storing computer-executable instructions for causing a computer to execute the above-described database hybrid deployment method. Attached Figure Description

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

[0017] Figure 1 is a schematic diagram of a system architecture provided by an embodiment of the present invention;

[0018] Figure 2 is a flowchart illustrating a database hybrid deployment method provided in an embodiment of the present invention;

[0019] Figure 3 is a schematic diagram of the deployment device provided in an embodiment of the present invention;

[0020] Figure 4 is a schematic diagram of a chip type label and performance evaluation score setting process provided in an embodiment of the present invention;

[0021] Figure 5 is a schematic diagram of the cluster tag interface provided in an embodiment of the present invention;

[0022] Figure 6 is a schematic diagram of the server tag interface provided in an embodiment of the present invention;

[0023] Figure 7 is a schematic diagram of the interface of the software image tag provided in an embodiment of the present invention;

[0024] Figure 8 is a schematic diagram of a process for calculating performance evaluation scores according to an embodiment of the present invention;

[0025] Figure 9 is a flowchart illustrating a database hybrid deployment method provided in an embodiment of the present invention;

[0026] Figure 10 is a schematic diagram of the interface for applying for and creating a database service provided in an embodiment of the present invention;

[0027] Figure 11 is a schematic diagram of the architecture of heterogeneous chip hybrid deployment within a cluster provided in an embodiment of the present invention;

[0028] Figure 12 is a flowchart illustrating a database hybrid deployment method provided in an embodiment of the present invention;

[0029] Figure 13 is a schematic diagram of the heterogeneous chip hybrid architecture of the database node provided in an embodiment of the present invention;

[0030] Figure 14 is a schematic diagram of a database hybrid deployment device provided in an embodiment of the present invention;

[0031] Figure 15 is a schematic diagram of the structure of the computer device provided in an embodiment of the present invention. Detailed Implementation

[0032] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this invention, and not all of them. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0033] Referring to Figure 1, which is a system architecture diagram applicable to an embodiment of this application, the system architecture includes at least a deployment device 101 and a database platform 102. The deployment device 101 and the database platform 102 can be directly or indirectly connected through wired or wireless communication, which is not limited in this application.

[0034] The deployment device 101 can be a terminal device, a server, or a device within a database platform. The terminal device can be a smartphone, tablet, laptop, desktop computer, smart home appliance, smart voice interaction device, smart vehicle device, etc., but is not limited to these. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms.

[0035] Database Cloud Platform 102 is a new type of cloud computing service that provides high-performance, highly reliable, highly secure, and flexibly scalable database hosting services. Database Cloud Platform 102 can provide various types of database services, such as relational databases like MySQL, non-relational databases like Redis and MongoDB, and distributed databases like Tidb, Oceanbase, and Updrdb. Database Cloud Platform 102 also provides a complete database operation and maintenance solution, including backup and recovery, monitoring, rapid expansion, and data transfer.

[0036] In this application, the database cloud platform 102 adopts a container-based database cloud platform, which uses Kubernetes or Swarm for container management to complete the deployment and management of database containers. Each database instance in the platform is an independent container deployed on the host machine, and each container is configured with a dedicated IP address, a central processing unit (CPU), memory, as well as tablespaces and log spaces. The tablespace stores data, and the log space stores database logs.

[0037] In this application's embodiments, the database service refers to all systems capable of storing data, including relational databases, in-memory databases, non-relational databases, message brokers, etc.

[0038] The database cloud platform 102 includes multiple server clusters. Any server cluster may include servers of the same chip type or servers of different chip types. This application does not specify the number of server clusters included in the database cloud platform 102 or the number of servers included in each server cluster.

[0039] When deploying database services, in order to prevent failures such as downtime or unexpected interruptions, a multi-node architecture is usually built, such as master-slave, master-slave, MHA (Master HA) cluster, and MGR (MySQL Group Replication) cluster, etc. This is a high-availability architecture, so that when a single node fails, the availability of the database can be restored as quickly as possible through other nodes, minimizing downtime and ensuring that business is not interrupted due to database failure.

[0040] In this embodiment, the original correspondence between logical clusters and racks is broken in terms of physical rack deployment. Different clusters and different types of servers can be mixed in the same physical rack, which helps improve the average number of servers used per rack. For example, if a rack currently has servers with chip type 1 deployed, and if these servers are no longer used in future procurement or planning, the not-yet-fully-configured rack can be configured with servers of other chip types, avoiding idle rack rack slots and improving the average number of servers used per rack.

[0041] It should be noted that the structure shown in Figure 1 above is only an example, and the embodiments of the present invention do not limit it.

[0042] Based on the above description, Figure 2 shows an exemplary flowchart of a database hybrid deployment method provided in an embodiment of this application. This process can be executed by a deployment device, which can be the deployment device 101 shown in Figure 1.

[0043] As shown in Figure 2, the process specifically includes:

[0044] Step 210: Obtain the first request. The first request is used to request the creation of a first database service on the database platform. The first database service includes at least one database node. The database platform includes at least one server cluster and a software image that supports multiple chip types. Each server cluster includes servers that support at least two chip types.

[0045] In this embodiment of the application, the first database service can be any database service created on the database platform. For any database service, it can include one database node or multiple database nodes.

[0046] Step 220: For each database node in the first database service, execute the following steps 220-1 to 220-2 respectively:

[0047] Step 220-1: Based on the chip architecture selected by the user for the first database service, select a first server that supports the chip type corresponding to the database node from at least one server cluster of the database platform, and select a first software image that supports the chip type corresponding to the database node from the database platform.

[0048] Step 220-2: Deploy the database node on the first server based on the first software image.

[0049] Specifically, the database node is deployed by deploying a container on the first server based on the first software image.

[0050] In this embodiment, each server cluster supports servers with at least two chip types. This solves the problem of insufficient resources for a single type of server, preventing scalability and quickly meeting business deployment needs. Furthermore, during database software deployment, based on the chip architecture selected by the user for the first database service, servers and software images supporting the chip type corresponding to the database node are selected within the database cluster. This allows for deployment of the database service based on the chip architecture chosen by the user, even when multiple chip types of servers are used simultaneously.

[0051] Optionally, in step 220-1 above, the chip architecture selected by the user for the first database service can be a single-chip architecture or a hybrid chip architecture. The specific implementation process of step 220 above will be explained below based on these two chip architectures.

[0052] In the first implementation, when the user selects a single-chip architecture for the first database service, all database nodes included in the first database service correspond to the same chip type; for example, the user selects the first chip type for the first database service. The deployment device executes steps S11 and S12 once for each database node included in the first database service:

[0053] Step S11: Based on the first chip type selected by the user for the first database service, select a first server that supports the first chip type from the database platform for the database node, and select a first software image that supports the first chip type from the database platform.

[0054] Step S12: Based on the selected first software image that supports the first chip type, deploy the database node on the selected first server that supports the first chip type.

[0055] For example, taking a first database service comprising two database nodes, namely database node 1 and database node 2, and the first chip type being a Kunpeng chip, the specific implementation process of step 220 above includes: for database node 1, selecting a server cluster supporting the Kunpeng chip from at least one server cluster of the database platform, then selecting a server supporting the Kunpeng chip from the server cluster supporting the Kunpeng chip; if multiple servers supporting the Kunpeng chip are selected, then a server can be randomly selected from the multiple servers supporting the Kunpeng chip, such as server 1, as the server for deploying database node 1; and selecting a software image 1 supporting the Kunpeng chip from the database platform; and then creating database node 1 on server 1 based on software image 1. Next, for database node 2, a server cluster supporting the Kunpeng chip is selected from at least one server cluster on the database platform. Then, a server supporting the Kunpeng chip is selected from the server clusters supporting the Kunpeng chip. If multiple servers supporting the Kunpeng chip are selected, one server, such as server 2, is randomly selected from these servers to deploy database node 2. Additionally, a software image 2 supporting the Kunpeng chip is selected from the database platform. Then, database node 2 is created on server 2 based on software image 2. This completes the creation process of the first database service, including database node 1 and database node 2.

[0056] It should be noted that database node 1 and database node 2 can be deployed on the same server or on different servers. If database node 1 and database node 2 are deployed on two different servers, these two servers can be in the same cluster or in different clusters. From a high availability perspective, it is generally advisable to deploy different nodes of the same database service on different servers or in different clusters to avoid single points of failure affecting the use of the database service.

[0057] In this embodiment, during the database software deployment process, based on the user-selected single-chip architecture, servers matching the user-selected chip type are selected within the database cluster, and software images matching the user-selected chip type are deployed. This allows users to choose the chip type to deploy the database service according to their needs. Furthermore, in multi-chip server scenarios, deploying the database service based on the user-selected single-chip architecture means that each database node is deployed on a server supporting the same chip type, ensuring performance parity and consistent computing power across different database nodes.

[0058] In the second implementation method, when the user selects a hybrid chip architecture for the first database service, at least two database nodes in the first database service correspond to different chip types. For example, the first database service includes database node 1, database node 2, and database node 3, where database node 1 corresponds to the Hygon chip type, database node 2 corresponds to the Kunpeng chip type, and database node 3 corresponds to the Intel chip type; or, for another example, the first database service includes database node 1, database node 2, and database node 3, where database node 1 corresponds to the Hygon chip type, database node 2 corresponds to the Hygon chip type, and database node 3 corresponds to the Kunpeng chip type. Based on this situation, step 220-1 can be implemented as follows: The deployment device determines the chip type corresponding to each database node according to the hybrid chip architecture selected by the user for the first database service, then selects a first server that supports the chip type corresponding to the database node from at least one server cluster of the database platform, and selects a first software image that supports the chip type corresponding to the database node from the database platform. Several possible implementation methods are provided below:

[0059] In a first possible implementation, the hybrid chip architecture includes a hybrid deployment method and a user specifying a corresponding chip type for each database node in the first database service. That is, the user not only selects a hybrid deployment method for the first database service but also specifies a corresponding chip type for each database node included in the first database service. The deployment device obtains the chip type selected by the user for each database node and executes steps S21 and S22 once for each database node included in the first database service.

[0060] Step S21: Based on the chip type selected by the user for a database node, select a first server from the database platform that supports the chip type selected by the user for the database node, and select a first software image from the database platform that supports the chip type selected by the user for the database node.

[0061] Step S22: Based on the first software image of the chip type selected by the user for the database node, deploy the database node on the first server that supports the chip type selected by the user for the database node.

[0062] For example, the first database service includes three database nodes: database node 1, database node 2, and database node 3. The user specifies the Hygon chip type for database node 1, the Kunpeng chip type for database node 2, and the Intel chip type for database node 3. The specific implementation process of step 220 includes: the deployment device selecting a first server supporting the Hygon chip type from at least one server cluster of the database platform, and selecting a first software image supporting the Hygon chip type from the database platform; then, based on the first software image supporting the Hygon chip type, creating database node 1 on the first server supporting the Hygon chip type; subsequently, the deployment device selecting a first server supporting the Kunpeng chip type from at least one server cluster of the database platform, and selecting a first software image supporting the Kunpeng chip type from the database platform; then, based on the first software image supporting the Kunpeng chip type, creating database node 2 on the first server supporting the Kunpeng chip type; subsequently, the deployment device selecting a first server supporting the Intel chip type from at least one server cluster of the database platform, and selecting a first software image supporting the Intel chip type from the database platform; then, based on the first software image supporting the Intel chip type, creating database node 3 on the first server supporting the Intel chip type.

[0063] In the second possible implementation, the hybrid chip architecture includes a hybrid deployment method and multiple chip types selected by the user for the first database service. That is, the user not only selects a hybrid deployment method for the first database service but also selects multiple chip types supported by the first database service, but does not specify the chip type for each database node. The deployment device obtains the multiple chip types selected by the user, and then determines the chip type corresponding to each database node based on the multiple chip types supported by the first database service selected by the user. Then, for each database node included in the first database service, steps S31 and S32 are executed once more.

[0064] Step S31: Based on the chip type corresponding to the database node determined by the deployment device, select a first server from the database platform that supports the chip type corresponding to the database node, and select a first software image from the database platform that supports the chip type corresponding to the database node.

[0065] Step S32: Based on the first software image that supports the chip type corresponding to the database node, deploy the database node on the first server that supports the chip type corresponding to the database node.

[0066] In some embodiments, determining the chip type corresponding to each database node based on the multiple chip types supported by the user-selected first database service can be achieved in the following ways:

[0067] In the first process, based on the multiple chip types selected by the user and the number of nodes included in the first database service, the number of nodes deployed for each of the multiple chip types selected by the user is calculated.

[0068] Taking the first database service as having n nodes and the number of chip types corresponding to the multiple chip types selected by the user as m, let arrays k[1]~k[m] store the node data deployed for the first chip type up to the number of nodes deployed for the m chip type, where k[0]=0, 1≤x≤m. Then the number of nodes n, the number of chip types m, and the number of nodes deployed for each chip type k[x] of the first database service satisfy the following formula (1):

[0069] In formula (1), This indicates the integer division operation.

[0070] For example, the first database service includes 10 nodes, i.e., n is 10; the multiple chip types selected by the user include three types: Hygon chip type, Kunpeng chip type and Intel chip type, i.e., m is 3. Then, by substituting n=10, m=3, x=1 into the above formula (1), we can get the number of nodes deployed for the first chip type k[1]=4; by substituting n=10, m=3, x=2 into the above formula (1), we can get the number of nodes deployed for the second chip type k[2]=4; by substituting n=10, m=3, x=3 into the above formula (1), we can get the number of nodes deployed for the third chip type k[3]=3.

[0071] Step 2: Determine the chip type corresponding to each database node based on the number of nodes deployed for each chip type.

[0072] Taking the three chip types selected by the user, including Hygon, Kunpeng and Intel, as an example, the combination of the number of nodes deployed for these three chip types is 4, 4 and 3 respectively. Which chip type deploys 3 database nodes and which chip type deploys 4 database nodes can be randomly determined by the deployment device or specified by the user. This application does not impose any restrictions on this.

[0073] For example, four database nodes are deployed for Hygon chips, four database nodes are deployed for Kunpeng chips, and three database nodes are deployed for Intel chips; for another example, four database nodes are deployed for Hygon chips, four database nodes are deployed for Intel chips, and three database nodes are deployed for Kunpeng chips; for yet another example, four database nodes are deployed for Kunpeng chips, four database nodes are deployed for Intel chips, and three database nodes are deployed for Hygon chips.

[0074] A third possible implementation involves a hybrid chip architecture, including a hybrid deployment method. In this method, the user selects a hybrid deployment method only for the first database service, without specifying the multiple chip types supported by the first database service or the chip type for each database node. The deployment device determines the chip type selected for each database node based on the hybrid chip architecture selected by the user. Then, steps S31 and S32 are executed again for each database node included in the first database service.

[0075] The deployment device determines the chip type for each database node based on the user-selected hybrid chip architecture in the following ways:

[0076] Step 1: Based on the number of chip types supported by the database platform and the number of nodes included in the first database service, calculate the number of nodes deployed for each chip type supported by all servers included in the database platform.

[0077] The number of chip types supported by the database platform can be understood as the total number of chip types supported by all servers included in the database platform. For example, if the chip types of all servers included in the database platform include the following categories: Hygon, Kunpeng, Intel, Zhaoxin, Loongson, and Shenwei, then the database platform supports a total of 6 chip types.

[0078] Taking the number of nodes included in the first database service as n, the number of chip types supported by the database platform as m, and the number of nodes deployed for each chip type as k[x] as an example, these three parameters also satisfy the above formula (1). The calculation method of the number of nodes deployed for each chip type k[x] can be referred to the relevant description in the second implementation method above, and will not be repeated here.

[0079] Step two involves determining the chip type corresponding to each database node based on the number of nodes deployed for each chip type supported by the database platform. For specific implementation details, please refer to the relevant content in the second implementation method described above; it will not be repeated here.

[0080] A fourth possible implementation involves a hybrid chip architecture with a hybrid deployment mode. The user selects this mode only for the first database service, without specifying the multiple chip types supported by the first database service or the chip type for each database node. The deployment device determines the chip type corresponding to each database node based on the hybrid chip architecture selected by the user and the database type of the first database service.

[0081] The first database service includes database types with master-slave architecture and load balancing. The following explains the specific methods for determining the chip type corresponding to the database node based on these two database types:

[0082] The first approach involves a primary / standby database architecture for the first database service. The deployment device can determine the chip type for both the primary and standby database nodes. For example, the deployment device can randomly select the chip type for the primary and standby database nodes from the chip types supported by the database platform.

[0083] The chip types selected for the primary and backup database nodes can be the same or different. When the primary and backup database nodes have different chip types, for each database node, the chip package size can be determined based on the performance benchmark package selected by the user for the first database service, the performance evaluation score of the benchmark chip corresponding to the performance benchmark package, and the performance evaluation score of the chip type corresponding to that database node. This ensures that the performance of the two database nodes included in the first database service is equivalent. The specific implementation process for determining the chip package size for each database node can be found in the relevant description of step S41 below, and will not be repeated here.

[0084] In the second scenario, the database type of the first database service is a multi-node load balancing type. The deployment device calculates the number of nodes deployed for each chip type supported by the server in the database platform based on the number of chip types supported by the database platform and the number of nodes included in the first database service. Then, based on the number of nodes deployed for each chip type supported by the server in the database platform, it determines the chip type corresponding to the database node. For a detailed implementation process, please refer to the relevant description in the aforementioned third embodiment, which will not be repeated here.

[0085] In any of the possible implementations of Implementation Method 2 above, after determining the chip type corresponding to each database node, the deployment device may further perform the following steps:

[0086] Step S41: Determine the chip package size corresponding to the database node based on the performance benchmark package selected by the user for the first database service, the performance evaluation score of the benchmark chip corresponding to the performance benchmark package, and the performance evaluation score of the chip type corresponding to the database node.

[0087] The performance benchmark package selected by the user for the first database service includes the number of CPU cores and the amount of memory. For example, if the database platform uses an Intel chip as the performance benchmark, the performance benchmark package selected by the user is 2C8G, which means that the performance benchmark package selected by the user using an Intel chip as the benchmark includes 2 CPU cores and 8G of memory.

[0088] Before step S41, the deployment device may first obtain the performance evaluation score of the chip type corresponding to the database node. In one possible implementation, for each chip type supported by the server in the database platform, the following steps are performed: obtaining the performance evaluation matrix corresponding to the chip type, the performance evaluation matrix including performance test data obtained by testing at least one preset performance index of the chip type, the weights corresponding to at least one preset performance index, and the benchmark values ​​corresponding to at least one preset performance index; for the test data corresponding to each preset performance index in the performance evaluation matrix, normalizing the test data corresponding to the preset performance index according to the benchmark value and correction coefficient, to obtain normalized test data; calculating the performance evaluation score of the chip type according to the weights corresponding to each preset performance index in the performance evaluation matrix and the normalized test data corresponding to each preset performance index.

[0089] Specifically, different weights are assigned to each preset performance indicator based on its importance and impact on server performance. The weight refers to the relative importance of a preset performance indicator in the chip performance evaluation; the higher the weight, the more important the preset performance indicator.

[0090] It should be noted that when normalizing test data corresponding to multiple preset performance indicators for a single chip type, the correction coefficients used for different preset performance indicators can be the same or different. However, for the same preset performance indicator across different chip types, the same correction coefficient must be used.

[0091] In this embodiment of the application, the number of CPU cores D of the performance benchmark package and the performance evaluation score T of the benchmark chip corresponding to the performance benchmark package are... d The performance evaluation score T for the chip type corresponding to the database node. c The number of CPU cores C in the chip performance package corresponding to the database node satisfies the following formula (2):

[0092] In formula (2), This indicates the integer division operation.

[0093] For example, if the performance benchmark package is 2C8G, the performance evaluation score of the Intel chip is 100, the performance evaluation score of the Hygon chip is 68, and the performance evaluation score of the Kunpeng chip is 59, then using the above formula (2), the Hygon chip performance package with the same performance as the performance benchmark package can be calculated to be 3C12G, and the Kunpeng chip performance package with the same performance as the performance benchmark package can be calculated to be 4C16G. In this embodiment, the memory is defaulted to 4 times the number of CPU cores. It should be understood that in the specific implementation process, the multiple relationship between memory and the number of CPU cores can also be set according to actual needs, and this application does not limit this.

[0094] Step S42: Based on the chip package size and chip type corresponding to the database node, select the first server that supports the chip type corresponding to the database node from at least one server cluster of the database platform.

[0095] In this application, when creating a database service, a specific chip type is selected as the computing power benchmark to determine the corresponding chip performance package, thereby enabling the calculation of peer-to-peer resource packages for heterogeneous nodes. The same calculation method is used when scaling up or down the database to add database nodes with equivalent performance resources.

[0096] To better explain the embodiments of this application, the following describes a database hybrid deployment method provided by the embodiments of this application in conjunction with a specific implementation scenario. The process of this method can be executed by the deployment device shown in Figure 1. The structure of the deployment device 300 is as shown in Figure 3, including a tag device 301, a chip computing power evaluation device 302, a heterogeneous chip hybrid deployment device 303 within the cluster, and a heterogeneous chip hybrid deployment device 304 for database nodes.

[0097] First, the tag device 301 will be introduced.

[0098] In this embodiment, when creating a server cluster, an inbound server, and an inbound software image on a database platform, the tagging device 301 in the deployment apparatus can add tags or attributes to the operation objects, such as labeling the chip types supported by the operation objects, performance evaluation scores, and other attributes. The operation objects include any of the following: server cluster, server, and software image. The following description uses adding or updating tags to the operation objects as an example. The specific implementation of adding performance evaluation scores or attributes can refer to the implementation method of adding tags, and the specific implementation of updating performance evaluation scores or attributes can refer to the implementation method of updating tags; these details will not be repeated here.

[0099] When creating or storing an object on the database platform, add a supported chip type tag to the object based on the chip type selected by the user; or, when updating a tag on an object on the database platform, update the supported chip type tag for the object based on the chip type updated by the user.

[0100] Figure 4 is a schematic diagram illustrating a chip type label and performance evaluation score setting process in an embodiment of the present invention. This process is executed by the labeling device 301. As shown in Figure 4, the specific process includes:

[0101] Step 401: Select the operation object on the database platform; if the selected operation object is a cluster, proceed to step 402; if the selected operation object is a server, proceed to step 405; if the selected operation object is a software image, proceed to step 409.

[0102] Step 402: Continue to determine the type of operation performed on the cluster. If the operation type is to create a new cluster, continue to step 403; if the operation type is to update cluster attributes, continue to step 404.

[0103] Step 403: Create a new cluster and add a chip type label to the cluster; then determine whether it is successful. If successful, the process ends; if it fails, perform exception handling and end.

[0104] For example, Figure 5 shows a schematic diagram of the cluster label interface. The various heterogeneous chip clusters can support multiple chip architectures such as X86, Kunpeng, and Hygon. When creating a new database cluster, users can add labels for the chip types supported by the cluster in the CPU architecture column.

[0105] Step 404: Update the chip type label of the cluster; if successful, the process ends; if it fails, perform exception handling and end.

[0106] The cluster's chip type labels support adding and deleting operations.

[0107] Step 405: Continue to determine the type of operation performed on the server; if the operation type is to add a new server to the database, then proceed to step 406; if the operation type is to update server attributes, then proceed to step 408.

[0108] Step 406: Import the data into the server database and add a chip type tag to the new server. If successful, proceed to step 407. If it fails, handle the exception and end the process.

[0109] Figure 6 shows a schematic diagram of the server label interface. The host in Figure 6 is the server of this application. Each server supports a fixed type of chip architecture. For any cluster, the chip architecture supported by each server in the cluster can be the same or different. Figure 6 only shows an example of servers in the cluster that are labeled with the same chip type.

[0110] Step 407: Calculate the server's chip performance evaluation score; if successful, the process ends; if it fails, perform exception handling and end the process.

[0111] The server's chip performance evaluation score is recorded in the backend database and is not displayed on the page.

[0112] The specific implementation of step 407 above can be found in the chip performance evaluation method shown in Figure 7 below. The chip performance evaluation score is calculated when each chip type server is first added to the database or when the chip performance evaluation matrix is ​​updated. For servers of the same chip type, the performance evaluation score does not need to be recalculated when they are subsequently added to the database; that is, the performance evaluation score is calculated for the chip type, not for each individual server. For example, when a Hygon chip type server is added to the database for the first time, the performance evaluation score corresponding to the Hygon chip type is calculated. Subsequent additions of Hygon chip servers do not require recalculation of the performance evaluation score. Similarly, the performance evaluation score for other chip type servers is calculated only when they are first added to the database.

[0113] Step 408: Update the chip type label on the server; if successful, the process ends; if it fails, perform exception handling and end the process.

[0114] The server's chip type label supports adding and deleting operations.

[0115] Step 409: Continue to determine the operation type of the software image; if the operation type is to add a new software image to the database, then continue to step 410; if the operation type is to update software image attributes, then continue to step 411.

[0116] Step 410: Import the new software image and add a chip type tag to the software image; if successful, the process ends; if it fails, perform exception handling and end.

[0117] Figure 7 shows a schematic diagram of the software image tab interface. Each software image supports multiple chip architectures. For example, Figure 7 shows software images with X86 chip type and Hygon chip type added.

[0118] Step 411: Update the chip type label of the software image. If successful, the process ends; if it fails, perform exception handling and end the process.

[0119] The chip type label in the software image can be added and deleted.

[0120] The exception handling in each of the above steps mainly involves recording relevant logs for failures, including the time of failure, the operation steps, and the reason for failure.

[0121] The following is an introduction to the chip computing power evaluation device 302.

[0122] Because the CPU performance of servers with different chip types within a database platform varies, when heterogeneous chips are used in a database node deployment, if different nodes within the database service use different types of CPU chips, the performance of different database nodes often differs even with the same number of CPU cores. In this case, if a master-slave architecture database service experiences a master-slave switchover, or if some nodes in a multi-node architecture database service fail, there is a risk of overall or non-linear performance degradation of the database service. Therefore, a key challenge to address when heterogeneous chips are used in database node deployment is to assess the performance differences between different chip types and to equip the master and slave databases or multiple nodes of the same database service with nearly identical computing power. This assessment can be performed by the chip computing power assessment device 302.

[0123] Research and testing have shown that no single metric can fully reflect the differences between different chips in database application scenarios. Therefore, this application proposes a comprehensive evaluation method for server performance across different chip types. This method utilizes general CPU performance test data (including data obtained from performance tests using speccpu and cpubench), combined with other metrics such as CPU clock speed and cache, and heavily relies on database performance test data from the sysbench tool to construct a performance evaluation matrix. The performance evaluation matrix can be represented in tabular form, where the first column is the performance metric name, the second column is the test method, the third column is the measured data (based on the measured data obtained from each test method), the fourth column is the metric weight, and the fifth column is the metric benchmark value. The benchmark value is generally selected from test data of chip types used in large-scale production applications or common applications, such as Intel chips. It should be understood that the performance evaluation matrix can be continuously expanded and updated as computing power evaluation work progresses and test methods are upgraded to more accurately reflect chip computing capabilities, thereby ensuring the performance consistency of database services across multiple nodes.

[0124] For example, Table 1 below shows the performance evaluation matrix of the Hygon 5380 chip, where the benchmark value is the Intel 4314 chip.

[0125] Table 1 Performance Evaluation Matrix of Hygon 5380 Optical Chip

[0126] The following section describes the specific implementation of calculating the performance evaluation scores for each chip type.

[0127] The method for chip performance evaluation is described below with specific examples. Figure 8 is a schematic flowchart illustrating an embodiment of the present invention for calculating a performance evaluation score. As shown in Figure 8, the specific process includes:

[0128] Step 801: Obtain the type of chip to be evaluated.

[0129] Step 802: Determine whether the server's chip type is a new chip type; if it is a new chip type, proceed to step 804; if it is not a new chip type, it means that the chip has already been evaluated, proceed to step 803.

[0130] Step 803: Determine if there are any updates or additions to the test data of the evaluated chip; if yes, proceed to step 804, which updates the performance evaluation data recorded in the database; otherwise, end the process.

[0131] Step 804: Record performance evaluation data and generate a performance evaluation matrix. If successful, proceed to step 805; otherwise, handle the exception and terminate the process.

[0132] The specific process of step 804 includes: obtaining the test results of the server's chip type based on various tools such as CPUBench and SPEC CPU, then recording the chip's performance evaluation data in the database, and generating a performance evaluation matrix.

[0133] Step 805: Normalize the performance evaluation data. If normalization is successful, proceed to step 806; otherwise, handle the exception and terminate the process.

[0134] Since the test data in the chip performance evaluation matrix is ​​provided by different testing tools and the standards are not uniform, the test data needs to be normalized to dimensionless scores before calculating the overall chip performance score. The normalization formula is as follows: (3)

[0135] In formula (3), This indicates that the calculation result is rounded down.

[0136] Where X is the normalized score of the indicator, and the calculation result is rounded to the nearest integer; S is the test data in the third column of the chip performance evaluation matrix; D is the benchmark value of the indicator in the fifth column; and α is the correction coefficient.

[0137] Step 806: Calculate the chip's performance evaluation score based on the normalized dimensionless score; if the performance evaluation score is calculated successfully, continue to step 807; if it fails, handle the exception and end the process.

[0138] The formula for calculating the chip's performance evaluation score is as follows:

[0139] In formula (4), The result is rounded down. T is the chip's performance evaluation score, X(i) is the dimensionless score of the i-th indicator, W(i) represents the weight of the i-th indicator, i∈(1,N) represents the indicator category, and N is the total number of indicators.

[0140] For example, for the performance evaluation matrix of Hygon 5380 shown in Table 1 above, the measured data corresponding to each indicator in the performance evaluation data of the performance evaluation matrix are normalized according to formula (3), and then the performance evaluation score of Hygon 5380 is calculated to be 69 points according to formula (4) above.

[0141] Step 807: Record the performance evaluation score of the chip type in the database; if successful, the process ends; if it fails, the process ends after exception handling. The performance evaluation score of the chip type recorded in the database is used to calculate the performance packages of various chips when heterogeneous chips are mixed in the database nodes.

[0142] The exception handling process in step 807 mainly involves recording failure-related logs, including the time, operation step 80, and reason for failure.

[0143] The following section introduces the heterogeneous chip mixed deployment device 303 within the cluster.

[0144] By setting tag attributes, CPU chip type tags are added to clusters, servers, and software images. Then, servers with different chip types can be added within a logical cluster. During the database software deployment process, the heterogeneous chip mixed deployment device 303 within the cluster can select servers of the same type and deploy software images of the same type within the cluster according to the chip architecture selected by the user.

[0145] Figure 9 is a schematic flowchart illustrating an exemplary database hybrid deployment method in an embodiment of the present invention. This process is executed by the heterogeneous chip hybrid deployment device 303 within the cluster. As shown in Figure 9, the specific process includes:

[0146] Step 901: Apply for the creation of a database service on the database platform.

[0147] Step 902: Select the CPU architecture, i.e., the chip type.

[0148] Figure 10 shows a schematic diagram of the interface for applying to create a database service. The CPU architecture options on this interface include x86, ARM, Hygon, and hybrid. If the user selects any one of x86, ARM, or Hygon, they have chosen a single-chip architecture; if they select hybrid, they have chosen a hybrid chip architecture. In this example, the user selected the x86 chip CPU architecture, meaning they have chosen a single-chip x86 architecture. This means that all database nodes in the database service to be created will use x86 chip type servers.

[0149] Step 903: The database platform deploys database nodes according to the user's application options.

[0150] Step 904: Filter clusters. Check if there are clusters that support the selected chip type based on the cluster's CPU architecture label. If yes, continue to step 905. If not, end the process after exception handling.

[0151] Step 905: Filter servers within the cluster. Filter servers that support the selected chip type by their CPU architecture tags. If a server is found, continue to step 906. Otherwise, handle the exception and end the process.

[0152] Step 906: Filter the software image. Determine whether the selected chip type is supported based on the CPU architecture tag of the software image. If supported, continue to step 907. If not supported, handle the exception and end the process.

[0153] Step 907: Create the database node.

[0154] Step 908: Has the creation been successful? If successful, continue to step 909; if it fails, handle the exception and end the process.

[0155] Step 909: Determine if there are any other database nodes to be deployed. If so, continue to step 904; otherwise, end the process.

[0156] The exception handling process in each of the above steps mainly involves recording failure-related logs, including time, operation steps, and reasons for failure.

[0157] The heterogeneous chip hybrid deployment architecture within the cluster to which the above-mentioned database hybrid deployment method is applicable is shown in Figure 11. The server cluster in this architecture is a hybrid cluster, containing several Hygon, Kunpeng, and X86 servers. Using the hybrid deployment device 303 within the cluster, three database services with different chip types are deployed within the cluster, as shown in Figure 11. These three database services are all in a primary-backup architecture, with the primary and backup databases of each database service having the same CPU chip. Specifically, the CPU chips of the primary and backup database nodes of the first database service are both Hygon chips, the CPU chips of the primary and backup database nodes of the second database service are both Kunpeng chips, and the CPU chips of the primary and backup database nodes of the third database service are both X86 chips.

[0158] Database services are typically deployed across multiple nodes. For example, MySQL can be deployed with two nodes (master and backup), while Kafka can be deployed with three or five nodes depending on requirements. Multiple database nodes can be deployed on servers of a selected chip type within the cluster, as shown in Figure 9 above. In other embodiments, they can also be deployed on heterogeneous chip servers within the cluster. This deployment method can be executed by the heterogeneous chip hybrid deployment device 304. The database platform provides several switches or options to meet personalized hybrid deployment needs: first, it can control whether multiple nodes are deployed via heterogeneous chips; second, it can specify the chip type of multiple nodes; and third, it can select the heterogeneous chip computing power model benchmark. Based on the user's personalized options, the database platform completes the hybrid deployment of multiple database service nodes on heterogeneous chips.

[0159] Figure 12 is a schematic flowchart illustrating an exemplary database hybrid deployment method in an embodiment of the present invention. This process is executed by the heterogeneous chip hybrid deployment device 304 for database nodes. As shown in Figure 12, the specific process includes:

[0160] Step 1201: Apply for the creation of database service on the database platform.

[0161] Step 1202: Select whether to deploy the CPU architecture as "hybrid"; if "hybrid" is selected, continue to step 1203; if other architectures are selected, execute the intra-cluster hybrid deployment process and end.

[0162] In the interface for applying to create a database service shown in Figure 10, the CPU architecture includes X86, ARM, Hygon, and hybrid. If the user selects "hybrid" in the interface for applying to create a database service, that is, selects a hybrid chip architecture, then the database service to be created must support at least two chip types.

[0163] The process of mixing components within the cluster can be referred to the method shown in Figure 9 above, and will not be repeated here.

[0164] Step 1203: Select chip type.

[0165] Because heterogeneous chip servers are used for deployment, two or more chip types need to be selected depending on the type of database service to be deployed. One approach is for the user to specify the chip type for each database node individually. For example, after selecting "Hybrid" in the database service application interface shown in Figure 10, the interface can display multiple chip type options, allowing the user to specify the corresponding chip type for each database node. Another approach is for the user to only specify the hybrid deployment method. For example, after selecting "Hybrid" in the database service application interface shown in Figure 10, the interface can display multiple chip type options, allowing the user to select multiple chip types for the database service to be deployed, but without specifying the chip type for each database node. The database platform then determines the chip type for each database node. Yet another approach involves the database platform determining the chip type for each database node.

[0166] Step 1204: Select the baseline performance package for the database service.

[0167] The baseline performance package includes the number of CPU cores and memory size, such as 2C8G, or 4C16G. The database platform uses Intel chips as the benchmark for the performance package.

[0168] Step 1205: Calculate the package size for other types of chips based on the performance evaluation scores of each type of chip and the selected benchmark performance package.

[0169] The specific calculation method for step 1205 above can be found in the relevant description in step S41 above, and will not be repeated here.

[0170] For example, the baseline package for an Intel chip is 2 cores and 8 gigabytes (2C8G), with a performance evaluation score of 100. The performance evaluation score for a Hygon chip is 68, and the performance evaluation score for a Kunpeng chip is 59. Therefore, the equivalent performance package for a Hygon chip is 3 cores and 12 gigabytes (3C12G), and the equivalent performance package for a Kunpeng chip is 4 cores and 16 gigabytes (the memory is assumed to be 4 times the number of CPU cores).

[0171] Step 1206: Calculate the number of nodes deployed for each type of chip.

[0172] If it is a primary-backup database service, the chip type is determined according to the current node type, such as the primary node being Hygon and the backup node being x86.

[0173] If it is a multi-node load-balanced database service, the distribution is balanced according to the number of nodes and the number of chip types. Assuming that the total number of nodes of the database service is n and there are m types of chips, the calculation method of the number of nodes deployed for the first to m chip types can refer to the above formula (1), which will not be repeated here.

[0174] Step 1207: Deploy each database node sequentially based on the calculation results of the number of nodes deployed for each type of chip and other user application options.

[0175] Step 1208: Filter clusters. Check if there are clusters that support the database node chip type based on the cluster CPU architecture label. If there are, continue to step 1209. If not, handle the exception and end the process.

[0176] Step 1209: Filter servers within the cluster. Filter servers that support the selected chip type by using the server CPU architecture tag. If found, continue to step 1210. If not, handle the exception and end the process.

[0177] Step 1210: Filter the software. Determine whether the selected chip type is supported based on the software image label. If supported, continue to step 1211. If not supported, handle the exception and end the process.

[0178] Step 1211: Create the database service node.

[0179] Step 1212: Has the creation been successful? If so, continue to step 1213. If it fails, handle the exception and end the process.

[0180] Step 1213: Determine if there are any other database nodes to be deployed. If so, continue to step 1208; otherwise, end the process.

[0181] The exception handling process in each of the above steps mainly involves recording failure-related logs, including time, operation steps, and reasons for failure.

[0182] The heterogeneous chip architecture of the database nodes applicable to the above-described hybrid database deployment method is shown in Figure 13. This architecture features a hybrid server cluster containing several Hygon, Kunpeng, and x86 chip servers. Within the cluster are four database services deployed on heterogeneous chips, as shown in Figure 13. These three database services all use a master-slave architecture, with the master and slave databases of each service having different CPU chips. Specifically, the first database service uses a Hygon chip as its master and an x86 chip as its slave. The second database service uses a Kunpeng chip as its master and an x86 chip as its slave. The third database service uses a Hygon chip as its master and a Kunpeng chip as its slave. The fourth database service uses a Kunpeng chip as its master and a Hygon chip as its slave.

[0183] In this embodiment, by co-deploying the primary and backup database nodes on heterogeneous chip servers, the demand for user-specified chips can be met more effectively. This avoids resource shortages on certain types of chip servers while other types of servers remain idle, preventing uneven distribution and resource waste. Taking a primary-backup MySQL database as an example, if the user specifies the use of Hygon chip servers, the primary node can be deployed on a Hygon server, and the backup node on an Intel server. By effectively combining different chips, the advantages of each chip can be fully utilized, improving the heterogeneity of the database, thereby enhancing the performance of the entire database system and improving the continuity of database services and resource utilization efficiency.

[0184] Furthermore, by co-deploying different nodes of various software on heterogeneous chip servers, the data migration efficiency and simplification process of databases and other software during migration and transformation can be improved. Taking the migration of a MySQL database from an Intel server to a Kunpeng server as an example, the previous migration process involved first creating a new Kunpeng database, then migrating the data through logical backup, and finally taking the original Intel database offline. However, this application supports rebuilding the Intel database node to be migrated on the Kunpeng server through the reconstruction function of the Database Cloud Platform (DBAAS) after co-deployment on different chips. Then, through the full database backup and restore function provided by DBAAS, the data migration can be completed quickly, which is more efficient than logical migration. Moreover, the process is simple, the old node is automatically deleted during the reconstruction process, does not occupy additional resources for a long time, and does not require taking the process offline.

[0185] Based on the same technical concept, this application provides a schematic diagram of the structure of a database hybrid deployment device, as shown in Figure 14. The device 1400 includes:

[0186] The acquisition module 1401 is used to acquire a first request, the first request being used to request the creation of a first database service on the database platform, the first database service including at least one database node;

[0187] The processing module 1402 is configured to perform the following for each database node in the first database service: selecting a first server that supports the chip type corresponding to the database node from at least one server cluster of the database platform according to the chip architecture selected by the user for the first database service, and selecting a first software image that supports the chip type corresponding to the database node from the database platform; and deploying the database node on the first server according to the first software image.

[0188] Optionally, the chip architecture is a single-chip architecture that supports the first chip type; the processing module 1402 is specifically used for: selecting a first server that supports the first chip type from at least one server cluster of the database platform according to the single-chip architecture that supports the first chip type selected by the user for the first database service, and selecting a first software image that supports the first chip type from the database platform; and deploying the database node on the selected first server that supports the first chip type according to the selected first software image that supports the first chip type.

[0189] Optionally, the chip architecture is a hybrid chip architecture; the processing module 1402 is used for:

[0190] The chip type corresponding to the database node is determined based on the hybrid chip architecture selected by the user for the first database service;

[0191] The chip package size corresponding to the database node is determined based on the performance benchmark package selected by the user for the first database service, the chip type corresponding to the database node, and the performance evaluation score of the chip type corresponding to the database node.

[0192] Based on the chip package size and chip type corresponding to the database node, a first server that supports the chip type corresponding to the database node is selected from at least one server cluster of the database platform.

[0193] Optionally, the hybrid chip architecture includes a hybrid deployment method and a chip type specified by the user for each database node; the processing module 1402 is specifically used to: determine the chip type specified by the user for the database node based on the hybrid chip architecture selected by the user for the first database service.

[0194] Optionally, the hybrid chip architecture includes a hybrid deployment method and multiple chip types selected by the user for the first database service; the processing module 1402 is specifically used to: calculate the number of nodes deployed for each of the multiple chip types according to the number of chip types corresponding to the multiple chip types selected by the user for the first database service and the number of nodes included in the first database service; and determine the chip type corresponding to the database node according to the number of nodes deployed for each of the multiple chip types.

[0195] Optionally, the hybrid chip architecture includes a hybrid deployment method; the processing module 1402 is specifically used for:

[0196] Based on the number of chip types supported by the server in the database platform and the number of nodes included in the first database service, calculate the number of nodes deployed for each chip type supported by the server in the database platform.

[0197] The chip type corresponding to the database node is determined based on the number of nodes deployed for each chip type supported by the server in the database platform.

[0198] Optionally, the acquisition module 1401 is further configured to: acquire a performance evaluation matrix corresponding to each chip type supported by the server in the database platform, wherein the performance evaluation matrix includes performance test data obtained by testing at least one preset performance index of the chip type, the weights corresponding to the at least one preset performance index, and the benchmark values ​​of the indexes corresponding to the at least one preset performance index.

[0199] The processing module 1402 is further configured to: for each preset performance index in the performance evaluation matrix, normalize the test data corresponding to the preset performance index according to the index benchmark value and correction coefficient, and obtain normalized test data.

[0200] The performance evaluation score of the chip type is calculated based on the weight of each preset performance indicator in the performance evaluation matrix and the normalized test data corresponding to each preset performance indicator.

[0201] Optionally, the processing module 1402 is further configured to:

[0202] When creating or adding an operation object to the database platform, a supported chip type tag is added to the operation object based on the chip type selected by the user; the operation object includes any of the following: cluster, server, and software image; or,

[0203] When performing a tag update operation on an object on the database platform, the supported chip type tags for the object are updated according to the chip type updated by the user.

[0204] The computer device can be the deployment device shown in Figure 1. As shown in Figure 15, the computer device includes at least one processor 1501 and a memory 1502 connected to at least one processor. In this embodiment, the specific connection medium between the processor 1501 and the memory 1502 is not limited. In Figure 15, the processor 1501 and the memory 1502 are connected via a bus. The bus can be divided into address bus, data bus, control bus, etc.

[0205] In this embodiment of the application, the memory 1502 stores instructions that can be executed by at least one processor 1501. By executing the instructions stored in the memory 1502, at least one processor 1501 can perform the steps of the above-described database health assessment method.

[0206] The processor 1501 is the control center of the computer device, capable of connecting various parts of the computer device via various interfaces and lines. It performs database health assessments by running or executing instructions stored in the memory 1502 and accessing data stored in the memory 1502. Optionally, the processor 1501 may include one or more processing units. The processor 1501 may integrate an application processor and a modem processor. The application processor primarily handles the operating system, user interface, and applications, while the modem processor primarily handles wireless communication. It is understood that the modem processor may not be integrated into the processor 1501. In some embodiments, the processor 1501 and the memory 1502 may be implemented on the same chip; in other embodiments, they may be implemented on separate chips.

[0207] Processor 1501 can be a general-purpose processor, such as a central processing unit (CPU), digital signal processor, application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0208] Memory 1502, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules. Memory 1502 may include at least one type of storage medium, such as flash memory, hard disk, multimedia card, card-type memory, random access memory (RAM), static random access memory (SRAM), programmable read-only memory (PROM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), magnetic storage, magnetic disk, optical disk, etc. Memory 1502 can be any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer device, but is not limited thereto. In the embodiments of this application, memory 1502 can also be a circuit or any other device capable of implementing storage functions for storing program instructions and / or data.

[0209] Based on the same inventive concept, embodiments of this application provide a computer-readable storage medium storing a computer program executable by a computer device, which, when run on the computer device, causes the computer device to perform the steps of the above-described database health assessment method.

[0210] Those skilled in the art will understand that embodiments of the present invention can be provided as methods or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied 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.

[0211] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer apparatus or other programmable data processing apparatus, create means for implementing the functions specified in one or more blocks of the flowchart illustrations and / or one or more blocks of the block diagrams.

[0212] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer device or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0213] These computer program instructions may also be loaded onto a computer device or other programmable data processing device to cause a series of operational steps to be performed on the computer device or other programmable device to produce a process implemented by the computer device, such that the instructions, which execute on the computer device or other programmable device, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0214] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0215] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A database hybrid deployment method, characterized in that, include: Obtain a first request, the first request being used to request the creation of a first database service on the database platform, the first database service including at least one database node; The database platform includes at least one server cluster and a software image that supports multiple chip types, with each server cluster including servers that support at least two chip types. For each database node in the first database service, execute: Based on the chip architecture selected by the user for the first database service, a first server that supports the chip type corresponding to the database node is selected from at least one server cluster of the database platform, and a first software image that supports the chip type corresponding to the database node is selected from the database platform. The database node is deployed on the first server based on the first software image.

2. The method as described in claim 1, characterized in that, The chip architecture is a single-chip architecture that supports the first chip type; the step of selecting a first server that supports the chip type corresponding to the database node from at least one server cluster of the database platform, and selecting a first software image that supports the chip type corresponding to the database node from the database platform, based on the chip architecture selected by the user for the first database service, includes: Based on the single-chip architecture that supports the first chip type selected by the user for the first database service, a first server that supports the first chip type is selected from at least one server cluster of the database platform, and a first software image that supports the first chip type is selected from the database platform. The step of deploying the database node on the first server based on the first software image includes: The database node is deployed on the first server that supports the first chip type, based on the first software image selected that supports the first chip type.

3. The method as described in claim 1, characterized in that, The chip architecture is a hybrid chip architecture; the step of selecting a first server that supports the chip type corresponding to the database node from at least one server cluster of the database platform, based on the chip architecture selected by the user for the first database service, includes: The chip type corresponding to the database node is determined based on the hybrid chip architecture selected by the user for the first database service; The chip package size corresponding to the database node is determined based on the performance benchmark package selected by the user for the first database service, the chip type corresponding to the database node, and the performance evaluation score of the chip type corresponding to the database node. Based on the chip package size and chip type corresponding to the database node, a first server that supports the chip type corresponding to the database node is selected from at least one server cluster of the database platform.

4. The method as described in claim 3, characterized in that, The hybrid chip architecture includes a hybrid deployment method and the chip type specified by the user for each database node; The step of determining the chip type corresponding to the database node based on the hybrid chip architecture selected by the user for the first database service includes: Based on the hybrid chip architecture selected by the user for the first database service, determine the chip type specified by the user for the database node.

5. The method as described in claim 3, characterized in that, The hybrid chip architecture includes a hybrid deployment method and multiple chip types selected by the user for the first database service; The step of determining the chip type corresponding to the database node based on the hybrid chip architecture selected by the user for the first database service includes: Based on the number of chip types corresponding to the multiple chip types selected by the user for the first database service and the number of nodes included in the first database service, calculate the number of nodes deployed for each of the multiple chip types. The chip type corresponding to the database node is determined based on the number of nodes deployed for each of the multiple chip types.

6. The method as described in claim 3, characterized in that, The hybrid chip architecture includes a hybrid deployment method; determining the chip type corresponding to the database node based on the hybrid chip architecture selected by the user for the first database service includes: Based on the number of chip types supported by the server in the database platform and the number of nodes included in the first database service, calculate the number of nodes deployed for each chip type supported by the server in the database platform. The chip type corresponding to the database node is determined based on the number of nodes deployed for each chip type supported by the server in the database platform.

7. The method according to any one of claims 1-6, characterized in that, The method further includes: For each chip type supported by the server in the database platform, execute: Obtain the performance evaluation matrix corresponding to the chip type. The performance evaluation matrix includes performance test data obtained by testing at least one preset performance index of the chip type, the weights corresponding to the at least one preset performance index, and the benchmark values ​​of the indexes corresponding to the at least one preset performance index. For each preset performance index in the performance evaluation matrix, the test data corresponding to the preset performance index is normalized according to the index benchmark value and correction coefficient to obtain normalized test data. The performance evaluation score of the chip type is calculated based on the weight of each preset performance indicator in the performance evaluation matrix and the normalized test data corresponding to each preset performance indicator.

8. The method according to any one of claims 1-6, characterized in that, The method further includes: When creating or adding an operation object to the database platform, a supported chip type tag is added to the operation object based on the chip type selected by the user; the operation object includes any of the following: cluster, server, and software image; or, When performing a tag update operation on an object on the database platform, the supported chip type tags for the object are updated according to the chip type updated by the user.

9. A database hybrid deployment device, characterized in that, include: A receiving module is used to obtain a first request, the first request being used to request the creation of a first database service on the database platform, the first database service including at least one database node; The processing module is configured to perform the following for each database node in the first database service: selecting a first server that supports the chip type corresponding to the database node from at least one server cluster of the database platform, based on the chip architecture selected by the user for the first database service, and selecting a first software image that supports the chip type corresponding to the database node from the database platform. The database node is deployed on the first server based on the first software image.

10. A computer device, characterized in that, include: Memory, used to store program instructions; A processor is configured to invoke program instructions stored in the memory and execute the method according to any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions for causing a computer to perform the method according to any one of claims 1 to 8.

Images