Dynamic SQL rewriting methods in distributed databases

Abstract

This invention provides a dynamic SQL rewriting method for distributed databases. A rule distribution table is created at the SQL layer to store the original SQL to be rewritten and the target rules. A local shared-memory hash table implemented in C is created on each CN node. Each CN node reads the contents of the rule distribution table into its local shared-memory hash table. After the database kernel parses the SQL, it determines the current execution plan type based on the number of target DN nodes and whether there is data interaction between DN nodes. Then, based on the different execution plans, the corresponding SQL rewriting process is executed. When a user modifies the rule distribution table, each CN node synchronously updates its local shared-memory hash table in real time. This invention enables centralized rule management and unified SQL rewriting at the CN nodes, improving the performance and consistency of the distributed database.

Description

Technical Field

[0001] This invention belongs to the field of computer technology, further to the field of distributed database technology, and more specifically relates to a dynamic SQL rewriting method under a distributed database. Background Technology

[0002] SQL rewriting refers to the process of analyzing, transforming, or rewriting the original SQL statement submitted by the user to generate a new, equivalent (or adjusted according to business rules) SQL statement.

[0003] SQL rewriting is necessary because the underlying database structure may be inconsistent with the "logical view" seen by the application. For example, the data may be sharded and partitioned, certain fields may need to be de-identified, read-write separation may need to be implemented, and certain dangerous operations (such as DELETE without WHERE) may need to be prevented.

[0004] Existing centralized databases support SQL rewriting via plugins (such as pg_query_rewrite), while for distributed databases, the roles of each node in a distributed database cluster include: GTM, CN, and DN, and their specific responsibilities are shown in Table 1 below:

[0005] Table 1: Roles and Responsibilities of Each Node in a Distributed Database Cluster

[0006]

[0007] Users access the distributed database by accessing the CN (Content Node) node; that is, the CN node is the first to receive the SQL query. Therefore, SQL rewriting occurs on the CN node. In a distributed database scenario, the following technical challenges arise:

[0008] 1. Complex rule synchronization: Rules are usually stored in a distributed table (or rule distribution table), which needs to be loaded separately by each node, posing risks of inconsistency and deadlock;

[0009] 2. Delayed rewriting timing: Traditional SQL rewriting processes are mostly executed in the parse_analyze phase, while some execution plans that bypass the parse process (such as the Light Proxy execution plan) and SQL statements that require the participation of all nodes (such as DDL statements) cannot be covered;

[0010] Introduction to the parse_analyze phase: In a database, when we submit an SQL statement, the database needs to perform a series of processes before it can be finally executed and return results. This process typically includes: ① Parsing, ② Analysis, ③ Rewriting, ④ Optimization, and ⑤ Execution; the "parse_analyze phase" refers to the first two phases: parsing and semantic analysis.

[0011] Introduction to SQL and DDL statements: SQL (Structured Query Language): A general term for structured query languages, primarily including four forms: DDL, DML, DCL, and TCL. DDL (Data Definition Language): A data definition language, typically used to define and modify database structures; it is one form of SQL statement.

[0012] 3. Low storage efficiency: The regular storage structure is an array, which results in low efficiency for adding, deleting, searching, and modifying data, and poor scalability;

[0013] 4. Distributed performance overhead: DN nodes also need to load rules, which increases additional communication and computing overhead.

[0014] Therefore, a SQL processing mechanism that can centrally manage rules and perform unified rewriting on CN nodes is needed to improve the performance and consistency of distributed databases. Summary of the Invention

[0015] The purpose of this invention is to overcome the shortcomings of the prior art and provide a dynamic SQL rewriting method for distributed databases.

[0016] This invention is achieved through the following technical solution:

[0017] This invention provides a dynamic SQL rewriting method for distributed databases, comprising:

[0018] Create a rule distribution table at the SQL layer to store the original SQL and target rules that need to be rewritten;

[0019] A local shared memory hash table implemented in C language is created on each CN node. When the database system starts, each CN node reads the contents of the rule distribution table into the local shared memory hash table.

