WO2018043843A1 - Relational database storage system and method for supporting quick query processing with low data redundancy, and method for processing query on basis of relational database storage method - Google Patents

Abstract

A relational database storage method according to one embodiment generates a join graph including tables and edges on the basis of a database schema including information on reference and limitation conditions between database tables, and a query set including join predicate information, classifies the type of tables on the basis of the cost of a join operation between the tables included in the join graph, classifies the type of edges in the join graph on the basis of the type of the tables connected to each other by the edge, adds a virtual edge between two tables satisfying an indirect edge condition in the join graph, and generates a database partitioning plan for the join graph on the basis of the type of edges including the virtual edge.

Description

Relational database storage system that supports fast query processing with low data redundancy, how to handle queries based on how and how to store relational databases

The technical field uses graph-based database partitioning schemes and hash-based multi-column table partitioning methods to process queries based on relational database storage systems, storage methods, and relational database storage methods that support fast query processing with low data redundancy. It's about how

Partitioning of the database has been widely used as a query optimization technique in many query processing systems because it reduces the I / O overhead required for relatively expensive join operations.

In particular, parallel and distributed query processing systems in which compute nodes are connected by a network can utilize a partitioned database to process equal join operations that satisfy certain conditions. In this case, for example, a join operation of two tables R and S is an equal join (Ra = Sb), and a join column (Ra = Sb) included in a join predicate splits the tables R and S. This may mean the same as the partitioning column used in the.

In the parallel and distributed query processing systems, parallel join processing can be performed independently on a data set allocated to each slave node without exchanging data through a network when processing a join operation. Because of these advantages, the importance of database partitioning method has been emphasized recently.

The most recently proposed database partitioning method is a method of generating a database partitioning plan in the form of a tree using a referential constraint and join predicates between two tables. The database partitioning plan uses the maximum spanning tree obtained from the schema graph. The schema graph shows the tables as nodes, the referential constraints or join predicates as edges, the equal join predicates obtained from the referential constraints or join predicates as edge labels, and The graph shows the weight of the edge as the smaller value of the size of both edge tables.

Partitioning a database using a maximum-strength tree involves splitting a child table S out of two adjacent tables R and S that have a parent-child relationship in the tree. Tuples belonging to s

A partitioning column value and a tuple of the i th (1 ≤ i ≤ P) partition of the parent table

If the partitioning column values in the table match, the tuple s is stored in the i th partition of the parent table. In this case, tuples belonging to the child table may be duplicated and stored in one or more partitions according to the number of partitions of the parent table satisfying the above condition.

However, partitioning the database using the maximum spanning tree has the following problems.

First, the method of using the maximum spanning tree must refer to the partition of the table corresponding to the parent in the tree to partition the table. Therefore, two adjacent tables having a parent-child relationship have data dependencies with each other, and the number of operations that refer to the partition of the parent table required for partitioning the table increases in proportion to the database size. Therefore, there is a serious problem that the data loading time is greatly increased when partitioning a large database.

Second, due to the above-described data dependency, tuple-level data duplication may occur seriously in the partition of the child table according to the distribution of tuples in the parent table. That is, when a child table refers to a column used as a foreign key of a parent table, the degree of data redundancy may increase because the distribution of the foreign key is not unique.

Third, as the complexity of the database schema or input query set increases, one or more referential constraints or join predicate relationships can exist between the two tables.

In this case, considering the maximum number of referential constraints or join predicates as partitioning predicates, data locality of a partitioned database may be increased. However, if the database partition plan follows the tree shape, the tree depth may be deepened or one or more tree partition plans may be generated. In this case, as the depth of the tree becomes deep due to data dependency between adjacent partitioned tables, the degree of cumulative data overlap may become very large.

In addition, when more than one database partitioning plan is created, table-level redundancy may occur in which a large table is partitioned several times. At this time, the labels of the edges including the partitioning relationship may be the same, thereby increasing the data redundancy, but may cause inefficiency that does not increase the data locality.

Fourth, since the tree structure cannot have a cyclic relationship between nodes, the tree-shaped partitioning scheme cannot also include a cyclic relationship between tables. In other words, data locality for circular join cannot be guaranteed through a tree-type database partition. However, the more complex the query, the more often it involves circular joins. In the case of tree-type database partitioning, a remote join operation that does not guarantee data locality causes a problem of degrading complex query processing performance.

Fifth, tree-type database partitioning adds repartitioning operations to the query execution plan to eliminate query processing results and tuple-level redundancy. It requires a process. In the method of removing such duplicate tuples, since duplicate tuples must be transmitted between nodes through a network communication before a join operation is performed, a problem arises in that query processing performance is slowed depending on the degree of partition overlap.

As described above, it is difficult to develop an efficient database partitioning method that satisfies both query processing performance and storage space, and a relational database storage system using the same, compared to the importance of the database partitioning method.

According to an embodiment, a cost model based analysis using graph theory for a database schema and a series of input queries is performed, even though the complexity of the input graph increases, the optimal graph structure in terms of query processing performance and storage space efficiency. Can provide a database partitioning plan.

According to an embodiment, by partitioning a database on a hash basis using only partitioning columns of a corresponding table in a graph structure, a database partitioning plan in which data dependency between tables having parent-child relationships in a tree structure does not occur may be provided.

According to an embodiment, partitioning tables independently on each machine using a hash-based partitioning method may ensure data scalability as well as performance of data loading.

According to an embodiment, a table relation in one or more referential constraints or join predicate relations may be represented by a graph structure, in particular, a multi graph structure, thereby expressing a circular join relationship or a circular reference relationship between tables.

According to an embodiment, the degree of data redundancy may be greatly reduced through hash-based partitioning without data dependency on information of partitioning columns included in partitioning predicate information of edges included in a table.

According to an embodiment, a bitmap table, which is a set of bitmap vectors containing tuple overlapping information at each tuple level included in a partition of a table, is used to remove duplicates in a scan operation independently at each node without repartitioning the table. can do.

According to an embodiment, by using a subpartitioning method using a bitmap vector, an additional overhead due to a bitmap table access is reduced when performing a scan operation considering deduplication, and without additional overhead of a query rewriting process. Can improve query processing performance.

According to an embodiment, based on the concept of sub partitioning, the processing performance of a query may be improved by using a scan operation that reads only some of the subpartitions required when processing a query on a partitioned table.

According to one side, the relational database storage method is at least one of a database schema including information about references and constraints between the database tables and a query set including the join predicate information Based on the step of generating a join graph comprising tables and edges; Classifying the types of the tables based on a cost of a join operation between the tables included in the join graph; Distinguishing a type of edges in the join graph based on the type of the tables connected to each other by an edge; Adding a virtual edge between two tables that satisfy an indirect edge condition in the join graph; And generating a database partitioning plan for the join graph based on the type of edges including the virtual edge.

The generating of the join graph may include configuring an edge between tables included in the join graph by using at least one of the information about the reference and the constraint and the join predicate information.

The classifying the types of the tables may include classifying the types of the tables based on a cost of a join operation between a table in the join graph and adjacent tables adjacent to the table.

