KR20150044013A - Method and System for Managing Database, and Tree Structure for Database - Google Patents

Abstract

The present invention relates to method and system for managing database storing lower bound and upper bound of key value of multiple records included in one page, and deleting the overlapped key values in multiple records by using the same, while forming index of database, to reduce storage space in which the index page is stored, so that the performance of the database is improved.

Description

Database Management Method, System, and Database Tree Structure {Method and System for Managing Database, and Tree Structure for Database}

The present invention relates to a database management method, a system, and a database tree structure, and more particularly, to a database management method, system, and database tree structure using an index compression method.

A database management system (DBMS, hereinafter referred to as DBMS) is a system for managing a database in which a vast amount of data is stored, and is an important system Element.

In this DBMS, all data is stored in a database in the form of a table, where a table is a basic structure for storing data in a database, and a table is made up of one or more records. Here, the record means one row of the table. Each record is composed of one or more columns. A column is a domain having a name representing a table item of the real world constituting the table, and may be referred to as an attribute or a field.

When a specific query is inputted from the outside, such a DBMS performs functions such as selecting, inserting, updating, and deleting data in the database according to the inputted query. Here, the query refers to any request for data stored in a table in the database, that is, a description of what kind of operation is desired to be performed on the data, and is expressed using a language such as SQL (Structured Query Language).

Meanwhile, as the amount of data increases, the DBMS generally has an index. Here, an index refers to a data structure that increases the speed of searching for a table in a database field. Such an index is a data structure composed of {key value, pointer} pair to quickly access a data record (tuple) .

The above-described background technology is technical information that the inventor holds for the derivation of the present invention or acquired in the process of deriving the present invention, and can not necessarily be a known technology disclosed to the general public prior to the filing of the present invention.

In an embodiment of the present invention, a lower limit value and an upper limit value of a key value of a plurality of records included in a page are stored as delimiters, and redundant portions of the keys are deleted from a plurality of records A database management method, a system, and a database tree structure in which a storage space in which an index page is saved is saved, thereby improving the performance of the database.

In addition, one embodiment of the present invention enables compression in a run-time so that compression is not performed when an insert / delete load is increased in a specific area, The present invention provides a database management method, system, and database tree structure with improved efficiency.

In an embodiment of the present invention, it is unnecessary to further record meta data regarding a secondary compression method and range, and as the number of records stored in a page increases, And a database tree structure in which the compression efficiency is maximized as compared with the method of the first embodiment.

In addition, an embodiment of the present invention performs a validity check of a leaf node using LFK and UFK of each page whenever a tree structure of an index is traversed, A database management method, a system, and a database tree structure that can be used in a database management system.

According to an embodiment of the present invention, a lower limit value of a key value of a plurality of records included in each page is stored as a lower fence key (LFK), or an upper limit value of a key value of a record is stored as an upper fence key (UFK); Extracting a common area among key values of a plurality of records constituting the page as a prefix; And a step of storing a portion of the key value of the plurality of records except a portion corresponding to the prefix.

In this embodiment, the prefix may be stored in a lower fence key (LFK) or an upper fence key (UFK).

In the present embodiment, key values other than the prefix may be stored in a record other than the record in which the lower fence key (LFK) or the upper fence key (UFK) is stored among the records.

In this embodiment, the record may be a multi-column record including a plurality of key values.

In this embodiment, among the plurality of key values, a key value having a same value in a record constituting one page may be extracted by the prefix.

In the present embodiment, each of the pages may be a leaf node of a B-tree or B + tree structure.

In the present exemplary embodiment, the database management method may further include restoring a source key value of a record included in the page, and the step of restoring the original key value may include determining whether the LFK and the UFK exist in the page, ; Comparing the LFK and the UFK when the LFK and the UFK are present in the page, and extracting a common prefix; And recovering the original key value by combining the extracted prefix with the key value of the corresponding record.

In the present embodiment, when there is no LFK and UFK in the page, the key value stored in each record may be the original key value.

