Commit | Line | Data |
---|---|---|
81b62568 KB |
1 | .\" Copyright (c) 1990, 1993 |
2 | .\" The Regents of the University of California. All rights reserved. | |
f52ca292 | 3 | .\" |
ad787160 C |
4 | .\" Redistribution and use in source and binary forms, with or without |
5 | .\" modification, are permitted provided that the following conditions | |
6 | .\" are met: | |
7 | .\" 1. Redistributions of source code must retain the above copyright | |
8 | .\" notice, this list of conditions and the following disclaimer. | |
9 | .\" 2. Redistributions in binary form must reproduce the above copyright | |
10 | .\" notice, this list of conditions and the following disclaimer in the | |
11 | .\" documentation and/or other materials provided with the distribution. | |
12 | .\" 3. All advertising materials mentioning features or use of this software | |
13 | .\" must display the following acknowledgement: | |
14 | .\" This product includes software developed by the University of | |
15 | .\" California, Berkeley and its contributors. | |
16 | .\" 4. Neither the name of the University nor the names of its contributors | |
17 | .\" may be used to endorse or promote products derived from this software | |
18 | .\" without specific prior written permission. | |
f52ca292 | 19 | .\" |
ad787160 C |
20 | .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND |
21 | .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE | |
22 | .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE | |
23 | .\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE | |
24 | .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL | |
25 | .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS | |
26 | .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) | |
27 | .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT | |
28 | .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY | |
29 | .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF | |
30 | .\" SUCH DAMAGE. | |
f52ca292 | 31 | .\" |
ed554bc5 | 32 | .\" @(#)btree.3 8.3 (Berkeley) 2/21/94 |
ad787160 | 33 | .\" |
ed554bc5 | 34 | .TH BTREE 3 "February 21, 1994" |
c38379a5 | 35 | .\".UC 7 |
f52ca292 KB |
36 | .SH NAME |
37 | btree \- btree database access method | |
38 | .SH SYNOPSIS | |
39 | .nf | |
40 | .ft B | |
41 | #include <sys/types.h> | |
42 | #include <db.h> | |
43 | .ft R | |
44 | .fi | |
45 | .SH DESCRIPTION | |
46 | The routine | |
47 | .IR dbopen | |
48 | is the library interface to database files. | |
49 | One of the supported file formats is btree files. | |
50 | The general description of the database access methods is in | |
51 | .IR dbopen (3), | |
52 | this manual page describes only the btree specific information. | |
53 | .PP | |
54 | The btree data structure is a sorted, balanced tree structure storing | |
55 | associated key/data pairs. | |
56 | .PP | |
57 | The btree access method specific data structure provided to | |
58 | .I dbopen | |
59 | is defined in the <db.h> include file as follows: | |
60 | .PP | |
61 | typedef struct { | |
62 | .RS | |
63 | u_long flags; | |
64 | .br | |
65 | u_int cachesize; | |
66 | .br | |
ad787160 | 67 | int maxkeypage; |
f52ca292 KB |
68 | .br |
69 | int minkeypage; | |
70 | .br | |
85dcccdd | 71 | u_int psize; |
ad787160 | 72 | .br |
f52ca292 KB |
73 | int (*compare)(const DBT *key1, const DBT *key2); |
74 | .br | |
85dcccdd | 75 | size_t (*prefix)(const DBT *key1, const DBT *key2); |
ad787160 C |
76 | .br |
77 | int lorder; | |
f52ca292 KB |
78 | .RE |
79 | } BTREEINFO; | |
80 | .PP | |
81 | The elements of this structure are as follows: | |
82 | .TP | |
83 | flags | |
84 | The flag value is specified by | |
85 | .IR or 'ing | |
86 | any of the following values: | |
87 | .RS | |
88 | .TP | |
89 | R_DUP | |
d6d37eec KB |
90 | Permit duplicate keys in the tree, i.e. permit insertion if the key to be |
91 | inserted already exists in the tree. | |
92 | The default behavior, as described in | |
4e3894e7 | 93 | .IR dbopen (3), |
d6d37eec KB |
94 | is to overwrite a matching key when inserting a new key or to fail if |
95 | the R_NOOVERWRITE flag is specified. | |
96 | The R_DUP flag is overridden by the R_NOOVERWRITE flag, and if the | |
c38379a5 | 97 | R_NOOVERWRITE flag is specified, attempts to insert duplicate keys into |
d6d37eec KB |
98 | the tree will fail. |
99 | .IP | |
c38379a5 KB |
100 | If the database contains duplicate keys, the order of retrieval of |
101 | key/data pairs is undefined if the | |
102 | .I get | |
103 | routine is used, however, | |
104 | .I seq | |
105 | routine calls with the R_CURSOR flag set will always return the logical | |
106 | ``first'' of any group of duplicate keys. | |
f52ca292 KB |
107 | .RE |
108 | .TP | |
109 | cachesize | |
110 | A suggested maximum size (in bytes) of the memory cache. | |
111 | This value is | |
112 | .B only | |
113 | advisory, and the access method will allocate more memory rather than fail. | |
114 | Since every search examines the root page of the tree, caching the most | |
115 | recently used pages substantially improves access time. | |
116 | In addition, physical writes are delayed as long as possible, so a moderate | |
117 | cache can reduce the number of I/O operations significantly. | |
118 | Obviously, using a cache increases (but only increases) the likelihood of | |
119 | corruption or lost data if the system crashes while a tree is being modified. | |
120 | If | |
121 | .I cachesize | |
122 | is 0 (no size is specified) a default cache is used. | |
123 | .TP | |
ad787160 | 124 | maxkeypage |
8c94657b KB |
125 | The maximum number of keys which will be stored on any single page. |
126 | Not currently implemented. | |
8b4acb9e KB |
127 | .\" The maximum number of keys which will be stored on any single page. |
128 | .\" Because of the way the btree data structure works, | |
129 | .\" .I maxkeypage | |
130 | .\" must always be greater than or equal to 2. | |
131 | .\" If | |
132 | .\" .I maxkeypage | |
133 | .\" is 0 (no maximum number of keys is specified) the page fill factor is | |
134 | .\" made as large as possible (which is almost invariably what is wanted). | |
f52ca292 KB |
135 | .TP |
136 | minkeypage | |
137 | The minimum number of keys which will be stored on any single page. | |
138 | This value is used to determine which keys will be stored on overflow | |
139 | pages, i.e. if a key or data item is longer than the pagesize divided | |
140 | by the minkeypage value, it will be stored on overflow pages instead | |
141 | of in the page itself. | |
142 | If | |
143 | .I minkeypage | |
144 | is 0 (no minimum number of keys is specified) a value of 2 is used. | |
145 | .TP | |
8c94657b KB |
146 | psize |
147 | Page size is the size (in bytes) of the pages used for nodes in the tree. | |
148 | The minimum page size is 512 bytes and the maximum page size is 64K. | |
149 | If | |
150 | .I psize | |
151 | is 0 (no page size is specified) a page size is chosen based on the | |
152 | underlying file system I/O block size. | |
153 | .TP | |
f52ca292 KB |
154 | compare |
155 | Compare is the key comparison function. | |
156 | It must return an integer less than, equal to, or greater than zero if the | |
157 | first key argument is considered to be respectively less than, equal to, | |
158 | or greater than the second key argument. | |
159 | The same comparison function must be used on a given tree every time it | |
160 | is opened. | |
161 | If | |
162 | .I compare | |
163 | is NULL (no comparison function is specified), the keys are compared | |
164 | lexically, with shorter keys considered less than longer keys. | |
165 | .TP | |
166 | prefix | |
167 | Prefix is the prefix comparison function. | |
168 | If specified, this routine must return the number of bytes of the second key | |
169 | argument which are necessary to determine that it is greater than the first | |
170 | key argument. | |
171 | If the keys are equal, the key length should be returned. | |
172 | Note, the usefulness of this routine is very data dependent, but, in some | |
173 | data sets can produce significantly reduced tree sizes and search times. | |
174 | If | |
175 | .I prefix | |
176 | is NULL (no prefix function is specified), | |
177 | .B and | |
178 | no comparison function is specified, a default lexical comparison routine | |
179 | is used. | |
180 | If | |
181 | .I prefix | |
182 | is NULL and a comparison routine is specified, no prefix comparison is | |
183 | done. | |
8c94657b KB |
184 | .TP |
185 | lorder | |
186 | The byte order for integers in the stored database metadata. | |
187 | The number should represent the order as an integer; for example, | |
188 | big endian order would be the number 4,321. | |
189 | If | |
190 | .I lorder | |
191 | is 0 (no order is specified) the current host order is used. | |
f52ca292 KB |
192 | .PP |
193 | If the file already exists (and the O_TRUNC flag is not specified), the | |
194 | values specified for the parameters flags, lorder and psize are ignored | |
195 | in favor of the values used when the tree was created. | |
196 | .PP | |
197 | Forward sequential scans of a tree are from the least key to the greatest. | |
198 | .PP | |
199 | Space freed up by deleting key/data pairs from the tree is never reclaimed, | |
200 | although it is normally made available for reuse. | |
201 | This means that the btree storage structure is grow-only. | |
202 | The only solutions are to avoid excessive deletions, or to create a fresh | |
203 | tree periodically from a scan of an existing one. | |
204 | .PP | |
205 | Searches, insertions, and deletions in a btree will all complete in | |
206 | O lg base N where base is the average fill factor. | |
207 | Often, inserting ordered data into btrees results in a low fill factor. | |
208 | This implementation has been modified to make ordered insertion the best | |
209 | case, resulting in a much better than normal page fill factor. | |
210 | .SH "SEE ALSO" | |
211 | .IR dbopen (3), | |
212 | .IR hash (3), | |
213 | .IR mpool (3), | |
214 | .IR recno (3) | |
48c2722a | 215 | .sp |
f52ca292 KB |
216 | .IR "The Ubiquitous B-tree" , |
217 | Douglas Comer, ACM Comput. Surv. 11, 2 (June 1979), 121-138. | |
48c2722a KB |
218 | .sp |
219 | .IR "Prefix B-trees" , | |
220 | Bayer and Unterauer, ACM Transactions on Database Systems, Vol. 2, 1 | |
221 | (March 1977), 11-26. | |
222 | .sp | |
f52ca292 KB |
223 | .IR "The Art of Computer Programming Vol. 3: Sorting and Searching" , |
224 | D.E. Knuth, 1968, pp 471-480. | |
225 | .SH BUGS | |
226 | Only big and little endian byte order is supported. |