A partition-level connection method and apparatus for a distributed database

Abstract

One or more embodiments of this specification provide a partition-level connection method and apparatus for a distributed database. The distributed database includes multiple data tables, which are partitioned based on the same partition key. Each data table is divided into multiple logical partitions, and multiple logical partitions belonging to different data tables are connected based on the same partition key. The connection method includes: receiving connection rules planned for M logical partitions located on a first physical machine, wherein the M logical partitions belong to M data tables respectively; checking whether the physical machine where the M logical partitions are located has changed; if so, obtaining the second physical machine where the logical partitions whose location has changed are located, and performing a data migration cost assessment, wherein the data migration cost assessment is used to calculate the cost of migrating the logical partitions from the second physical machine to the first physical machine; and determining whether to execute the connection rules based on the result of the data migration cost assessment.

Description

[0001] This application is a divisional application of the patent application filed on June 27, 2018, with application number "201810682121.7" and titled "A Partition-Level Connection Method and Apparatus for a Distributed Database". Technical Field

[0002] This specification relates to the field of computer technology, and in particular to a partition-level connection method and apparatus for a distributed database. Background Technology

[0003] In database systems, data partitioning is a crucial method for improving operational efficiency and system performance. For queries involving multiple partitions, databases often employ multi-threaded / process concurrent execution to enhance efficiency. However, parallel execution incurs the cost of data exchange. Therefore, the optimizer tries to aggregate mergeable operations into a single thread. One aggregation method is called partition-level join—when the partition keys and join keys of two or more tables requiring a join operation are the same, the join operation can be pushed down to the corresponding partition, avoiding data exchange across threads / processes. However, in distributed databases, this optimization is limited by the physical distribution of partitions. Distributed database systems frequently involve data migration. Data partitions on the same physical machine during the optimization phase may be migrated to other machines during the execution phase. Staticly generated parallel partition-level join plans cannot automatically handle this situation. Summary of the Invention

[0004] To address the issues raised above, this specification provides a partition-level join method for distributed databases.

[0005] The distributed database contains multiple data tables, which are partitioned based on the same partition key. Each data table is further divided into multiple logical partitions, and these logical partitions belonging to different data tables are joined based on the same partition key. The joining method includes:

[0006] Receive connection rules for M logical partitions located on the first physical machine, wherein the M logical partitions belong to M data tables respectively;

[0007] Verify whether the physical machines where the M logical partitions are located have changed;

[0008] If so, obtain the second physical machine where the logical partition whose location has changed is located, and perform a data migration cost assessment. The data migration cost assessment is used to calculate the cost of migrating the logical partition from the second physical machine to the first physical machine.

[0009] Whether to execute the connection rule is determined based on the results of the data migration cost assessment.

[0010] More preferably, the connection rule includes obtaining logical partitions with the same partition key value from the M logical partitions located on the first physical machine, and performing equi-connection on the logical partitions with the same partition key value.

[0011] More preferably, determining whether to execute the connection rule based on the data migration cost assessment includes: comparing the cost value with a preset cost value threshold.

[0012] If the cost value is less than the preset cost threshold, the logical partition is migrated from the second physical machine location back to the first physical machine, and the join rule is executed on the tables of the multiple logical partitions of the multiple data tables.

[0013] If the cost value is greater than the preset cost threshold, the connection rule will not be executed.

[0014] More preferably, the data migration cost includes the time required to migrate the logical partition from the second physical machine back to the first physical machine.

[0015] More preferably, the data migration cost includes the number of data exchanges required to migrate the logical partition from the second physical machine back to the first physical machine.

[0016] This specification also provides a partition-level connection device for a distributed database, the distributed database comprising multiple data tables, the multiple data tables being partitioned based on the same partition key, wherein any data table is divided into multiple logical partitions, and multiple logical partitions belonging to different data tables are connected based on the same partition key, the connection device comprising:

[0017] The receiving module receives connection rules planned for M logical partitions located on the first physical machine, wherein the M logical partitions belong to M data tables respectively;

[0018] The verification module verifies whether the physical machines where the M logical partitions are located have changed.