The dividing of the types of the tables may include: a sum of first join operation costs when the table is divided and stored in a storage device and the table to a plurality of slave nodes based on the aggregate information of the table and the adjacent tables. Calculating a sum of the cost of the second join operation when replicating; Dividing the type of the table into one of a first type and a second type according to a comparison result between the sum of the first join operation cost and the second join operation cost; And storing the table according to the type of the divided table.

The dividing of each type of the edges may include dividing each type of the edges into one of an inter edge and an intra edge, based on a type of tables connected to each other by the edges. It may include a step.

The dividing into any one of the inter edge and the intra edge may include determining the type of the edge as an intra edge when all types of tables connected to each other by the edge are the first type; And when one type of the tables connected to each other by the edge is the first type and the other type is the second type, determining the type of the edge as the inter edge.

The adding of the virtual edge may include checking whether a pair of tables of a first type included in the join graph satisfy the indirect edge condition; And adding the virtual edge between the pair of tables of the first type that satisfies the indirect edge condition.

The indirect edge condition is a first condition in which a first table, which is a pair of tables of the first type, and a second table are connected through the same third table, a first edge of the first table, and a second edge of the second table. ; A second condition that the same column of the third table is included in the labels of the first edge and the second edge; And a third condition that the type of the third table is the second type.

The generating of the database partitioning plan may include calculating, according to the type of the edges, a gain when performing the join operation by using a table of a first type using the edges; Sorting the edges in ascending order of gain; Initializing a partition graph having nodes of a first type of tables in the join graph; And updating the segmentation graph by processing the edges in the sorted order.

The types of edges include at least one of an intra edge, an inter edge, and an indirect edge, and the calculating of the gains includes calculating the gains using different split gain models according to the types of edges. Can be.

The updating of the segmentation graph may include searching for two adjacent triangular edges that satisfy a triangular edge condition for edges in the join graph based on the database partition scheme; Searching for a hub table that satisfies a hub table condition for an edge in the join graph based on the database partitioning plan; And adding the edge, the two triangular edges, and the hub table to the segmentation graph.

The triangular edge condition is a condition that the type of the edge in the join graph is an intra edge; A condition that edges of each of two tables of a first type connected to the intra edge are present, and wherein each of the edges is connected to the same table; A condition in which the labels of each of the edges include a column of the same table; And a condition that the type of the same table is the second type.

The hub table condition is that the type of the edge in the join graph is an intra edge or an indirect edge between two tables of the first type, and the edge of each of the two tables of the first type is the triangular edge condition. Accordingly, a condition that is edges satisfying the triangular edge condition may be included with respect to one or more columns of the common table classified as the second type.

The relational database storage method may further include: splitting tuples included in the tables based on a hash function based on the database partitioning plan; And storing the corresponding tuple in a partition corresponding to each of the divided tuples based on information associated with a partitioning column of the corresponding tuple.

The partitioning based on the hash may include determining a location of a partition in which the corresponding tuple is to be stored, based on a hash function of all partitioning column values of the tuples; Generating a bitmap vector using index information of the corresponding partitioning column in the partitioning column set; And updating bitmap vector information of the corresponding tuple in the bitmap table of the table by using the bitmap vector.

The storing of the corresponding tuple may include generating a bitmap vector set by using partitioning column information of a table including a list of tuples shuffled for each partition corresponding to each of the divided tuples; Initializing a subpartition for a bitmap vector included in the bitmap vector set; Storing each tuple in a corresponding subpartition using a bitmap vector corresponding to each tuple included in the tuple list; And when all tuples included in the tuple list are stored in the subpartition, configuring the partition of the table including the tuple list by the union of all the subpartitions.

According to one side, a method for processing a query based on the relational database storage method comprising the steps of determining whether the table is used in a join operation in the input query; Determining whether the intersection between the first partitioning column set of the table and the second partitioning column set of the table to be joined with the table is empty by using the partition column information of the table; Selecting one partitioning column associated with the table according to the scan mode of the table determined based on the determination; Calculating a list of bitmap vectors corresponding to the selected partitioning column; Selecting a subpartition corresponding to at least one bitmap vector included in the list of bitmap vectors; And scanning the selected subpartition.

The selecting of any one partitioning column may include determining one of a first scan mode and a second scan mode to read the table based on the determination; And selecting one partitioning column among the partitioning column included in the intersection and the partitioning column included in the first partitioning column set according to any one of the scan modes.

According to one side, the graph-based database partitioning plan can improve the processing performance of the query while reducing data redundancy for a database schema and a set of input queries with a very large number of tables and relationships between the tables.

According to one side, a database with low data redundancy while maximizing data locality for processing queries including circular reference relationships and circular join relationships between tables in an input schema or query set by utilizing graph theory such as triangular edge search. You can create a split plan.

According to one side, independent processing of a scan operation on a node without rewriting a query to add a repartitioning process for deduplication when processing a query using a partition including a duplicate tuple by subpartitioning You can remove duplicates with

According to one side, by using a tuple-level hash-based partitioning method using partitioning column information included in the database partitioning plan of the graph structure, the occurrence of data dependency problem exists between the parent-child tables in the tree structure. You can block.

According to one side, by using the tuple-level hash-based partitioning method using the partitioning column information included in the database partitioning plan of the graph structure to solve the degradation of data loading performance due to partition reference operation during data loading, Data duplication can be prevented from overlapping.

1 illustrates the structure of a relational database storage system according to one embodiment.

2 is a table showing symbols and meanings of symbols used in embodiments.

3 is a flow diagram illustrating a relational database storage method according to one embodiment.

4 is a flowchart illustrating a method of classifying types of tables according to an embodiment.

5 is a flowchart illustrating a method of classifying edge types according to an embodiment.

6 is a flowchart illustrating a method of adding a virtual edge according to an embodiment.

7 is a flowchart illustrating a method of generating a database partitioning plan according to one embodiment.

8 is a flowchart illustrating a method of searching for a triangular edge according to an embodiment.

9 is a flowchart illustrating a method of searching a hub table according to an embodiment.

10 is a flowchart illustrating a map operation of a data loader included in a master node according to an embodiment.

11 is a flowchart illustrating a reduce operation of a data loader included in a master node according to an embodiment.

12 is a diagram illustrating an example of a partition when partitioning and storing a table using a bitmap table, according to an embodiment.

FIG. 13 illustrates an example of a partition when partitioning and storing a table by subpartitioning according to an embodiment; FIG.

14 is a flow diagram illustrating a method of processing a query based on a relational database storage method, according to one embodiment.

Hereinafter, exemplary embodiments will be described in detail with reference to the accompanying drawings. However, the scope of the patent application is not limited or limited by these embodiments. Like reference numerals in the drawings denote like elements.

Various modifications may be made to the embodiments described below. The examples described below are not intended to be limited to the embodiments and should be understood to include all modifications, equivalents, and substitutes for them.

The terminology used herein is for the purpose of describing particular example embodiments only and is not intended to be limiting of examples. Singular expressions include plural expressions unless the context clearly indicates otherwise. In this specification, terms such as "comprise" or "have" are intended to indicate that there is a feature, number, step, action, component, part, or combination thereof described on the specification, and one or more other features. It is to be understood that the present invention does not exclude the possibility of the presence or the addition of numbers, steps, operations, components, components, or a combination thereof.

