A structured query language request processing method and DDM node

Abstract

The present application discloses a SQL request processing method and a DDM node, which can save manpower and time costs to a certain extent. The method of the present application is implemented by a database system, which includes a DDM node and multiple database nodes, and the logic table of the DDM node records the corresponding relationship between each database node and the data stored therein. The method includes: the DDM node can receive a first SQL request. Then, after the DDM node determines that the data to be processed is located in a target database node among multiple database nodes using the first SQL request and its own logic table, it can generate a second SQL request, and the second SQL request is used to request the target database node to process the data, and the second SQL request carries the identifier of the DDM node. Then, the DDM node can send a second SQL request to the target database node. Finally, the DDM node can receive the processing result of the data to be processed returned by the target database, and the processing result can carry the identifier of the DDM node.

Description

[0001] This application claims the priority of the Chinese patent application filed with the State Intellectual Property Office on October 6, 2023, with application number 202311288346.1 and invention name “A problem localization method, device and computing device cluster”, all contents of which are incorporated by reference in this application. Technical Field

[0002] Embodiments of the present application relate to the field of cloud technology, and more particularly to a structured query language (SQL) request processing method and a DDM node. Background Art

[0003] With the rapid development of cloud technology, more and more users choose to deploy their databases in the cloud to enjoy the cloud storage services provided to users by the database system built based on cloud technology. This can not only reduce the cost of local data storage to a certain extent, but also provide sufficient protection for the user's data security.

[0004] In the related art, the database system usually includes multiple distributed database middleware (DDM) nodes and multiple database nodes. Each DDM node can be used as a medium for users to access multiple database nodes, and multiple database nodes can be used to store user data. When a user needs to process one or some data, he can send an SQL request to a DDM node. Then, the DDM node can process the user's SQL request and send the processed request to the database node so that the database node returns the processing results of these data. Finally, the DDM node can return the processing results of these data to the user for the user to use.

[0005] In the above process, if the user reports that there is an abnormality in the processing of this data and reports it to the staff of the database system, the staff needs to find the DDM node that processes this data to view the log to determine the specific cause of the abnormality. Since the database system contains multiple DDM nodes, the staff needs to check each DDM node one by one, which consumes a lot of manpower and time costs. Summary of the invention

[0006] An embodiment of the present application provides a SQL request processing method and a DDM node, which can add a DDM node identifier to a SQL request during the processing of the SQL request, so that the identifier can be used to quickly locate the relevant DDM node in the subsequent process, thereby saving manpower and time costs to a certain extent.

[0007] A first aspect of an embodiment of the present application provides a SQL request processing method, which is applied to a database system, wherein the database system includes a DDM node and multiple database nodes, wherein the DDM node includes a logic table, wherein the logic table records a corresponding relationship between each database node and the data stored therein, and wherein the method includes:

[0008] When a user needs to process the data to be processed, the user may send a first SQL request to the DDM node, where the first SQL request is used to request the DDM node to process the data to be processed that the user needs to process.

[0009] After receiving the first SQL request, the DDM node can use the first SQL request and its own logic table to determine the target database node where the data to be processed by the user is located among multiple database nodes, and then generate a second SQL request, which is used to request the target database node among multiple database nodes to process the data to be processed by the user. It should be noted that the second SQL request carries the identifier of the DDM node.

[0010] After receiving the second SQL request, the DDM node may send the second SQL request to the target database node, so that the target database node processes the data to be processed that the user needs to process based on the second SQL request, thereby obtaining the processing results of the data, and sending the processing results of the data to the DDM node. For example, if the processing results of the data are used to indicate that the processing of the data has failed, the processing results of the data carry the identifier of the DDM node. If the processing results of the data are used to indicate that the processing of the data is successful, the processing results of the data usually do not carry the identifier of the DDM node, because in this case, the user usually opens the processing results of the data to view and confirm the specific processing status of the data, and the identifier of the DDM node, as content not associated with the data, is usually not suitable for display to the user, so as to ensure the user experience.

[0011] After obtaining the processing results of these data, the DDM node can send the processing results of these data to the user's client for the user to use.

[0012] It can be seen from the above method that: if the processing result of the data to be processed is used to indicate that the processing performed on the data has failed, then the processing result of the data fed back by the DDM node to the user may carry the identifier of the DDM node. Therefore, after the user finds that the processing performed by the database system on the data has failed based on the processing results of the data, the user can promptly feedback to the staff of the database system. Therefore, the staff can extract the identifier of the DDM node from the processing results of the data, and determine the DDM node from multiple DDM nodes of the database system based on the identifier of the DDM node, and then check the log in the DDM node to determine the cause of the data processing failure. It can be seen that due to the existence of the identifier for positioning, the staff does not need to check the DDM nodes one by one, and can quickly locate the DDM node responsible for processing the data, thereby saving labor costs and time costs to a certain extent.

[0013] In a possible implementation, after the DDM node determines that the target database node where the data to be processed is stored among multiple database nodes based on the first SQL request and the logic table, the generation of the second SQL request includes: the DDM node generates an identifier of the DDM node; the DDM node splices the identifier of the DDM node with the first SQL request to obtain a third SQL request, the third SQL request is used to request the DDM node to process the data to be processed, and the third SQL request carries the identifier of the DDM node; the DDM node converts the third SQL request to obtain a fourth SQL request, the fourth SQL request is used to request multiple database nodes to process the data to be processed, and the fourth SQL request carries the identifier of the DDM node; after determining that the data to be processed is located in the target database node among multiple database nodes based on the fourth SQL request and the logic table, the DDM node converts the fourth SQL request to obtain the second SQL request. In the aforementioned implementation, after obtaining the first SQL request, the DDM node can use the information of the DDM node to generate a unique identifier of the DDM node bound to the first SQL request. After obtaining the identifier of the DDM node, the DDM node can insert the identifier of the DDM node into the first SQL request, thereby obtaining the third SQL request. After obtaining the third SQL request, the DDM node can make a preliminary translation of the third SQL request to obtain a fourth SQL request pointing to multiple database nodes. After obtaining the fourth SQL request, the DDM node can use the fourth SQL request to query the logical table of the DDM node to detect which database node or nodes among the multiple database nodes the data to be processed that the user needs to process is located in. After determining that the data to be processed is located in the target database node among the multiple database nodes, the DDM node can further translate the fourth SQL to obtain a second SQL request pointing to the target database node. In this process, the identifier is always carried in the third SQL request, the fourth SQL request, and the second SQL request, so that these SQL requests are closely linked. If it is necessary to find any of these SQL requests in the log set of the DDM node later, the identifier can be used to complete the search.