[0019] The cost assessment module obtains the second physical machine where the logical partition whose location has changed is located, and performs a data migration cost assessment. The data migration cost assessment is used to calculate the cost of migrating the logical partition from the second physical machine to the first physical machine.

[0020] The decision module determines whether to execute the connection rule based on the result of the data migration cost assessment.

[0021] More preferably, the connection rule includes obtaining logical partitions with the same partition key value from the M logical partitions located on the first physical machine, and performing equi-connection on the logical partitions with the same partition key value.

[0022] More preferably, the judgment module further: compares the value of the loss with a preset value threshold.

[0023] If the cost value is less than the preset cost threshold, the logical partition is migrated from the second physical machine location back to the first physical machine, and the join rule is executed on the tables of the multiple logical partitions of the multiple data tables.

[0024] If the cost value is greater than the preset cost threshold, the connection rule will not be executed.

[0025] More preferably, the data migration cost includes the time required to migrate the logical partition from the second physical machine back to the first physical machine.

[0026] More preferably, the data migration cost includes the number of data exchanges required to migrate the logical partition from the second physical machine back to the first physical machine.

[0027] Accordingly, this specification also provides a computer device, including: a memory and a processor; the memory stores a computer program executable by the processor; when the processor runs the computer program, it performs the steps described in the partition-level join method for distributed databases described above.

[0028] Accordingly, this specification also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the steps described in the partition-level join method for the distributed database described above.

[0029] The database partition-level join method and apparatus provided in this specification introduce the ability to automatically handle data migration or situations where a few partitions do not meet the conditions of the partition-level join plan when statically generating a parallel partition-level join plan adapted to a distributed database. Based on the built-in cost model, it can adaptively handle changes in the physical distribution of partitions in a distributed system, thereby improving the execution efficiency of database operation commands such as user queries. Attached Figure Description

[0030] Figure 1 A flowchart illustrating a database partition-level connection method provided as an exemplary embodiment of this specification;

[0031] Figure 2 This specification provides a logical architecture diagram for parallel execution of partition-level join operations on multiple physical machines in a distributed database, as an exemplary embodiment of the present specification.

[0032] Figure 3 A schematic diagram of a database partition-level connection device provided for an exemplary embodiment of this specification;

[0033] Figure 4 This is a hardware structure diagram for running an embodiment of the database partition-level connection method or apparatus provided in this specification. Detailed Implementation

[0034] Database partitioning is a common physical database design technique used to reduce the total amount of data read and write operations and thus shorten response time during specific database operations. Database (or table) partitioning involves distributing data from a large data table across different system partitions, hard drives, or different server devices according to different partitioning strategies. This achieves balanced data distribution, distributing large amounts of data evenly across different storage media. Each partition receives a portion of the data, allowing users to locate a specific partition and perform the required operations on the table. Furthermore, it facilitates data table management; for example, to delete data for a specific time period, one can partition by date and then directly delete that date partition. Therefore, data partitioning is an important means of improving operational efficiency and system performance.

[0035] For data operations involving multiple partitions, databases often employ multi-threaded / process concurrent execution to improve efficiency. To reduce the data exchange costs associated with parallel execution, the database optimizer tries to merge operations within the same thread / process. One method of merging operations is called "partition-level join," where the join key of two or more tables matches their partition key (i.e., the columns referenced in the join operation are the same columns referenced in the partition operation). In this case, the join operation can be executed simultaneously within multiple partitions without data exchange between them. However, when the database is a distributed system comprised of one or more physical machines interconnected via a network, data migration is frequent. Data partitions on the same physical machine during the optimization phase may be migrated to other machines during the execution phase. Staticly generated parallel partition-level join plans cannot automatically handle this situation.

[0036] Based on the above problems, this specification proposes an exemplary embodiment of a partition-level connection method for a distributed database, such as... Figure 1 As shown, the distributed database contains multiple data tables, which are partitioned based on the same partition key. Each data table is divided into multiple logical partitions, and these logical partitions belonging to different data tables are joined based on the same partition key. The joining method includes:

[0037] Step 102: Receive the connection rules planned for M logical partitions located on the first physical machine, wherein the M logical partitions belong to M data tables respectively;

[0038] Step 104: Check whether the physical machines where the M logical partitions are located have changed;

[0039] if,

[0040] Step 106: Obtain the second physical machine where the logical partition whose location has changed is located, and perform a data migration cost assessment. The data migration cost assessment is used to calculate the cost of migrating the logical partition from the second physical machine to the first physical machine.

[0041] Step 108: Determine whether to execute the connection rule based on the result of the data migration cost assessment.

[0042] The distributed database described in the embodiments provided in this specification refers to a distributed database composed of one or more physical machines interconnected through a network. Each of these physical machines may have a complete copy or a partial copy of all the data. These multiple physical machines located at different physical addresses are interconnected through the network to form a complete, globally logically centralized, and physically distributed database. After multiple data tables in the database are logically partitioned based on the same partition key, the multiple logical partitions of each data table can be located on different physical machines. When formulating the join rules (or join plans) for the aforementioned "partition-level joins," the distributed database needs to formulate join plans for the corresponding logical partitions of the multiple data tables located on the same physical machine to connect the corresponding logical partitions. This facilitates various operations on the joined data, such as adding, deleting, modifying, and querying data, within the same thread / process on that physical machine.

[0043] Figure 2 This specification illustrates a logical architecture for parallel execution of partition-level join operations across multiple physical machines in a distributed database, as provided in one embodiment. For simplicity, Figure 2 The diagram illustrates only the connection of corresponding logical partitions (e.g., the p0 partition of t1 and the p0 partition of t2) after partitioning two data tables t1 and t2 based on the same partition key in each physical machine. Those skilled in the art will understand that in practical applications, a single physical machine can contain multiple different logical partitions of a single data table. This specification does not limit the number of logical partitions of a single data table within a physical machine, but the partition-level join rules (e.g., ...) are... Figure 2The join operation shown needs to be performed on M logical partitions belonging to M data tables (such as partition p1 of t1 and partition p1 of t2, or partition p2 of t1 and partition p2 of t2). Those skilled in the art should know that M should be a natural number. The aforementioned "corresponding logical partitions" refer to the fact that these multiple logical partitions can be joined based on the same partition key, and various operations on the data can be performed on the joined data within the same thread / process on the same physical machine. The specific process of partitioning based on the same partition key is not limited in this specification; various partitioning strategies such as hash partitioning or range partitioning can be used.

[0044] For example, in Figure 2 In the illustrated embodiment, t1 and t2 can be partitioned based on a hash partitioning mode. The first column c1 of t1 is its partition key, and the first column c1 of t2 is also its partition key. Furthermore, the attributes of column c1 of t1 and column c2 of t2 are the same. The partitioning process can be as follows:

[0045] select * from t1, t2 where t1.c1 = t2.c1;

[0046] create table t1 (c1 int, c2 int) partition by hash(c1) partitions 4;

[0047] create table t2 (c1 int, c2 int) partition by hash(c1) partitions 4;

[0048] This divides tables t1 and t2 into four logical partitions: p0, p1, p2, and p3, respectively.

[0049] Typically, the specific partition-level join rules described above are planned by the distributed database optimizer. The optimizer, based on the physical machine location of the logical partitions shown in the current database partition tables, performs joins for multiple data tables located on the same physical machine (such as...). Figure 2 For the corresponding logical partitions of t1 and t2 shown (such as the p3 partition of t1 and the p3 partition of t2), define the partition-level join rules (such as...). Figure 2The join rules (join 0, join 1, join 2, or join 4) can include multiple corresponding logical partitions of the multiple data tables located on the same physical machine, the join method, the join process, etc., and can generally be represented as the execution plan tree generated by the optimizer. The join methods mentioned above include, but are not limited to, inner joins, outer joins, and cross joins of the multiple logical partitions, and in partition-level joins, all of the above join methods should be based on the partition keys of the multiple data tables when the partitions were generated. To further improve the data processing efficiency after performing partition-level joins on multiple databases, the join method in the above join rules should preferably be an equi-join, that is, to obtain logical partitions with the same partition key value from multiple logical partitions belonging to multiple data tables located on the same physical machine, and to perform an equi-join on the logical partitions with the same partition key value.