[0020] After the database kernel parses the SQL, it determines the type of execution plan currently in use based on the number of target DN nodes and whether there is data interaction between the DN nodes.

[0021] If the current execution plan is Light Proxy, the SQL rewriting process is as follows: obtain the string of the SQL statement in the client request packet on the CN node, perform original SQL matching based on the contents of the local shared memory hash table of the CN node, rewrite the SQL statement after a successful match, reconstruct the message packet using the rewritten SQL statement, and then transparently send the new message packet to the DN node for execution.

[0022] If the current execution is a Stream execution plan, the SQL rewriting process is as follows: in the query_parse stage of the CN node, query the contents of the local shared memory hash table, match the original SQL statement, rewrite the syntax tree after a successful match, generate the rewritten execution plan, and then push the rewritten execution plan of the CN node down to each DN node;

[0023] If the current execution plan is FQS and Remote Query, the SQL rewriting process is as follows: Before creating the portal on the CN node, for the original SQL that matches the local memory hash table, the query_string in the portal is rewritten as the target SQL. The portal is constructed using the target SQL. Subsequent SQLs sent to the DN node use the modified target SQL in the portal.

[0024] When a user modifies the rule distribution table, each CN node synchronously updates its local shared memory hash table in real time.

[0025] In the above technical solution, the table fields of the rule distribution table include: original SQL, target rule, database name and node name, where the target rule refers to the rewritten target SQL.

[0026] In the above technical solution, the table fields of the rule distribution table also include: scope of application, update time and whether it is enabled.

[0027] In the above technical solution, the local shared memory hash table implemented in C language supports O(1) add, delete, modify and query operations.

[0028] In the above technical solution, if only one DN node needs to execute, it is determined that the LightProxy execution plan is currently being used; if multiple DN nodes need to execute and there is data interaction between the DN nodes, it is determined that the Stream execution plan is currently being used; if multiple DN nodes need to execute and there is no data interaction between the DN nodes, it is determined that the FQS execution plan or the Remote Query execution plan is currently being used.

[0029] In the above technical solution, the specific process of rewriting and reconstructing message packets when executing the Light Proxy execution plan is as follows: when executing query rewriting, if the incoming SQL is found to match, the query tree is tagged, and the original SQL in the query tree is rewritten into the target SQL. Then, when executing LightProxy, the msg packet that the front end passes to CN in the input parameters is reconstructed, and the query information in it is changed into the target SQL.

[0030] In the above technical solution, when a user modifies the rule distribution table, an `add_rule` or `delete_rule` operation is executed on a CN node. Then, after adding or deleting rules and modifying the hash table on that CN node, synchronization is performed, sending messages to other CN nodes. The rules to be added or deleted are then added or deleted from the local memory hash tables of each CN node. All operations take effect in real time without requiring a database restart.

[0031] Another aspect of the present invention provides an electronic device comprising: one or more processors; and a memory for storing one or more programs, wherein, when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to perform the method as described above.

[0032] Another aspect of the present invention provides a computer-readable storage medium storing computer-executable instructions, which, when executed, are used to implement the method described above.

[0033] Another aspect of the present invention provides a computer program product comprising computer-executable instructions which, when executed, are used to implement the method described above.

[0034] The advantages and beneficial effects of this invention are as follows:

[0035] Centralized management: Rules are stored and applied on CN nodes, enabling centralized management of rules and unified SQL rewriting on CN nodes, thus improving the performance and consistency of the distributed database.

[0036] Comprehensive coverage: Supports SQL rewriting for four types of execution plans: Light Proxy, Stream, FQS, and RemoteQuery.

[0037] Performance optimization: A CN local memory hash table structure implemented in C language is used to improve the efficiency of rule query.

[0038] Compatible and transparent: Light Proxy rewrite ensures that the client protocol is unaware of the changes by constructing new message packets.

[0039] Dynamically scalable: Changes to the rule distribution table can be instantly synchronized to the CN local memory hash table, and the rewritten logic takes effect dynamically. Attached Figure Description