In the present exemplary embodiment, the database management method may further include a step of adding a new record to the page or changing a existing record, and the step of adding or changing the record may include adding the LFK and UFK A step of determining whether or not the presence of the data exists; Comparing the LFK and the UFK when the LFK and the UFK are present in the page, and extracting a common prefix; And adding or changing the remaining key values from which the prefix is excluded in the record to be added or changed, as a record.

In the present embodiment, if the LFK and the UFK do not exist in the corresponding page, the prefix is not extracted, and a record may be added or changed in the corresponding page.

According to another embodiment of the present invention, there is provided a database management method of a B-tree or B + tree structure, comprising: generating an index of a B-tree or B + tree structure; Recovering a predetermined record from the index; A step of adding or changing a predetermined record in the index, wherein the step of generating the index comprises: if a lower limit value of a key value belonging to the corresponding leaf node is LFK (lower fence key) in at least one end of the at least one leaf node, Or an upper fence key (UFK) is stored as an upper limit value of a key value belonging to the corresponding leaf node.

Another embodiment of the present invention includes a query analyzer for receiving and analyzing a query statement in which a fetch request for a record included in a specific table and an update request for at least one column included in the record are defined together; An execution plan generating unit for generating an execution plan for executing the analyzed query; An execution plan execution unit for executing the execution plan by fetching the record and updating the at least one column in accordance with the execution plan; And stores a lower limit value of a key value of a plurality of records belonging to each page of the index as a lower fence key, or stores an upper limit value of a key value of a record as an upper fence key (UFK) And an index management unit including an index generation unit for generating an index.

In the present embodiment, the index generator may extract a common area among key values of a plurality of records constituting each page as a prefix.

In the present embodiment, the index generator may store, in an index, a remaining portion excluding a portion corresponding to the prefix, which is a common region, from a key value of a plurality of records constituting each page.

In this embodiment, the prefix may be stored only in a lower fence key (LFK) or an upper fence key (UFK).

In this embodiment, only the key values other than the prefix may be stored in the record other than the record in which the lower fence key (LFK) or the upper fence key (UFK) is stored in each record.

In the present embodiment, the index management unit may further include a record restoring unit for restoring original key values from the records included in each page of the index.

In this embodiment, the record restoring unit checks whether the LFK and the UFK exist in the corresponding page, and when there is the LFK and the UFK in the page, the record restoring unit compares the LFK and the UFK to extract the prefix, The original key value can be restored by combining the prefix and the value of the corresponding record.

In the present embodiment, the index management unit may further include a record update unit for adding a new record to each page of the index or changing a record present.

In this embodiment, the record update unit checks whether the LFK and the UFK exist in the corresponding page, and when the LFK and the UFK exist in the corresponding page, the LFK and the UFK are compared with each other to extract the prefix, Or the remaining data excluding the prefix from the record to be changed can be added or changed as a record in the corresponding page.

According to another embodiment of the present invention, there is provided a database tree structure of a B-tree or B + tree structure, comprising: a root node located at the top of a tree structure and storing one or more classified key values; And at least one leaf node in which a lower limit value of a key value belonging to the corresponding leaf node is stored as a lower fence key in at least one end or an upper value key of a key value belonging to the corresponding leaf node is stored as an upper fence key Start the database tree structure.

In the present embodiment, a record existing between the lower fence key (LFK) and the upper fence key (UFK) in the leaf node may store only the remaining key values except the common area in the key value of the record.

In this embodiment, the distinguishing key value stored in the root node may be LFK on one side of the adjacent leaf node and UFK on the other side.

In the present embodiment, the LFK may not be stored in the leftmost leaf node among the plurality of leaf nodes, and the UFK may not be stored in the leaf node located at the rightmost of the plurality of leaf nodes.

Other aspects, features, and advantages will become apparent from the following drawings, claims, and detailed description of the invention.

According to the present invention as described above, it is possible to save the storage space in which the index page is stored, thereby improving the performance of the database.

In addition, one embodiment of the present invention enables compression in a run-time so that compression is not performed when an insert / delete load is increased in a specific area, It is possible to obtain an effect of improving the efficiency of the apparatus.