[0014] In one possible implementation, the method further includes: if the time required from receiving the first SQL request to sending the processing result is greater than or equal to a preset first threshold, the DDM node generates a first log, the first log is used to indicate that the third SQL request is a SQL request with low processing efficiency, and the identifier of the DDM node is used as an index for the DDM node to query the first log. In the aforementioned implementation, after the processing results of these data are sent to the user, the DDM node can calculate the time required from the DDM node receiving the first SQL request to the DDM node sending the processing results of these data, and detect whether the time is greater than or equal to the preset first threshold. If the time is greater than or equal to the first threshold, the DDM node can generate a first log in the first log set, and the first log is used to indicate that the third SQL request is a SQL request with low processing efficiency. Then, if the user believes that the DDM node returns the processing results of the data too slowly and gives feedback to the staff, the staff can retrieve the first log in the first log set based on the identifier of the DDM node (because the first log records the third SQL request and the third SQL request carries the identifier of the DDM node), thereby determining that the third SQL request (from the first SQL request) is an SQL request with low processing efficiency, which is equivalent to determining that there is a problem with the DDM node in processing the first SQL request to obtain the second SQL request. Therefore, the staff can solve these problems in a targeted manner.

[0015] In one possible implementation, the method further includes: if the time required from sending the second SQL request to receiving the processing result is greater than or equal to a preset second threshold, the DDM node generates a second log, the second log is used to indicate that the second SQL request is a SQL request with low processing efficiency, and the identifier of the DDM node is used as an index for the DDM node to query the second log. In the aforementioned implementation, after receiving the processing results of the data sent by the target database node, the DDM node can calculate the time required from the DDM node sending the second SQL request to receiving the processing results of the data, and detect whether the time is greater than or equal to the preset second threshold. If the time is greater than or equal to the second threshold, the DDM node can generate a second log in the second log set, and the second log is used to indicate that the second SQL request is a SQL request with low processing efficiency. Then, if the user believes that the DDM node returns the processing results of the data too slowly and gives feedback to the staff, the staff can retrieve the second log in the second log set based on the identifier of the DDM node (because the second log records the second SQL request and the second SQL request carries the identifier of the DDM node), thereby determining that the second SQL request is an SQL request with low processing efficiency, which is equivalent to determining that there is a problem in the link of the target database node processing the second SQL request to obtain the processing results of the data, so the staff can solve these problems in a targeted manner.

[0016] In one possible implementation, the method further includes: the DDM node generates a third log based on the processing result, the third log is used to indicate that the third SQL request is a SQL request that is successfully processed or failed to process, and the identifier of the DDM node is used as the index for the DDM node to query the third log. In the aforementioned implementation, any operation related to the third SQL request performed by the DDM node can generate a corresponding log in the third log set. For example, the DDM node generates an identifier of the DDM node bound to the first SQL request, and this generation operation can be written as a log to the third log set. For another example, the DDM node splices the first SQL request and the identifier of the DDM node bound to the first SQL request to obtain the third SQL request, and this splicing operation can also be written as a log to the third log set. For another example, the DDM node converts the third SQL request into a fourth SQL request, and this conversion operation can also be written as a log to the third log set. For another example, the DDM node converts the fourth SQL request into a second SQL request, and this conversion operation can also be written as a log to the third log set. For another example, when the settlement node sends the second SQL request to the target database node and receives the processing results of these data, this sending operation and this receiving operation can also be written as logs (i.e., the aforementioned third log) into the third log set, etc. Since these logs all contain the identifier of the DDM node, the identifier can be used as an index for the DDM node to query these logs from the third log set, thereby realizing the tracing of the SQL request in the subsequent process.

[0017] In one possible implementation, the identifier of the DDM node includes any one of the following: the network address of the DDM node; the network address of the user and the network address of the DDM node; a numerical value generated based on the network address of the DDM node; or a numerical value generated based on the network address of the user and the network address of the DDM node.

[0018] In a possible implementation, the database system includes multiple DDM nodes, and the DDM node is any one of the multiple DDM nodes.

[0019] A second aspect of an embodiment of the present application provides a DDM node, which is arranged in a database system, and the database system further includes multiple database nodes. The DDM node includes a logic table, and the logic table is used to record the correspondence between each database node and the data stored therein. The DDM node includes: a receiving module, which is used to receive a first SQL request; a processing module, which is used to generate a second SQL request after determining a target database node in which the data to be processed is stored in multiple database nodes based on the first SQL request and the logic table, wherein the second SQL request is used to request the target database node to process the data to be processed, and the second SQL request carries an identifier of the DDM node; a sending module, which is used to send the second SQL request to the target database node; and the receiving module is also used to receive a processing result of the data to be processed returned by the target database node, and the processing result carries the identifier of the DDM node.

[0020] In one possible implementation, the processing module is used to: generate an identifier of a DDM node; concatenate the identifier of the DDM node with the first SQL request to obtain a third SQL request, the third SQL request is used to request the DDM node to process the data to be processed, and the third SQL request carries the identifier of the DDM node; convert the third SQL request to obtain a fourth SQL request, the fourth SQL request is used to request multiple database nodes to process the data to be processed, and the fourth SQL request carries the identifier of the DDM node; after determining that the data to be processed is located in a target database node among multiple database nodes based on the fourth SQL request and the logical table, convert the fourth SQL request to obtain a second SQL request.

[0021] In one possible implementation, the processing module is further used to generate a first log if the time required from receiving the first SQL request to sending the processing result is greater than or equal to a preset first threshold, and the first log is used to indicate that the third SQL request is a SQL request with low processing efficiency, and the identifier of the DDM node is used as an index for the DDM node to query the first log.

[0022] In one possible implementation, the processing module is further used to generate a second log if the time required from sending the second SQL request to receiving the processing result is greater than or equal to a preset second threshold, and the second log is used to indicate that the second SQL request is a SQL request with low processing efficiency, and the identifier of the DDM node is used as an index for the DDM node to query the second log.

[0023] In one possible implementation, the processing module is further used to generate a third log based on the processing result, and the third log is used to indicate whether the third SQL request is a SQL request that is successfully processed or failed to process, and the identifier of the DDM node is used as an index for the DDM node to query the third log.

[0024] In one possible implementation, the identifier of the DDM node includes any one of the following: the network address of the DDM node; the network address of the user and the network address of the DDM node; a numerical value generated based on the network address of the DDM node; or a numerical value generated based on the network address of the user and the network address of the DDM node.

[0025] In a possible implementation, the database system includes multiple DDM nodes, and the DDM node is any one of the multiple DDM nodes.

[0026] A third aspect of an embodiment of the present application provides a computing device cluster, the computing device cluster includes at least one computing device, each computing device includes a processor and a memory: the memory is used to store instructions; the processor is used to enable the computing device cluster to execute the method described in the first aspect or any possible implementation method of the first aspect according to the instructions.

[0027] A fourth aspect of an embodiment of the present application provides a computer storage medium, which stores one or more instructions. When the instructions are executed by one or more computers, the one or more computers implement the method described in the first aspect or any possible implementation method of the first aspect.

[0028] A fifth aspect of the embodiments of the present application provides a computer program product, which stores instructions. When the instructions are executed by a computer, the computer implements the method described in the first aspect or any possible implementation method of the first aspect.

