Method and system for implementing hash distribution table in distributed database

Abstract

The present invention discloses a method and system for implementing a hash distribution table in a distributed database, which belongs to the technical field of distributed database optimization, and the technical problem to be solved is how to implement a hash distribution table in a distributed database. The method includes: creating a distribution table in the form of a parent-child table, the parent table is used to store metadata information of the distribution table and related information of the child table, and the child table is used to store table data of the distribution table according to the hash value; fixing the Leader of the Range of each child table on each node corresponding to the child table, and storing the node ID of its assigned node in each child table; creating an index of the distribution table and storing the index in the corresponding child table, and each primary key index of the distribution table must contain all distribution columns as a unique key; when performing data operations on the data in the distribution table, encoding the child table ID to obtain the tableID code, and after sending the tableID code to each child table, performing data operations on the target row.

Description

Technical Field

[0001] The present invention relates to the technical field of distributed database optimization, in particular to a method and system for realizing a hash distribution table in a distributed database. Background Art

[0002] The main design goals of a distributed relational database are scalability, strong consistency, and high reliability. In order to improve the scalability of the database, the distributed database adopts a completely decentralized architecture. The status of each node in the cluster is completely equal. The server provides a standard SQL interface to the outside world. The access node converts the SQL request into a KV operation and sends the operation to other nodes for processing when necessary. The underlying storage organizes the data into an ordered Key-Value pair to form a KVmap. The KV map is logically divided into a large number of Key spaces according to the range. Each Key space is called a Range. Each Range is replicated and distributed to multiple nodes to ensure its high availability. Queries are executed concurrently on each data node in the form of distributed tasks. The Raft consistency protocol is used between multiple copies of the Range. For single or batch modifications of data in the same Range, Raft guarantees the ACID semantics of the Range operation. There is only one leader among multiple identical Ranges, which is responsible for executing the corresponding kv operations. The Raft protocol is used to synchronize multiple copies of the Range. The election of the leader also relies on the Raft protocol

[0003] The key of the user table is an arbitrary byte array, which is composed of: globally unique tableID + primary key ID + primary key code. The Range diagram is as follows Figure 1 shown.

[0004] When the database processes query requests, especially when it is an associated query, since the data in the table is randomly distributed on each node, before executing the join operation, the data in the table must be hashed and redistributed according to the join column, and the rows with the same hash characteristics must be sent to the same node for the join operation. The cost of the hash redistribution operation is: the sum of the data volume of the two tables multiplied by the cost of redistributing each piece of data. In addition, when the database cluster network is in poor condition, hash redistribution will send a large amount of data through the network, and the distributed join operation will cause very high latency, affecting the execution performance of the database query.

[0005] The characteristics of the distribution table are: users can specify which columns in the table are distribution columns. The distribution table can store each data in the table in each node in the database according to the hash value corresponding to its distribution column. In this way, the data in the table is pre-distributed by hash. When joining the query, if the join column is consistent with the distribution column of the distribution table, the distribution table can perform the join operation locally, eliminating the hash redistribution operation and improving the execution performance of the database query.

[0006] Based on the above analysis, how to implement hash distribution tables in distributed databases is a technical problem that needs to be solved. Summary of the invention

[0007] The technical task of the present invention is to address the above shortcomings and provide a method and system for implementing a hash distribution table in a distributed database to solve the technical problem of how to implement a hash distribution table in a distributed database.

[0008] In a first aspect, a method for implementing a hash distribution table in a distributed database of the present invention is applied to a distributed kv database, and the method comprises:

[0009] Create a distribution table in the form of a parent-child table, the distribution table including a parent table and at least one child table, the parent table is used to store metadata information of the distribution table and related information of the child table, the child table corresponds to the cluster node one by one, and is used to store table data of the distribution table according to the hash value;

[0010] The Leader of the Range of each subtable is fixed on each node corresponding to the subtable. Each subtable stores the node ID of its assigned node, so that the KV operation of the distribution table is sent to each node where the subtable is located, realizing the distributed operation of each subtable.

[0011] Create an index for the distribution table and store it in the corresponding subtable. Each primary key index of the distribution table must contain all distribution columns as a unique key.