In addition, according to an embodiment of the present invention, it is unnecessary to further record meta data regarding a secondary compression scheme and a range, and the compression efficiency is maximized as the number of records stored in a page increases .

In addition, an embodiment of the present invention performs a validity check of a leaf node using LFK and UFK of each page whenever a tree structure of an index is traversed, The effect can be obtained.

1 is a schematic block diagram of a database management system according to an embodiment of the present invention.
2A is a flowchart illustrating an index generation step of a database management method according to an embodiment of the present invention.
FIG. 2B is a flowchart illustrating a record restoring step of the database management method according to an embodiment of the present invention.
2C is a flowchart illustrating a record addition / change step of the database management method according to an embodiment of the present invention.
FIG. 3 is a diagram exemplifying a structure of a B-tree index to which a database management method and system of the present invention is applied.
4 is a diagram showing the arrangement of key values of a general B-tree page.
5 is a diagram showing the arrangement of key values of a B-tree page according to the database management method and system of the present invention.
6A and 6B are diagrams illustrating a process of dividing a page in a B-tree index to which the database management method and system of the present invention are applied.

The following detailed description of the invention refers to the accompanying drawings, which are given by way of illustration of specific embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention. It should be understood that the various embodiments of the present invention are different, but need not be mutually exclusive. For example, the specific shapes, structures, and characteristics described herein may be implemented by changing from one embodiment to another without departing from the spirit and scope of the invention. It should also be understood that the location or arrangement of individual components within each embodiment may be varied without departing from the spirit and scope of the present invention. Therefore, the following detailed description is not to be taken in a limiting sense, and the scope of the present invention should be construed as encompassing the scope of the appended claims and all equivalents thereof. In the drawings, like reference numbers designate the same or similar components throughout the several views.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings in order to facilitate a person skilled in the art to which the present invention pertains.

1 is a schematic block diagram of a database management system according to an embodiment of the present invention. Referring to FIG. 1, a database management system 100 according to an embodiment of the present invention is configured as follows.

First, various data are stored in the database 110 in a table format. As described above, each table is composed of one or more records, and each record is composed of one or more columns. For example, in the case of a database storing posts for a predetermined bulletin board, the table means a set of posts, the record means each post, and the column means an area where a post identifier, a post author, . It is to be understood that the scope of the present invention is not limited to the number of databases 110 and the number of databases 110 may be varied according to the configuration of the database management system 100, The configuration may be varied.

The database management system 100 performs a function of integrally managing the database 110 such as updating or deleting data recorded in the database 110 or adding data to the database 110, And includes a query analysis unit 120, an execution plan generation unit 130, and an execution plan execution unit 140. The database management system 100 may further include an entry management unit 150 and an index management unit 160.

The query analyzer 120 receives a query for processing data stored in the database 110 from various external servers (not shown) or administrator terminals (not shown) linked to the database management system 100 , And analyzes the received query. The query analyzing unit 120 may include a query receiving unit and a parser, and may further include a validity verifying unit.

The execution plan generation unit 130 generates an execution plan for fetching the requested record and updating the column included in the record based on the parse tree determined to be valid by the validity verification unit of the query analysis unit 120 And stores it in the memory 170 to be described later. Here, the execution plan means a data structure including a method of fetching a record from a specific table, a result record list, whether to perform an increase operation on a column requested to be updated, and the like.

In one embodiment, the execution plan generating unit 130 may select either the sequential scanning method or the index scanning method as a method of fetching a requested record from a specific table. Here, the sequential scan method refers to a method of sequentially retrieving records having an identifier of a record while sequentially scanning the records included in the specific table. An index scan method is an index for each identifier of each record, Which means that the corresponding record is fetched by only scanning the corresponding record. The index of such a DBMS will be described later in detail.

The execution plan execution unit 140 fetches the corresponding record from the specific table according to the execution plan generated by the execution plan generation unit 130 and updates the column value recorded in the column on the record corresponding to the physical position of the column requested to be updated To update the corresponding column value. Specifically, the execution plan execution unit 140 processes an execution plan generated by generating a transaction for executing the execution plan generated by the execution plan generation unit 130 during the corresponding transaction. Here, a transaction constitutes one logical unit of work and is defined using one or more SQL statements. The use of such transactions can ensure data consistency and data concurrency.