[0029] The embodiment of the present application is implemented through a database system, and the database system may include multiple DDM nodes and multiple database nodes. The logical table included in each DDM node records the corresponding relationship between each database node and the data stored therein. When a user needs to process data, the user may send a first SQL request to a certain DDM node among the multiple DDM nodes, and the first SQL request is used to request the DDM node to process the data to be processed. Then, after the DDM node determines that the data to be processed is located in a target database node among the multiple database nodes using the first SQL request and the logical table of the DDM node, it may generate a second SQL request, and the second SQL request is used to request the target database node among the multiple database nodes to process the data, and the second SQL request carries the identifier of the DDM node. Then, the DDM node may send a second SQL request to the target database node, so that the target database node processes the data to be processed based on the second SQL request, and returns the processing result of the data to be processed to the DDM node, and the processing result may carry the identifier of the DDM node. Finally, the DDM node may send the processing result of the data to be processed to the user. In the above process, if the processing result of the data to be processed is used to indicate that the processing performed on the data to be processed has failed, then the processing result of the data to be processed fed back to the user by the DDM node may carry the identifier of the DDM node. Therefore, after the user finds that the processing performed by the database system on the data has failed based on the processing result of the data to be processed, the user can promptly feedback to the staff of the database system. Therefore, the staff can extract the identifier of the DDM node from the processing result of the data to be processed, and determine the DDM node from multiple DDM nodes of the database system based on the identifier, and then check the log in the DDM node to determine the cause of the data processing failure. It can be seen that due to the existence of the identifier for positioning, the staff does not need to check the DDM nodes one by one, and can quickly locate the DDM node responsible for processing the data, thereby saving labor costs and time costs to a certain extent. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] Figure 1 A schematic diagram of the structure of a database system provided in an embodiment of the present application;

[0031] Figure 2 A structural diagram of a DDM node provided in an embodiment of the present application;

[0032] Figure 3 A schematic diagram of a SQL request processing method provided in an embodiment of the present application;

[0033] Figure 4 Another schematic diagram of the structure of the database system provided in the embodiment of the present application;

[0034] Figure 5A structural diagram of a DDM node provided in an embodiment of the present application;

[0035] Figure 6 A schematic diagram of a structure of a computing device provided in an embodiment of the present application;

[0036] Figure 7 A schematic diagram of the structure of a computing device cluster provided in an embodiment of the present application;

[0037] Figure 8 A schematic diagram of computer devices in a computer cluster provided in an embodiment of the present application being connected via a network. DETAILED DESCRIPTION

[0038] An embodiment of the present application provides a SQL request processing method and a DDM node, which can add a DDM node identifier to a SQL request during the processing of the SQL request, so that the identifier can be used to quickly locate the relevant DDM node in the subsequent process, thereby saving manpower and time costs to a certain extent.

[0039] The terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and need not be used to describe a specific order or sequential order. It should be understood that the terms used in this way can be interchangeable under appropriate circumstances, which is only to describe the distinction mode adopted by the objects of the same attributes when describing in the embodiments of the present application. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, so that the process, method, system, product or equipment comprising a series of units need not be limited to those units, but may include other units that are not clearly listed or inherent to these processes, methods, products or equipment.

[0040] With the rapid development of cloud technology, more and more users choose to deploy their databases in the cloud to enjoy the cloud storage services provided to users by the database system built based on cloud technology. This can not only reduce the cost of local data storage to a certain extent, but also provide sufficient protection for the user's data security.

[0041] In the related art, the database system usually includes multiple DDM nodes and multiple database nodes. Each DDM node can be used as a medium for users to access multiple database nodes, and multiple database nodes can be used to store user data. When a user needs to process one or some data, he can send an SQL request to a DDM node. Then, the DDM node can process the user's SQL request and send the processed request to the database node so that the database node returns the processing results of these data. Finally, the DDM node can return the processing results of these data to the user for the user to use.

[0042] In the above process, if the user reports that there is an abnormality in the processing of these data or reports it to the staff of the database system, the staff needs to find the DDM node that processes these data to view the logs to determine the specific cause of the abnormality. Since the database system contains multiple DDM nodes, the staff needs to check each DDM node one by one, which consumes a lot of manpower and time costs.

[0043] Furthermore, since the user may have sent different SQL requests to the DDM node successively, these SQL requests may get the same processed SQL request after being processed by the DDM node. If the processed SQL request has problems in the subsequent processing, the staff cannot determine which SQL request of the user it came from when querying the log, so the staff needs to ask the user to cooperate in the analysis, resulting in a poor user experience.

[0044] Furthermore, based on the above problems, when users encounter data processing exceptions, due to a series of problems such as the location of DDM nodes and the tracing of SQL requests, the resolution of data processing exceptions is quite slow, which may cause users to be dissatisfied with the cloud services provided by the database system, resulting in user complaints.

[0045] In order to solve the above problems, an embodiment of the present application provides a SQL request processing method, which can be implemented through a database system. Figure 1 A schematic diagram of the structure of the database system provided in the embodiment of the present application is shown in FIG. Figure 1 As shown, the database system includes an infrastructure for providing storage services, which includes multiple DDM nodes and multiple database nodes, wherein any DDM node is connected to multiple database nodes in communication, that is, any DDM node can access multiple database nodes. The following introduces the DDM node and the database node respectively:

[0046] DDM nodes can also be called computing nodes. Multiple DDM nodes can be presented as a whole to the user's client as DDM. When the user's client accesses DDM, it can randomly access any DDM node among the multiple DDM nodes contained in DDM and send SQL requests to the DDM node so that the DDM completes the corresponding data processing for the SQL request. It is worth noting that Figure 2 As shown ( Figure 2A structural diagram of a DDM node provided in an embodiment of the present application) is provided. For any one of the multiple DDM nodes, the DDM node may include a first transceiver module, a marking module, a conversion module, a second transceiver module and a log module. Among these modules, the first transceiver module, the marking module and the conversion module can be understood as Biz threads run by the DDM node, and the second transceiver module can be understood as input / output (IO) threads run by the DDM node. The first transceiver module can be used to receive an initial SQL request sent by a user's client, the marking module is used to mark the initial SQL request with a unique identifier to obtain an initial SQL request carrying the identifier, the conversion module is used to convert the initial SQL request carrying the identifier into an intermediate SQL request carrying the identifier, and then convert the intermediate SQL request carrying the identifier into a final SQL request carrying the identifier, and the second transceiver module is used to send the final SQL request carrying the identifier to one or more database nodes (database nodes) so that the database node returns a corresponding SQL response, and returns the SQL response to the first transceiver module so that the first transceiver module returns the SQL response to the user's client. It is worth noting that the log module may include a logical slow SQL log set, a physical slow SQL log set and a regular SQL log set. When the first transceiver module, the marking module, the conversion module and the second transceiver module perform corresponding operations, the actual operation results may be written into each unit in the log module, which will not be expanded here.

