Algorithms and Data Structures for External Memory

106 Spatial Data Structures and Range Search
Table 12.1 Summary of the costs (in number of I/Os) for R-tree updates and queries.
Packing refers to the percentage storage utilization.
Update with 50% of the data
Data set Update method Building Querying Packing (%)
RI
CT
NJ
NY
Naive
Hilbert
Buffer
Naive
Hilbert
Buffer
Naive
Hilbert
Buffer
Naive
Hilbert
Buffer
259,263
15,865
13,484
805,749
51,086
42,774
1,777,570
120,034
101,017
3,736,601
246,466
206,921
6,670
7,262
5,485
40,910
40,593
37,798
70,830
69,798
65,898
224,039
230,990
227,559
600, 1,250, and 5,000 rectangles, respectively; buffer size 0 corresponds
to the naive method and the larger buffers correspond to the buffer
method. The query performance of each resulting R-tree was measured
by posing rectangle intersection queries using rectangles taken
from TIGER hydrographic data. The results, depicted in Figure 12.2,
show that buffer R*-trees, even with relatively small buffers, achieve a
tremendous speedup in number of I/Os for construction without any
worsening in query performance, compared with the naive method. The
CPU costs of the two methods are comparable. The storage utilization
of buffer R*-trees tends to be in the 90% range, as opposed to roughly
70% for the naive method.
Bottom-up methods can build R-trees even more quickly and more
compactly, but they generally do not support bulk dynamic operations,
which is a big advantage of the buffer tree approach. Kamel
et al. [208] develop a way to do bulk updates with Hilbert R-trees, but
at a cost in terms of query performance. Table 12.1 compares dynamic
update methods for the naive method, for buffer R-trees, and for Hilbert
R-trees [208] (labeled “Hilbert”). A single R-tree was built for each of
the four US states, containing 50% of the road data objects for that
state. Using each of the three algorithms, the remaining 50% of the
objects were inserted into the R-tree, and the construction time was
64
92
90
66
92
90
66
92
91
66
92
90