[0050] To prevent the physical migration of the aforementioned logical partition data within the distributed database from affecting the accurate execution of the connection plan, in an illustrative embodiment of this specification, an operator RX can be introduced at the logical level of the database for each logical partition. After receiving the connection rules (or connection plan) from the optimizer, this logical operator RX checks whether the physical location corresponding to each logical partition has changed compared to the physical location where the logical partition should be located, as specified in the connection rules.

[0051] If the execution of the logical operator RX checks and finds that the physical machine corresponding to the logical partition is the same as the physical machine that the logical partition should be on as specified in the join rule (i.e., they are on the same physical machine), then the RX operator executes "short-circuit mode," meaning the aforementioned join rule is applicable to that logical partition. Figure 2 The join rules shown, join 0, join 1, join 2, and join 3, are all available for their logical partitions, which can directly return the results of their data scans to the database system (or optimizer).

[0052] Because distributed databases are prone to data migration due to human error or other system command execution, if the execution of the logical operator RX detects that its corresponding logical partition is no longer located on the physical machine that the logical partition should reside on according to the join rules, such as... Figure 2The p3 partition of t2 shown is no longer located on physical machine 3 as determined during the connection rule generation. RX can communicate with the module in the distributed database responsible for recording data partition information to obtain the current location of the corresponding logical partition on physical machine 4, and send this location to the database's cost assessment module responsible for calculating data migration costs. This cost assessment process includes calculating the database system cost required to migrate the logical partition corresponding to the logical operator RX from physical machine 4 back to physical machine 3. For example, in... Figure 2 In the process, the database system (usually the optimizer) responds to the request from RX corresponding to p3 partition of t2, and evaluates the cost required to migrate p3 partition of t2 from its current physical machine 4 back to the physical machine 3 corresponding to join plan 3.

[0053] The module responsible for calculating the cost of data migration in the aforementioned database is typically a functional module included in the optimizer of the distributed database. The specific manifestation of this data migration cost may include the system moving the logical partition from the second physical machine (e.g., ...). Figure 2 Physical machine 4) migrates back to the first physical machine (e.g., physical machine 4) Figure 2 The time required for physical machine 3 in the middle (system instruction latency) may also include transferring the logical partition from the second physical machine (such as Figure 2 Physical machine 4) migrates back to the first physical machine (e.g., physical machine 4) Figure 2 The cost of data migration is commonly represented by the number of data exchanges required between the physical machines in the diagram (3). This specification does not limit the mathematical model or algorithm on which the above cost evaluation process is based. Those skilled in the art can set up a data migration cost evaluation model based on specific application scenarios and set different data migration cost thresholds for specific application scenarios. The data migration cost threshold is used to represent the cost of migrating logical partition data between different physical machines that the database system can accept in order to maintain the original partition-level connection plan (rules).

[0054] After assessing the migration cost of the logical partition data, the database system can determine whether the above-mentioned join rule can be executed based on the result of the data migration cost assessment. There are several ways to make this determination. For example, the logical judgment module of the database system can use the cost threshold comparison method to make the judgment, comparing the data migration cost calculated above with the migration cost threshold preset by the system for logical partition data migration:

[0055] If the cost value calculated by the cost evaluation model is less than the preset cost threshold, the distributed database can issue a migration instruction to migrate the logical partition from the second physical machine back to the first physical machine, and determine to execute the connection rules on the data tables of the multiple logical partitions of the multiple data tables. The above migration can be achieved through methods such as RPC remote data calls.

[0056] If the cost calculated by the cost assessment model is greater than the preset cost threshold, the database system will not execute the connection rule. Figure 2 The join rule shown is join 4, meaning it will no longer be executed. In this case, the optimizer can generate new join rules to create new partition-level join plans for logical partitions that are currently on the same physical machine. For logical partitions that are not on the same physical machine, based on the needs of the actual application scenario, if it is necessary to join multiple logical partitions on different physical machines, a new join plan should be formulated, such as a separate hash join of the left and right tables, broadcasting the left table, or randomly sending the right table.