The database management system 100 generates or deletes an entry consisting of an identifier of a record and an identifier of a column to be updated, matches the generated entry with a column value corresponding to a column identifier included in the entry, And the column value of the column requested to be updated in the memory 170 may be matched with the entry generated in the entry management unit 150 and stored.

The database management system 100 may further include an index management unit 160 for creating or deleting an index and storing the generated index in the memory 170. The index management unit 160 may include an index generation unit 161, a record restoration unit 163, and a record update unit 165.

The index generator 161 generates an index for the specific database 110. At this time, the index generator 161 stores the lower limit value of the key value belonging to each page of the index as LFK (lower fence key), and the upper limit value of the key value is UFK (upper fence key) As shown in FIG. In addition, the index generator 161 extracts a common region among key values of a plurality of records constituting each page as a prefix. In addition, the index generator 161 deletes a portion corresponding to a prefix from a key value of a plurality of records constituting each page, and stores the deleted index in the index.

The record restoring unit 163 restores original key values from the records included in each page of the index. In detail, the record restoring unit 163 checks whether or not LFK and UFK exist in the corresponding page, and when LFK and UFK exist in the page, the record restoring unit 163 extracts the prefix by comparing LFK and UFK, To restore the original key value.

The record updating unit 165 adds a new record to each page of the index or changes the existing record. In detail, the record update unit 165 checks whether LFK and UFK exist in the corresponding page, and if LFK and UFK exist in the corresponding page, LFK and UFK are compared with each other to extract a prefix, And adds or changes the remaining data excluding the prefix to the corresponding page as a record.

The index creation process of the index creation unit 161, the record restoration process of the record restoration unit 163, and the record update process of the record update unit 165 will be described in detail with reference to FIG.

Hereinafter, a database management method using the separator-based index compression method will be described in more detail.

2A, 2B, and 2C are flowcharts illustrating a database management method according to an embodiment of the present invention. 3 is a diagram illustrating a structure of a B-tree index to which a database management method and system of the present invention is applied. FIG. 4 is a diagram showing an arrangement of key values of a general B-tree page, FIG. 5 is a diagram showing an arrangement of key values of a B-tree page according to a database management method and system of the invention.

2 to 5, a database management method according to an embodiment of the present invention includes a step of creating an index (step S100), a step of restoring a record from an index (step S200), and a step of adding / (Step S300).

This will be described in more detail as follows.

Indexes are data structures that speed up operations on tables in the database field. Indexes can be created using a single coulmn index or multiple columns in a table, providing a basis for efficient ordering operations in conjunction with record access as well as high-speed retrieval operations. do. The disk space required to store the index is usually less than the disk space required to store the table. Because the normal index only has a key-field and does not have other details of the table.

The B tree (or B + tree) is a type of tree data structure widely used in databases and file systems for constructing such an index. It is an associative mapping data structure for quickly querying a record having a specific value (key). The B-tree (or B + tree) has a tree-structured page unit in order to reduce the number of I / Os since data is recorded on a large-capacity disk with slow access. In one page, a key and the position (Object ID or Record ID) of an actual record including this key as an attribute are recorded in the order of the keys. That is, {Key - OID} combines and constitutes each index record (hereinafter referred to as a record).

Due to the above characteristics, the key values of records in a page can have considerable similarity between adjacent values. For example, if you specify an employee number, mail folder number, and mail serial number as index keys to distinguish each mail in a company's mail system (that is, a multicolumn index), one employee has 100,000 total messages, If 10,000 messages are stored in the mail folder, the number of the index and the number of the mail folder are the same for 10,000, and 100,000 are the same value. If 1,000 pages are entered in a conventional B-tree page in the conventional way, about ten pages will be stored each time the duplicate number and mail folder number are duplicated. Therefore, there is a problem that unnecessary memory is wasted because the same value is repeatedly stored many times.