Unless defined otherwise, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art. Terms such as those defined in the commonly used dictionaries should be construed as having meanings consistent with the meanings in the context of the related art and shall not be construed in ideal or excessively formal meanings unless expressly defined in this application. Do not.

In addition, in the description with reference to the accompanying drawings, the same components regardless of reference numerals will be given the same reference numerals and duplicate description thereof will be omitted. In the following description of the embodiment, when it is determined that the detailed description of the related known technology may unnecessarily obscure the gist of the embodiment, the detailed description thereof will be omitted.

1 is a diagram illustrating a structure of a relational database storage system according to an embodiment. Referring to FIG. 1, a relational database storage system according to an embodiment includes a master node 110 and N slave nodes 150-1,... 150 -N. The master node 110 and the N slave nodes 150-1,... 150 -N may be configured as a cluster connected by a network.

The master node 110 may include a database partition determiner 120, a table partition storage device 130, and a partitioned table reading device 140.

The database partition determiner 120 may include a table partitioning module 121, an edge partitioning module 122, an indirect edge search module 123, a triangular edge search module 124, a hub table search module 125, and a database partition plan generator ( 126). The operation of the database partition determiner 120 will be described with reference to FIGS. 3 to 9.

The table partition storage device 130 may include a data loader 135. The data loader 135 may perform a map operation and a reduce operation. The operation of the data loader 135 will be described with reference to FIGS. 10 to 13.

The partitioned table reading device 140 may process a query by reading a query based on a relational database storage method. The operation of the partitioned table reading device 140 will be described with reference to FIG. 14.

Each of the slave nodes 150 includes a CPU 151, a main memory 153, and an auxiliary memory 157. The main memory 153 and the auxiliary memory 157 may store database partitions 1 155 and 159 corresponding to the corresponding slave nodes, respectively.

In the slave nodes 150, N partitioned database partitions may be distributed and stored in one partition for each slave node. The database partition may be stored in both the main memory 153 and the auxiliary memory 157 of each slave node. For example, in an in-memory query processing system, the CPU 151 may process a query using a database partition 155 stored in the main memory 153. In addition, in the case of a disk-based query processing system, the CPU 151 may process a query using the database partition 159 stored in the auxiliary storage device 157.

The symbols used in the following embodiments and the meanings of the symbols refer to the table shown in FIG. 2.

3 is a flowchart illustrating a relational database storage method according to an embodiment. Referring to FIG. 3, a method is shown in which the master partition 110 (of database partition determiner 120) shown in FIG. 1 generates a database partition plan.

The master node includes tables and edges, based on a database schema that contains information about references and constraints between database tables, and a query set that includes join predicate information. Create a join graph (310). Information about references and constraints between database tables may be referred to as 'reference constraint relationship information'.

The database schema may define, for example, data entities, attributes, relationships, and constraints of data values constituting the database.

The master node can construct a table (database table) for a given database schema or input query set as nodes in a join graph.

The master node may configure edges between tables included in the join graph by using at least one of reference constraint relationship information and join predicate information.

If the database schema is given as input, the master node can construct the edge between the tables in the join graph by using the referential constraint relationship information between the two tables included in the database schema. Alternatively, if a query set is given as input, the master node can construct the edges between the tables in the join graph using the join predicate information contained in the query in the query set. In this case, the label of the edge may be configured by using partitioning column information of two tables connected at both ends of the edge. In a referential constraint, a referential-referred relationship can be considered as an equal join predicate. For example, if a database schema is given as input, the master node can set the weight of all edges to '1'. Alternatively, if a query set is given as an input, the master node may set the frequency of the join predicate included in the query of the query set as the weight of the edge.

The master node classifies the types of tables based on the cost of the join operation between the tables included in the join graph (320). The master node may classify the types of tables based on the cost of a join operation between the tables in the join graph and adjacent tables adjacent to the tables. The cost of the join operation can be calculated, for example, by the cost model of the join operation. The cost model of the join operation may be defined as the sum of the scan costs of the join tables occurring in the processing of the join operation.

The master node is based on the aggregate information of the table and the adjacent tables, the sum of the first join operation cost when the table is stored in the storage unit and the second join operation cost when the table is replicated to the plurality of slave nodes. The sum can be calculated. The master node divides the table type into one of the first type and the second type according to the comparison result between the sum of the first join operation cost and the second join operation cost, and stores the table according to the divided table type. Can be. The first type may be, for example, a 'Part-table' type, and the second type may be, for example, a 'Rep-table' type. A method of distinguishing the types of tables by the master node will be described in detail with reference to FIG. 4.

The master node distinguishes the types of edges in the join graph based on the types of tables connected by the edges (330). The master node may classify each type of edge into one of an inter edge and an intra edge based on the types of tables connected to each other by the edge. A method of distinguishing the types of edges by the master node will be described with reference to FIG. 5.

The master node adds a virtual edge between two tables satisfying the indirect edge condition in the join graph (340). An indirect edge condition and a method of adding a virtual edge by the master node will be described with reference to FIG. 6.

The master node generates a database partitioning plan for the join graph based on the types of edges including the virtual edge (350). The master node may calculate a gain when performing a join operation by a table of the first type using the edges according to the types of edges, and sort the edges in the order of gain.

The master node may initialize a split graph that uses the first type of tables in the join graph as nodes. The master node can update the segmentation graph by processing the edges in sorted order. A method of generating a database partition plan by the master node will be described in detail with reference to FIG. 7.

4 is a flowchart illustrating a method of classifying types of tables according to an exemplary embodiment. Referring to FIG. 4, a method of distinguishing the types of tables by the master node 110 (the table classification module 121 of FIG. 1) shown in FIG. 1 is illustrated.

The master node may select table T in the join graph (410).

The master node calculates the sum of the cost of the first join operation between the table T and the adjacent tables adjacent to the table T when the table T is partitioned and stored in the storage device based on the aggregation information of the tables T and the adjacent tables adjacent to the table T. It may be calculated (420).