[0047] A database node can also be called a storage node. Multiple database nodes can be used to store user data. For any of the multiple database nodes, if the database node receives the final SQL request with an identifier sent by the DDM node, it can process the data indicated by the SQL request to obtain the data processing result as a response to the SQL request and return it to the DDM node.

[0048] Furthermore, for any one of the multiple DDM nodes or any one of the multiple database nodes, since the database system can be built based on cloud technology, the DDM node or the database node can essentially be a cloud instance in the cloud service system. The cloud instance can be presented in a variety of ways. For example, the cloud instance can be a physical server designated by the cloud management platform. For example, the cloud instance can also be a virtual machine (VM) created by the cloud management platform on the physical server through virtualization technology. For example, the cloud instance can also be a container (docker) created by the cloud management platform on the physical server through virtualization technology. For example, the cloud instance can also be a micro virtual machine (microVM) created by the cloud management platform on the physical server through virtualization technology. For example, the cloud instance can also be a container created by the cloud management platform on the physical server through virtualization technology. For example, the cloud instance can also be a bare metal server designated by the cloud management platform, and so on.

[0049] Furthermore, multiple DDM nodes or multiple database nodes can generally be set up in one site or multiple sites. The sites can be presented in various forms. For example, one or more sites can be multiple regions in the infrastructure. For another example, one or more sites can be multiple availability zones in the infrastructure. For another example, one or more sites can be at least one edge site and at least one central cloud site in the infrastructure, and so on.

[0050] Based on the above database system, it can be known that in the link of user-DDM node-database node, the SQL request will be marked with a unique identifier by the DDM node, so the operation results for the SQL request carrying the identifier will be recorded as logs in the log module of the DDM node, for example, whether the database node successfully processes the SQL request carrying the identifier, whether the database node processes the SQL request carrying the identifier inefficiently (i.e., the processing is slow), whether the DDM node and the database node as a whole process the SQL request carrying the identifier inefficiently, etc. Based on this, once the user or the staff of the database system finds that there is an abnormality in the processing of the SQL request carrying the identifier (for example, the processing fails or the processing efficiency is low, etc.), since the identifier is used to indicate the DDM node that marks the SQL request, the staff can quickly locate the DDM node based on the identifier and view the specific log to determine what kind of problem occurred in the processing of the SQL request, so as to provide timely feedback to the user.

[0051] In order to better understand the workflow of the above database system, Figure 3 This workflow is further introduced. Figure 3A schematic diagram of a SQL request processing method provided in an embodiment of the present application, such as Figure 3 As shown, this method is applied to Figure 1 The database system shown includes multiple DDM nodes and multiple database nodes. The method includes:

[0052] 301. A DDM node receives a first SQL request, where the first SQL request is used to request the DDM node to process data to be processed.

[0053] In this embodiment, when a user has data to be processed, the user can send a first SQL request (i.e., an initial SQL request) to any one of the multiple DDM nodes through the client used by the user, wherein the first SQL request includes a first SQL statement, and the first SQL statement can be used to instruct the DDM node to process the data to be processed. Therefore, the first SQL request can be used to request the DDM node to process the data to be processed that the user needs to process.

[0054] It should be noted that the DDM node can access multiple database nodes, each of which stores a certain amount of data. It is worth noting that the DDM node includes a logic table, which can record the corresponding relationship between each database node and the data stored therein.

[0055] For example, Figure 4 As shown ( Figure 4 Another structural diagram of the database system provided in the embodiment of the present application) is provided, assuming that the database system includes DDM and 4 database nodes, the user can deploy his own physical database in the database system, and the user has data 1 and data 2. Each DDM node constituting the DDM is deployed with a logical database corresponding to the user's physical database, and the logical database can correspond one-to-one to 4 sub-physical databases (deployed on 4 remote database nodes respectively), wherein the physical table 0 of the sub-physical database 0 on the database node 0 stores data 1, and the physical table 6 of the sub-physical database 2 on the database node 2 stores data 2. It can be seen that the user's physical database is deployed in a distributed architecture, presented as sub-physical database 0 and sub-physical database 2.

[0056] It should be noted that the logical database of the DDM node may include a logical table, and the logical table may record the correspondence between the four sub-physical databases (that is, the four database nodes) and the physical tables they contain, as well as the correspondence between the 12 physical tables and all the data stored in them. For example, the logical table may record the following correspondence: the sub-physical database 0 of the database node 0 contains the physical table 0, the physical table 1, and the physical table 2, the physical table 0 contains the data 1, etc., the physical table 1 contains some data, etc., the physical table 2 contains other data, etc. As for the other sub-physical databases, it is similar and will not be repeated here.

[0057] If the user needs to confirm the amount of data stored in the database system, he can send an initial SQL request to DDM, so a DDM node in DDM can successfully receive the initial SQL request from the user, and the initial SQL request can be "select count(*)from table". It should be noted that the user deploys his own independent physical database in the database system, so when the user edits the initial SQL request, he usually considers asking the DDM node to open its physical database to realize data processing. In other words, the "table" in the initial SQL request can be understood as the physical table of the user's own physical database, because the user cannot perceive the existence of logical databases and sub-physical databases, etc.

[0058] 302. After the DDM node determines that the data to be processed is stored in a target database node among multiple database nodes based on the first SQL request and the logical table of the DDM node, it generates a second SQL request, where the second SQL request is used to request the target database node among the multiple database nodes to process the data to be processed, and the second SQL request carries an identifier of the DDM node.

[0059] After receiving the first SQL request, the DDM node can use the first SQL request and its own logical table to determine the target database node among multiple database nodes where the data to be processed that the user needs to process is located, and then generate a second SQL request (i.e., the final SQL request carrying an identifier), wherein the second SQL request includes a second SQL statement and the identifier of the DDM node (also referred to as the tracing information of the DDM node). The second SQL statement can be used to instruct the target database node among multiple database nodes to process the data to be processed that the user needs to process, so the second SQL request can be used to request the target database node among multiple database nodes to process the data to be processed that the user needs to process.

[0060] Specifically, the DDM node can obtain the second SQL request in the following manner:

[0061] (1) After receiving the first SQL request, the DDM node can use the information of the DDM node (of course, it can also use the information of the user and the information of the DDM node, etc.) to generate a unique identifier of the DDM node bound to the first SQL request, so the identifier can be used to indicate the DDM node. Among them, the user information can include the user's network address, etc., and the information of the DDM node can include the network address of the DDM node, etc., so the identifier can be presented in a variety of ways, for example, the identifier can be presented as the network address of the DDM node, for example, the identifier can be presented as the network address of the user and the network address of the DDM node, for example, the identifier can also be presented as a value obtained by performing a series of calculations on the network address of the DDM node, for example, the identifier can also be presented as a value obtained by performing a series of calculations on the network address of the user and the network address of the DDM node, etc.

[0062] As in the above example, after receiving the initial SQL request, the DDM node can generate a special and unique value "d682a3bb000000" using the user's network address and the DDM node's network address. Then, the value can be used as the identifier of the DDM node bound to the initial SQL request.