In order to solve such a problem, a database management method and system using a separator-based index compression method according to the present invention is characterized in that a prefix stored redundantly among key values of one page is divided into page delimiters (Lower Fence Key) and Upper Fence Key (UFK), thereby saving memory space.

Referring again to FIG. 2, in the database management method according to an exemplary embodiment of the present invention, the step of generating an index (step S100) may include storing a lower limit value of a key value belonging to one page as a lower fence key (LFK) (Step S120), an upper limit value of a key value belonging to one page is stored as an upper fence key (step S110), a common area among key values of a plurality of records forming a page is extracted as a prefix (step S120) And a prefix, which is a common area, is deleted from key values of a plurality of records constituting one page, and then stored (step S130).

This can be easily understood as follows.

Referring to FIG. 3 illustrating a structure of a B-tree index to which the present invention is applied, in the index used for quickly searching record data in the database, the B-tree index used in the present invention includes a leaf It consists of leaf nodes and their intermediate nodes. The root node is the highest node among the intermediate nodes. In FIG. 3, there are four leaf nodes and one intermediate node, and one intermediate node immediately becomes a root node. At this time, each leaf node immediately constitutes each page. That is, the four leaf nodes shown in FIG. 3 constitute four pages.

Here, the root node of the B-tree index shown in FIG. 3 has three different key values P1, P2, and P3. The first sort key value P1 is a delimiter that distinguishes pages 1 and 2, the second sort key value P2 is a delimiter that distinguishes page 2 and page 3, And page 4, respectively.

As described above, the database management method according to the embodiment of the present invention stores the lower limit value of the key value belonging to each page as LFK (lower fence key), and also stores the upper limit value of the key value belonging to each page as UFK (upper fence key) As shown in FIG. In this case, the lower fence key LFK is stored in the left end of each page as shown in the drawing to define the lower limit value of the page, and the upper fence key is stored in the right end of each page when viewed in the drawing, Quot; is defined as the upper limit value.

A database management method according to an embodiment of the present invention extracts a common area among key values of a plurality of records existing between an LFK (lower fence key) and an UFK (upper fence key) in each page as a prefix , The LFK (lower fence key) and the UFK (upper fence key), the prefix is deleted from the key value, and only the remaining key value is stored. Thus, redundant storage of data is prevented to save memory space.

That is, the first key value P1 becomes UFK (UFK1) of page 1 and LFK (LFK2) of page 2. Similarly, the second discrimination key value P2 becomes UFK (UFK2) of page 2 and LFK (LFK3) of page 3. Likewise, the third key value P3 becomes UFK (UFK3) of page 3 and LFK (LFK4) of page 4. In this case, LFK (lower fence key) can not be set for the leftmost leaf node (page 1) located at the leftmost among a plurality of leaf nodes, and thus the prefix extraction can not be performed on the corresponding page. Likewise, it is not possible to set the upper fence key (UFK) on the extreme right leaf node (page 4) located at the far right, and thus it is not possible to extract the prefix in the corresponding page.

To explain this in more detail, Fig. 4, which shows the arrangement of the key values of a general B-tree page, and Fig. 5, which shows the arrangement of the key values of the B-tree page according to the database management method and system of the present invention, are compared. In FIGS. 4 and 5, it is assumed that there are only 10 records for explanation.

Referring to FIG. 4, the same value is stored ten times in the ten records constituting one page, with the same value being duplicated as the number (KR10000) and the mail folder number (FD0001). Referring to FIG. 5, according to the database management method of the present invention, the KR 10000 and the mail folder number FD0001, which are redundantly stored among the key values of one page, are set to LFK (Lower Fence Key) and the Upper Fence Key (UFK) that sets the upper limit value of the page, and only the key value in which the prefix is deleted is stored in the general record between LFK and UFK. That is, as shown in Fig. 5, the number (KR10000) and the mail folder number (FD0001), which are key values common to the ten records, are all deleted, and only the mail serial number, which is a unique key value, is stored in each record.