[0040] Figure 1 This diagram illustrates an application scenario of the dynamic SQL rewriting method for a distributed database according to the present invention.

[0041] Figure 2 This is a flowchart illustrating a dynamic SQL rewriting method for a distributed database according to the present invention.

[0042] For those skilled in the art, other related figures can be obtained from the above figures without any creative effort. Detailed Implementation

[0043] Hereinafter, embodiments of the present invention will be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the invention. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of the invention for ease of explanation. However, it will be apparent that one or more embodiments may be practiced without these specific details. Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concept of the invention.

[0044] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the invention. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0045] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0046] In the technical solution of this invention, the user information (including but not limited to user personal information, user image information, user device information, such as location information) and data (including but not limited to data used for analysis, stored data, and displayed data) involved are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, invention, and application of related data all comply with relevant laws, regulations, and standards, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entry points for users to choose to authorize or refuse.

[0047] In scenarios involving automated decision-making using personal information, the methods, devices, and systems provided in this invention offer users corresponding entry points for choosing to agree to or reject the automated decision-making results. If the user chooses to reject, the process proceeds to the expert decision-making stage. Here, "automated decision-making" refers to the activity of automatically analyzing and evaluating an individual's behavioral habits, interests, or economic, health, and credit status through computer programs, and then making a decision. Here, "expert decision-making" refers to the activity of making decisions by personnel who specialize in a particular field, possess specialized experience, knowledge, and skills, and have reached a certain level of professional expertise.

[0048] Existing centralized databases support SQL rewriting via plugins (such as pg_query_rewrite), but they suffer from the following drawbacks in distributed scenarios: ① Complex rule synchronization: Rules are typically stored in distributed tables, requiring each node to load them separately, leading to inconsistency and deadlock risks; ② Delayed rewriting timing: Traditional methods often execute during the parse_analyze phase, failing to cover some execution plans that bypass the parse process (such as Light Proxy) and SQL queries requiring participation from all nodes (such as DDL); ③ Low storage efficiency: Rule storage is based on arrays, resulting in low efficiency for adding, deleting, querying, and modifying rules, and poor scalability; ④ Distributed performance overhead: DN nodes also need to load rules, increasing additional communication and computational overhead.

[0049] In view of this, embodiments of the present invention provide a dynamic SQL rewriting method for distributed databases, which can centrally manage rules and complete unified SQL rewriting on CN nodes to improve the performance and consistency of distributed databases.

[0050] Figure 1 The diagram illustrates an application scenario of a dynamic SQL rewriting method in a distributed database according to an embodiment of the present invention.

[0051] like Figure 1As shown, application scenario 100 according to this embodiment may include a first terminal device 101, a second terminal device 102, a third terminal device 103, a network 104, and a cluster server 105. The network 104 serves as a medium for providing communication links between the first terminal device 101, the second terminal device 102, the third terminal device 103, and the cluster server 105. The network 104 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0052] Users can use the first terminal device 101, the second terminal device 102, and the third terminal device 103 to interact with the cluster server 105 via the network 104 to receive or send messages, etc. Various communication client applications can be installed on the first terminal device 101, the second terminal device 102, and the third terminal device 103, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).

[0053] The first terminal device 101, the second terminal device 102, and the third terminal device 103 can be various electronic devices with displays and support web browsing, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0054] Cluster server 105 can be a server that provides various services, such as a backend management server that supports websites browsed by users using first terminal device 101, second terminal device 102, and third terminal device 103 (this is just an example). A distributed database is deployed on cluster server 105, which includes multiple server nodes that can analyze and process received user requests and other data, and feed back the processing results (such as web pages, information, or data obtained or generated based on user requests) to the terminal devices.