In step 420, when partitioning the table T into the storage device, that is, when the table T is a table type to be partitioned, the sum of the first join operation costs is, for example, the join processing cost model Cost _Part (T Can be obtained by

Join processing cost model Cost _Part (T) is the scan cost of a partitioned table that occurs when partitioned table T is joined with all adjacent tables.

Sum of the cost of scanning all tables in the set adj (T) of adjacent tables

It can be defined as. In this case, the join operation cost model according to the type of table may be defined as the sum of the scan costs of the join tables generated at the join process.

The master node replicates table T to N slave nodes based on the aggregate information of the tables T and adjacent tables adjacent to table T, that is, when table T is a table type to be replicated, The sum of the cost of the second join operation with adjacent adjacent tables may be calculated (430).

In step 430, when replicating table T to N slave nodes, that is, when table T is a table type to be replicated, the sum of the second join operation costs is, for example, the join processing cost model Cost _Rep. It can obtain | require by (T).

Join processing cost model Cost _Rep (T) is the sum of the table scan costs incurred when table T is joined with all neighboring tables when replicated to P partitions.

Sum of all scan costs of all tables in the set adj (T)

It can be defined as. Here, the number of partitioning columns of neighboring tables is reduced by 1 because the data locality is guaranteed even when the table T is replicated and the neighboring tables are queried using any column of the table T.

The master node may compare a difference between the cost of the first join operation cost Cost _Part (T) and the sum of the second join operation cost Cost _Rep (T) (440).

As a result of the comparison of step 440, if the sum of the costs of the first join operation is less than the sum of the costs of the second join operation, the master node may divide the type of table into a 'part-table'. (450). The master node can partition the table.

As a result of the comparison in step 440, if the sum of the costs of the first join operation is greater than or equal to the sum of the costs of the second join operation, the master node sets the type of table to 'Rep-table'. Can be distinguished (460). The master node can replicate the table to N slave nodes.

The master node may check whether all tables are separated (470). If it is determined in step 470 that all the tables are not distinguished, the master node may select the next table 480 and perform the processes of steps 420 to 470 for the next table.

As a result of checking in step 470, if all the tables have been identified, the master node may terminate the operation.

5 is a flowchart illustrating a method of classifying edge types according to an exemplary embodiment. Referring to FIG. 5, a method of distinguishing types of edges by the master node 110 (the edge classification module 122 of FIG. 1) illustrated in FIG. 1 is illustrated.

The master node may select the edge e in the join graph (510).

The master node may determine whether both types of tables of the edge e, that is, the types of tables connected to each other by the edge are tables to be replicated (520). If it is determined in step 520 that all of the types of tables are tables to be replicated, the master node may terminate the operation by checking whether all edges have been identified (560).

As a result of the determination of step 520, the types of tables connected to each other by edge e If it is not a table to be replicated, the master node may determine whether all types of tables are tables to be partitioned (530).

In step 530, if one type of the tables connected to each other by the edge is a table to be replicated and the other type is a table to be split, the master node may classify (determine) the type of the edge as an inter edge. May be 540.

In operation 530, when the types of tables connected to each other by the edge are tables to be split, the master node may classify (determin) the type of edge e into an intra edge (550).

The master node may check whether all edges have been identified (560). If all edges are not distinguished in step 560, the master node may select the next edge to perform the processes of steps 520 to 560.

If all edges are identified in step 560, the master node may terminate the operation.

6 is a flowchart illustrating a method of adding a virtual edge according to an embodiment. Referring to FIG. 6, a method of searching for a virtual edge by the master node 110 (indirect edge search module 123 of FIG. 1) shown in FIG. 1 is illustrated.

The master node checks whether a pair of all the first types of tables (partitioned tables) included in the join graph satisfy the indirect edge condition, and checks between the pairs of tables to be partitioned that satisfy the indirect edge condition. You can add virtual edges. Whether the pair of tables to be partitioned satisfies the indirect edge condition may be determined through the steps 620 to 650 shown in FIG. 6.

The master node may select a table pair <R, S> of the table type to be split included in the join graph (610).

The master node may determine whether the table R and the table S constituting the table pair are connected through the same table T and the edge e1 of the table R and the edge e2 of the table S (620).

As a result of the determination in step 620, if it is determined that the table R and the table S are connected through the table T and the edge e1 and the edge e2, the master node includes the same column of the table T in the label of the edge e1 and the label of the edge e2. In operation 630, it may be determined.

If the same column of the table T is included in the label of the edge e1 and the label of the edge e2 in step 630, the master node may determine whether the type of the table T is a table to be replicated (640).

If it is determined in step 640 that the type of table T is a table to be replicated, then the master node determines the edges e1 and e2 of the edges e1 and e2 of table R and table S that satisfy all of steps 620 through 640. In operation 650, it may be determined whether an edge e including a table R and a table S column included in the label of e2 exists between the table R and the table S.

If edge e does not exist between table R and table S in step 650, the master node may distinguish edge e as an indirect edge (660). In operation 660, the master node may add a virtual edge between the table R and the table S having the columns of the table R and the table S included in the labels of the edge e1 and the edge e2.

If it is determined in step 620 to step 650 that the result is not the determination of the conditions, the master node selects another table pair (680), and for each other table pair, The process can be performed.

The master node may determine whether it has identified all pairs of tables to partition in the join graph (670). If the step 670 does not identify all the pairs of tables to be partitioned, the master node selects another table pair to be partitioned (680) and repeats the process of steps 620 to 670 for the other partitioned table pair. Can be done.

Once the step 670 has identified all the pairs of tables to be partitioned, the master node may end the operation.

7 is a flowchart illustrating a method of generating a database partition plan according to an embodiment. Referring to FIG. 7, a method is shown in which the master node 110 (database partition plan generator 126 of FIG. 1) shown in FIG. 1 generates a database partition plan.

The master node may initialize the maximum-priority queue benefitQ (705).

The master node selects one edge e included in the union of the intra edge, the inter edge, and the indirect edge, which are the result of the operation of the edge classification module 122 and the indirect edge search module 123 described above with reference to FIGS. 5 and 6. May be 710.

The master node may calculate a split gain benefit (e) using a split gain model according to the edge type of edge e. The partitioning gain model is modeled in terms of table scan cost in terms of the cost of processing the join operation that can be obtained when partitioning a table using a given edge e. In other words, the split gain model quantifies the gain from join processing locally for a given edge using a table partitioned using the edge, from the table scan point of view. Therefore, the larger the sum of the sizes of the two end tables of the edge, the larger the weight of the edge, that is, the higher the frequency of join operations for the edge, the greater the gain obtained when the table is partitioned using the edge. Hereinafter, a split gain model according to three edge types will be described through steps 715 to 735.

The master node may determine whether the edge type of edge e is an intra edge Ea (715). As a result of the determination in step 715, if the edge type of edge e is an intra edge, the master node splits using the partitioning column information of the edges in the triangular edge set triEdges (e) included in both end tables of edge e and edge e. The gain model may be modeled 720. In this case, the master node may model a split gain obtained by locally joining a join operation corresponding to edge e and triangular edges when partitioning three tables included in the edges. The triangular edge set triEdges (e) can be obtained through the triangular edge search module 124 shown in FIG.

In step 720, the splitting gain of edge e may be calculated as sz (e) * w (e). The splitting gain for edge e 'included in the triangular edge set is

It can be the sum of sz (e ') * w (e')) values for. The master node may use sz (e) * w (e) + sz (e ') * w (e') corresponding to the sum of two calculation values as a split gain model of the intra edge. The master node may map the gain benefit (e) calculated through the split gain model according to the edge type (intra edge (Ea)) to the edge e and add (insert) the maximum priority queue benefitQ (740).

As a result of the determination of step 715, if the edge type of the edge e is not an intra edge, the master node may determine whether the edge type of the edge e is an indirect edge Et (725).

If it is determined in step 725 that the edge type of edge e is an indirect edge Et, the master node can model the split gain model of the indirect edge by the sum of the split gains of the triangular edges found from the indirect edge e. There is (730). In this case, the indirect edge itself is not included in the split gain model because the indirect edge is an edge that does not actually exist. If the edge e is not an indirect edge but an edge that actually exists in the join graph, the edge e may be classified as an intra edge type by the edge classification model 122.