[0012] When performing data operations on data in a distribution table, the target row is the row that needs to be operated on. A hash calculation is performed on the target row and the corresponding sub-table ID is found. The sub-table ID is encoded to obtain the tableID code. After the tableID code is sent to each sub-table, data operations are performed on the target row. The data operations include adding, deleting, modifying and updating table data.

[0013] Preferably, the metadata information includes table name, column name, primary key information, index information and constraints;

[0014] The relevant information of the sub-table includes the sub-table ID, distribution column information and node ID.

[0015] Preferably, the index of the distribution table is created and the corresponding fillback operation is performed in the background, including the following steps:

[0016] Take all the data from each subtable and return the subtable ID of each subtable;

[0017] The subtable ID is encoded into a key-value format, and the code is inserted into the corresponding subtable.

[0018] As a preferred method, the target row is the row to be operated, a hash calculation is performed on the target row, and the corresponding subtable ID is searched, and the subtable ID is encoded to obtain the tableID code, including the following steps:

[0019] Calculate the hash value based on the column value of the distribution column in the target row data;

[0020] Find the corresponding subtable ID based on the hash value;

[0021] Encode the corresponding subtable ID into a tableID code in key-value format.

[0022] As a preferred embodiment, when updating the data in the distribution table, it is also necessary to determine whether the sub-table IDs of the updated data and the original data are the same. If they are the same, perform an update operation; if they are different, perform a delete+insert operation.

[0023] Preferably, the method further comprises converting the ordinary table into a distribution table, which specifically comprises the following steps:

[0024] Use the common table as the parent table and add the corresponding child table to the common table;

[0025] Perform data cleaning on common tables;

[0026] Take out all the data in the common table, calculate the sub-table into which the hash value corresponding to its distribution column needs to be inserted, replace the prefix of the key with the corresponding sub-table ID, encode the sub-table ID into the key-value format, and insert it into the corresponding sub-table.

[0027] Preferably, the key-value format is:

[0028] key: child table ID+indexID+indexVal+primaryKey.

[0029] Preferably, when deleting a distribution table, the corresponding child table is searched according to the metadata information in the parent table and the related child table information, and a drop operation is performed in the corresponding child table.

[0030] Preferably, when a distributed join query is performed on a distribution table, the distribution column of the distribution table is the same as the join column, and the hash value redistribution process is changed to local execution;

[0031] When performing a lookupjoin operation on a distribution table, different scan construction rules are selected based on whether the lookup column contains the distribution column.

[0032] In a second aspect, a system for implementing a hash distribution table in a distributed database of the present invention is used to execute a method for implementing a hash distribution table in a distributed database as described in any one of the first aspects, and the system comprises:

[0033] A distribution table creation module, which is used to create a distribution table in the form of a parent-child table. The distribution table includes a parent table and at least one child table. The parent table is used to store metadata information of the distribution table and related information of the child table. The child table corresponds to the cluster node one by one and is used to store table data of the distribution table according to the hash value; and is used to fix the Leader of the Range of each child table on each node corresponding to the child table. Each child table stores the node ID of its assigned node, so that the KV operation of the distribution table is sent to each node where its child table is located, so as to realize the distributed operation of each child table;

[0034] An index creation module, which is used to create an index of the distribution table and store the index in a corresponding subtable. Each primary key index of the distribution table must contain all distribution columns as a unique key.

[0035] A data operation module, which is used to perform data operations on the data in the distribution table, taking the row to be operated as the target row, performing hash calculation on the target row and finding the corresponding subtable ID, and encoding the subtable ID to obtain the tableID code, after sending the tableID code to each subtable, performing data operations on the target row, and the data operations include adding, deleting, modifying and updating the table data;

[0036] A common table conversion module, wherein the common table conversion module is used to convert a common table into a distribution table;

[0037] A distribution table deletion module, which is used to delete a distribution table, find the corresponding child table according to the metadata information in the parent table and the related child table information, and perform a drop operation in the corresponding child table;

[0038] A distributed support module, wherein the distributed support module provides distributed support for the distribution table by performing the following operations: when a distributed join query is performed on the distribution table, the distribution column of the distribution table is the same as the join column, and the hash value redistribution process is changed to local execution; when a lookupjoin operation is performed on the distribution table, different scan construction rules are selected to be executed according to whether the lookup column contains the distribution column;