[0063] (2) After obtaining the identifier of the DDM node, the DDM node can concatenate the identifier of the DDM node and the first SQL request to obtain a third SQL request (i.e., the initial SQL request carrying the identifier). The third SQL request includes the first SQL statement and the identifier of the DDM node. The first SQL statement can be used to instruct the DDM node to process the pending data that the user needs to process, so the third SQL request can be used to request the DDM node to process the pending data that the user needs to process.

[0064] Still as in the above example, after obtaining the identifier, the DDM node can concatenate the identifier with the initial SQL request to obtain the initial SQL request carrying the identifier. The initial SQL request carrying the identifier can be " / *d682a3bb000000* / select count(*)from table". It can be understood that the initial SQL request carrying the identifier is also used to request the DDM node to open the user's physical database to realize data processing.

[0065] (3) After obtaining the third SQL request, the DDM node may convert the third SQL request to obtain a fourth SQL request (i.e., an intermediate SQL request carrying an identifier). The fourth SQL request includes the third SQL statement and the identifier. The third SQL statement is used to instruct multiple database nodes to process the pending data required by the user. The fourth SQL request carries the identifier, so the fourth SQL request can be used to request multiple database nodes to process the pending data required by the user.

[0066] Still as in the above example, after obtaining the initial SQL request carrying the identifier, the DDM node can convert the initial SQL request carrying the identifier to obtain an intermediate SQL request carrying the identifier, and the intermediate SQL request carrying the identifier can be " / *d682a3bb000000* / select sum(*)from table". It should be noted that since the initial SQL request carrying the identifier is used to request the DDM node to open the user's physical database to realize data processing, and the DDM node is deployed with a logical database corresponding to the physical database, the "table" in the intermediate SQL request carrying the identifier obtained by the DDM node can be understood as the logical table of the logical database, that is, the intermediate SQL request carrying the identifier can be used to request the DDM node to open the logical database to realize data processing. Since the logical database corresponds to the four sub-physical databases on the four database nodes, the intermediate SQL request carrying the identifier can also be used to request the four database nodes to open the four sub-physical databases to realize data processing.

[0067] (4) After obtaining the fourth SQL request, the DDM node may query the logical table of the DDM node based on the fourth SQL request to detect which database node or nodes among the multiple database nodes the to-be-processed data to be processed by the user is located. The database node where the to-be-processed data to be processed by the user is located is referred to as the target database node hereinafter (the number of target database nodes is at least one, and the at least one target database node may be one of the multiple database nodes, or may be a part of the multiple database nodes, or may be all of the multiple database nodes, which is not limited here). After determining that the to-be-processed data to be processed by the user is located in the target database node among the multiple database nodes, the DDM node may further convert the fourth SQL request to obtain the second SQL request.

[0068] Still as in the above example, after receiving the intermediate SQL request carrying the identifier, the DDM node can open the logical table of the logical database based on the request. The logical table records the correspondence between the 4 sub-physical databases and the physical tables they contain, and the correspondence between the 12 physical tables and the data stored in them. Then, the DDM node can traverse the logical table to determine from the logical table that data 1 is located in physical table 0, and data 2 is located in physical table 6. In this way, the DDM node can determine that data 1 and data 2 that the user needs to process are located in sub-physical database 0 of database node 0 and sub-physical database 2 of database node 2, respectively.

[0069] Subsequently, the DDM node may further transform the intermediate SQL request carrying the identifier, thereby obtaining the final SQL request 1 carrying the identifier and the final SQL request 2 carrying the identifier. The final SQL request 1 carrying the identifier may be " / *d682a3bb000000* / select count(*)from table_0", and the final SQL request 1 carrying the identifier may be used to request database node 0 to open sub-physical database 0 to implement data processing. The final SQL request 2 carrying the identifier may be " / *d682a3bb000000* / select count(*)from table_6", and the final SQL request 2 carrying the identifier may also be used to request database node 2 to open sub-physical database 2 to implement data processing.

[0070] 303. The DDM node sends a second SQL request to the target database node.

[0071] 304. The DDM node receives the processing result of the to-be-processed data from the target database node, where the processing result carries the identifier of the DDM node.

[0072] After obtaining the second SQL request, the DDM node may send the second SQL request to the target database node, so that the target database node processes the to-be-processed data required by the user based on the second SQL request, thereby obtaining the processing results of the data, and sending the processing results of the data to the DDM node. After obtaining the processing results of the data, the DDM node may send the processing results of the data to the user's client for the user to use.

[0073] Specifically, the processing results of these data can be presented in the following ways:

[0074] The processing results of the data sent by the target database node to the DDM node, if the processing results of the data are used to indicate that the processing of the data is successful, the processing results of the data usually do not carry the identification of the DDM node, if the processing results of the data are used to indicate that the processing of the data has failed, the processing results of the data carry the identification of the DDM node. In this way, once the user checks the processing results of the data and finds that the processing of the data has failed, or the staff monitors the processing results of the data in real time and finds that the processing of the data has failed, the identification carried in the processing results can be directly used to locate the DDM node to further confirm the cause of the failure of the processing of the data.

[0075] Still like the above example, after receiving the final SQL request 1, database node 0 can open sub-physical database 0, and after detecting that data 1 is stored in physical table 0, it can be determined that sub-physical database 0 stores 1 data of the user, so the processing result can be generated as "1". Similarly, after receiving the final SQL request 2, database node 2 can open sub-physical database 2, and after detecting that data 2 is stored in physical table 6, it can be determined that sub-physical database 2 stores 1 data of the user, so the processing result can be generated as "1". Then, database node 0 and database node 2 can return the processing results to the DDM node respectively, so the DDM node can summarize the processing results, and the summarized processing result is "2", which can be used to indicate that the processing performed on data 1 and data 2 is successful. Subsequently, the DDM node can return the summarized processing results to the user for the user to use.

[0076] It is worth noting that if database node 0 and database node 2 encounter certain failures during the execution of the above operations, they will not be able to process the data that the user needs to process. In this case, the processing results generated by database node 0 and database node 2 are both " / *d682a3bb000000* / error". Then, database node 0 and database node 2 can return the processing results to the DDM node respectively, so the DDM node can summarize the processing results. The summarized processing result is " / *d682a3bb000000* / error", which can be used to indicate that the processing of data 1 and data 2 has failed. Subsequently, the DDM node can return the summarized processing results to the user to let the user know.

[0077] More specifically, the DDM node includes a first log set (i.e., a logical slow SQL log set), so the DDM node can record logs in the following manner:

[0078] After sending the processing results of these data to the user's client, the DDM node can calculate the time required from the DDM node receiving the first SQL request to the DDM node sending the processing results of these data, and detect whether the time is greater than or equal to the preset first threshold (the size of the first threshold can be set according to actual needs and is not limited here). If the time is greater than or equal to the preset first threshold, the DDM node can generate a first log (i.e., a logical slow SQL log) in the first log set, and the first log is used to indicate that the third SQL request is an SQL request with low processing efficiency. Since the third SQL request carries the identifier of the DDM node, the identifier of the DDM node can be used as an index for the DDM node to query the first log from the first log set.