[0055] It should be noted that the dynamic SQL rewriting method under a distributed database provided in this embodiment of the invention can generally be executed by the cluster server 105. Alternatively, the dynamic SQL rewriting method under a distributed database provided in this embodiment of the invention can also be executed by other servers or server clusters that are different from the cluster server 105 and can communicate with the first terminal device 101, the second terminal device 102, the third terminal device 103 and / or the cluster server 105. Alternatively, the dynamic SQL rewriting method under a distributed database provided in this embodiment of the invention can also be executed by the first terminal device 101, the second terminal device 102 or the third terminal device 103, or by other terminal devices that are different from the first terminal device 101, the second terminal device 102 or the third terminal device 103.

[0056] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0057] It should be noted that the sequence numbers of the operations in the following methods are for descriptive purposes only and should not be considered as indicating the execution order of the operations. Unless explicitly stated otherwise, the method does not need to be executed in the exact order shown.

[0058] The following will be based on Figure 1 The described scene, combined with the appendix Figure 2 A method for dynamic SQL rewriting in a distributed database according to an embodiment of the present invention will be described in detail.

[0059] A dynamic SQL rewriting method for distributed databases, comprising the following:

[0060] I. Rule Storage

[0061] Create a rule distribution table at the SQL layer to store the original SQL statements that need to be rewritten and the target rules. Preferably, this distribution table is named pg_query_rewrite_rules.

[0062] The rule distribution table includes the following fields: original SQL, target rule (i.e., the rewritten target SQL), database name, node name, applicable scope, update time, and whether it is enabled, as detailed in Table 2 below:

[0063] Table 2: Table Field Structure of the Regular Distribution Table

[0064] ;

[0065] Create a local shared-memory hash table implemented in C language on each CN node to store the original SQL statements and target rules that need to be rewritten.

[0066] II. Hash Table Loading

[0067] When the database system starts, each CN node reads the contents of the rule distribution table into a local shared memory hash table. The local shared memory hash table implemented in C language supports O(1) CRUD operations (O(1) is a classic description of the performance of hash tables in computer science, and is a way of representing time complexity. It means that no matter how large the amount of data is, the time required for the operation remains basically unchanged), which can conveniently and quickly implement CRUD operations.

[0068] III. SQL Rewriting Process

[0069] The dynamic SQL rewriting method for distributed databases provided in this embodiment supports the rewriting of four types of execution plans: Light Proxy execution plan, Stream execution plan, FQS execution plan, and Remote Query execution plan.

[0070] Light Proxy execution plans are lightweight, fast, and efficient proxy implementations that require only one DNS node to execute; SQL is simply sent to the specified DNS node. They are commonly used for point queries and exact match queries.

[0071] The Stream execution plan is generated on the CN node from the original SQL statement. The CN node then distributes the execution plan to each DN node, and each DN node uses the Stream operator to interact with data during the execution process.

[0072] FQS (Fast Query Shipping) execution plan involves the CN node directly sending the original SQL statement to each or some DN nodes, with each DN node executing independently and without data interaction between them.

[0073] Remote Query execution plans are a compromise solution. When a statement cannot generate a Stream or FQS execution plan, the CN node generates a plan, distributes part of the original statement to the DN nodes, and each DN node executes it independently. After execution, the results are sent back to the CN node, which then executes the remaining plan. For example, an update statement with a returning statement and a join between two tables does not support Stream execution plans. The CN node retrieves data from the two tables from the DN node using Remote Query, completes the join operation on the CN node, constructs the final update statement based on the join result, and distributes it to the DN nodes using Remote Query.

[0074] After the database kernel performs the parse phase on the SQL (syntactic analysis and semantic analysis), it determines the execution plan to use based on the number of target DN nodes and whether there is data interaction between the DN nodes. Specifically:

[0075] ① If only one DN node needs to execute, then it is determined that the LightProxy execution plan is currently being used;

[0076] ② If multiple DN nodes need to execute and there is data interaction between the DN nodes, then it is determined that the current execution plan is Stream;

[0077] ③ If multiple DN nodes need to execute, and there is no data interaction between DN nodes, then determine whether the current execution plan is FQS or Remote Query.