[0039] The common table conversion module is used to convert a common table into a distributed table through the following steps:

[0040] Use the common table as the parent table and add the corresponding child table to the common table;

[0041] Perform data cleaning on common tables;

[0042] Take out all the data in the common table, calculate the sub-table into which the hash value corresponding to its distribution column needs to be inserted, replace the prefix of the key with the corresponding sub-table ID, encode the sub-table ID into the key-value format, and insert it into the corresponding sub-table.

[0043] The implementation and system of the hash distribution table in the distributed database of the present invention has the following advantages:

[0044] 1. In the distributed KV database, the creation, deletion, import and related alter operations of the distribution table are realized, the functions of inserting, deleting and updating data in the distribution table are supported, and the distributed plan related to the distribution table is added. The distribution table can improve the execution performance of complex queries in the scenario of large amount of database data, and improve the execution efficiency of database AP scenario;

[0045] 2. Based on the characteristics of the distribution table, users can specify which columns in the table are distribution columns. The distribution table can make each data in the table be stored in each node in the database according to the hash value corresponding to its distribution column. In this way, the data in the table is hash pre-distributed. When joining the query, if the join column is consistent with the distribution column of the distribution table, the distribution table can perform the join operation locally, eliminating the hash redistribution operation and improving the execution performance of the database query. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0047] The present invention is further described below in conjunction with the accompanying drawings.

[0048] Figure 1 It is a flowchart of a method for implementing a hash distribution table in a distributed database in Example 1;

[0049] Figure 2 It is a related class diagram of sub-tables in the distribution table creation process in the implementation method of the hash distribution table in the distributed database of Example 1;

[0050] Figure 3 This is a flowchart of adding, deleting and modifying a distribution table in the implementation method of a hash distribution table in a distributed database in Example 1;

[0051] Figure 4 It is a block diagram of a distribution table join in the implementation method of a hash distribution table in a distributed database in Example 1;

[0052] Figure 5 This is a block diagram of a common table join in the implementation method of a hash distribution table in a distributed database in Example 1. DETAILED DESCRIPTION

[0053] The present invention is further described below in conjunction with the accompanying drawings and specific embodiments so that those skilled in the art can better understand the present invention and implement it. However, the embodiments are not intended to limit the present invention. In the absence of conflict, the embodiments of the present invention and the technical features in the embodiments may be combined with each other.

[0054] The embodiment of the present invention provides a method and system for realizing a hash distribution table in a distributed database, which are used to solve the technical problem of how to realize a hash distribution table in a distributed database.

[0055] Embodiment 1:

[0056] The implementation method of the hash distribution table in the distributed database of the present invention is applied to the distributed kv database, and the method comprises:

[0057] S100, creating a distribution table in the form of a parent-child table, the distribution table including a parent table and at least one child table, the parent table is used to store metadata information of the distribution table and related information of the child table, the child table corresponds to the cluster node one by one, and is used to store table data of the distribution table according to the hash value;

[0058] S200, fix the Leader of the Range of each subtable on each node corresponding to the subtable, and store the node ID of its assigned node in each subtable, so that the KV operation of the distribution table is sent to each node where the subtable is located, so as to realize the distributed operation of each subtable;

[0059] S300, create an index of the distribution table and store the index in the corresponding subtable. Each primary key index of the distribution table must contain all distribution columns as a unique key.

[0060] S400. When performing data operations on data in a distribution table, the target row is the row that needs to be operated on. A hash calculation is performed on the target row and the corresponding sub-table ID is searched. The sub-table ID is encoded to obtain a tableID code. After the tableID code is sent to each sub-table, data operations are performed on the target row. The data operations include adding, deleting, modifying and updating table data.