[0079] As in the above example, after the DDM node returns the aggregated processing results to the user, it can calculate the time required from receiving the initial SQL request to returning the processing results. If the time is greater than or equal to a certain threshold, the DDM node records the following logical slow SQL log "slow SQL: / *d682a3bb000000* / selectcount(*)from table" in the logical slow SQL log collection. It can be seen that the identifier "d682a3bb000000" can be used as the index for the DDM node to query the logical slow SQL log from the logical slow SQL log collection.

[0080] More specifically, the DDM node includes the second log set (i.e., the physical slow SQL log set), so the DDM node can record logs in the following ways:

[0081] After receiving the processing results of the data sent by the target database node, the DDM node can calculate the time required for the DDM node to send the second SQL request and receive the processing results of the data, and detect whether the time is greater than or equal to the preset second threshold (the size of the second threshold can be set according to actual needs and is not limited here). If the time is greater than or equal to the preset second threshold, the DDM node can generate a second log (i.e., a physical slow SQL log) in the second log set, and the second log is used to indicate that the second SQL request is an SQL request with low processing efficiency. Since the second SQL request carries the identifier of the DDM node, the identifier of the DDM node can be used as an index for the DDM node to query the second log from the second log set.

[0082] Still as in the above example, after the DDM node receives the processing results returned by database node 0 and database node 2, it can calculate the time required from sending the final SQL request carrying the identifier to receiving the processing result. If the time is greater than or equal to another threshold, the DDM node records the following physical slow SQL log "slowSQL: / *d682a3bb000000* / select count(*)from table_0, / *d682a3bb000000* / select count(*)from table_6" in the physical slow SQL log collection. It can be seen that the identifier "d682a3bb000000" can be used as the index for the DDM node to query the physical slow SQL log from the physical slow SQL log collection.

[0083] More specifically, the DDM node includes a third log set (i.e., a conventional SQL log set), so the DDM node can record logs in the following manner:

[0084] After receiving the processing results of the data sent by the target database node, the DDM node can also generate a third log in the third log set based on the processing results of the data, and the third log is used to indicate whether the third SQL request is a SQL request that is successfully processed or failed to process. Since the third SQL request carries the identifier of the DDM node, the identifier of the DDM node can be used as an index for the DDM node to query the third log from the third log set.

[0085] It should be understood that any operation performed by the DDM node related to the third SQL request can generate a corresponding log in the third log set. For example, the DDM node generates an identifier of the DDM node bound to the first SQL request, and this generation operation can be written as a log in the third log set. For another example, the DDM node splices the first SQL request and the identifier of the DDM node bound to the first SQL request to obtain the third SQL request, and this splicing operation can also be written as a log in the third log set. For another example, the DDM node converts the third SQL request into a fourth SQL request, and this conversion operation can also be written as a log in the third log set. For another example, the DDM node converts the fourth SQL request into a second SQL request, and this conversion operation can also be written as a log in the third log set, and so on. Since these logs all contain the identifier, the identifier can be used as an index for the DDM node to query these logs from the third log set.

[0086] The embodiment of the present application is implemented through a database system, and the database system may include multiple DDM nodes and multiple database nodes. The logical table included in each DDM node records the corresponding relationship between each database node and the data stored therein. When a user needs to process data, the user may send a first SQL request to a certain DDM node among the multiple DDM nodes, and the first SQL request is used to request the DDM node to process the data to be processed. Then, after the DDM node determines that the data to be processed is located in a target database node among the multiple database nodes using the first SQL request and the logical table of the DDM node, it may generate a second SQL request, and the second SQL request is used to request the target database node among the multiple database nodes to process the data, and the second SQL request carries the identifier of the DDM node. Then, the DDM node may send a second SQL request to the target database node, so that the target database node processes the data to be processed based on the second SQL request, and returns the processing result of the data to be processed to the DDM node, and the processing result may carry the identifier of the DDM node. Finally, the DDM node may send the processing result of the data to be processed to the user. In the above process, if the processing result of the data to be processed is used to indicate that the processing performed on the data to be processed has failed, then the processing result of the data to be processed fed back to the user by the DDM node may carry the identifier of the DDM node. Therefore, after the user finds that the processing performed by the database system on the data has failed based on the processing result of the data to be processed, the user can promptly feedback to the staff of the database system. Therefore, the staff can extract the identifier of the DDM node from the processing result of the data to be processed, and determine the DDM node from multiple DDM nodes of the database system based on the identifier, and then check the log in the DDM node to determine the cause of the data processing failure. It can be seen that due to the existence of the identifier for positioning, the staff does not need to check the DDM nodes one by one, and can quickly locate the DDM node responsible for processing the data, thereby saving labor costs and time costs to a certain extent.

[0087] Furthermore, in an embodiment of the present application, if the user sends different initial SQL requests (i.e., the first SQL request) to the DDM node, since the identifier generated by the DDM node for each initial SQL request is unique, even if different initial SQL requests are converted into the same final SQL request (i.e., the second SQL request) by the DDM node, the DDM node will make these final SQL requests carry the identifiers bound to each initial SQL request, so that these final SQL requests carrying their respective identifiers can be distinguished. In this way, once the processing efficiency for a certain final SQL request is low, when the staff queries the physical slow SQL log set of the DDM node, they can directly trace back to the corresponding initial SQL request based on the identifier carried by the final SQL request. In this way, the staff can complete the source analysis of the slow SQL request by themselves and feedback to the user, thereby improving the user experience.

[0088] Furthermore, in an embodiment of the present application, the DDM node is not only provided with a physical slow SQL log set, but also provided with a logical slow SQL log set. Once it is determined that the processing efficiency of a certain initial SQL request reported by the user is low, the staff can determine the identifier bound to the initial SQL request, and query from the physical slow SQL log set and the logical slow SQL log set of the DDM node based on the identifier. If only a log is queried from the physical slow SQL log set indicating that the final SQL request carrying the identifier is a slow SQL request, it means that there is a problem in the database node when processing the final SQL request to obtain the processing result of the data. If only a log is queried from the logical slow SQL log set indicating that the initial SQL request carrying the identifier is a slow SQL request, it means that there is a problem in the DDM node when processing the initial SQL request to obtain the final SQL request carrying the identifier. In this way, the staff can determine the cause of the slow SQL request by themselves, solve these problems and feedback to the user, thereby further improving the user experience.

[0089] Furthermore, in the embodiment of the present application, due to the existence of the identifier, a series of problems such as the positioning of the DDM node and the tracing of the SQL request are quickly resolved, which can avoid user complaints about the database system to a certain extent.

