HP Large Objects System Management Manual

HP Large Objects System Management Manual – 543599.001
4.2.2 Storing and Retrieving Partial Objects
The Large Object system allows the calling application to store and retrieve objects in
chunks, as opposed to storing full content with one call to PutBuddyObject, as
described in the previous section.
To store an object in chunks, the space must first be allocated using
AllocateBuddyObject. It is then possible to write the object in chunks by using many
calls to the PutBuddyObject API. This is achieved using the objectId supplied by
AllocateBuddyObject, the offset, and the length of the chunk to be stored. The
chunks may be stored in any order, and at any time. It is therefore the responsibility
of the calling application to ensure that only chunks that have been successfully
written are read back.
To retrieve an object in chunks, the calling application may call GetBuddyObject
many times, supplying the offset and length of the desired chuck to be returned.
4.2.3 Storage Algorithms
There are basically two algorithms that are used for storing objects within Buddy Sets.
They can be decided through run-time decisions driven by the values of relevant
parameters in the parm table. These algorithms either aim for the best performance
(as measured by both CPU time and pathlength.) or optimize disk storage. Parameter
321 has the most significant impact on how the object is stored (see Appendix B).
4.2.4 Best Performance
In this algorithm, object content is stored in one Buddy Space. The storage algorithm
calculates the segment size that is just larger than the object to be stored. For
example, if the object to be stored is 5123 bytes, then it is stored in an 8 kilobytes
segment. The result is a request to find a Buddy Space with a power of 2 of 13. In
this case, there are (8192-5123) = 3069 bytes of wasted disk space at the end of the 8
kilobytes segment used to store the object; that is, about 37%.
When the object to be stored is larger than the largest segment available, then the
object is split up and stored in multiple segments within the BuddySpace with the
maximum segment size. In some instances, these segments are contiguous within the
BuddySpace, but over time, it is more probable that the segments are not contiguous.
For example, if a large multi-media file of 5 megabytes needs to be stored, and the
largest segment size available is approximately 1 megabyte (power of 2 is 20), then 6
segments are used within the chosen BuddySpace. The first 5 segments are fully
utilized, each storing 917504 bytes, but there are 655,360 bytes remaining to be stored
in the last segment, wasting about 29% of that specific segment.
The advantage of this selection algorithm is that the object is stored in one write
operation (except as described in the previous paragraph for Large Objects that
require multiple segments to be stored), which makes efficient use of the NSK disk
subsystem. The disadvantage is that an object rarely fits exactly into a segment, and
so space is wasted. The worst case is an object that is just one byte larger than any
specific segment size forcing it into the next power of two segment size. This wastes
50% of the space of that segment. Therefore, the average space wasted is around 25%.
Page 29 of 37