[0061] The implementation of the distribution table is similar to the form of a parent-child table. The parent table does not store actual data, but only stores relevant metadata information of the table (table name, column name, primary key information, index information, constraints, etc.) and relevant information of the child table (child table ID, distribution column information, node ID, etc.). The child table is responsible for storing actual data. When creating a distribution table, the same number of child tables as the number of nodes will be created. Each child table is assigned a cluster-unique ID identifier, which is at the same level as the table ID. Since the unit responsible for executing kv operations in this distributed database is the leader of each Range, the special point of the distribution table is that the leader of all Ranges corresponding to each child table needs to be fixed on its corresponding node, so each child table stores its assigned node ID to identify which node the leader of all Ranges of this child table needs to be fixed on. The relevant class diagram is as follows: Figure 3 shown.

[0062] The index of the distribution table also needs to be stored in its corresponding subtable. Therefore, in order to maintain the uniqueness of the unique key, each unique key (primary key index, unique index) of the distribution table must contain all distribution columns. If there is neither a primary key nor a unique key, this restriction does not exist. This restriction also needs to be considered when creating a distribution table. Creating an index performs the corresponding fillback operation in the background. The specific process is: take all the data from each subtable, return the subtable ID of each subtable, encode it into the corresponding key-value format (key: subtable ID + indexID + indexVal + primaryKey) and insert it into the corresponding subtable.

[0063] When performing data operations (addition, modification, deletion, and update) on the distribution table, the hash value must be calculated based on the column value of the distribution column in the row data to be operated, and the corresponding subtable ID must be found based on the hash value. The subtable ID is then encoded into a key-value format according to the corresponding subtable ID, and the corresponding addition, deletion, and modification operations are performed. One special case is when performing an update operation on the distribution column in the distribution table, it is necessary to determine whether the subtable ID of the updated data is the same as the subtable ID of the original data. If they are the same, the update operation can be performed. If they are different, it needs to be decomposed into delete+insert operations. The relevant flow chart is as follows: Figure 4 shown.

[0064] As a further improvement of the above embodiment, when deleting a distribution table, the difference between deleting a distribution table and deleting an ordinary table is that the actual data is not in the parent table, and it is necessary to perform a corresponding deletion operation on each child table in the parent table, find the corresponding child table based on the distribution information in the parent table, and perform the corresponding drop operation.

[0065] As a further improvement of this embodiment, it also includes converting the ordinary table into a distribution table. The specific operations are: adding corresponding sub-table information in the ordinary table, and then performing corresponding data cleaning work, taking out all the data in the ordinary table, calculating which sub-table the hash value corresponding to its distribution column needs to be inserted into, replacing the prefix of the key with the corresponding sub-table ID, encoding it into a key-value format, and inserting it into the corresponding sub-table.

[0066] As a further improvement of this embodiment, it also involves distributed plan support related to distribution tables.

[0067] When executing an association query in the database, if the join column is the same as the distribution column of the distribution table, the output of the distribution table result is directly connected to the join operator of the local node when executing the association query, eliminating the process of hash redistribution of the ordinary table.

[0068] When performing nested association queries, each join operator only cares about whether the left and right inputs have been hash-distributed on each node according to the current join column. If the input of the join operator meets the requirements, a local join operation can be performed. Therefore, each left and right output of the join operator needs to return the last hash-distributed column and whether hash distribution has been performed.

[0069] When the input is a distribution table, the returned distribution columns are the distribution columns of the distribution table, and hash redistribution has been performed.

[0070] When performing a lookupjoin operation on a distributed table, if the table to be looked up is a distributed table, multiple scan operations need to be constructed with the table ID of each subtable to query each subtable. Special case: when the lookup column contains the distribution column of the distributed table, the corresponding subtable ID can be calculated based on the hash value of the distribution column to construct a single scan operation.

[0071] Comparison of distributed execution plans between distributed tables and ordinary tables Figure 4 and Figure 5 shown.

[0072] In order to ensure the accuracy of related operations of the distribution table when the database cluster nodes are increased or decreased, when the database nodes are increased, the distribution table should be temporarily treated as an ordinary table, and the distributed plan of the ordinary table should be followed. In addition, the data cleaning operation is performed asynchronously in the background, and the distribution table is reconstructed according to the new nodes. When the database nodes are reduced, considering that the node reduction may be an abnormal situation, the distribution table is converted into an ordinary table, but the operation of reconstructing the distribution table is not performed temporarily. After a period of time, if the node has not been restored, a new distribution table is constructed according to the new cluster node.