[0090] The above is a detailed description of the SQL request processing method provided in the embodiment of the present application. The following will introduce the DDM node provided in the embodiment of the present application. Figure 5 A structural diagram of a DDM node provided in an embodiment of the present application, such as Figure 5As shown, the DDM node is set in the database system, and the database system also includes multiple database nodes. The DDM node includes a logic table, and the logic table is used to record the corresponding relationship between each database node and the data stored therein. The DDM node includes:

[0091] Receiving module 501, used for receiving a first SQL request;

[0092] A processing module 502 is used to generate a second SQL request after determining a target database node in which the data to be processed is stored among the multiple database nodes based on the first SQL request and the logic table, wherein the second SQL request is used to request the target database node to process the data to be processed, and the second SQL request carries an identifier of the DDM node;

[0093] A sending module 503 is used to send a second SQL request to a target database node;

[0094] The receiving module 501 is further used to receive the processing result of the to-be-processed data returned by the target database node, where the processing result carries the identifier of the DDM node.

[0095] In one possible implementation, the processing module 502 is used to: generate an identifier of a DDM node; concatenate the identifier of the DDM node with the first SQL request to obtain a third SQL request, where the third SQL request is used to request the DDM node to process the data to be processed, and the third SQL request carries the identifier of the DDM node; convert the third SQL request to obtain a fourth SQL request, where the fourth SQL request is used to request multiple database nodes to process the data to be processed, and the fourth SQL request carries the identifier of the DDM node; after determining that the data to be processed is located in a target database node among multiple database nodes based on the fourth SQL request and the logical table, convert the fourth SQL request to obtain a second SQL request.

[0096] In one possible implementation, the processing module 502 is further used to generate a first log if the time required from receiving the first SQL request to sending the processing result is greater than or equal to a preset first threshold, and the first log is used to indicate that the third SQL request is a SQL request with low processing efficiency, and the identifier of the DDM node is used as an index for the DDM node to query the first log.

[0097] In one possible implementation, the processing module 502 is further used to generate a second log if the time required from sending the second SQL request to receiving the processing result is greater than or equal to a preset second threshold, and the second log is used to indicate that the second SQL request is a SQL request with low processing efficiency, and the identifier of the DDM node is used as an index for the DDM node to query the second log.

[0098] In one possible implementation, the processing module 502 is further used to generate a third log based on the processing result, where the third log is used to indicate whether the third SQL request is a SQL request that is successfully processed or failed to process, and the identifier of the DDM node is used as an index for the DDM node to query the third log.

[0099] In one possible implementation, the identifier of the DDM node includes any one of the following: the network address of the DDM node; the network address of the user and the network address of the DDM node; a numerical value generated based on the network address of the DDM node; or a numerical value generated based on the network address of the user and the network address of the DDM node.

[0100] In a possible implementation, the database system includes multiple DDM nodes, and the DDM node is any one of the multiple DDM nodes.

[0101] It should be noted that the information interaction, implementation process, etc. between the modules / units of the above-mentioned device are based on the same concept as the method embodiment of the present application, and the technical effects they bring are the same as those of the method embodiment of the present application. For specific contents, please refer to the description in the method embodiment shown above in the embodiment of the present application, and will not be repeated here.

[0102] See also Figure 6 , Figure 6 A schematic diagram of the structure of a computing device provided in an embodiment of the present application. Figure 6 As shown, the computing device 600 (which can be used to present the aforementioned DDM node) includes: a processor 601, a memory 602, a communication interface 603 and a bus 604. The processor 601, the memory 602 and the communication interface 603 are coupled via a bus (not marked in the figure). The memory 602 stores instructions. When the execution instructions in the memory 602 are executed, the computing device 600 executes the method executed by the DDM node in the above method embodiment.

[0103] The computing device 600 may be one or more integrated circuits configured to implement the above method, such as one or more application specific integrated circuits (ASIC), or one or more microprocessors (digital signal processors, DSP), or one or more field programmable gate arrays (FPGA), or a combination of at least two of these integrated circuit forms. For another example, when the unit in the device can be implemented in the form of a processing element scheduler, the processing element can be a general-purpose processor, such as a central processing unit (CPU) or other processor that can call a program. For another example, these units can be integrated together and implemented in the form of a system-on-a-chip (SOC).

[0104] The processor 601 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, transistor logic devices, hardware components or any combination thereof. The general-purpose processor may be a microprocessor or any conventional processor.

[0105] The memory 602 may be a volatile memory or a nonvolatile memory, or may include both volatile and nonvolatile memories. Among them, the nonvolatile memory may be a read-only memory (ROM), a programmable ROM (PROM), an erasable programmable ROM (EPROM), an electrically erasable programmable ROM (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM).

[0106] The memory 602 stores executable program codes, and the processor 601 executes the executable program codes to respectively implement the functions of the aforementioned receiving module, processing module, and sending module, thereby implementing the aforementioned SQL request processing method. That is, the memory 602 stores instructions for executing the aforementioned SQL request processing method.

[0107] The communication interface 603 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the computing device 600 and other devices or a communication network.

[0108] In addition to the data bus, the bus 604 may also include a power bus, a control bus, a status signal bus, etc. The bus may be a peripheral component interconnect express (PCIe) bus, or an extended industry standard architecture (EISA) bus, a unified bus (Ubus or UB), a compute express link (CXL), a cache coherent interconnect for accelerators (CCIX), etc. The bus may be divided into an address bus, a data bus, a control bus, etc.

[0109] See also Figure 7 , Figure 7 A schematic diagram of the structure of a computing device cluster provided in an embodiment of the present application. Figure 7 As shown, the computing device cluster 700 includes at least one computing device 600 .

[0110] like Figure 7 As shown, the computing device cluster 700 includes at least one computing device 600. The memory 602 in one or more computing devices 600 in the computing device cluster 700 may store the same instructions for executing the above SQL request processing method.

[0111] In some possible implementations, the memory 602 of one or more computing devices 600 in the computing device cluster 700 may also store partial instructions for executing the above SQL request processing method. In other words, a combination of one or more computing devices 600 may jointly execute the above SQL request processing method.

[0112] It should be noted that the memory 602 in different computing devices 600 in the computing device cluster 700 can store different instructions, which are respectively used to execute part of the functions of the above-mentioned cloud management platform. That is, the instructions stored in the memory 602 in different computing devices 600 can implement the functions of one or more modules of the receiving module, the processing module, the sending module, etc.

[0113] In some possible implementations, one or more computing devices 600 in the computing device cluster 700 may be connected via a network, which may be a wide area network or a local area network.

[0114] See also Figure 8 , Figure 8A schematic diagram of computer devices in a computer cluster provided in an embodiment of the present application being connected via a network. Figure 8 As shown, two computing devices 600A and 600B are connected via a network. Specifically, they are connected to the network via a communication interface in each computing device.

[0115] In a possible implementation, the memory in the computing device 600A stores instructions for executing functions of the receiving module, the sending module, etc. Meanwhile, the memory in the computing device 600B stores instructions for executing functions of the processing module, etc.

