KR100236675B1 - Method of exchanging cost-base object buffer for object-orient database system - Google Patents

Abstract

The present invention relates to a cost-based object buffer replacement method for an object-oriented database system. Specifically, in the object buffer of an object-oriented database system, the size and the replacement cost of objects are not constant for each object. It takes into account the replacement of objects so that the total cost incurred per unit time and unit space is minimized.

In the present invention, the cost for the object is calculated including not only the cost of retrieving the object but also the cost of replacing the object, and the unit cost is divided by the product of the object's size and the distance to the point where future reference is expected. Calculate

Since the present invention generalizes to consider the size and replacement cost of an object in existing object buffer replacement methods, the present invention can be applied to any application to which the existing methods are applied. In particular, object-oriented data in which replacement cost is not proportional to the number of buffer faults. It can be used efficiently in the base system.

Description

Cost-Based Object Buffer Replacement for Object-Oriented Database Systems

The present invention relates to a method of replacing an object buffer for an object-oriented database system. In detail, the present invention relates to replacing objects for minimizing total costs incurred per unit time and unit space in consideration of both size and replacement cost of objects. .

Generally, a buffer manager, a component of a database management system (hereinafter referred to as a DBMS), is a page, which is a unit of physical access of a disk, which constitutes a database. Manage database buffers (or database buffers) to make them accessible on main memory.

The buffer manager is a low-level component of the DBMS that receives a request for data from a high-level component and fetches the disk page where the data is stored from the disk to the buffer. Resident Because of the limited capacity of the buffer, if there is not enough storage space for the requested data to reside, the buffer manager selects the least likely one of the pages already in the buffer (also called the victim), Use the memory you occupied. If the victim's page changes, it writes it back to disk. As such, the process of selecting an existing page and reusing the storage space is called a replacement.

Since accessing pages on disk is much larger than accessing data residing on main memory, the buffer manager can help minimize the number of disk accesses that are incurred by buffers of a given size and the requested data. Aim. In traditional relational or network DBMSs, a database buffer is managed as an area consisting of pages corresponding to the size of a physical disk page, and requests for tuples (or records), which are logical units of data, are called corresponding tuples. (tuple) or a request for the page where the record is stored, so both fetching and replacing in the buffer is in physical pages.

If the requested page does not reside in the buffer, a buffer fault occurs. The rate at which a buffer fault occurs per unit request of a page is called a buffer fault rate. In page-based buffers, the cost of replacement is usually proportional to the number of buffer faults. The reason is that the total cost consists of the fetch cost of fetching the page that caused the buffer fault and the replacement cost of replacing the victims, since the replacement cost is represented as a constant fraction of the fetch cost. Therefore, minimizing the buffer fault rate in page-based buffers minimizes the overall cost.

On the other hand, unlike most existing DBMSs, the object-oriented database system (Object-Oriented Database Management System: OODBMS) manages the database buffer is divided into an object buffer (page buffer) and a page buffer (page buffer).

An object buffer is a buffer for managing objects that are logical units, and a page buffer is a buffer for managing physical pages and storing disks. The parent component of the OODBMS only accesses objects that reside in the object buffer. When attempting to access an object that does not reside in the object buffer, the object buffer manager requests the page where the object is stored and retrieves the object from the page buffer. do. If there is not enough space, the object buffer manager selects objects to replace in the object buffer and writes them back to the page buffer. This buffer management method is called dual buffering.

In the double buffering method, the object buffer has some characteristics different from the page buffer. First, objects residing in object buffers can be of different sizes. Objects belonging to different classes may exist in the object buffer, and objects belonging to the same class may have different sizes if they have variable length attributes.

Second, operations performed on an object are accumulated while the object resides in a buffer. That is, even if the operation for changing the attribute of the object is performed several times, it is written only to the object residing in the object buffer and not immediately reflected in the page buffer, but is written to the page buffer when the object is replaced. If an index is defined for a changed property of an object, the object buffer manager also updates the index for that property so that the query processor can retrieve the changed object by index.

In an existing DBMS, because an object buffer does not exist, every time the contents of a record or tuple changes, the index must be updated with the page it is stored in. In an OODBMS, an object buffer exists so that objects are replaced to reduce index update overhead. Update the index when it is done.

Due to the characteristics of the object buffer as described above, the replacement cost is not constant for each object in the object buffer, so the assumption that the cost incurred by the replacement method is proportional to the buffer fault rate no longer holds. If the size of an object exceeds the page size, the contents of the object must be written to multiple pages when the object is replaced, which may entail disk access to multiple pages. In fact, the contents of the object are reflected in the page residing in the page buffer, but the actual disk access occurs when the page is written to disk by page replacement, and if the page does not reside in the buffer, the page must be fetched from disk. Access takes place. In addition, the number of indexes established for attributes of an object or the number of accesses of a disk page required to update each index may vary from object to object.