Thus, in step 730 the split gain model for indirect edge e can be calculated as the sum of sz (e ') * w (e') for triangular edge e 'contained in triangular edge set triEdges (e). . The master node may add (insert) the maximum benefit queue benefitQ after mapping the gain benefit e calculated through the split gain model according to the edge type (indirect edge Et) to the edge e (740).

If it is determined in step 725 that the edge type of the edge e is not an indirect edge, the master node may determine that the type of the edge is an inter edge and determine a split gain model of the inter edge (735). In step 735, the split gain model of the inter edge may be configured as the split gain of the intra edge. In this case, the reason why the indirect edge is not included in the split gain model of the inter edge is that the type of one of the tables at both ends of the edge is the table to be partitioned and the type of the other table is the table to be replicated according to the definition of the intra edge. This is because the triangle edge condition is not satisfied. Therefore, the split gain model of the inter edge can be calculated as sz (e) * w (e).

The master node may add (insert) the maximum benefit queue benefitQ after mapping the gain benefit (e) calculated through the split gain model according to each edge type to the edge e (740).

The master node may determine whether mapping information of all edge and split gains in the edge union has been added to the maximum priority queue benefitQ (745).

If the verification of step 745 indicates that the mapping information of all edges and split gains in the edge union has not been added to the maximum priority queue benefitQ, then the master node selects the next edge (750) and for the next edge (step 715). To step 750 may be performed.

If the verification result of step 745 indicates that the mapping information of all edge and split gains in the edge union has been added to the maximum priority queue benefitQ, the master node uses the maximum priority queue benefitQ to generate the database partitioning plan to generate the database partitioning plan. The divided graph PG, which is a graph, may be initialized (755).

The master node is a set of tables of the table type to be split in the join graph. V _part 760 may be selected. The master node can use the table set V _part to generate a partition graph for a database partition plan.

The master node may extract the first edge e in the maximum priority queue benefitQ, which is the edge that brings the maximum split gain among the edges of the join graph (765). In step 765, the master node extracts the first edge e, and then removes the first edge e from the maximum priority queue benefitQ. Thereafter, the maximum priority cue benefitQ may be aligned such that the edge with the next highest divide gain after the first edge e removed is the first edge.

The master node may check whether the maximum number of partitioning columns (K) of both end tables R and table S of the edge e extracted in step 765 satisfies a preset constraint (770). In this case, the preset constraint may be configured with the following four conditions.

The first condition is | C (R) | <k∧ | C (S) | <k and the second and third conditions are | C (R) | = k∧ | C (S) | <k or | C (R) | <k∧ | C (S) | = k. At this time, whether or not the constraint is satisfied may be determined according to the intersection of the partitioning column included in the edge label function and each partitioning column set. To specify this in detail, the partitioning columns of table R and table S included in the label of edge e are Rc and Sc, respectively.

If the constraint is satisfied, the third condition

In this case, the constraint may be satisfied.

The last condition, | (R) | = k∧ | C (S) | in k both tables R and S

In this case, the constraint may be satisfied.

When the edge e in the join graph extracted in step 765 satisfies the constraint of the maximum number of partitioning columns, the master node searches for two adjacent triangular edges that satisfy the triangular edge condition (triangular edge condition) for the edge e. Then, it can be added to the split graph PG (775). A method of searching for two adjacent triangular edges that satisfy the triangular edge condition by the master node will be described with reference to FIG. 8.

The master node may search the hub table for edge e in the join graph extracted in step 765, and then add the searched hub table to the partition graph PG (780). In operation 780, the master node may search for one or more tables in the join graph corresponding to the extracted edge e, and classify a table satisfying the hub table condition among the searched tables into a hub table type. A method of searching for a table that satisfies the hub table condition for the edge e by the master node will be described with reference to FIG. 9.

The master node may add edge e to the split graph PG (785). When the master node adds the edge e to the split graph PG, the master node can update the partitioning column information included in the edge label in the two tables at both ends of the edge.

The master node may check whether the maximum priority queue benefitQ is empty (790). If the verification result of step 790 indicates that the maximum priority queue benefitQ is not empty, the master node may repeat the process of steps 765 to 795.

If the verification result of step 790 indicates that the maximum priority queue benefitQ is empty, the master node may return the database partitioning plan (795) and terminate the operation. Therefore, the tables of each partition table type in the returned database partition plan do not exceed the maximum k of partitioning columns.

8 is a flowchart illustrating a method of searching for a triangular edge according to an embodiment. Referring to FIG. 8, two edges e1 and e2 satisfying the triangular edge conditions of steps 820 to 840 by the master node 110 (of Samgat edge search module 124 of FIG. 1) shown in FIG. 1. The process of searching for is shown. Edges that meet triangular edge conditions can be added to the split graph.

When the input edge e is input (810), the master node determines whether the type of the input edge e is an intra edge type, that is, the two tables R and S of the table type to be split at both ends of the input edge e are the same table T and edge e1. And it may be determined whether the connection is through e2 (820). As a result of the determination of step 820, if the two tables R and S are not connected through the same table T and the edges e1 and e2, the master nodo may terminate the operation.

As a result of the determination in step 820, when the two tables R and S are connected through the same table T and edges e1 and e2, the master slaver may determine whether the labels of the edges e1 and e2 include the columns of the same table T. It may be 830. As a result of the determination of step 830, when the labels of the edges e1 and e2 do not include the columns of the same table T, the master node may terminate the operation.

As a result of the determination in step 830, when the labels of the edges e1 and e2 include columns of the same table T, the master node may determine whether the type of the table T is a table to be replicated (840). If it is determined in step 840 that the type of table T is not a table to be replicated, then the master node may terminate the operation.

If it is determined in step 840 that the type of table T is a table to be replicated, the master node may distinguish the edges e1 and e2 into triangular edge types (850).

9 is a flowchart illustrating a method of searching a hub table according to an embodiment. Referring to FIG. 9, a process of searching for a table that satisfies a hub table condition by the master node (the hub table search module 126 of FIG. 1) is illustrated. The hub node search module 126 of the master node may search for a table of one or more table types to be replicated that satisfies the hub table condition for a given edge e.

The master node is adjacent to the edge e if the input edge e is an intra edge or an indirect edge between two tables R and S of the table type to be split (910), and is connected to the common table T _i and the column T _i [k]. In operation 920, it may be determined whether the triangular edges e1 and e2 of the tables R and S exist.

If there are no triangular edges e1 and e2 of tables R and S connected to a common table T _i and column T _i [k] in step 920, then the master node has another table T _j and column T _j [k]. In operation 940, it may be determined whether two triangular edges of the tables R and S connected to the P and S are present.

In step 920, if the triangular edges e1 and e2 of the tables R and S connected to the common table T _i and the column T _i [k] exist, the master node converts the common table T _i to the hub table (Hub-table). (930). Here, 'the triangular edges e1 and e2 of the tables R and S connected by the common table T _i and the column T _i [k] exist' means that the edges e1 and e2 of the tables R and S have a common table T _i. It can be understood to mean that the edges satisfying the triangular edge condition with respect to the column T _i [k] of. The common table T _i may be a table of a table type to be replicated according to a triangular edge condition.