[0057] Of course, the database system can also use a scoring and ranking system to determine whether the above-mentioned connection rule can be executed based on the data migration cost assessment result. For example, the logical partition data migration cost required to execute the partition-level connection rule in different physical machines can be sorted according to the value. The database system selects the partition-level connection rule with the value within an acceptable range, and uses the corresponding RX operator to migrate the data of the corresponding logical partition back to the physical machine indicated by the original partition-level connection rule to execute the original partition-level connection rule.

[0058] The embodiments described above in this specification implement the processing of partition-level join plans for distributed databases by introducing the logical operator RX. When the database system optimizer statically generates a parallel partition-level join plan adapted to the distributed database, the interaction between RX and various functional modules of the database system introduces the ability to automatically handle data migration or situations where a few partitions do not meet the conditions of the partition-level join plan. Based on a built-in cost evaluation model, it can adaptively handle changes in the physical distribution of logical partitions in the distributed database, improving the execution efficiency of database operation commands such as user queries. Those skilled in the art should understand that the logical operator RX is only an abstract representation of the database system at the logical operation level, and the actual implementation of this logical process should not be limited to any expression in any computer language.

[0059] Corresponding to the above process, the embodiments of this specification also provide a partition-level connection device for a distributed database. This device can be implemented in software, hardware, or a combination of both. Taking software implementation as an example, as a logical device, it is formed by the CPU (Central Processing Unit) of the device loading the corresponding computer program instructions into memory for execution. From a hardware perspective, besides... Figure 4 In addition to the CPU, memory, and storage shown, the device containing this data processing unit typically includes other hardware such as chips for wireless signal transmission and reception, and / or other hardware such as boards for implementing network communication functions.

[0060] Figure 3 The diagram shows a partition-level connection device 30 for a distributed database provided in this specification. The distributed database contains multiple data tables, which are partitioned based on the same partition key. Each data table is divided into multiple logical partitions, and these logical partitions belonging to different data tables are connected based on the same partition key. The connection device 30 includes:

[0061] The receiving module 302 receives the connection rules planned for M logical partitions located on the first physical machine, wherein the M logical partitions belong to M data tables respectively;

[0062] The verification module 304 verifies whether the physical machines where the M logical partitions are located have changed.

[0063] The cost assessment module 306 obtains the second physical machine where the logical partition whose location has changed is located, and performs a data migration cost assessment. The data migration cost assessment is used to calculate the cost of migrating the logical partition from the second physical machine to the first physical machine.

[0064] The judgment module 308 determines whether to execute the connection rule based on the result of the data migration cost assessment.

[0065] More preferably, to further improve the execution efficiency of parallel partition-level joins in a distributed database, the join rule includes obtaining logical partitions with the same partition key value from the M logical partitions located on the first physical machine, and performing equi-joins on the logical partitions with the same partition key value.

[0066] More preferably, the judgment module further: compares the value of the loss with a preset value threshold.

[0067] If the cost value is less than the preset cost threshold, the logical partition is migrated from the second physical machine location back to the first physical machine, and the join rule is executed on the tables of the multiple logical partitions of the multiple data tables.

[0068] If the cost value is greater than the preset cost threshold, the connection rule will not be executed.

[0069] More preferably, the data migration cost includes the time required to migrate the logical partition from the second physical machine back to the first physical machine.

[0070] More preferably, the data migration cost includes the number of data exchanges required to migrate the logical partition from the second physical machine back to the first physical machine.

[0071] The specific implementation process of the functions and roles of each module in the above device can be found in the implementation process of the corresponding steps in the above method. For relevant details, please refer to the description of the method embodiment. It will not be repeated here.

[0072] The device embodiments described above are merely illustrative. The modules described as separate components may or may not be physically separate, and the components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the units or modules can be selected to achieve the purpose of the solution described in this specification, depending on actual needs. Those skilled in the art can understand and implement this without any inventive effort.