Therefore, the replacement method for the object buffer must consider the replacement cost as well as the buffer fault rate.

However, until now, studies on the method of replacing objects in the double buffering method are very insufficient, and all of the proposed replacement methods aim at ignoring the replacement cost and minimizing only the buffer fault rate.

As a representative replacement method, Least Recently Used (LRU) is a method of selecting a longest used page as a victim. Other LRU variants include CLOCK, LRU-K, and 2Q. CLOCK is a simplified method of LRU that uses the reference bit to distinguish the most recently referenced pages. LRU-k is a generalized method of LRU, which selects the oldest page with the last k th reference point as the victim, and 2Q is the same as LRU-2 but uses a simpler data structure.

All of these methods are suitable for page replacement, but not for object buffers where the replacement cost is not proportional to the number of buffer faults.

Most commercial OODBMSs rely on simple methods or apply existing page-based methods to object buffers. For example, ORION and UniSQL, developed by Microelectronics and Computer Technology Corporation (MCC) in the United States, UniSQL relies on simple garbage collection to replace all objects that are not currently in use. However, gathering unnecessary information can also be costly because it replaces any objects that may be used in the future.

Versant's Versant and Servio's GemStone use LRU, an existing page-based method.

The object buffer replacement method of the present invention for solving the above problems is a cost-based object buffer replacement algorithm (Cobra) based on the cost of minimizing the total cost including the size and replacement of the object as well as the retrieval cost. The purpose is to provide).

1 is a schematic block diagram of a system in which a cost-based object buffer replacement method of the present invention is implemented.

2 is a flowchart illustrating a process of replacing an object buffer according to an embodiment of the present invention.

3 is a table for setting parameters used in performing the performance evaluation of the present invention.

4 is a result of performing the performance evaluation with the 007 benchmark using the variable of FIG.

5 is a table showing the numerical value of FIG.

Explanation of symbols on the main parts of the drawings

10: CPU20: Memory

21: Application 22: Object-Oriented Database System

22-1: Object Buffer Manager 22-2: Page Buffer Manager

23: object buffer 24: page buffer

100: computer 200: disk

As shown in FIG. 1, a system configuration in which a cost-based object buffer replacement method (Cobra) is implemented is a central processing unit (CPU) 10, an application program 21, an OODBMS 22, and an object buffer. And a disk 100 in which a database is stored, and a computer 100 formed of a memory 20 or the like in which the resident area of the page buffer 24 is located.

The object buffer 23 in the memory 20 is for managing objects that are logical units, the page buffer 24 is for managing pages in a physical unit in which an object is stored and actually accessing a disk. The buffer 23 is managed by the object buffer manager 22-1, and the page buffer 24 is managed by the page buffer manager 22-2.

Before defining the Cobra of the present invention implemented in the above system, several terms are defined.

When the set of objects stored in the database is N = {1, ..., n}, the sequence of object requests originating from the parent component of the OODBMS is defined as a reference string, and w = r ₁ r ₂ ... r _t ..., r _t ∈ N

Where r _t = x refers to the object x in the t th request. t represents the position of the permutation but can also be interpreted as a point in time on a discrete time axis. That is, the object x may be referred to at the time t.

The time difference (or distance) from the time point t until the object x is referred to as forward distance is defined as d _t (x). If x was first referenced (i.e. r _{t + i} = x) at the i (i≥0) th time, starting after and including the time point t, then d _t (x) = i If not, then d _t (x) = ∞. For example, when the reference string is 1 2 1 4 3 2, the forward distance to the object 2 is r ₆ = 2, so d ₃ (2) = 6-3 = 3.

The time (or distance) from page t to the last k-th point referenced before is called backward k-distance and denoted by b _t (x, k).

If x was referenced as the last kth time after j (j≥1) th from time t (i.e. r _tj = x and thereafter k-1 times before _t ), then b _t (x, k) If = j and x is never referenced, we define b _t (x, k) = ∞.

For example, the rear two-distance for page x = 1 at time point t = 6 at reference string 1 2 1 4 3 2 would be 6-1 = 5.

In an OODBMS using object buffer replacement method A, the total cost incurred for a reference string of length T (T> 0) w = r ₁ ... r _T and an object buffer of size m (m> 0) Suppose that (A, m, w), the total cost can be expressed by the equation (1).

[Equation 1]