The master node satisfies the triangle edge conditions for the column T _j [k] in that the two triangular edge of the table R and S that are connected to the columns of T _j [k] of the other tables T _j exists, in other words, a different table T _j In operation 940, it may be determined whether two triangular edges exist.

If there are two triangular edges of the tables R and S connected to the columns T _j [k] of the other table T _j in step 940, the master degree may further divide the other table T _j into a hub table (950). .

In operation 940, if two triangular edges of the tables R and S connected to the columns T _j [k] of the other table T _j do not exist, the master rigor may terminate the operation.

10 is a flowchart illustrating a map operation of a data loader included in a master node according to an embodiment. Referring to FIG. 10, a process of performing table partitioning based on a hash function for each tuple of a given table is performed by a master node (table partition storage device 130) according to an embodiment.

The master node may select a tuple t included in the table T (1005). The master node can grasp the partitioning information of the table T from the database partitioning plan.

The master node may check whether all partitioning column values of the tuple t selected in step 1005 are null (1010).

If all partitioning column values of the tuple t selected in step 1010 are null, the master node selects 1045 the partition location pid in which the tuple t is to be stored in a round robin manner, and then You can shuffle the key-value pairs << pid, bitM [pid]>, t> with tuple t as the key and all the <pid, bitM [pid]> pairs as keys for all partition locations pid stored in the set pidS. 1050.

If all partitioning column values of the tuple t selected in step 1010 are not null, the master node may determine whether only the value t.c of some partitioning column c of the tuple t is null (1015).

If it is determined in step 1015 that only the value tc of some partitioning column c of tuple t is null, the master node ignores the corresponding partitioning column (s) (c) and has no other partitioning that does not have a null value. The column may be selected (1020). The master node may again determine step 1015 for another partitioning column that does not have a null value.

If it is determined in step 1015 that the value tc of some partitioning column c of the tuple t is not null, the master node uses the hash function hash () for the partitioning column value tc to determine the partition location pid where the tuple will be stored. After the decision, it can be stored in the set pidS of the partition location (1025). Since the partitioning method of the relational database storage system according to an embodiment may use one or more partitioning columns for partitioning a table, the set of partition positions pidS may include one or more partition positions.

The master node may generate a bitmap vector bitV through index information i of the current partitioning column in the partitioning column set C (T) of the table T (1030). Bitmap vector information is used later to store tuples in partitions.

The master node may update the bitmap vector for the tuple t to the bitmap table bitM [pid] of the pid-th partition of the table T using the bitmap vector bitV generated in operation 1030 (1035).

The master node may check whether hash-based partitioning has been performed for all partitioning columns in the tuple of table T (1040). If in step 1040 no hash-based partitioning has been performed for all partitioning columns in the tuples of table T, the master node selects another partitioning column 1020 to perform the process of steps 1015 to 1035. Can be.

If hash-based partitioning has been performed for all partitioning columns in the tuples of table T in step 1040, the master node has <pid, bitM [pid]> pairs for all partition location pids stored in the set pidS of the partition index. The key may be shuffled into a key-value pair << pid, bitM [pid]>, t> with tuple t as a value (1050). Here, bitM [pid] is a bitmap table of the pid-th partition, and is subpartition information in which the current tuple t is to be stored in the bitmap vector in the table T.

The master node may check whether shuffling has been completed for all tuples of the table T (1055). In step 1055, if the shuffle is not completed for all tuples of the table T, the master node may select 1060 the next tuple to perform the processes of steps 1010 to 1055. The master node may repeat the above process until it shuffles all tuples.

If the shuffle is completed for all tuples of the table T in step 1055, the master node may end the operation.

11 is a flowchart illustrating a reduce operation of a data loader included in a master node according to an embodiment. Referring to FIG. 11, a process in which a master node (table partition storage device 130) performs a reduce operation on all tuples of a table T that has been shuffled through is illustrated in FIG. 10.

The master node may receive a tuple list list (t) having the same partition position pid for the bitmap vector bitV that has been shuffled through the mapping process of FIG. 10 (1110).

The master node may generate | C (T) | bitmap vector set V through the partitioning column information of the table T including the tuple list list (t) (1120). For example, if | C (T) | = 2, the bitmap vector set V = {00,01,10,11}.

The master node may initialize the subpartition SubP _V for the bitmap vector v included in the bitmap vector set V generated in step 1120 (1130). For example, if the bitmap vector set V = {00,01,10,11}, four subpartitions (SubP ₀₀ , SubP ₀₁ , SubP ₁₀₎ for the bitmap vector v included in the bitmap vector set V _, SubP ₁₁ ) may be initialized.

The master node may select a tuple t included in the tuple list list (t) (1140).

The master node may store the selected tuple t in the subpartition SubP _bitV (1150). In this case, when the selected tuple t is shuffled, the master node may store the tuple t in the corresponding subpartition SubP _bitV using the bitmap vector bitV, which is subpartition information, in the <pid, bitV> pair used as a key.

The master node may check whether all tuples t in the tuple list list (t) are stored in the subpartition (1160). If all tuples t have not been stored in the subpartition as a result of checking in step 1160, the master node selects 1170 the next tuple in the tuple list list (t) to perform the operations of steps 1150 to 1160. can do.

As a result of checking in step 1160, if all tuples t are stored in the subpartition, the master node stores all the tuples in the tuple list list (t) in the subpartition SubP _V , and then unions all subpartitions (U SubP _V ). In this case, the current partition P _i (T) may be configured (1180).

The master node may store the database partition P _i (T) configured in operation 1180 in a main memory device or an auxiliary storage device of an i th (1 ≦ i ≦ N) slave node among N slave nodes (1190). In this case, the database partition P _i (T) may be divided and stored using a sub-partitioning concept. Subpartitioned database partitions will be described in detail with reference to embodiments in which the tables of the database shown in FIGS. 12 to 13 are divided and stored.

12 is a diagram illustrating an example of partitions when a table is divided and stored using a bitmap table, according to an exemplary embodiment. Referring to FIG. 12, an embodiment of a method of additionally storing and dividing a bitmap table for each database partition is shown.

Two partitioning columns R [1] 1210a and R [2] 1210b of the table R 1210 may be divided and stored through the above-described processes of FIGS. 10 to 11.

The table R 1210 may be divided and stored into three partitions 1220 in total. Since the number of partitioning column sets of table R 1210 | C (R) | = 2, the possible bitmap vectors are (0,0) (1230b), (0,1) (1230d), (1,0 ) 1230c and (1, 1) 1230a.

The location pid of the partition where tuples of the table R 1210 are to be divided and stored may be determined according to two partitioning column values.

For example, the tuple (1,1) is stored only in the first database partition P ₁ (R) because all partitioning columns have the same value '1', and the bitmap vector may be (1,1). This is because the tuples (1,1) stored in the first database partition P ₁ (R) are the original tuples that are not duplicated from the partitioning column perspective.

