Product Documentation

FairCom ISAM for C

Previous Topic

Next Topic

Alternative Key Types

FairCom DB supports a number of basic key types:

  • Fixed-length keys (0)
  • Do not allow an ISAM update to change the key value - KTYP_NOISMKEYUPD (0x80)
  • Variable length keys with padding compression - KTYP_VLENGTH (0x608)
  • Variable length keys with simple RLE key compression - KTYP_VLENGTH_SRLE (0xE00)

    Legacy key compression options:

  • Leading-character compression COL_PREFIX (0x04)
  • Padding compression COL_SUFFIX (0x08)
  • Leading/padding compression COL_BOTH (0x0C)

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:

  • Deleted nodes using these modes may not be reclaimed. This could lead to performance issues on indexes with many updates/deletes.
  • The compression algorithms could impart a significant CPU cost on key operations, especially for larger node sizes (PAGE_SIZE).
  • For indexes under transaction control (ctPREIMG or ctTRNLOG) leaf nodes are limited to the same maximum number of keys as a non-compressed index, but still incur the above performance degradation. Only the internal nodes of the index provide any file system space savings.

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:

  1. IIDX.ikeytyp = KTYP_VLENGTH (0x0608)

    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.

  2. IIDX.ikeytyp = KTYP_VLENGTH_SRLE (0x0E00)

    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.

In This Section

Fixed Length Keys

Leading Character Compression Keys

Padding Compression Keys

Combined Compression Keys

KTYP_NOISMKEYUPD mode prevents ISAM record update from changing index key value

Variable-Length Key Compression