Here, Cmin (w) is the minimum cost that can be incurred by the reference string w in a situation where the space of the object buffer is infinite. Assuming that the object buffer manager will eventually replace all objects after processing w, Cmin (w) consists of the cost of initially fetching the objects referenced by w into the object buffer and the cost of replacing them last.

Cextra (A, m, w) is the cost incurred by object buffer replacement method A replacing objects that will be referenced again in the event of insufficient buffer space. This consists of the replacement cost of the objects and the withdrawal costs that occur when the replaced objects are referenced again. That is, if a set of objects to be replaced at time t is X _t , and a set of objects to be drawn is Y _t , a set of objects that will be referenced again among the objects belonging to X _t X ' _t = {x ∈ X _t pd _t (x) ≠ ∞}, the set of previously replaced objects among objects belonging to Y _t Y ' _t = {y ∈ Y _t py ∈ X' _{t '} , t' = t-b _t (y, 1) , b _t (y, 1) "` ∞}.

In this case, if the fetch cost and replacement cost for the object x are called Cfetch (x) and Crep (x), Cextra (A, m, w) can be expressed by Equation 2.

[Equation 2]

Cfetch (x) and Crep (x) for object x are determined by the size of object x, whether an index is created on the object's attributes, whether the object is modified, and the storage model of the underlying storage system of OODBMS.

In Equation 2, it can be seen that the object x belonging to X ' _t belongs to Y' _{t + dt (x)} . Therefore, when looking at the cost based on an object x, the cost incurred by replacing x at a point in time t can be called Cfetch (x) + Crep (x) for d _t (x) time.

Convert this to cost per unit time: (Cfetch (x) + Crep (x)) / d _t (x) per unit time.

Accordingly, the object buffer replacement method A can minimize Cextra (A, m, w) by minimizing the cost incurred per unit time at every point in time.

However, when dealing with variable-length objects, the cost incurred per unit space must be taken into consideration when selecting the object to be replaced at some time t. The reason for this is that replacing large objects, even among objects with the same cost per unit time, frees up more space, thus reducing the number of replacements. Therefore, if the size of the object x is called size (x), replacing x at some point in time t (Crep (x) + Cfetch (x)) / size (x) per unit time until the point at which object x is referenced again Incurred by d _t (x)) At this time, since d _t (x) is not known at some time t, this value should be predictable.

Cobra, an object buffer replacement method of the present invention, has a minimum value of Cextra (A, m, w) by replacing an object x, which becomes the minimum unit time and cost per unit space, which is expected at a certain time t expressed by Equation 3. Be sure to

[Equation 3]

Where E [d _t (x)] is the approach to the expected value of the forward distance.

In order to calculate the expected unit time and cost per unit space at a certain time t expressed by Equation 3, E [d _t (x)], which is an approach value to the expected value of the forward distance, must be estimated.

Cobra uses the LRU-k approach to approach the forward distance expectations.

That is, the expected value of the forward distance for the object x at a certain time t is estimated using the distance b _t (x, k) to the time point at which x was last referred to. Cobra uses the method of LRU-2 in particular, where LRU-2 is the distance b _t (x, 2) to the last reference point.

Also, to implement Cobra, information such as HIST (x, 1), HIST (x, 2), and COST (x) must be maintained for each object in main memory.

HIST (x, 1) and HIST (x, 2) are the two viewpoints at which object x was last referenced, where HIST (x, 1) is the most recently referenced viewpoint, and HIST (x, 2) is the last second Save the referenced time point. If the object is referenced only once, the value of HIST (x, 2) represents ∞. If the object is never referenced, both HIST (x, 1) and HIST (x, 2) are ∞.

COST (x) stores the cost incurred by object x, which is calculated as Crep (x) + Cfetch (x).

Hereinafter, an embodiment of the present invention will be described in detail with reference to the accompanying drawings.

FIG. 2 shows an object buffer manager 22-1 when requesting an object x to the object buffer manager 22-1 at a time point t during execution of an application 21 according to an embodiment of the object-oriented database system implemented in the system of FIG. 1. 1) is a flowchart illustrating a process of returning the requested object according to the method of the present invention.

First, when object x is referenced at time point t, object buffer manager 22-1 updates the two time-points HIST (x, 1) and HIST (x, 2) values for which object x was last referenced, according to the current time point t. (S10).

Subsequently, it is checked whether the object x exists in the object buffer 23 (S20). If the object x exists, the process proceeds to step S70 to return the object and terminate the request for the object x. However, if the object x does not exist in the object buffer 23, it is determined whether there is extra space for loading the object x in the object buffer 23 before the object x is read from the page buffer 24 and loaded (S30). ). If there is no extra space in the object buffer 23, the steps S40 and S50 are performed until the extra space is secured to replace the objects on a cost basis.