[0078] 1. If the current execution plan is Light Proxy, rewrite the SQL as follows:

[0079] Since Light Proxy directly obtains the SQL statement string from the client request packet, this invention obtains the SQL statement string from the client request packet on the CN node. Based on the contents of the local shared memory hash table of the CN node, the string of the SQL statement obtained from the client request packet is matched with the original SQL in the hash table (if the strings match, the match is successful). After a successful match, the SQL statement is rewritten, and the message packet is reconstructed using the rewritten SQL statement. Then, the new message packet is transparently sent to the DN node for execution.

[0080] To elaborate further, the specific process of rewriting and reconstructing the message packet is as follows: when executing query rewriting, if the incoming SQL is found to match, then the query tree is tagged, and the original SQL in the query tree is rewritten into the target SQL. Then, when executing LightProxy, the msg packet that the front end passes to the CN node in the input parameters is reconstructed, and the query information in it is changed into the target SQL.

[0081] 2. If the current execution plan is for a Stream, rewrite the SQL as follows:

[0082] In the query_parse phase (i.e., the syntax analysis and semantic analysis phase) of the CN node, the contents of the local shared memory hash table are queried to match the original SQL statement. If the match is successful, the syntax tree is rewritten to generate the rewritten execution plan. Then, the rewritten execution plan of the CN node is pushed down to each DN node. After that, each DN node uses the Stream operator to interact with data during the execution process.

[0083] 3. If the current execution plan is an FQS execution plan or a Remote Query execution plan, rewrite the SQL as follows:

[0084] For SQL queries that follow the FQS execution plan and the Remote Query execution plan, before creating the portal on the CN node, for the original SQL queries that match the local memory hash table (which have already been matched during the query rewriting phase), the query_string in the portal is rewritten into the target SQL. The portal is then constructed using this target SQL. Subsequent SQL queries sent to the DN node use the modified target SQL from the portal.

[0085] IV. Dynamic Maintenance of Rules

[0086] When a user modifies the rule distribution table, each CN node synchronously updates its local shared memory hash table. That is, when adding or deleting rules, in addition to adding or deleting rules in the rule distribution table, all CN nodes also add or delete rules in their local memory hash tables. The logic for this operation is as follows:

[0087] Execute an `add_rule` or `delete_rule` operation on a CN node, then add, delete, and modify the rule distribution table and hash table on that CN node. Finally, perform synchronization, sending a message to other CN nodes to add or delete the necessary rules from their local memory hash tables. All add, delete, and modify operations take effect immediately without requiring a database restart.

[0088] The present invention also provides a computer-readable storage medium carrying one or more programs that, when executed, implement the method according to embodiments of the present invention.

[0089] According to embodiments of the present invention, the computer-readable storage medium may be a non-volatile computer-readable storage medium. Examples include, but are not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In the present invention, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0090] Embodiments of the present invention also include a computer program product comprising a computer program containing program code for executing the methods provided in the embodiments of the present invention. When the computer program product is run on an electronic device, the program code is used to enable the electronic device to implement the dynamic SQL rewriting method under a distributed database provided in the embodiments of the present invention.

[0091] In one embodiment, the computer program may rely on tangible storage media such as optical storage devices or magnetic storage devices. In another embodiment, the computer program may also be transmitted and distributed as signals over a network medium, and downloaded and installed via a communication component, and / or installed from a removable medium. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0092] According to embodiments of the present invention, program code for executing the computer programs provided in the embodiments of the present invention can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C", or similar programming languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0093] The flowcharts or block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagram or flowchart, and combinations of blocks in the block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions. Those skilled in the art will understand that the features described in the various embodiments of the present invention can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in the present invention. In particular, the features described in the various embodiments of the present invention can be combined and / or combined in various ways without departing from the spirit and teachings of the present invention. All such combinations and / or pairings fall within the scope of this invention.