Hereinafter, the step of restoring a record in the database management method according to an embodiment of the present invention will be described. 2 and 5, restoring a record in the database management method according to an embodiment of the present invention (step S200) includes checking whether LFK and UFK exist in the corresponding page (step S210 A step of extracting a prefix by comparing LFK and UFK when the LFK and the UFK exist in the page (step S220), and a step of combining the prefix and the value of the record to recover the original key value (step S230) do. This will be described in more detail as follows.

First, a binary search is performed to find which page a page to which a key value to be restored belongs, and then it is checked whether LFK and UFK exist in the corresponding page. If there is neither LFK nor UFK in the page, the page is compressed (i.e., duplicate data is deleted using the prefix), so the key value stored in each record is the original key value (S240 step). On the other hand, when both LFK and UFK exist in the page, the page is a page on which data compression using the prefix has been performed, so that a predetermined restoration routine is executed. That is, LFK, which is the lower limit value of the page, is compared with UFK, which is the upper limit value of the page, and the common region, that is, the prefix, of LFK and UFK is extracted. In the example of FIG. 5, KR10000: FD0001, which is a common area between LFK and UFK, will be extracted as a prefix. The original key value is restored by combining the extracted prefix with the key value stored in each record. That is, the original key value obtained by restoring SN10001 is KR10000: FD0001: SN10001.

Hereinafter, a step of adding or changing a record in the database management method according to an embodiment of the present invention will be described. 2 and 5, in the database management method according to an embodiment of the present invention, the step of adding or changing a record (step S300) includes a step of checking whether LFK and UFK exist in the corresponding page If the LFK and the UFK exist in the corresponding page, the LFK and the UFK are compared with each other to extract a prefix (step S320), and the remaining data excluding the prefix from the record to be added or changed is added to the corresponding page as a record (Step S330). This will be described in more detail as follows.

First, a binary search is performed to find which page a key value to be added or changed belongs to, and then it is checked whether LFK and UFK exist in the corresponding page. If either the LFK or the UFK is not present on the page, the page is compressed (i.e., the duplicate data is deleted using the prefix), and therefore, the value of the record is directly added or changed without any processing (Step S340). On the other hand, if both the LFK and the UFK exist in the page, the page is a page on which data compression using the prefix is performed, so that a predetermined decomposition routine is executed. That is, LFK, which is the lower limit value of the page, is compared with UFK, which is the upper limit value of the page, and the common region, that is, the prefix, of LFK and UFK is extracted. In the example of FIG. 5, KR10000: FD0001, which is a common area between LFK and UFK, will be extracted as a prefix. Next, only the remaining key values excluding the prefix from the key value of the record to be added or changed are added or changed to the corresponding position on the page. For example, if the key value to be added is KR10000: FD0001: SN13000, the prefix is KR10000: FD0001, and therefore only the SN13000 except for the prefix is added to the page.

Hereinafter, a process of dividing or merging pages in a database management method according to an embodiment of the present invention will be described.

6A and 6B are diagrams illustrating a process of dividing a page in a B-tree index to which the database management method and system of the present invention are applied.

The root node of the B tree index shown in FIG. 6A initially has two different key values P1 and P2. The first sorting key value P1 is a delimiter that distinguishes pages 1 and 2, and the second delimiting key value P2 is a delimiter that distinguishes pages 2 and 3. Then, the first key value P1 becomes UFK (UFK1) of page 1 and LFK (LFK2) of page 2. Similarly, the second discrimination key value P2 becomes UFK (UFK2) of page 2 and LFK (LFK3) of page 3.

In this state, it is assumed that page 2 should be divided on the basis of S, which is an arbitrary value between the first key P2 and the first key K1, because there is no more storage space on the page 2. [

In this case, page 2 stores the restored S as a new UFK (UFK2) as shown in FIG. 6B. Then, the data is compressed again using the existing LFK (LFK2) and the newly generated UFK (UFK2). That is, after comparing the LFK2 and UFK2 to extract the prefix, the remaining records excluding LFK2 and UFK2 are deleted from the key value and only the remaining key values are stored.

On the other hand, in page 3 of FIG. 6B that is newly created, S is stored as a new LFK (LFK3). Then, UFK (UFK2) of page 2 of Fig. 6A is stored as UFK (UFK3) of page 3 of Fig. 6B. Then, data is compressed again using LFK3 and UFK3. That is, after comparing LFK3 and UFK3 to extract the prefix, the remaining records excluding LFK3 and UFK3 are deleted from the key value, and only the remaining key values are stored.

Finally, in page 3 of FIG. 6B, S is inserted as a new key value between the first key value P1 and the second key value P2 of the parent node (here, the root node).

On the other hand, if the uncompressed page (that is, the page on which duplicate data is not deleted using the prefix) is not shown in the drawing, when dividing the page based on the new key value S, S) is set to UFK, data can be newly compressed using the existing LFK and the newly generated UFK. On the other hand, in the newly generated page, a new key value S is set to LFK, but since UFK is not set, data compression will not be performed.

Although not shown in the drawing, when two neighboring pages are mergeable (that is, when the sum of the number of records stored in two pages is equal to or smaller than the maximum value of the number of records that can be stored in one page , It is also possible to merge two pages. At this time, if both pages are compressed pages (i.e., pages in which redundant data are deleted using a prefix), new compression is performed after merging of two pages. On the other hand, if any one of the two pages is not a compressed page, the merging is not performed.

Table 1 shows the total number of index pages when a general database management method and system are applied and the total number of index pages when a database management method and system according to an embodiment of the present invention is applied This is a comparative table. Table 2 shows the average key length (average key length) when a general database management method and system are applied and the average key value length when a database management method and system according to an embodiment of the present invention is applied This is a comparative table.

Index name existing
Total index page count When applying the present invention
Index page
Decrease rate (%) PK (primary key) 4,120,635 21 Index 1 5,740,191 23 Index 2 6,056,621 18 Index 3 6,849,043 19 Index 4 5,793,081 15

Index name existing
Average key value length (bytes) When applying the present invention
Average key value length
Decrease rate (%) PK (primary key) 18 39 Index 1 30 33 Index 2 32 28 Index 3 38 29 Index 4 30 27

As shown in Table 1 and Table 2, when the database management method and system according to an embodiment of the present invention are applied, compared to the case where the conventional database management method and system are applied, the total number of index pages is reduced by about 19% And the average key value length was reduced by about 31%. That is, it can be seen that the storage space can be saved according to the present invention, thereby improving the performance of the database.

The database management method according to an embodiment of the present invention uses a key value used as a delimiter of a corresponding page in one page of the tree B as a {virtual key-OID} record, and stores the fence keys LFK and UFK), it is possible to quickly perform a decomposition operation of deleting the prefix from the combination of the original key values and the original key value from the LFK and UFK.

On the other hand, if there is no LFK or UFK in the page, the record can be stored in an existing manner, so that the compressed page (i.e., the page where the prefix is deleted from each record) and the uncompressed page Can be held together. Compressed and uncompressed records can also be kept mixed in pages where LFK and UFK exist. Therefore, it is possible to dynamically set the compression state in real time (run-time) irrespective of the current state of the B-tree. By using such a characteristic, if the load of an insert / delete in a specific area is increased, compression can be prevented from being performed, and the efficiency of database operation can be improved.

On the other hand, since the compression using the prefix is determined using LFK and UFK, there is no need to further record the metadata about the secondary compression method and range. Therefore, as the number of records stored in a page increases, compression efficiency is maximized as compared with a conventional method that includes meta information in a compressed record.

According to the present invention, since only key values except the prefix are stored, more records can be stored in one page of the B-tree. As a result, the storage space can be saved, and the possibility of being included in the buffer cache of the main memory as much as the smaller space is increased, thereby improving the performance of the database. Furthermore, the database management method according to an embodiment of the present invention is advantageous in terms of backward compatibility because it is simple to perform partitioning and restoration compared to other compression methods and does not change the storage structure, and only one flag indicating LFK and UFK is added And there is no additional metadata to record, which is advantageous in that it is structurally simple.

Further, by using the database management method of the present invention, validity check of a leaf node can be performed by using LFK and UFK of each page whenever a tree structure of an index is traversed, It is possible to obtain an effect of easily checking the error of the display device. Also, since the connection relationship of the leaf nodes can be grasped by LFK and UFK, the link can be removed from the leaf node, thereby improving the performance and efficiency in SMO (Structure Modification Operation).

The above-described database management method may be implemented in a form of a program that can be executed using various computer means. At this time, the program for performing the database management method may be a hard disk, CD-ROM, DVD, ROM, , Or a computer-readable recording medium such as a flash memory.

Although the present invention has been described with reference to the limited embodiments, various embodiments are possible within the scope of the present invention. It will also be understood that, although not described, equivalent means are also incorporated into the present invention. Therefore, the true scope of protection of the present invention should be defined by the following claims.

100: Database Management System
110: Database
120: Query Analyzer
130: Execution plan generation unit
140: Execution plan execution unit
150: Entry manager
160: Index management unit
161: Index generation unit
163:
165:

Claims (15)

A lower limit value of a key value of a plurality of records included in each page is stored as a lower fence key (LFK), or an upper limit value of a key value of a record is stored as an upper fence key (UFK);
Extracting a common area among key values of a plurality of records constituting the page as a prefix; And
And storing a remaining portion of the key value of the plurality of records except a portion corresponding to the prefix,
Wherein the LFK and the UFK are source key values including the prefix. The method according to claim 1,
Wherein the prefix is stored in a lower fence key (LFK) or an upper fence key (UFK). 3. The method of claim 2,
Wherein the key values other than the prefix are stored in a record other than the record in which the lower fence key (LFK) or the upper fence key (UFK) is stored among the records. The method according to claim 1,
Wherein the record is a multi-column record including a plurality of key values. 5. The method of claim 4,
Wherein a key value having a same value as a record of one page among the plurality of key values is extracted by the prefix. The method according to claim 1,
Wherein each of the pages is a leaf node of a B-tree or B + tree structure. The method according to claim 1,
The database management method includes:
Further comprising the step of adding a new record to the page or changing the existing record,
The step of adding or modifying the record includes:
Determining whether the LFK and the UFK are present in the corresponding page;
Comparing the LFK and the UFK when the LFK and the UFK are present in the page, and extracting a common prefix; And
And adding or changing the remaining key values from which the prefix is excluded in the record to be added or changed. 8. The method of claim 7,
If the LFK and UFK do not exist on the page,
Wherein the prefix is not extracted and a record is added or changed in the page. A recording medium on which a program for performing the method according to any one of claims 1 to 8 is recorded. A query analyzer for receiving and analyzing a query statement in which a fetch request for a record included in a specific table and an update request for at least one column included in the record are defined;
An execution plan generating unit for generating an execution plan for executing the analyzed query;
An execution plan execution unit for executing the execution plan by fetching the record and updating the at least one column in accordance with the execution plan; And
The lower limit value of the key value of a plurality of records belonging to each page of the index is stored as a lower fence key, or the upper limit value of the key value of the record is stored as an upper fence key (UFK) And an index generator for extracting a common area among key values of a plurality of records constituting each page by using a prefix,
Wherein the LFK and the UFK are source key values including the prefix. 11. The method of claim 10,
Wherein the index generator stores, in an index, a remaining portion excluding a portion corresponding to the prefix, which is a common region, from a key value of a plurality of records constituting each page. 11. The method of claim 10,
Wherein the prefix is stored only in a lower fence key (LFK) or an upper fence key (UFK). 13. The method of claim 12,
Wherein only the key values other than the prefix are stored in the record other than the record in which the lower fence key (LFK) or the upper fence key (UFK) is stored among the records. 11. The method of claim 10,
The index management unit,
And a record update unit for adding a new record to each page of the index or changing a record existing. 15. The method of claim 14,
Wherein the record update unit comprises:
If the LFK and the UFK exist in the corresponding page, the LFK and the UFK are compared with each other to extract the prefix, and if the LFK and the UFK exist in the page, Wherein the data is added or changed as a record on the page.

Images