[0116] It should be understood that Figure 8 The functions of the computing device 600A shown in FIG. 6A may also be completed by multiple computing devices. Similarly, the functions of the computing device 600B may also be completed by multiple computing devices.

[0117] The embodiment of the present application also relates to a computer storage medium, in which a program for signal processing is stored. When the program is run on a computer, the computer executes the following steps: Figure 3 The steps performed by the DDM node in the illustrated embodiment.

[0118] The present application also relates to a computer program product, which stores instructions, which, when executed by a computer, enable the computer to execute the following Figure 3 The steps performed by the DDM node in the illustrated embodiment.

[0119] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0120] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0121] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0122] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0123] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, read-only memory), random access memory (RAM, random access memory), disk or optical disk and other media that can store program code.

Claims

1. A structured query language SQL request processing method, characterized in that: The method is applied to a database system, the database system includes a database middleware DDM node and multiple database nodes, the DDM node includes a logic table, the logic table is used to record the corresponding relationship between each database node and the data stored therein, the method includes: The DDM node receives a first SQL request; After the DDM node determines, based on the first SQL request and the logic table, that the data to be processed is stored in a target database node among the multiple database nodes, the second SQL request is used to request the target database node to process the data to be processed, and the second SQL request carries an identifier of the DDM node; The DDM node sends the second SQL request to the target database node; The DDM node receives the processing result of the to-be-processed data returned by the target database node, where the processing result carries the identifier of the DDM node.

2. The method according to claim 1, characterized in that After the DDM node determines, based on the first SQL request and the logic table, that the data to be processed is stored in a target database node among the multiple database nodes, generating a second SQL request includes: The DDM node generates an identifier of the DDM node; The DDM node concatenates the identifier of the DDM node with the first SQL request to obtain a third SQL request, where the third SQL request is used to request the DDM node to process the data to be processed, and the third SQL request carries the identifier of the DDM node; The DDM node converts the third SQL request to obtain a fourth SQL request, where the fourth SQL request is used to request the multiple database nodes to process the data to be processed, and the fourth SQL request carries an identifier of the DDM node; After determining that the data to be processed is located in a target database node among the multiple database nodes based on the fourth SQL request and the logic table, the DDM node converts the fourth SQL request to obtain a second SQL request.

3. The method according to claim 2, characterized in that The method further comprises: If the time required from receiving the first SQL request to sending the processing result is greater than or equal to a preset first threshold, the DDM node generates a first log, where the first log is used to indicate that the third SQL request is a SQL request with low processing efficiency, and the identifier of the DDM node is used as an index for the DDM node to query the first log.

4. The method according to claim 2 or 3, characterized in that: The method further comprises: If the time required from sending the second SQL request to receiving the processing result is greater than or equal to a preset second threshold, the DDM node generates a second log, where the second log is used to indicate that the second SQL request is a SQL request with low processing efficiency, and the identifier of the DDM node is used as an index for the DDM node to query the second log.

5. The method according to any one of claims 2 to 4, characterized in that: The method further comprises: The DDM node generates a third log based on the processing result, and the third log is used to indicate whether the third SQL request is a SQL request that is successfully processed or failed to be processed. The identifier of the DDM node serves as an index for the DDM node to query the third log.

6. The method according to any one of claims 1 to 5, characterized in that: The identifier of the DDM node includes any of the following: The network address of the DDM node; The network address of the user and the network address of the DDM node; A value generated based on the network address of the DDM node; or, A value generated based on the network address of the user and the network address of the DDM node.

7. The method according to any one of claims 1 to 6, characterized in that: The database system includes multiple DDM nodes, and the DDM node is any one of the multiple DDM nodes.

8. A DDM node, characterized in that: The DDM node is set in a database system, and the database system further includes a plurality of database nodes. The DDM node includes a logic table, and the logic table is used to record the corresponding relationship between each database node and the data stored therein. The DDM node includes: A receiving module, used for receiving a first SQL request; a processing module, configured to generate a second SQL request after determining, based on the first SQL request and the logic table, a target database node in which the data to be processed is stored among the multiple database nodes, wherein the second SQL request is used to request the target database node to process the data to be processed, and the second SQL request carries an identifier of the DDM node; A sending module, used for sending the second SQL request to the target database node; The receiving module is further used to receive the processing result of the to-be-processed data returned by the target database node, and the processing result carries the identifier of the DDM node.

9. The DDM node according to claim 8, characterized in that: The processing module is used for: Generating an identifier of the DDM node; splicing the identifier of the DDM node with the first SQL request to obtain a third SQL request, where the third SQL request is used to request the DDM node to process the data to be processed, and the third SQL request carries the identifier of the DDM node; Convert the third SQL request to obtain a fourth SQL request, where the fourth SQL request is used to request the multiple database nodes to process the data to be processed, and the fourth SQL request carries an identifier of the DDM node; After determining that the data to be processed is located in a target database node among the multiple database nodes based on the fourth SQL request and the logic table, the fourth SQL request is converted to obtain a second SQL request.

10. The DDM node according to claim 9, characterized in that: The processing module is further used to generate a first log if the time required from receiving the first SQL request to sending the processing result is greater than or equal to a preset first threshold, wherein the first log is used to indicate that the third SQL request is a SQL request with low processing efficiency, and the identifier of the DDM node is used as an index for the DDM node to query the first log.

11. The DDM node according to claim 9 or 10, characterized in that: The processing module is further configured to generate a second log if the time required from sending the second SQL request to receiving the processing result is greater than or equal to a preset second threshold, wherein the second log is used to indicate that the second SQL request is a SQL request with low processing efficiency, and the identifier of the DDM node is used as an index for the DDM node to query the second log.

12. The DDM node according to any one of claims 9 to 11, characterized in that: The processing module is further used to generate a third log based on the processing result, wherein the third log is used to indicate whether the third SQL request is a SQL request that is successfully processed or failed to be processed, and the identifier of the DDM node is used as an index for the DDM node to query the third log.

13. The DDM node according to any one of claims 8 to 12, characterized in that: The identifier of the DDM node includes any of the following: The network address of the DDM node; The network address of the user and the network address of the DDM node; A value generated based on the network address of the DDM node; or, A value generated based on the network address of the user and the network address of the DDM node.

14. The DDM node according to any one of claims 8 to 13, characterized in that: The database system includes multiple DDM nodes, and the DDM node is any one of the multiple DDM nodes.

15. A computing device cluster, characterized in that: The computing device cluster includes at least one computing device, each computing device including a processor and a memory: The memory is used to store instructions; The processor is configured to cause the computing device cluster to execute the method according to any one of claims 1 to 7 according to the instructions.

16. A computer storage medium, characterized in that: The computer storage medium stores one or more instructions, which, when executed by one or more computers, enable the one or more computers to implement the method of any one of claims 1 to 7.

17. A computer program product, characterized in that The computer program product stores instructions, and when the instructions are executed by a computer, the computer implements the method according to any one of claims 1 to 7.

Images