[0073] In order to show the effect of the method of this embodiment, a TPC-H comparison test was conducted on a 7-node database cluster distributed table and a common table. The first column of all tables in TPC-H was used as a distribution column to create a distributed table, and all tables were common tables. TPC-H 22 statements with the same amount of data were tested in two scenarios. It was found that most queries could select the execution plan of the distributed table when associated queries were made, and the execution time of half of the queries was shortened by about 50%. The execution of other statements did not slow down compared with that of common tables. Therefore, the distributed table has some improvements on the database AP scenario.

[0074] Embodiment 2:

[0075] The system for implementing a hash distribution table in a distributed database of the present invention comprises a distribution table creation module, an index creation module, a data operation module, a common table conversion module, a distribution table deletion module, and a distributed support module. The system can execute the method disclosed in Example 1.

[0076] The distribution table creation module is used to create a distribution table in the form of a parent-child table, wherein the distribution table includes a parent table and at least one child table, wherein the parent table is used to store metadata information of the distribution table and related information of the child table, and the child table corresponds one-to-one to a cluster node, and is used to store table data of the distribution table according to a hash value; and is used to fix the Leader of the Range of each child table on each node corresponding to its child table, and each child table stores the node ID of its assigned node, so that the KV operation of the distribution table is sent down to each node where its child table is located, thereby realizing distributed operation of each child table.

[0077] In this module, the implementation of the distribution table is similar to the form of a parent-child table. The parent table does not store actual data, but only stores relevant metadata information of the table (table name, column name, primary key information, index information, constraints, etc.) and relevant information of the child table (child table ID, distribution column information, node ID, etc.). The child table is responsible for storing the actual data. When creating a distribution table, the same number of child tables as the number of nodes will be created. Each child table is assigned a cluster-unique ID identifier, which is at the same level as the table ID. Since the unit responsible for executing kv operations in this distributed database is the leader of each Range, the special point of the distribution table is that the leader of all Ranges corresponding to each child table needs to be fixed on its corresponding node, so each child table stores its assigned node ID to identify which node the leader of all Ranges of this child table needs to be fixed on.

[0078] The index creation module is used to create the index of the distribution table and store the index in the corresponding subtable. Each primary key index of the distribution table must contain all distribution columns as a unique key.

[0079] The index of the distribution table also needs to be stored in its corresponding subtable. Therefore, in order to maintain the uniqueness of the unique key, each unique key (primary key index, unique index) of the distribution table must contain all distribution columns. If there is neither a primary key nor a unique key, this restriction does not exist. This restriction also needs to be considered when creating a distribution table. Creating an index performs the corresponding fillback operation in the background. The specific process is: take all the data from each subtable, return the subtable ID of each subtable, encode it into the corresponding key-value format (key: subtable ID + indexID + indexVal + primaryKey) and insert it into the corresponding subtable.

[0080] The data operation module is used to perform data operations on the data in the distribution table. The target row is the row that needs to be operated. The target row is hashed and the corresponding sub-table ID is found. The sub-table ID is encoded to obtain the tableID code. After the tableID code is sent to each sub-table, data operations are performed on the target row. The data operations include adding, deleting, modifying and updating the table data.

[0081] When adding, deleting, or modifying data, the data operation module calculates the hash value based on the column value of the distribution column in the row data to be operated, finds the corresponding subtable ID based on the hash value, and then encodes it into the form of key-value according to the corresponding subtable ID, and then performs the corresponding addition, deletion, or modification operations. One special case is when performing an update operation on the distribution column in the distribution table, it is necessary to determine whether the subtable ID of the updated data is the same as that of the original data. If they are the same, the update operation can be performed. If they are different, it needs to be decomposed into a delete+insert operation.

[0082] The ordinary table conversion module is used to convert ordinary tables into distributed tables. The ordinary table conversion module is used to convert ordinary tables into distributed tables through the following steps: take the ordinary table as the parent table and add the corresponding child table to the ordinary table; perform data cleaning on the ordinary table; take out all the data in the ordinary table, calculate the child table into which the hash value corresponding to its distribution column needs to be inserted, replace the prefix of the key with the corresponding child table ID, encode the child table ID into the key-value format, and insert it into the corresponding child table.