[0094] The embodiments of the present invention have been described above. However, these embodiments are merely illustrative and not intended to limit the scope of the invention. Although various embodiments have been described above, this does not mean that the measures in the various embodiments cannot be used advantageously in combination. Various substitutions and modifications can be made by those skilled in the art without departing from the scope of the invention, and all such substitutions and modifications should fall within the scope of the invention.

Claims

1. A method for dynamic SQL rewriting in a distributed database, characterized in that, include: Create a rule distribution table at the SQL layer to store the original SQL and target rules that need to be rewritten; Create a local shared memory hash table implemented in C language on each CN node, and each CN node reads the contents of the rule distribution table into the local shared memory hash table; After the database kernel parses the SQL, it determines the type of execution plan currently in use based on the number of target DN nodes and whether there is data interaction between the DN nodes. If the current execution plan is Light Proxy, the SQL rewriting process is as follows: obtain the string of the SQL statement in the client request packet on the CN node, perform original SQL matching based on the contents of the local shared memory hash table of the CN node, rewrite the SQL statement after a successful match, reconstruct the message packet using the rewritten SQL statement, and then transparently send the new message packet to the DN node for execution. If the current execution is a Stream execution plan, the SQL rewriting process is as follows: in the query_parse stage of the CN node, query the contents of the local shared memory hash table, match the original SQL statement, rewrite the syntax tree after a successful match, generate the rewritten execution plan, and then push the rewritten execution plan of the CN node down to each DN node; If the current execution plan is FQS and Remote Query, the SQL rewriting process is as follows: Before creating the portal on the CN node, for the original SQL that matches the local memory hash table, the query_string in the portal is rewritten as the target SQL. The portal is constructed using the target SQL. Subsequent SQLs sent to the DN node use the modified target SQL in the portal. When a user modifies the rule distribution table, each CN node synchronously updates its local shared memory hash table in real time.

2. The dynamic SQL rewriting method under a distributed database according to claim 1, characterized in that: The table fields of the rule distribution table include: original SQL, target rule, database name, and node name, where the target rule refers to the rewritten target SQL.

3. The dynamic SQL rewriting method under a distributed database according to claim 2, characterized in that: The rule distribution table also includes the following fields: scope of application, update time, and whether it is enabled.

4. The dynamic SQL rewriting method under a distributed database according to claim 1, characterized in that: The local shared memory hash table implemented in C language supports O(1) operations for adding, deleting, modifying, and querying data.

5. The dynamic SQL rewriting method under a distributed database according to claim 1, characterized in that: If only one DN node needs to execute, then the LightProxy execution plan is used; if multiple DN nodes need to execute and there is data interaction between the DN nodes, then the Stream execution plan is used. If multiple DN nodes need to execute, and there is no data interaction between DN nodes, then determine whether the current execution plan is FQS or Remote Query.

6. The dynamic SQL rewriting method under a distributed database according to claim 1, characterized in that: When executing the Light Proxy execution plan, the specific process of rewriting and reconstructing the message packet is as follows: When executing query rewriting, if the incoming SQL matches, the query tree is tagged, and the original SQL in the query tree is rewritten into the target SQL. Then, when executing LightProxy, the msg packet that the front end passes to CN in the input parameters is reconstructed, and the query information in it is changed into the target SQL.

7. The dynamic SQL rewriting method under a distributed database according to claim 1, characterized in that: When a user modifies the rule distribution table, an add_rule or delete_rule operation is executed on a CN node. After adding or deleting rules and modifying the hash table on the local CN node, synchronization is performed, and messages are sent to other CN nodes to add or delete the rules that need to be added or deleted from the local memory hash tables of each CN node.

8. An electronic device, characterized in that, include: One or more processors; A memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the dynamic SQL rewriting method under a distributed database as described in claim 1.

9. A computer-readable storage medium, characterized in that: It stores computer-executable instructions, which, when executed, are used to implement the dynamic SQL rewriting method in a distributed database as described in claim 1.

10. A computer program product, characterized in that: The aforementioned computer program product includes computer-executable instructions that, when executed, implement the dynamic SQL rewriting method for a distributed database as described in claim 1.

Images