Hi Pat,
The known issues with using a primitive BLOB for storage are these:
- Binary BLOB or String SLOB types are contiguous areas of memory in object cache and interpreter string pools
- Storing and retrieving primitive BLOB and SLOB data can replace other objects in cache – this is generally detrimental
The benefits of using JadeBytes are:
- The amount of data a JadeBytes instance can contain is not limited by the size of object cache or by process virtual memory requirements
- Provides efficient piecewise sequential and random access to the content
- JadeBytes instances can be stored and retrieved without displacing other objects cached by a node
JadeBytes objects are stored in a separate file. The physical representation on disk is intended to offer better performance for storing and retrieving large instances of arbitrary length data than is provided with the legacy BLOB format. BLOB/SLOB data is stored as a linked list of max 16K segments and the tail segment can be any multiple of 64 bytes of content plus header. JadeBytes use up to 256K segments and the tail segment is a power of two multiple. As a result of the restricted range of segment sizes free-space manages can be more efficient than that used to manage arbitrary size free-space in a standard .dat file.
Another advantage to having exclusive JadeBytes objects in their own file is that if the parent class is reorged only the parent .dat file is processed during the reorg, and this can reduce elapsed time significantly.
The JadeBytes data structures are primarily optimised for performance not space. If you are storing a large number of small instances, then the space used is likely to be greater than that used by storing the same data in a binary property.
Regards,