[0073] The devices and modules described in the above embodiments can be implemented by computer chips or physical entities, or by products with certain functions. A typical implementation device is a computer, which can take the form of a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email sending and receiving device, game console, tablet computer, wearable device, or any combination of these devices.

[0074] Corresponding to the above method embodiments, embodiments of this specification also provide a computer device, which includes a memory and a processor. The memory stores a computer program executable by the processor; when the processor runs the stored computer program, it executes the various steps of the partition-level join method for a distributed database as described in this specification. For a detailed description of each step of the partition-level join method for a distributed database, please refer to the previous content, which will not be repeated here.

[0075] Corresponding to the above-described method embodiments, this specification also provides a computer-readable storage medium storing computer programs that, when executed by a processor, perform the various steps of the partition-level join method for a distributed database as described in this specification. For a detailed description of each step of the partition-level join method for a distributed database, please refer to the previous content, which will not be repeated here.

[0076] The above description is merely a preferred embodiment of this specification and is not intended to limit this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of protection of this specification.

[0077] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0078] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0079] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data.

[0080] Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transient media, such as modulated data signals and carrier waves.

[0081] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0082] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, the embodiments of this specification can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, the embodiments of this specification can take the form of computer program products implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

Claims

1. A partition-level join method for a distributed database, the distributed database comprising multiple data tables, the multiple data tables being partitioned based on the same partition key, wherein, Any data table is divided into multiple logical partitions. Multiple logical partitions belonging to different data tables and located on the same physical machine are joined based on the same partition key. The joining method includes: Receive connection rules for M logical partitions located on the first physical machine, wherein the M logical partitions belong to M data tables respectively; Verify whether the physical machines where the M logical partitions are located have changed; If so, obtain the second physical machine where the logical partition whose location has changed is located, and evaluate the data migration cost of migrating the logical partition from the second physical machine back to the first physical machine; Based on the data migration cost, determine whether to migrate the logical partition from the second physical machine back to the first physical machine. If so, migrate the logical partition from the second physical machine back to the first physical machine, and execute the join rule on the tables of the multiple logical partitions of the multiple data tables.

2. The method according to claim 1, further comprising: If it is determined that the logical partition will not be migrated from the second physical machine back to the first physical machine, the connection rule will not be executed.

3. The method according to claim 1, wherein the connection rule includes obtaining logical partitions with the same partition key value from the M logical partitions located on the first physical machine, and performing equi-connection on the logical partitions with the same partition key value.

4. The method according to claim 1, wherein the data migration cost includes the time required to migrate the logical partition from the second physical machine back to the first physical machine.

5. The method according to claim 1, wherein the data migration cost includes the number of data exchanges required to migrate the logical partition from the second physical machine back to the first physical machine.

6. A partition-level connection device for a distributed database, the distributed database comprising multiple data tables, the multiple data tables being partitioned based on the same partition key, wherein, Any data table is divided into multiple logical partitions. Multiple logical partitions belonging to different data tables and located on the same physical machine are connected based on the same partition key. The connection device includes: The receiving module receives connection rules planned for M logical partitions located on the first physical machine, wherein the M logical partitions belong to M data tables respectively; The verification module verifies whether the physical machines where the M logical partitions are located have changed. The cost assessment module obtains the second physical machine where the logical partition whose location has changed is located, and assesses the data migration cost of migrating the logical partition from the second physical machine back to the first physical machine. The judgment module determines whether to migrate the logical partition from the second physical machine back to the first physical machine based on the data migration cost. If so, the logical partition is migrated from the second physical machine back to the first physical machine, and the join rule is executed on the tables of the multiple logical partitions of the multiple data tables.

7. A computer device, comprising: Memory and processor; The memory stores computer programs that can be executed by a processor; When the processor runs the computer program, it performs the method as described in any one of claims 1 to 5.

8. A computer-readable storage medium having a computer program stored thereon, said computer program being executed by a processor to perform the method as described in any one of claims 1 to 5.

Images