The tuples (2, 3) are allocated to the second database partition P ₂ (R) by the first partitioning column R [1] 1210a, and the third database partition P ₃ (R by the second partitioning column R [2] 1210b. Can be divided and stored. Therefore, since one redundant tuple is additionally stored, one bit of the bitmap vector for the tuple (2,3) may have a value of '0'.

More specifically, the bitmap vector of tuple (2,3) stored in the second database partition P ₂ (R) is (1,0) (1230c), but the tuple (2,3) stored in the third database partition P ₃ (R) ) May be (0,1). This difference can later be used to eliminate duplicate results when processing queries using database partitions.

For example, if the table R included in the input query uses the partitioning column R [1], the tuple whose first bit value of the bitmap vector is '0' should be excluded from the query processing. Thus, the tuples (2, 3) stored in the third database partition P ₃ (R) are not used when processing the query.

As such, a bitmap table can be stored for each database partition, and query processing can be performed by excluding duplicate tuples included in the database partition by using the stored bitmap table information during query processing.

FIG. 13 is a diagram illustrating an example of partitions when a table is divided and stored by subpartitioning according to an embodiment. Referring to FIG. 13, a method of partitioning and storing a table by using a subpartitioning concept is illustrated.

The table R 1310 stores the same tuple as the table R 1210 of FIG. 12, and the partitioning column is also the same as two of R [1] 1310a and R [2] 1310b. In this case, it is assumed that the table R 1310 is divided and stored using three database partitions 1320 as in the embodiment of FIG. 12.

At this time, the number of partitioning column sets of the table R 1310 | C (R) | Since = 2, the bitmap vector set may include four bitmap vectors in total {00,01,10,11}.

Accordingly, each database partition Pi (R) may include four subpartitions 1320a, 1320b, 1320c, and 1320d, respectively. In one embodiment, the subpartitions constituting each database partition Pi (R) may represent one of four bitmap vectors.

Accordingly, the location of the stored partition is determined according to the partitioning column value used for the tuple of the table R 1310, and the subpartition of the corresponding partition to be finally stored is determined according to the calculated bitmap vector.

For example, the tuples 1, 1 of table R 1310 have the same hash function values for the two partitioning column values, and both are shuffled to the first database partition P ₁ (R), so no duplication occurs. Therefore, the bitmap vector can be calculated as (1,1).

Since the bitmap vector of the tuple (1,1) to be stored in the first database partition P ₁ (R) is also (1,1), the first database partition P ₁ (R) representing the bitmap vector (1,1) May be stored in the fourth sub-partition 1320d. At this time, each subpartition does not need to store a bitmap table separately.

In the case of partitioning a table by subpartitioning illustrated in FIG. 13, since the access to the bitmap table is not required during query processing, query processing performance may be improved compared to the table partitioning storage illustrated in FIG. 12.

Query processing for the table partitioned and stored through the table partition storage device 130 may be performed by the partition table reading device 140 of the master node. A method of processing the query for the partitioned and stored table by the partitioned table reading device 140 will be described with reference to FIG. 14.

14 is a flowchart illustrating a method of processing a query based on a relational database storage method, according to an exemplary embodiment. Referring to FIG. 14, a process in which a partitioned table reading device 140 of a master node processes a query for a table partitioned and stored through the table partitioning storage device 130 is illustrated.

The master node may receive an input query (query) Q (1405).

The master node may determine whether the partitioned table R is used for the join operation in the input query Q received in step 1405 and whether the table R is stored according to the relational database storage method.

The master node may determine whether table R is used for a join operation in input query Q (1410). In step 1410, the master node transitions to one of two states: when table R is used for join operations in input query Q, and when table R is not used for join operations, or if input query Q does not include a join operation. Can be distinguished.

If at step 1410 the table R is not used for a join operation in the input query Q, or if the input query Q does not include a join operation, then the master node switches the single scan mode to the scan mode of the table R. It may be determined (1425). The master node may select any partitioning column j among partitioning columns included in the partitioning column set C (R) of the divided table R according to the single scan mode (1435).

If the table R is used in the join operation in the input query Q in step 1410, the master node empty the intersection of the partitioning columns of the table S to be joined with the table R through the partitioning column information of the tables included in the database partitioning plan PG. Cognition may be checked (1415). If the intersection is empty in step 1415, the master node may perform steps 1425 and 1435.

If the intersection is not an empty set in step 1415, the master node may determine a join scan mode as the scan mode of the table R (1420). The master node intersects the set of partitioning columns of tables R and S according to the join scan mode.

One partitioning column j among one or more partitioning columns included in may be selected (1430).

The master node may calculate a list of bitmap vectors corresponding to the partitioning column j selected in step 1430 or 1435 (1440). In operation 1440, the master node may calculate a list V of bitmap vectors before reading the partitioned table for the partitioning column j. For example, when the number | C (R) | = 2 of the partitioning column set, if the partitioning column j is the first partitioning column in C (R), the bitmap vector list V = {10,11} may be obtained. Two bitmap vectors included in the bitmap vector list V mean that tuples that do not include a duplicate of the table R partitioned using the partitioning column j are stored in two subpartitions representing the bitmap vector.

Accordingly, the master node may select a subpartition corresponding to at least one bitmap vector included in the list of bitmap vectors (1445) and scan the selected subpartition (1450).

In step 1445, the master node is, for example, a subpartition SubP _v (of database partition P _i (R) representing a bitmap vector included in bitmap vector list V;

) Can be selected.

The master node may check whether all necessary tuples have been scanned (1455). If all the required tuples have not been read in step 1455, the master node selects another bitmap vector v in the bitmap vector list V (1460) until all the required tuples have been read (step 1460). The process can be repeated.

If all the necessary tuples have been read in step 1455, the master node may terminate the operation.

The embodiments described above may be implemented as hardware components, software components, and / or combinations of hardware components and software components. For example, the devices, methods, and components described in the embodiments may include, for example, processors, controllers, arithmetic logic units (ALUs), digital signal processors, microcomputers, field programmable gates (FPGAs). It may be implemented using one or more general purpose or special purpose computers, such as an array, a programmable logic unit (PLU), a microprocessor, or any other device capable of executing and responding to instructions. The processing device may execute an operating system (OS) and one or more software applications running on the operating system. The processing device may also access, store, manipulate, process, and generate data in response to the execution of the software. For convenience of explanation, one processing device may be described as being used, but one of ordinary skill in the art will appreciate that the processing device includes a plurality of processing elements and / or a plurality of types of processing elements. It can be seen that it may include. For example, the processing device may include a plurality of processors or one processor and one controller. In addition, other processing configurations are possible, such as parallel processors.

The software may include a computer program, code, instructions, or a combination of one or more of the above, and configure the processing device to operate as desired, or process it independently or collectively. You can command the device. Software and / or data may be any type of machine, component, physical device, virtual equipment, computer storage medium or device in order to be interpreted by or to provide instructions or data to the processing device. Or may be permanently or temporarily embodied in a signal wave to be transmitted. The software may be distributed over networked computer systems so that they may be stored or executed in a distributed manner. Software and data may be stored on one or more computer readable recording media.

