|
|
|
FairCom DB supports a number of basic key types:
Legacy key compression options:
The key type is set using the ikeytyp member of the IIDX Structure.
Normally you will use fixed-length keys.
FairCom DB offers 2 types of legacy key compression controlled by the IIDX.ikeytyp bits, COL_LEADING(0x04) and COL_PADDING(0x08), which may be combined. These can provide good compression within index nodes, but with the following major limitations:
In V12, support was added for true variable length keys that can provide key compression without the above limitations.
[01/2024]There are currently two recommended compression modes that provide support for variable length keys:
Use this for indexes over variable length fields (such as street address or file system paths) that may have a lot of variation in the length of the last index segment. This eliminates the key padding bytes on disk without the high performance costs of the legacy COL_SUFFIX (0x08) key compression. Anyone using the legacy padding compression (or COL_BOTH) should investigate this improved alternative.
This is suggested for indexes over fixed or variable length fields that may have a lot of repeating binary 0, ASCII space (0x20), or ASCII '0' values. Potential examples that may get good compression are 8 byte integers, UNICODE keys, padded binary or string data.
Legacy Key Compression Details:
If there is a reasonable amount of duplication in the leading characters of the key values, you can decrease the size of your index file by choosing leading-character compression. If your key lengths vary in size you may find that padding compression will decrease your index size (remember that you should be padding keys to the same length). Key type 0x0C (COL_BOTH) combines both types of compression. With compound (multi-segment) keys, c-tree builds the complete key value (for keylen bytes), then applies the compression logic. For this reason, only the last segment can be compressed.
Using one or both of the compression modes increases the CPU time to process a key since the key values must be compressed and expanded, and the key values cannot be located at fixed positions within the node. The increased CPU time is eventually offset by the reduced disk head movement due to the reduced size of the index. As the index grows, the compression can lead to fewer levels in the tree structure, compared with a fixed-length tree, because of the increase in branching, due to more keys in each node. A reduction in the number of levels leads directly to a reduction in the number of disk accesses.
Note: Key compression imposes a significant performance impact, especially when deleting records. Use this feature only when absolutely necessary to keep index space requirements to a minimum.
Leading character compression and padding compression each require a byte to store the extent of the compression. The maximum key length compressed is restricted to 255. Keys of greater length will only have compression applied to the leading and/or trailing 255 bytes. Further, employing the compression modes when no compression is possible will cause wasted storage since the bytes used to note the extent of the compression will be stored in addition to the key values.
The default padding character is an ASCII blank (0x20). This can be changed for a particular index file by using the SetVariableBytes() function. See SetVariableBytes for more details.