[0083] The distribution table deletion module is used to delete the distribution table, find the corresponding sub-table according to the metadata information in the parent table and the related sub-table information, and perform the drop operation in the corresponding sub-table. The difference between the deletion of the distribution table in this embodiment and the deletion of the ordinary table is that the actual data is not in the parent table, and the corresponding deletion operation needs to be performed on each sub-table in the parent table, and the corresponding sub-table is found according to the distribution information in the parent table to perform the corresponding drop operation.

[0084] The distributed support module provides distributed support for the distributed table through the following operations: when performing a distributed join query on the distributed table, the distribution column of the distributed table is the same as the join column, and the hash value redistribution process is changed to local execution; when performing a lookupjoin operation on the distributed table, different scan construction rules are selected based on whether the lookup column contains the distribution column.

[0085] When executing an association query in the database, if the join column is the same as the distribution column of the distribution table, the output of the distribution table result is directly connected to the join operator of the local node when executing the association query, eliminating the process of hash redistribution of the ordinary table.

[0086] When performing nested association queries, each join operator only cares about whether the left and right inputs have been hash-distributed on each node according to the current join column. If the input of the join operator meets the requirements, a local join operation can be performed. Therefore, each left and right output of the join operator needs to return the last hash-distributed column and whether hash distribution has been performed.

[0087] When the input is a distribution table, the returned distribution columns are the distribution columns of the distribution table, and hash redistribution has been performed.

[0088] When performing a lookupjoin operation on a distributed table, if the table to be looked up is a distributed table, multiple scan operations need to be constructed with the table ID of each subtable to query each subtable. Special case: when the lookup column contains the distribution column of the distributed table, the corresponding subtable ID can be calculated based on the hash value of the distribution column to construct a single scan operation.

[0089] In order to ensure the accuracy of the related operations of the distribution table when the database cluster nodes are increased or decreased, when the database nodes are increased, the distribution table should be temporarily treated as a common table, and the distributed plan of the common table should be followed. In addition, the data cleaning operation should be asynchronously performed in the background, and the distribution table should be reconstructed according to the new nodes. When the database nodes are reduced, considering that the node reduction may be an abnormal situation, the distribution table is converted into a common table, but the operation of reconstructing the distribution table is not performed temporarily. After a period of time, if the node has not been restored, a new distribution table is constructed according to the new cluster node. In this case, the module for converting the common table to the distribution table can be called.

[0090] The present invention has been shown and described in detail above through the accompanying drawings and preferred embodiments. However, the present invention is not limited to these disclosed embodiments. Based on the above multiple embodiments, those skilled in the art can know that the code review methods in the above different embodiments can be combined to obtain more embodiments of the present invention, and these embodiments are also within the protection scope of the present invention.

Claims

1. A method for implementing a hash distribution table in a distributed database, characterized in that Applied in a distributed kv database, the method includes: Create a distribution table in the form of a parent-child table, the distribution table including a parent table and at least one child table, the parent table is used to store metadata information of the distribution table and related information of the child table, the child table corresponds to the cluster node one by one, and is used to store table data of the distribution table according to the hash value; The Leader of the Range of each subtable is fixed on each node corresponding to the subtable. Each subtable stores the node ID of its assigned node, so that the KV operation of the distribution table is sent to each node where the subtable is located, realizing the distributed operation of each subtable. Create an index for the distribution table and store it in the corresponding subtable. Each primary key index of the distribution table must contain all distribution columns as a unique key. When performing data operations on data in a distribution table, the target row is the row that needs to be operated on. A hash calculation is performed on the target row and the corresponding sub-table ID is found. The sub-table ID is encoded to obtain the tableID code. After the tableID code is sent to each sub-table, data operations are performed on the target row. The data operations include adding, deleting, modifying and updating table data.

2. The method for implementing a hash distribution table in a distributed database according to claim 1, characterized in that The metadata information includes table name, column name, primary key information, index information and constraints; The relevant information of the sub-table includes the sub-table ID, distribution column information and node ID.

3. The method for implementing a hash distribution table in a distributed database according to claim 1, characterized in that Create an index for the distribution table and perform the corresponding fillback operation in the background, including the following steps: Take all the data from each subtable and return the subtable ID of each subtable; The subtable ID is encoded into a key-value format, and the code is inserted into the corresponding subtable.

