|Publication number||US4611272 A|
|Application number||US 06/463,469|
|Publication date||Sep 9, 1986|
|Filing date||Feb 3, 1983|
|Priority date||Feb 3, 1983|
|Publication number||06463469, 463469, US 4611272 A, US 4611272A, US-A-4611272, US4611272 A, US4611272A|
|Inventors||David B. Lomet|
|Original Assignee||International Business Machines Corporation|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (8), Non-Patent Citations (10), Referenced by (105), Classifications (9), Legal Events (6)|
|External Links: USPTO, USPTO Assignment, Espacenet|
1. Field of the Invention
The present invention relates to file organizations for computer systems. More particularly, it relates to the accessing of data in secondary storage systems, such as disks, in a minimum number of access attempts.
2. Description of the Prior Art
The secondary storage devices in large computer systems provide for the storing, updating and retrieving of data to and from large collections of data in the main memory of the computer. The organization of such data, termed files, is obviously important to make accessing efficient. In addition, it is important to be able to insert (and delete) new data elements into and from the files particularly on random access secondary storage devices, such as disks. Such files are termed "dynamic" files.
As is well known to skilled computer designers and system programmers, many techniques for structuring such files have been proposed, with the B-Tree index structure being the present standard for commercial equipment. The article by D. Comer, "The Ubiquitous B-Tree", Computing Surveys, Vol. 11, No. 2, June 1979, pages 1-137 contains a good review of B-Trees.
Another, more recent type of file organization scheme suitable for dynamic files is extendible (also known as expandable or dynamic) hashing. A number of techniques have been developed that permit extendible hashing to be used as a fast method to access large files residing on external storage for files of fixed size as well as for files which increase in size. For example, the article by R. Fagin et al entitled, "Extendible Hashing--A Fast Access Method for Dynamic Files", ACM Trans. Data Base Syst. Vol. 4, No. 3, September, 1979, pp. 315-344, describes the access technique of extendible hashing which, unlike conventional hashing, has a structure which grows and shrinks as the file does. The Fagin et al method separates the hash address space from the address space of the data by employing an index between the hash function and the disk address where data is stored; and it generates more bits than are required initially to identify the index term. However, Fagin et al. require close to two disk accesses per data access once the file is sufficiently large that only a small portion of the index fits in the main memory.
Litwin in his article entitled, "Linear Virtual Hashing: A New Tool for Files and Tables Implementation", published in Proc. 6th Int'l. Conf. on Very Large Data Bases, Montreal, 1980, pages 212 to 223, describes a dynamic hashing function, called a linear hashing function, in which the hash addresses of the keys are changed in some predefined order instead of changing the hash address for the data whose page has overflowed. This has the advantage of causing the space allocated for the file to grow linearly by the addition of contiguous pages to the end of the current file. However, Litwin assumes the existence of a contiguous, continuous address space, which is not an effective way to utilize the space efficiently. While he describes a method of mapping his page numbers to disk addresses, his method of utilizing the disk space has the result that the cost, in disk accesses, to add an additional primary page to his file typically requires three accesses per page. Further, the number of overflow pages used and the performance are not as favorable as those of my invention.
The paper by G. Martin, entitled, "Spiral Storage; Incrementally Augmentable Hash Addressed Storage", Theory of Computation, Report No. 27, U. of Warwick, Coventry, England, March 1979, describes a hashing technique in which the keys are mapped into the address space so that they tend to be more dense at one portion of the space than at another. During file growth, keys which used to occupy the more dense space are spread over the new, less dense space. Martin uses a hash function mapping the keys onto the space exponentially rather than uniformly. However, Martin's method of mapping the relative pages generated by his hash function into real disk addresses is complicated and expensive in disk accesses per primary page added. Further, his method of handling overflow records involves rehashing, which can result in adverse performance, particularly on unsuccessful searches.
These extendible hashing techniques do not require a complete file reorganization and rehashing to cope with file growth or shrinkage. In addition, they provide faster random access than is typically provided by tree index methods, such as B-trees. They also provide for a limited form of sequentiality, i.e., the ability to sequence through the records of the file in some order, though not in key order. However, none of these hashing methods alone provides for a combination of advantages which is desired in file addressing, i.e., a single disk access, straightforward storage management of the underlying disk space and avoiding the necessity for rehashing to cope with collisions.
A characteristic of all extendible hashing schemes, with the exception of the spiral storage described in the above-referenced paper by Martin, has been oscillatory performance. The hash function distributes the hashed keys uniformly over the pages of the file. Thus, these pages fill up uniformly and become completely filled almost simultaneously. Within a small period of further file growth, the large majority of file pages all overflow and their entries must be split over two pages. The result is that utilization swings between 50% and almost 100%, suddenly "crashing" to 50% during the short splitting period. In addition, the cost of doing an insertion is comparatively low at low utilizations but is considerably higher during the splitting period because so many insertions lead to page splitting. Finally, if overflow records are required by the technique, as they usually are, then the frequency of occurrence of overflow increases dramatically as utilization approaches 100%. This results in a sharp increase in the cost (in terms of disk accesses) of insertions and searches as accessing of the overflow records becomes increasingly common.
It is therefore an object of my invention to retrieve data from a chosen (arbitrary) key almost always with a single access.
It is a further object of my invention to enable a change in the size of a file without major reorganization or rehashing.
It is another object of my invention to manage the physical disk space as part of the method itself in such a way that storage space is utilized efficiently, by means of straight-forward techniques.
It is yet another object of my invention to provide a method of access in which the cost of the search and the insertion of keys do not vary as the file grows (or shrinks).
My invention is the organizing of a key accessed (indexed) file such that the file structure consists only of two levels, an index level and a data level. Both levels are permanently stored in a page-organized secondary storage medium that supports random accessing of the pages. The index level is designed to have a fixed and specifiable number of pages and is stored entirely in the computer's memory when the file is in use. The fixed size of the index is made possible by having each index entry reference a data node with a growing (or shrinking) number of data pages as the file changes in size. Avoiding the accessing of more than one of the data pages referenced by an index entry is accomplished by means of an address computation that utilizes bits of the search argument The number of bits involved in this computation is given by:
log.sub.2 (number of pages referenced by the index term)
where the number of such pages is an integral power of two.
A maximum buffer size is selected which represents the number of pages of main memory which will be committed to the file (and access) method to aid in accessing the data. This buffer contains an index to the file, as in extendible hashing, but the index is limited so as to be contained within the buffer size. The existence of an index level makes storage management easier. Once the index has grown to its limit further file growth is accomplished by means of doubling the number of pages in a data node so that the number of pages referenced by an index entry is likewise doubled.
Overflow pages are used, when required, to make sure that storage utilization remains adequately high. A novel technique for overflow pages assures that unsuccessful searches rarely require more than two disk accesses while achieving high space utilization for the overflow pages.
The method includes choosing a hashing function, h(key), which distributes the keys of the file uniformly. The result of this function is then exponentially distributed using another function, exhash(key), such that there are twice as many key entries near one boundary of the key space than at the other boundary.
I call this novel and improved form of extendible hashing by the name of bounded index exponential hashing, termed "BEH" hashing. It has important advantages over most of the other extendible hashing technique in that it provides both random access to any record of a file in close to one disk access as well as performance which does not vary with file size. It is straightforward to implement and requires only a fixed and specifiable amount of main storage to achieve this performance. Its underlying physical disk storage is readily managed, and record overflow is handled so as to insure that unsuccessful searches rarely take more than two accesses.
FIG. 1 is a schematic diagram illustrating the placement of the index level in main memory and the data node level in secondary memory.
FIGS. 2.1 and 2.2 are block diagrams illustrating the structure of a file according to my invention, before and after data node doubling, respectively.
FIG. 3 is a block diagram illustrating the structure of a data node together with its associated tree (O-Tree) of overflow pages.
In describing my invention, I use the following terminology which has become standard in this field. A file is a collection of records, each one identified by a key. An access method includes a logical storage structure into which a file can be mapped, and the algorithms needed to manage this structure. The method manages a collection of storage units, called pages, usually of fixed size, of a secondary storage device or devices. To specify an access method, the relationship between the pages as well as the internal structure of a page and algorithms for file updating (inserting, deleting or changing records) and retrieval must be described. By the term "access" I mean any of the operations of updating or retrieving. Pages are accessed by following an access path which leads from page to page. In general, a page contains records and index entries containing pointers to other pages. If a page contains only index entries, it is called a directory (or index) page. If a page contains only keys, and their associated records, then it is called a data page, or leaf.
According to my invention, a hashing function h(key) is chosen that distributes the keys of the file as uniformly as possible. A hashing function chosen from a class of universal hashing functions as described in the paper by J. L. Carter et al entitled, "Universal Classes of Hash Functions", J. Computers and System Science, Vol. 18, No. 2, (April, 1979), pp. 143-144, provides a very high probability that the hashed keys will be distributed uniformly. For example, the following hashing function is suitable:
h(key)=(((m * key)+n) mod p) mod b (1)
when p is a prime number, b is the size of the hash space, and m and n are integers.
The hash address space (i.e., the range of h) must be such as to accommodate the entire planned growth of the file; hence in practice it produces hash addresses of 24 bits or more. These are interpreted as 24-bit (or more) fractions between zero and one.
The result of the hash function (1) is then exponentially distributed, using the function:
exhash(key)=2.sup.h(key) -1 (2)
where h(key) is the result of applying the universal hash function. The purpose of equation (2) is to assure uniform performance, instead of oscillatory performance, as the file grows. After this step, the exponential nature of the hash function does not enter into the access method further. Performance is influenced but not the algorithms.
The function exhash(key) remaps a uniform distribution of hashed keys in the range from zero to one into values that also range from zero to one but are such that hashed key frequency varies over this range. Hashed keys near zero are, using the exponential hash, twice as frequent as hashed keys near one. Disk access behavior can be made constant because the relative frequency of pages with any given utilization can be made constant, thus removing oscillations in overflows and in splitting frequency.
I use exponential hashing without altering the important characteristics of other extendible hashing techniques. Thus, the exponential hashed key value can be stored with data and index entries and can be used to assist in searching within pages of the file. More importantly, when pages overflow, the bits of the stored hashed key determine how to split the entries on the overflowing page over two pages.
The splitting is the same kind of digital splitting required for most extendible hashing methods. It consists of the following. Let kp be the prefix of all hashed key values (i.e., the results of exhash(key)) that are stored on a given page. When the page is full and yet another key is to be inserted, the contents of the page are split (divided) between two pages as follows. The page contents (index or data) that are associated with hashed keys prefixed by kp `0` are placed in one of the pages while the contents that are associated with hashed keys prefixed by kp `1` are placed on the other page.
FIG. 1 illustrates the physical placement of the BEH index in computer main memory and data nodes placed on secondary storage devices as contiguous blocks of pages, with the number of pages being an integral power of two.
FIG. 2.1 illustrates the state of the BEH organized file prior to data node doubling. At this stage, a copy of the index level resides in the buffer of the main (primary) computer memory; the data level resides in the secondary memory, such as a disk. For simplicity of presentation, an index size, in pages, of four is assumed.
In my preferred embodiment, the file is searched as follows. The first bits of exhash(ARG), where ARG is the search key whose data is desired, are used to select the index page where the search for ARG's data continues. In the file shown in the figures, the first two bits of exhash(ARG) are used and the `01` index page is selected. Additional bits of exhash(ARG), e.g., bits 2 through 5, are used to find the disk address, "PTR", in index page `01` which refers to the page on which data for ARG will reside, if the search is to be successful. The page referenced by PTR is read and is searched to determine whether "ARG" is present or not, and if so to return its associated data. The node (page) at the data level in FIG. 2.1 contains data for values of exhash(ARG) begingning with `10` `101`. Di in the data level page is the data for ARG=Ki with exhash(ARG)=`01` `101` `011`=`01101011`. A complete description of searching the file, before and after data node doubling is given in the FILE OPERATIONS section of the specification.
Assume that a data node (page) overflows and that the index page which references it is itself filled. In the standard extendible hashing method, this would trigger the splitting of the data page, causing the index page to overflow. Index page overflow would be handled by doubling the index size, thereby separating the entries on each page of the index into two pages, based on the first bit of ID, which is the unused suffix of the stored result of applying exhash to the incoming insertion arguments. Thus, the index would increase to eight pages and require three bits of exhash(ARG) to access it.
In my method of BEH hashing, index size does not increase. Rather, the data node doubles in size so as to accommodate the overflow, instead of the node splitting into two nodes. Thus, multi-page data nodes arise as the file grows in size. Subsequent page overflow may lead to subsequent additional data node doubling. The doubling, just as the splitting did, divides the entries between pages based on the value of the next bit of the stored hashed key values. This requires that: (a) entries in the index level refer to a data node whose size is also indicated; and (b) the search procedure make use of this size and the appropriate bits of exhash(ARG) in order to select the page of the data node on which the data associated with ARG resides.
Because of (b), having this size be log2 (node size in pages) is useful, as this is the number of bits of exhash(ARG) to be used in making this selection. FIG. 2.2 illustrates the BEH file of FIG. 2.1 after the node containing exhash(ARG) has doubled.
Node doubling, regardless of the original size of the node, has the effect of splitting the contents of each page of the node between two pages of the doubled node. In the example of FIG. 2, the node goes from one page to two pages. This splitting of page contents over two pages of the new doubled node is performed based on the appropriate binary digit of the hashed key value, exactly as splitting in most extendible hashing methods is performed. Thus, if kp is the prefix of all hashed key values of a page of the original node, then the two contiguous pages of the doubled node that will contain these values are such that kp `0` is the prefix of all hashed key values of one of the pages and kp `1` is the prefix of all hashed key values of the other page. In the example of FIG. 2, kp=`01` `101` for the data node illustrated in FIG. 2.1. This value continues as the hashed key prefix for the data node of FIG. 2.2 but not for each page of the node. Rather, the hashed key prefix for the first (zeroth) page is `01` `101` `0` while the hashed key prefix for the second (oneth) page is `01` `101` `1`.
At the time of doubling, all information associated with the original page is split between the two new pages in the above manner. This includes not only the immediate contents of the original page, but also any overflow information that would have been contained in the original page had there been sufficient space. Thus, doubling of a node typically permits such overflow information to be absorbed into the two new pages, thus eliminating the overflow pages after doubling.
The initial growth of the file may be done by using the index doubling scheme of extendible hashing so long as the index, in pages, can be contained within the buffer. All subsequent file growth is then handled using data node doubling. Thus, one begins with a one page index and inserts "records" until that index page can no longer hold all the required index entries pointing to data pages. At this point the index doubles, all entries beginning with a `0` bit being indexed via page 0 of the index, all those beginning with a `1` bit being indexed via page 1. Subsequently, when one of those index pages overflows, the index will be doubled again, as with extendible hashing. This doubling stops when the index size, in pages, equals the maximum permitted by the buffer size. Data node doubling is then used for further file growth.
The search method, i.e., how to find data associated with a given key, is illustrated by the SEARCH program in Table I. The program is explained as follows. The key is supplied to SEARCH as the value of ARG. The address in main memory of the data associated with the key is returned by SEARCH in D-- ADR if ARG is found. If ARG is found, then the variable FOUND is set to true when SEARCH returns, otherwise it is set to false. The SEARCH is then initiated by:
The following is a description of how this SEARCH procedure accomplishes its purpose.
(1) Convert the search argument ARG to its hashed value, using EXHASH; call the result HK.
(2) Let P be the starting secondary storage address of the index pages and I-- SIZE be the logarithm base two of the size, in pages, of the index.
(3) Compute the index page Q on which to find the index term that will lead to the data for ARG; it is found by taking the first I-- SIZE bits of HK and adding them to P, i.e.
(4) Convert the disk address Q into a memory address by locating the starting address of the page in main memory, i.e.,
(This is possible without reading data from secondary storage because the index pages of the file are already in main memory.)
(5) Find the index entry for HK in the page pointed to by I-- ADDR. Since the index entry need not contain the part of HK used to find the index page, we need to provide only
HK.sub.-- REST=SUBSTR(HK,I.sub.-- SIZE,*)
which removes from HK the first I-- SIZE bits. What is returned as a result of finding an index entry for HK-- REST are three quantities:
(i) LEN which is the number of bits of HK-- REST that are consumed in identifying the index entry;
(ii) SIZE which is the logarithm, base two, of the number of pages in the data node referenced by the index entry; and
(iii) PTR which is the disk address of the first (zeroth) page of the data node referenced by the index entry.
CALL IFIND(HK.sub.-- REST, I.sub.-- ADDR, LEN, SIZE,PTR)
(6) Compute, using the next SIZE bits of HK-- REST after those used in identifying the index entry, i.e., LEN bits, the disk address of the data page where data for ARG is to be found, i.e.,
PAGE.sub.-- DISP=SUBSTR(HK REST,LEN,SIZE)
DATA.sub.-- PAGE=PTR+PAGE DISP
(7) Read the data page specified in DATA-- PAGE from secondary storage into memory and report its memory address in DATA-- ADDR., i.e.,
CALL READ(DATA.sub.-- PAGE, DATA.sub.-- ADDR)
Note: This call to READ is the only place, except for the case when data page overflow occurs, where reading secondary storage is required.
(8) Find ARG on the data page read into memory. If ARG is found, then FOUND is set to true, if not found, then false. If an overflow page exists for the node then OVERFLOW is set to true; if not, then false. If OVERFLOW is true then O-- PAGE will be set to the disk address of the overflow page. If ARG is found, the address of its data is returned in D-- ADR. Thus,
CALL DFIND(ARG,D.sub.-- ADR,FOUND, OVERFLOW,O.sub.-- PAGE)
(9) If ARG's data has been found, then return, as a result of the SEARCH procedure, D-- ADR, and FOUND set to true, i.e.,
IF FOUND THEN RETURN.
(10) If ARG's data has not been found and no overflow page exists, then ARG's data does not exist in the file. RETURN FOUND set to false as a result of the SEARCH procedure, i.e.,
IF NOT (OVERFLOW) THEN RETURN
(11) If ARG has not been found but an overflow page exists on which might be located the data for ARG, then search the overflow page (or pages) for ARG's data.
Since the overflow page is identified within the node by PAGE-- DISP, we must supply PAGE-- DISP as well as ARG and O-- PAGE. The result we expect is an appropriate setting for the quantities D-- ADR and FOUND.
CALL OFIND(ARG,O.sub.-- PAGE,PAGE DISP, D.sub.-- ADR,FOUND).
(Note that OFIND is not normally called because overflow is unusual. Further, if it is called, it usually involves only a single read of a page from secondary storage.)
*SUBSTR is a function procedure that takes a string argument, e.g., HK, a starting position in the string, e.g., 0, and a length for the substring, e.g., I-- SIZE, and returns the string which consists of locations "start" through "start+length -1" of the string argument. If an * is given as the length, the substring specified includes the remainder of the argument string.
TABLE I______________________________________SEARCH:PROCEDURE(ARG,D --ADR,FOUND)______________________________________DCLP: START SECONDARY STORAGE ADDRESS OF THEINDEX PAGESI-SIZE: LOGARITHM BASE TWO OF THE NUMBER OFINDEX PAGESHK: = EXHASH(ARG);Q: = P+SUBSTR(HK,0,I --SIZE);I --ADDR: = LOCATE(Q);HK --REST: = SUBSTR(HK,I --SIZE,*);CALL IFIND(HK --REST,I --ADDR,LEN,SIZE,PTR):PAGE --DISP = SUBSTR(HK --REST,LEN,SIZE);DATA --PAGE = PTR+PAGE --DISP:CALL READ(DATA --PAGE, DATA --ADDR);CALL DFIND(ARG,D --ADR,FOUND,OVERFLOW,O --PAGE)IF FOUND | NOT (OVERFLOW)THEN RETURN;Note: This simply combines the cases described inthe text. Only if ARG is not FOUND and OVERFLOWpages exist do we perform the following statements.CALL OFIND(ARG,OPAGE,PAGE --DISP,D --ADR,FOUND);RETURN:END SEARCH.______________________________________
Insertion and deletion both proceed by first searching for the designated entry and locating the page on which it resides or is to reside. Most of the time these update operations will then merely change that page in the expected way, i.e., for insertion, including a new record with a key value that did not exist previously; and for deletion, removing the record whose key matches the key value specified.
In these cases, both operations require only a single read, when overflow records are absent, followed by a single write of the updated page back onto the disk. The existence of overflow records requires a second read prior to the write. If insertion requires a page to "split", then the size of the data node is doubled, thus spreading the entries of each of its pages over two pages. Such multipage doubling can be done quite efficiently by reading and writing multiple pages during each I/O operation, because the pages are contiguous.
Hashing cannot support key ordered sequential search. There are times, however, when sequential access is desirable and key order is not important. For this case, BEH hashing has the very desirable property of page contiguity within a node. This permits reading blocks of pages with a single I/O read and buffering the results. Disk arm movement is of course greatly reduced under these conditions.
I provide a concrete method for handing overflows so to assure that file utilization is maintained at a reasonable level by an appropriate choice of the number of pages devoted to accommodating overflow entries. This assures good and constant performance for the file.
One overflow page is associated with every 2n contiguous pages of a data node. The number `n` is not fixed but changes as the utilization of a node increases. For a good compromise between utilization and disk access performance, it is not necessary to have more than one overflow page for every four data pages except for very small page sizes. Thus, an overflow page contains entries that share a common prefix `X` such that `X` concatenated with a bit string of length `n` produces the common prefix `kp` of one of its associated primary pages.
The fact that an overflow page is associated with consecutive primary pages has important implications with respect to node doubling and sequential search, for the same basic reason. In both these cases, it is possible to perform multipage I/O operations because many pages will have to be accessed in any event. Thus, the number of separate I/O operations can be reduced by a large factor. For savings to be realized, however, it is necessary to avoid many separate I/O operations in accessing the associated overflow entries of these pages. This organization requires one additional I/O operation to access the overflow entries for 2n consecutive pages. This permits the saving in I/O operations for the primary pages to become a real saving even after overflow pages are included.
When a page of a node first overflows, it must reference a designated page in that node, perhaps the first page (page zero) to obtain a reference to the initial overflow page, if one exists. If no such overflow page exists, one is allocated and a pointer to it stored in both page zero, for the sake of the currently non-overflowing pages, and in the overflowing page. This initial overflow page will serve as the root of a "tree" of overflow pages which is grown as the number of overflow entries increases, such that more and more overflow pages are required.
Whenever an overflow page itself overflows, the entries on the page are split between two pages, the current page and a newly allocated one, based on the bits of the key. That is, the overflow page is split digitally, exactly as the entries in the primary pages are. Each of the two pages then serves as the overflow page for one half of the primary pages served by the original overflow page A pointer to the new overflow page is stored in the original overflow page and, when appropriate, in the primary page whose insertion triggered the split. (Note that the other primary pages that share the new overflow page do not have their overflow page pointers immediately updated. Rather, this is done during the next access to the primary page that requires an access to the overflow page as well.) FIG. 3 is a diagram of how this process works. As is indicated in FIG. 3, this growth process can continue until a "tree" of pages, called an O-tree, exists.
Note that if all overflow entries are from one half of the primary pages using the overflow page, then the splitting process described above that uses the next bit of the stored hashed key would fail to accommodate the overflow entries. All would still be assigned to one page. In this case, one must find the first bit that succeeds in splitting the overflow entries and use this for dividing them, constructing an index in the original page that reflects the actual splitting performed.
It is possible for the O-tree to grow sufficiently so that one primary page ends up having more than one overflow page, particularly if the page size is small. This growth can proceed in exactly the same fashion with respect to O-tree structure. However, the primary page itself should point directly to all pages containing its overflow entries. Thus, the primary page will need to contain a small "index" to each of its overflow pages, rather than simply the one pointer. This index should indicate not just the overflow page addresses, but also the key space of entries in each such page. This information will continue to enable the disk access cost of a search to be limited to no more than two accesses.
As is readily observed, each node of an O-tree which serves as the ancestor of other nodes also serves as a leaf node, so the O-tree structure has missing links. In particular, as I have constructed the O-tree in FIG. 3, all links to leftmost pages of the tree have been eliminated. This saves both space and search time.
When a primary page is full, each successive insertion will result in an entry being placed in an overflow page. The overflow page is found as follows. The pointer to the overflow page points either to the first page of the node or to an actual overflow page. If that page is the first page of the node, a pointer in this page refers to the root of the O-tree. Following the pointer leads to the root of the O-tree and the situation becomes the same as if the overflow pointer in the primary page had pointed at an overflow page initially. If the prefix associated with the overflow page is a prefix of the entry, then the page is the correct overflow page for the primary page and the entry can be inserted into this page (or found in this page if the operation is a search). If this is not the case, the index in the page must be accessed to find the pointer to the next node in the O-tree where the overflow page for the entry might be located. Note that indirections are followed only when `1` bits are encountered in the argument key. Thus, the number of links traversed is, on average, half the height of the implicit binary tree represented by the O-tree.
Whenever a primary page discovers that its overflow page has moved, during either a search or an insertion, it updates its overflow page pointer to refer to the new overflow page. (The overflow page "moves" as the O-tree grows and overflow pages split.) Thus, occasionally extra accesses to additional overflow pages occur.
The penalty in extra accesses can be reduced. It is possible to eliminate the initial reference to the first page of the node by allocating an initial overflow page (or pages) when a node is doubled. The primary pages can then be initialized so as to point directly to the "root" of the O-tree. Further, the height of O-trees can be clipped so as to never exceed a selected number, e.g., six. This can be accomplished by allocating an overflow page for every 64 pages of the node instead of only one per node.
Because the O-tree is a dynamic structure which can grow to accommodate more and more overflow entries, there is no fixed point at which a node must double because an entry cannot be inserted. Thus it becomes necessary to define when doubling is to occur. In doing so, I make use of the fact that when the size of the file is known, it is possible to determine a doubling frontier x, which is in the range of exhash(ARG), at which doubling should occur. The value of x varies with the file size. The result is that, as the file grows, the value of x is contained in different data nodes. The node currently containing the value of x is the one to be doubled. If the file shrinks, this process can be reversed, leading to the halving of the indicated node.
To determine the value of x, a count must be kept of the number of entries (records) E contained in the file. This count can be kept along with the index for the file in the main memory buffer.
The following fixed quantities also help determine the value of x.
(1) I: the number of index terms, and hence the number of data nodes.
(2) M: the number of data entries (records) that can be contained on a data page. This is an average if the size of the records is variable.
(3) n: the size associated with the index entry for exhash(key)=`11 . . . 1`, i.e., the last entry of the index. This size indicates a data node of 2n pages.
(4) u: the fill utilization if one ignores the presence of overflow pages. This is the desired utilization. The error introduced by ignoring overflow pages is very small for values of u up to 75-80%.
By simple algebra, then, it is possible to compute the value x which indicates which node to double. It is: ##EQU1## The value of x will cross a node boundary after the insertion of:
ΔE=2.sup.n *M*u entries, (4)
i.e., after the insertion of sufficient data to fill one additional data node. The value of ΔE doubles after the data node size of the last index entry increases from 2n pages to 2n +1 pages At this point, the value of x changes from `11 . . . 1` to `00 . . . 0`, that is, it changes from referencing the last index entry to referencing the first index entry.
Thus, the signal for doubling a node is not given by the state of its O-tree but rather by a property of the file, i.e., the value of x.
There are two reasons for having an index level for BEH files. One is to permit the nodes of the file to be mapped into non-contiguous storage, thus avoiding the storage utilization penalty associated with pre-allocating large blocks of the disk to the file prior to the space being needed to store data. The second reason is to permit multipage reading and writing to be used during node doubling (or node halving) or for sequential reading, thus improving the performance of these operations.
Because BEH-organized files grow by node doubling (and shrink by node halving), they are managed by a method derived from the storage management scheme called the "buddy" method which is described in D. Knuth, The Art of Computer Programming, Vol. 1, Fundamental Algorithms, Addison Wesley, (1977).
A "buddy" allocation method works with blocks of storage whose units are some integral power of two in size. Separate free lists are maintained for each different size block. If a block size is requested and there are no blocks of that size available, a larger block is split (and its pieces split again if necessary) in order to provide a block of the desired size. When blocks are freed, the "buddy" of the block must be examined to determine whether the freed block can be consolidated with it to create a larger block. Any consolidated block is likewise a candidate for further consolidation. It is this process that gives the method its name.
A buddy to a freed block is that block of the same size as the freed block whose address is determined as follows. If each disk address is l bits long, and the freed block has 2k units of storage (pages), then the buddy will share a common prefix with the freed block, the length of which will be l-k-1. The bit in the buddy following this common prefix will be the complement of the corresponding bit in the freed block. If consolidation occurs, the result is a free block of size 2k+1.
In the BEH file all nodes have numbers of pages that are integral powers of two. Hence, no space is wasted within the blocks. Further, the growth of the file (or its shrinkage) is such as to require a gradual change from one block size to another which is double (half) the size of the previous block. The activity of changing block size occurs at the frontier indicated by the value of x. Blocks in this region are readily consolidated during file growth, without the number of blocks on each free list of blocks of a given size ever becoming large. During file shrinkage, splitting of blocks preserves the short length of these lists.
When managing disk storage, unlike main memory, one wants to avoid going to the "buddy" itself to see whether it is free and can be consolidated with the just freed block. If this were done, it would require an extra disk access for each free operation. For this reason, all bookkeeping required by the method is fully separate from the storage being managed so that it can be kept in main memory. Because of the short free lists for each size of available block, finding a buddy is readily accomplished by simply searching the free list with the appropriate size blocks. If these lists are very short, a sequential search should be adequate. Should the lists be somewhat longer, a binary digital tree (trie) can be used to locate the buddy. In either case, the technique needed is straightforward. The detailed algorithms and data representations required are well known.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US3681781 *||Sep 4, 1970||Aug 1, 1972||Goodyear Aerospace Corp||Storing and retrieval method|
|US4096567 *||Aug 13, 1976||Jun 20, 1978||Millard William H||Information storage facility with multiple level processors|
|US4240143 *||Dec 22, 1978||Dec 16, 1980||Burroughs Corporation||Hierarchical multi-processor network for memory sharing|
|US4257097 *||Dec 11, 1978||Mar 17, 1981||Bell Telephone Laboratories, Incorporated||Multiprocessor system with demand assignable program paging stores|
|US4290105 *||Apr 2, 1979||Sep 15, 1981||American Newspaper Publishers Association||Method and apparatus for testing membership in a set through hash coding with allowable errors|
|US4295124 *||Aug 13, 1979||Oct 13, 1981||National Semiconductor Corporation||Communication method and system|
|US4325120 *||Dec 21, 1978||Apr 13, 1982||Intel Corporation||Data processing system|
|US4468728 *||Jun 25, 1981||Aug 28, 1984||At&T Bell Laboratories||Data structure and search method for a data base management system|
|1||D. Comer, "The Ubiquitous B-Tree", Computing Surveys, vol. 11, No. 2, Jun. 1979.|
|2||*||D. Comer, The Ubiquitous B Tree , Computing Surveys, vol. 11, No. 2, Jun. 1979.|
|3||G. Martin, "Spiral Storage: Incrementally Augmentable Hash Addressed Storage", Theory of Computation, Report No. 27, U. of Warwick, Coventry, England, Mar. 1979.|
|4||*||G. Martin, Spiral Storage: Incrementally Augmentable Hash Addressed Storage , Theory of Computation, Report No. 27, U. of Warwick, Coventry, England, Mar. 1979.|
|5||J. L. Carter et al., "Universal Classes of Hash Functions", J. Computers and System Sciences, vol. 18, No. 2, Apr. 1979, pp. 143-144.|
|6||*||J. L. Carter et al., Universal Classes of Hash Functions , J. Computers and System Sciences, vol. 18, No. 2, Apr. 1979, pp. 143 144.|
|7||R. Fagin et al., "Extendible Hashing-A Fast Access Method for Dynamic Files", ACM Trans. Database Syst., vol. 4, No. 3, Sep. 1979, pp. 315-344.|
|8||*||R. Fagin et al., Extendible Hashing A Fast Access Method for Dynamic Files , ACM Trans. Database Syst., vol. 4, No. 3, Sep. 1979, pp. 315 344.|
|9||W. Litwin, "Linear Hashing: A New Tool for File and Table Addressing", Proc. 6th Int'l. Conf. on Very Large Databases, Montreal, 1980, pp. 212-223.|
|10||*||W. Litwin, Linear Hashing: A New Tool for File and Table Addressing , Proc. 6th Int l. Conf. on Very Large Databases, Montreal, 1980, pp. 212 223.|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US4774657 *||Jun 6, 1986||Sep 27, 1988||International Business Machines Corporation||Index key range estimator|
|US4800489 *||May 19, 1988||Jan 24, 1989||Motorola, Inc.||Paged memory management unit capable of selectively supporting multiple address spaces|
|US4807122 *||Apr 23, 1986||Feb 21, 1989||Mitsubishi Denki Kabushiki Kaisha||Information storage system|
|US4827462 *||Mar 26, 1987||May 2, 1989||International Business Machines Corporation||Modular data storage directories for large-capacity data storage units|
|US4864534 *||Oct 21, 1987||Sep 5, 1989||Alcatel N.V.||Apparatus and method for entering setting commands in a computer-controlled interlocking system|
|US4897785 *||Jun 17, 1988||Jan 30, 1990||Bbc Brown, Boveri & Company, Limited||Search system for locating values in a table using address compare circuit|
|US4945475 *||Nov 21, 1989||Jul 31, 1990||Apple Computer, Inc.||Hierarchical file system to provide cataloging and retrieval of data|
|US5047918 *||Dec 19, 1988||Sep 10, 1991||Tektronix, Inc.||File management system|
|US5058002 *||Jun 13, 1988||Oct 15, 1991||Mitsubishi Denki Kabushiki Kaisha||Page splitting method and apparatus for a database stored in a plurality of memory storage units|
|US5089952 *||Oct 7, 1988||Feb 18, 1992||International Business Machines Corporation||Method for allowing weak searchers to access pointer-connected data structures without locking|
|US5095423 *||Mar 27, 1990||Mar 10, 1992||Sun Microsystems, Inc.||Locking mechanism for the prevention of race conditions|
|US5119291 *||May 1, 1990||Jun 2, 1992||International Business Machines Corporation||Modular data storage directories for large-capacity data storage units wherein the index to the records in a sector is located in the next adjacent sector|
|US5199073 *||Oct 8, 1991||Mar 30, 1993||International Business Machines Corporation||Key hashing in data processors|
|US5202986 *||Sep 28, 1989||Apr 13, 1993||Bull Hn Information Systems Inc.||Prefix search tree partial key branching|
|US5204958 *||Jun 27, 1991||Apr 20, 1993||Digital Equipment Corporation||System and method for efficiently indexing and storing a large database with high data insertion frequency|
|US5218696 *||Sep 17, 1992||Jun 8, 1993||International Business Machines Corporation||Method for dynamically expanding and rapidly accessing file directories|
|US5257365 *||Mar 16, 1990||Oct 26, 1993||Powers Frederick A||Database system with multi-dimensional summary search tree nodes for reducing the necessity to access records|
|US5261088 *||Apr 26, 1990||Nov 9, 1993||International Business Machines Corporation||Managing locality in space reuse in a shadow written B-tree via interior node free space list|
|US5265244 *||Jun 22, 1990||Nov 23, 1993||International Business Machines Corporation||Method and system for facilitating processing of statistical inquires on stored data accessible through a data access structure|
|US5293595 *||Dec 17, 1990||Mar 8, 1994||Unisys Corporation||Paging system using extension tables for conflict resolution|
|US5307486 *||Jul 7, 1992||Apr 26, 1994||Kabushiki Kaisha Toshiba||Method for updating an index tree structure of data based on node sizes|
|US5307494 *||Feb 26, 1993||Apr 26, 1994||Fuji Xerox Co., Ltd.||File name length augmentation method|
|US5339398 *||Jul 14, 1992||Aug 16, 1994||North American Philips Corporation||Memory architecture and method of data organization optimized for hashing|
|US5339411 *||Oct 22, 1993||Aug 16, 1994||Pitney Bowes Inc.||Method for managing allocation of memory space|
|US5367672 *||Aug 2, 1991||Nov 22, 1994||Kabushiki Kaisha Toshiba||Apparatus for retrieving data using the remainder of a hashed search key to identify a group of keys and comparing the key to the group of keys|
|US5418947 *||Dec 23, 1992||May 23, 1995||At&T Corp.||Locating information in an unsorted database utilizing a B-tree|
|US5418949 *||Sep 30, 1993||May 23, 1995||Fujitsu Limited||Page map, metamap, and relation group file management supervised by operation means for allocating, storing, and searching friendly and exclusive data items|
|US5446881 *||Sep 25, 1992||Aug 29, 1995||At&T Corp.||Database storage and retrieval method using a declining stage size and repetitive searches|
|US5519858 *||Jan 10, 1992||May 21, 1996||Digital Equipment Corporation||Address recognition engine with look-up database for storing network information|
|US5613105 *||Jun 30, 1993||Mar 18, 1997||Microsoft Corporation||Efficient storage of objects in a file system|
|US5644791 *||May 11, 1994||Jul 1, 1997||International Business Machines Corporation||System for storing pointers to initial sectors of variable length n units and storing second pointers within the initial sector of the n unit|
|US5758353 *||Dec 1, 1995||May 26, 1998||Sand Technology Systems International, Inc.||Storage and retrieval of ordered sets of keys in a compact 0-complete tree|
|US5764877 *||Sep 1, 1995||Jun 9, 1998||Digital Equipment Corporation||Media recovery with time-split B-trees|
|US5806065 *||May 6, 1996||Sep 8, 1998||Microsoft Corporation||Data system with distributed tree indexes and method for maintaining the indexes|
|US5819280 *||Jan 30, 1996||Oct 6, 1998||Fujitsu Limited||Data structure determining method for hierarchically structured data corresponding to identifiers and apparatus thereof|
|US5893931 *||Jan 15, 1997||Apr 13, 1999||Fujitsu Limited||Lookaside buffer for address translation in a computer system|
|US5919247 *||Jul 24, 1996||Jul 6, 1999||Marimba, Inc.||Method for the distribution of code and data updates|
|US5930805 *||May 20, 1998||Jul 27, 1999||Sand Technology Systems International, Inc.||Storage and retrieval of ordered sets of keys in a compact 0-complete tree|
|US6105032 *||Jun 5, 1998||Aug 15, 2000||Ip-First, L.L.C.||Method for improved bit scan by locating a set bit within a nonzero data entity|
|US6189036||Nov 5, 1998||Feb 13, 2001||International Business Machines Corporation||User access to objects in group based access control based on result of greatest common divisor of assigned unique prime numbers of user and object|
|US6272536||Jan 13, 1999||Aug 7, 2001||Marimba, Inc.||System and method for the distribution of code and data|
|US6292795 *||Feb 16, 1999||Sep 18, 2001||International Business Machines Corporation||Indexed file system and a method and a mechanism for accessing data records from such a system|
|US6298339 *||Dec 18, 1998||Oct 2, 2001||Telefonaktiebolaget Lm Ericsson (Publ)||Management in data structures|
|US6349308 *||Feb 15, 1999||Feb 19, 2002||Korea Advanced Institute Of Science & Technology||Inverted index storage structure using subindexes and large objects for tight coupling of information retrieval with database management systems|
|US6427147||Aug 28, 1998||Jul 30, 2002||Sand Technology Systems International||Deletion of ordered sets of keys in a compact O-complete tree|
|US6629243 *||Oct 7, 1999||Sep 30, 2003||Nds Limited||Secure communications system|
|US6675173 *||Dec 30, 1999||Jan 6, 2004||Ori Software Development Ltd.||Database apparatus|
|US7054872 *||May 29, 2001||May 30, 2006||Oracle International Corporation||Online tracking and fixing of invalid guess-DBAs in secondary indexes and mapping tables on primary B+tree structures|
|US7058642||Mar 20, 2002||Jun 6, 2006||Intel Corporation||Method and data structure for a low memory overhead database|
|US7246102 *||Dec 21, 2001||Jul 17, 2007||Agere Systems Inc.||Method of improving the lookup performance of three-type knowledge base searches|
|US7287033||Mar 5, 2003||Oct 23, 2007||Ori Software Development, Ltd.||Efficient traversals over hierarchical data and indexing semistructured data|
|US7362870 *||Apr 17, 2002||Apr 22, 2008||Sony Corporation||Method and apparatus for recording/playing back information|
|US7443984||Apr 2, 2001||Oct 28, 2008||Sony Corporation||Information processing system and method for distributing encrypted message data|
|US7467151||Jan 25, 2006||Dec 16, 2008||Intel Corporation||Method and data structure for a low memory overhead database|
|US7533245||Aug 1, 2003||May 12, 2009||Illinois Institute Of Technology||Hardware assisted pruned inverted index component|
|US7899057||Apr 28, 2006||Mar 1, 2011||Jds Uniphase Corporation||Systems for ordering network packets|
|US8065308||Oct 12, 2007||Nov 22, 2011||Ori Software Development Ltd.||Encoding semi-structured data for efficient search and browsing|
|US8107822||Aug 26, 2008||Jan 31, 2012||Finisar Corporation||Protocols for out-of-band communication|
|US8213333||Jul 11, 2007||Jul 3, 2012||Chip Greel||Identifying and resolving problems in wireless device configurations|
|US8321375 *||Jan 19, 2005||Nov 27, 2012||Xanavi Informatics Corporation||Search data update method and search data update system|
|US8396858||Aug 11, 2011||Mar 12, 2013||International Business Machines Corporation||Adding entries to an index based on use of the index|
|US8489597||Sep 1, 2004||Jul 16, 2013||Ori Software Development Ltd.||Encoding semi-structured data for efficient search and browsing|
|US8526821||Dec 28, 2007||Sep 3, 2013||Finisar Corporation||Transceivers for testing networks and adapting to device changes|
|US8577939 *||Jan 31, 2012||Nov 5, 2013||Quantum Corporation||Method for reliable and efficient filesystem metadata conversion|
|US8583657 *||May 28, 2004||Nov 12, 2013||Oracle International Corporation||Method and apparatus for using a hash-partitioned index to access a table that is not partitioned or partitioned independently of the hash partitioned index|
|US9442840||Dec 19, 2012||Sep 13, 2016||Qualcomm Incorporated||Virtual boundary codes in a data image of a read-write memory device|
|US9684677 *||Aug 20, 2013||Jun 20, 2017||Quantum Corporation||Method for reliable and efficient filesystem metadata conversion|
|US20020060994 *||Nov 15, 2001||May 23, 2002||Erno Kovacs||Transmission of carry-on objects using a wireless ad-hoc networking environment|
|US20030120621 *||Dec 21, 2001||Jun 26, 2003||Mcdaniel Betty A.||Method of improving the lookup performance of tree-type knowledge base searches|
|US20030182291 *||Mar 20, 2002||Sep 25, 2003||Sreenath Kurupati||Method and data structure for a low memory overhead database|
|US20040019795 *||Apr 17, 2002||Jan 29, 2004||Takumi Okaue||Information recording/reproducing apparatus and method|
|US20050033733 *||Sep 1, 2004||Feb 10, 2005||Ori Software Development Ltd.||Encoding semi-structured data for efficient search and browsing|
|US20050251524 *||May 28, 2004||Nov 10, 2005||Vikram Shukla||Method and apparatus for using a hash-partitioned index to access a table that is not partitioned or partitioned independently of the hash partitioned index|
|US20060122989 *||Jan 25, 2006||Jun 8, 2006||Sreenath Kurupati||Method and data structure for a low memory overhead database|
|US20060198312 *||Feb 1, 2006||Sep 7, 2006||Schondelmayer Adam H||Network diagnostic systems and methods for altering the format and bandwidth of network messages|
|US20060198318 *||Feb 1, 2006||Sep 7, 2006||Schondelmayer Adam H||Network diagnostic systems and methods for statistical triggering|
|US20060198319 *||Feb 1, 2006||Sep 7, 2006||Schondelmayer Adam H||Network diagnostic systems and methods for aggregated links|
|US20060200711 *||Feb 1, 2006||Sep 7, 2006||Schondelmayer Adam H||Network diagnostic systems and methods for processing network messages|
|US20060264178 *||May 20, 2005||Nov 23, 2006||Noble Gayle L||Wireless diagnostic systems|
|US20070038880 *||Aug 15, 2005||Feb 15, 2007||Noble Gayle L||Network diagnostic systems and methods for accessing storage devices|
|US20070086351 *||Sep 29, 2006||Apr 19, 2007||Noble Gayle L||Resource Allocation Manager for Wireless Diagnostic Systems|
|US20070087741 *||Sep 29, 2006||Apr 19, 2007||Noble Gayle L||Diagnostic Device Having Wireless Communication Capabilities|
|US20070087771 *||Sep 29, 2006||Apr 19, 2007||Noble Gayle L||Test Access Point Having Wireless Communication Capabilities|
|US20070211697 *||Mar 13, 2007||Sep 13, 2007||Finisar Corporation||Method of analyzing network with generated traffic|
|US20070253402 *||Apr 28, 2006||Nov 1, 2007||Noble Gayle L||Systems and methods for ordering network messages|
|US20080065596 *||Oct 12, 2007||Mar 13, 2008||Ori Software Development Ltd.||Encoding semi-structured data for efficient search and browsing|
|US20080075103 *||Oct 31, 2007||Mar 27, 2008||Finisar Corporation||Diagnostic device|
|US20080097954 *||Oct 20, 2006||Apr 24, 2008||Microsoft Corporation||Ranged lookups|
|US20080159737 *||Dec 28, 2007||Jul 3, 2008||Finisar Corporation||Transceivers for testing networks and adapting to device changes|
|US20080228712 *||Jan 19, 2005||Sep 18, 2008||Xanavi Informatics Corporation||Search Data Update Method and Search Data Update System|
|US20100082636 *||Sep 25, 2008||Apr 1, 2010||Nec Laboratories America, Inc.||Methods and Apparatus for Content-Defined Node Splitting|
|US20110225215 *||Jun 8, 2010||Sep 15, 2011||Hitachi, Ltd.||Computer system and method of executing application program|
|US20120131063 *||Jan 31, 2012||May 24, 2012||Laberge Tim||Method for reliable and efficient filesystem metadata conversion|
|US20130339401 *||Aug 20, 2013||Dec 19, 2013||Quantum Corporation||Method for Reliable and Efficient Filesystem Metadata Conversion|
|US20140173187 *||Oct 23, 2013||Jun 19, 2014||Qualcomm Incorporated||Virtual boundary codes in a data image of a read-write memory device|
|CN100444157C||Mar 13, 2003||Dec 17, 2008||英特尔公司||Method and data structure for a low memory overhead database|
|EP0284037A2 *||Mar 23, 1988||Sep 28, 1988||International Business Machines Corporation||Modular data storage directories for large-capacity data storage units|
|EP0284037A3 *||Mar 23, 1988||Mar 3, 1993||International Business Machines Corporation||Modular data storage directories for large-capacity data storage units|
|EP2633413A4 *||Oct 4, 2011||Jan 18, 2017||Microsoft Technology Licensing Llc||Low ram space, high-throughput persistent key-value store using secondary memory|
|WO1990004829A2 *||Oct 23, 1989||May 3, 1990||Eastman Kodak Company||Object-oriented, logic, and database programming tool|
|WO1990004829A3 *||Oct 23, 1989||Dec 13, 1990||Eastman Kodak Co||Object-oriented, logic, and database programming tool|
|WO1991014993A1 *||Mar 26, 1991||Oct 3, 1991||Sun Microsystems, Inc.||Locking mechanism for the prevention of race conditions|
|WO2003081476A2 *||Mar 13, 2003||Oct 2, 2003||Intel Corporation||Method and data structure for a low memory overhead database|
|WO2003081476A3 *||Mar 13, 2003||Mar 25, 2004||Intel Corp||Method and data structure for a low memory overhead database|
|WO2012054223A2||Oct 4, 2011||Apr 26, 2012||Microsoft Corporation||Low ram space, high-throughput persistent key-value store using secondary memory|
|U.S. Classification||1/1, 707/E17.037, 707/999.003|
|International Classification||G06F7/22, G06F12/00, G06F17/30|
|Cooperative Classification||Y10S707/99933, G06F17/30952|
|Feb 3, 1983||AS||Assignment|
Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, ARMON
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST.;ASSIGNOR:LOMET, DAVID B.;REEL/FRAME:004092/0794
Effective date: 19830203
|Nov 2, 1989||FPAY||Fee payment|
Year of fee payment: 4
|Jan 10, 1994||FPAY||Fee payment|
Year of fee payment: 8
|Mar 31, 1998||REMI||Maintenance fee reminder mailed|
|Sep 6, 1998||LAPS||Lapse for failure to pay maintenance fees|
|Nov 17, 1998||FP||Expired due to failure to pay maintenance fee|
Effective date: 19980909