In detail, in step S40, COST (y) / (size (y) * (t-HIST (y, 2)), which is a unit time and a cost per unit space, is calculated for all objects currently present in the object buffer. The object y with the smallest value is selected for replacement, where COST (y) is the cost incurred by object y described above, size (y) is the size of object y, and t-HIST (y, 2 ) Is the approach E [d _t (y)] to the expected value of the forward distance.

In step S50, the selected object y is replaced, and if y is updated, it is written in the page buffer 24, and after the replacement of the object y, the process proceeds to step S30 again to secure extra space. Check if it is

As a result of replacing the object on a cost basis (S40) (S50), if the extra space is secured in the object buffer 23, the object x is read from the page buffer 24 and loaded into the extra space (S60), and then the object x By returning to the application 21, all the steps of processing the request of the application 21 for the object x is terminated (S70).

The concept of Cobra described above is generalized to consider the size of object and replacement cost in Denning-Chen-Shedler's optimal method, which is based on LRU, LRU-k, and 2Q methods.

Denning-Chen-Shedler's method is a page-based algorithm, where pages x in which E [d _t (x)] is maximum, that is, 1 / (E [d _t (x)]) is the smallest of the pages in the buffer. This is a special case of Cobra that sets Crep (x) = 0, Cfetch (x) = 1, and size (x) = 1 because it replaces. Cobra can therefore be easily adapted to any application where traditional page-based methods are used.

In the object buffer replacement method Cobra of the present invention, performance evaluation is performed using a 007 benchmark, which is an object-oriented database system performance evaluation standard proposed by the University of Wisconsin, collecting unnecessary information (GARBAGE), LRU, LRU-2 Compared.

As a result of performing the 007 benchmark by setting the variable as shown in FIG. 3, in the case of T3B operation involving index update, unnecessary information collection (GARBAGE), LRU, LRU-2, and Cobra showed the same results as in FIG. 4. 5 is a numerical representation of the result of FIG. 4.

According to the results of the performance evaluation, the method of the present invention always shows the same or better result than the conventional page-based buffer replacement methods such as GARBAGE, LRU, and LRU-2.

As described above, the cost-based object buffer replacement method (Cobra) of the present invention is generalized to consider the size and replacement cost of the object in the optimal method of Denning-Chen-Shedler, which is the base of LRU, LRU-k, and 2Q methods. It can be easily adapted to any application where existing page-based methods are used.

In particular, the present invention can be effectively used as an object buffer replacement method of an object-oriented data bus management system in which replacement cost is not constant, and the replacement cost is buffered because it aims to minimize the total cost incurred per unit time and unit space. In situations that are not proportional to the fault rate, better performance can be achieved than traditional page-based replacement methods. In addition, because it uses a simple data structure, it can be easily implemented and used in a real commercial object-oriented database management system.

Claims (4)

In the object buffer replacement method for an object-oriented database system, an object-oriented database system characterized by calculating the unit time and the cost per unit space occurring during the replacement among the objects to select and replace the object is the minimum value Cost-based Object Buffer Replacement for Windows. The method of claim 1, wherein the cost per unit time and unit space is a sum of a withdrawal cost incurred when the object is withdrawn and a replacement cost incurred when the object is replaced with an expected value of the size of the object and the forward distance to the object. Cost-based object buffer replacement method for an object-oriented database system, characterized by dividing by the product of access values. The cost-based object for an object-oriented database system according to claim 2, wherein the approach value for the forward distance value is calculated as the distance from the time point at which the object is replaced to the time point at which the object is last referenced. How to replace the buffer. In the object buffer replacement method for an object-oriented database system, if an object x is referenced at a time point t in response to a request of the application 21 for the object x, the two time points at which the object x was last referenced in accordance with the current time point t Updating the HIST (x, 1) and HIST (x, 2) values; Checking whether the object x exists in the object buffer 23; Returning an object if the object x exists as a result of the inspection, and determining whether there is an extra space for loading the object x in the object buffer 23 if the object x does not exist; As a result of the determination, if there is no extra space in the object buffer 23, objects are replaced based on cost using the method of claim 1 until the extra space is secured, and if the replaced buffer is updated, the page buffer ( Recording at 24); As a result of replacing the object on a cost basis, if the extra space is secured in the object buffer 23, reading the object x from the page buffer 24 and loading it into the extra space; Cost-based object buffer replacement method for an object-oriented database system comprising the step of returning the object x to the application (21).