4. The method for implementing a hash distribution table in a distributed database according to claim 1, characterized in that The target row is the row to be operated on, hash calculation is performed on the target row, the corresponding subtable ID is found, and the subtable ID is encoded to obtain the tableID code, including the following steps: Calculate the hash value based on the column value of the distribution column in the target row data; Find the corresponding subtable ID based on the hash value; Encode the corresponding subtable ID into a tableID code in key-value format.

5. The method for implementing a hash distribution table in a distributed database according to claim 4, characterized in that When updating data in a distribution table, you also need to determine whether the subtable IDs of the updated data and the original data are the same. If they are the same, perform an update operation; if they are different, perform a delete+insert operation.

6. The method for implementing a hash distribution table in a distributed database according to claim 1, characterized in that The method further includes converting the common table into a distribution table, which specifically includes the following steps: Use the common table as the parent table and add the corresponding child table to the common table; Perform data cleaning on common tables; Take out all the data in the common table, calculate the sub-table into which the hash value corresponding to its distribution column needs to be inserted, replace the prefix of the key with the corresponding sub-table ID, encode the sub-table ID into the key-value format, and insert it into the corresponding sub-table.

7. The method for implementing a hash distribution table in a distributed database according to claim 3, 4 or 6, characterized in that The key-value format is: key: child table ID+indexID+indexVal+primaryKey.

8. The method for implementing a hash distribution table in a distributed database according to claim 1, characterized in that When deleting a distribution table, the corresponding child table is searched based on the metadata information in the parent table and the related child table information, and the drop operation is performed in the corresponding child table.

9. The method for implementing a hash distribution table in a distributed database according to claim 1, characterized in that When performing a distributed join query on a distributed table, the distribution column of the distributed table is the same as the join column, and the hash value redistribution process is changed to local execution; When performing a lookupjoin operation on a distribution table, different scan construction rules are selected based on whether the lookup column contains the distribution column.

10. A system for implementing a hash distribution table in a distributed database, characterized in that The system is used to execute the implementation method of the hash distribution table in the distributed database according to any one of claims 1 to 9, and comprises: A distribution table creation module, which is used to create a distribution table in the form of a parent-child table. The distribution table includes a parent table and at least one child table. The parent table is used to store metadata information of the distribution table and related information of the child table. The child table corresponds to the cluster node one by one and is used to store table data of the distribution table according to the hash value; and is used to fix the Leader of the Range of each child table on each node corresponding to the child table. Each child table stores the node ID of its assigned node, so that the KV operation of the distribution table is sent to each node where its child table is located, so as to realize the distributed operation of each child table; An index creation module, which is used to create an index of the distribution table and store the index in a corresponding subtable. Each primary key index of the distribution table must contain all distribution columns as a unique key. A data operation module, which is used to perform data operations on the data in the distribution table, taking the row to be operated as the target row, performing hash calculation on the target row and finding the corresponding subtable ID, and encoding the subtable ID to obtain the tableID code, after sending the tableID code to each subtable, performing data operations on the target row, and the data operations include adding, deleting, modifying and updating the table data; A common table conversion module, wherein the common table conversion module is used to convert a common table into a distribution table; A distribution table deletion module is used to delete a distribution table, find the corresponding child table according to the metadata information in the parent table and the related child table information, and perform a drop operation in the corresponding child table; A distributed support module, wherein the distributed support module provides distributed support for the distribution table through the following operations: when a distributed join query is performed on the distribution table, the distribution column of the distribution table is the same as the join column, and the hash value redistribution process is changed to local execution; when a lookupjoin operation is performed on the distribution table, different scan construction rules are selected to be executed according to whether the lookup column contains the distribution column; The common table conversion module is used to convert a common table into a distributed table through the following steps: Use the common table as the parent table and add the corresponding child table to the common table; Perform data cleaning on common tables; Take out all the data in the common table, calculate the sub-table into which the hash value corresponding to its distribution column needs to be inserted, replace the prefix of the key with the corresponding sub-table ID, encode the sub-table ID into the key-value format, and insert it into the corresponding sub-table.

Images