The method according to the embodiment may be embodied in the form of program instructions that can be executed by various computer means and recorded in a computer readable medium. The computer readable medium may include program instructions, data files, data structures, etc. alone or in combination. The program instructions recorded on the media may be those specially designed and constructed for the purposes of the embodiments, or they may be of the kind well-known and available to those having skill in the computer software arts. Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tape, optical media such as CD-ROMs, DVDs, and magnetic disks, such as floppy disks. Magneto-optical media, and hardware devices specifically configured to store and execute program instructions, such as ROM, RAM, flash memory, and the like. Examples of program instructions include not only machine code generated by a compiler, but also high-level language code that can be executed by a computer using an interpreter or the like. The hardware device described above may be configured to operate as one or more software modules to perform the operations of the embodiments, and vice versa.

Although the embodiments have been described with reference to the accompanying drawings, those skilled in the art may apply various technical modifications and variations based on the above. For example, the described techniques may be performed in a different order than the described method, and / or components of the described systems, structures, devices, circuits, etc. may be combined or combined in a different form than the described method, or other components. Or even if replaced or substituted by equivalents, an appropriate result can be achieved.

Claims (19)

1. Include tables and edges based on at least one of a database schema that includes information about references and constraints between database tables and a query set that includes join predicate information. Generating a join graph;

   Classifying the types of the tables based on a cost of a join operation between the tables included in the join graph;

   Distinguishing a type of edges in the join graph based on the type of the tables connected to each other by an edge;

   Adding a virtual edge between two tables that satisfy an indirect edge condition in the join graph; And

   Generating a database partitioning plan for the join graph based on the type of edges including the virtual edge

   Including a relational database storage method.
2. The method of claim 1,

   Generating the join graph

   Configuring edges between tables included in the join graph using at least one of the reference and constraint information and the join predicate information.

   Including a relational database storage method.
3. The method of claim 1,

   The step of classifying the types of tables

   Classifying the types of the tables based on a cost of a join operation between a table in the join graph and adjacent tables adjacent to the table

   Including a relational database storage method.
4. The method of claim 3,

   The step of classifying the types of tables

   The sum of the first join operation cost when the table is divided and stored in a storage device and the second join operation cost when the table is replicated to a plurality of slave nodes based on the set information of the table and the adjacent tables. Calculating a sum of;

   Dividing the type of the table into one of a first type and a second type according to a comparison result between the sum of the first join operation cost and the second join operation cost; And

   Storing the table according to the type of the divided table

   Including a relational database storage method.
5. The method of claim 1,

   The step of classifying each type of the edges

   Classifying each type of each of the edges into one of an inter edge and an intra edge, based on a type of tables connected to each other by the edge;

   Including a relational database storage method.
6. The method of claim 5,

   The step of dividing into any one of the inter edge and intra edge

   If the types of tables connected to each other by the edges are all first types, determining the type of the edge as an intra edge; And

   If any one of the types of tables connected to each other by the edge is a first type and the other type is a second type, determining the type of the edge as an inter edge

   Including a relational database storage method.
7. The method of claim 1,

   Adding the virtual edge

   Checking whether a pair of tables of a first type included in the join graph satisfy the indirect edge condition; And

   Adding the virtual edge between pairs of tables of a first type that satisfy the indirect edge condition

   Including a relational database storage method.
8. The method of claim 7, wherein

   The indirect edge condition is

   A first condition in which the first table and the second table, which are pairs of the tables of the first type, are connected through the same third table, a first edge of the first table, and a second edge of the second table;

   A second condition that the same column of the third table is included in the labels of the first edge and the second edge; And

   A third condition that the type of the third table is a second type

   Including, relational database storage method.
9. The method of claim 1,

   Generating the database partitioning plan

   Calculating, according to the types of edges, a benefit when performing the join operation by a table of a first type using the edges;

   Sorting the edges in ascending order of gain;

   Initializing a partition graph having nodes of a first type of tables in the join graph; And

   Updating the segmentation graph by processing the edges in the sorted order

   Including a relational database storage method.
10. The method of claim 9,

    The type of edges

    At least one of an intra edge, an inter edge, and an indirect edge,

    The step of calculating the gain

    Calculating the gain using different split gain models according to the types of edges

    Including a relational database storage method.
11. The method of claim 9,

    Updating the split graph

    Searching for two adjacent triangular edges satisfying triangular edge conditions for the edges in the join graph based on the database partitioning plan;

    Searching for a hub table that satisfies a hub table condition for an edge in the join graph based on the database partitioning plan; And

    Adding the edge, the two triangular edges, and the hub table to the split graph

    Further comprising, relational database storage method.
12. The method of claim 11,

    The triangular edge condition is

    The type of the edge in the join graph is an intra edge;

    A condition that edges of each of two tables of a first type connected to the intra edge are present, and wherein each of the edges is connected to the same table;

    A condition in which the labels of each of the edges include a column of the same table; And

    The condition that the type of the same table is a second type

    Including, relational database storage method.
13. The method of claim 11,

    The hub table condition is

    The type of the edge in the join graph is an intra edge or an indirect edge between two tables of the first type, and the edge of each of the two tables of the first type is the second type according to the triangular edge condition. Conditions that are edges that satisfy the triangular edge condition for one or more partitioned common table columns

    Including, relational database storage method.
14. The method of claim 1,

    Partitioning tuples included in the tables based on a hash function based on the database partitioning plan; And

    Storing the corresponding tuple in a partition corresponding to each of the divided tuples based on information associated with a partitioning column of the corresponding tuple.

    Further comprising, relational database storage method.
15. The method of claim 14,

    Partitioning based on the hash

    Determining a location of a partition in which the tuple is to be stored based on a hash function for all partitioning column values of the tuples;

    Generating a bitmap vector using index information of the corresponding partitioning column in the partitioning column set; And

    Updating bitmap vector information of the corresponding tuple in the bitmap table of the table by using the bitmap vector.

    Including a relational database storage method.
16. The method of claim 14,

    The storing of the corresponding tuple

    Generating a bitmap vector set using partitioning column information of a table including a list of tuples shuffled for each partition corresponding to each of the divided tuples;

    Initializing a subpartition for a bitmap vector included in the bitmap vector set;

    Storing each tuple in a corresponding subpartition using a bitmap vector corresponding to each tuple included in the tuple list; And

    When all the tuples included in the tuple list are stored in the subpartition, configuring a partition of the table including the tuple list by the union of all the subpartitions.

    Including a relational database storage method.
17. Determining whether the table is used in a join operation in the input query;

    Determining whether the intersection between the first partitioning column set of the table and the second partitioning column set of the table to be joined with the table is empty by using the partition column information of the table;

    Selecting one partitioning column associated with the table according to the scan mode of the table determined based on the determination;

    Calculating a list of bitmap vectors corresponding to the selected partitioning column;

    Selecting a subpartition corresponding to at least one bitmap vector included in the list of bitmap vectors; And

    Scanning the selected subpartition

    A method of processing a query based on a relational database storage method comprising a.
18. The method of claim 17,

    The step of selecting any one partitioning column

    Determining a scan mode of one of a first scan mode and a second scan mode to read the table based on the determination; And

    Selecting one partitioning column among the partitioning column included in the intersection and the partitioning column included in the first partitioning column set according to any one of the scan modes.

    A method of processing a query based on a relational database storage method comprising a.
19. A computer program stored on a medium in combination with hardware to carry out the method of claim 1.

Images