Redis design and implementation-Chapter7 compression list

Chapter7 Compression List

One of the underlying implementations of the list key and hash keys (the list key contains only a few elements, and the elements are small integers or shorter strings, and the hash keys contain a small number of key-value pairs, and the key and value for each key-value pair are small integers or shorter strings).

In order to save memory.

The composition of the compression list

A sequence of sequential (sequential) data structures consisting of a series of specially coded contiguous blocks of memory, containing multiple nodes entry, each entry holding a byte array or an integer.

Memory Organization:

Specific meaning:

The composition of a compressed list node

Each node holds a byte array or an integer value consisting of Previous_entry_length, encoding, and content three parts.

The saved byte array can be one of the following three lengths:

1. byte array with a length of less than or equal to 63 (2^{6}-1) bytes;

2. byte array with a length of less than or equal to 16383 (2^{14}-1) bytes;

3. byte array with a length of less than or equal to 4294967295 (2^{32}-1) bytes;

The integer value can be one of the following six lengths:

1. 4-bit long, unsigned integer between 0 and 12;

2. 1-byte long signed integer;

3. 3-byte long signed integer;

4. int16_t type integer;

5. int32_t type integer;

6. An integer of type int64_t.

Node Memory organization:

Specific meaning:

• Previous_entry_length: The length byte of the previous node entry, which corresponds to the forward pointer;

• Length: 1 or 5 bytes

• The previous node has a length of <254:1 bytes;

• The previous node has a length of >=254:5 bytes, and the first byte is set to 0xFE (that is, 254), and the last 4 bytes hold the true length data;

• Encoding: The type and length of data held by the content property of a node, based on byte data and integer data types, can be interpreted as follows

• Content: Saves the node's true data, which is determined by the encoding attribute;
  

Chain Update issues

Special cases:

• Insert: Multiple contiguous, 250~253 bytes directly from the E1 to En (previous_entry_length attribute is 1 bytes), when inserting a node of length >=254 bytes before E1, you need to update E1 PREVIOUS_ The Entry_length attribute (changed from 1 bytes to 5 bytes) causes the e1 length to >=254, so the chain updates E2, E3...en.

• Delete: After two nodes big (length >=254) and small (length <254) followed by multiple contiguous, 250~253 bytes directly from the node E1 to En (previous_entry_length attribute is 1 bytes) At this point, delete small, you need to update the E1 Previous_entry_length property (from 1 bytes to 5 bytes), resulting in E1 length >=254, so chain update E2, E3...en.

Cascading updates in the worst case, you need to do N-space redistribution of the compression list, and the worst complexity for each allocation is O (N), so the worst case for cascading updates is O (n^2). But the foreseeable effect on performance is small:

1. The probability of occurrence of the above two cases is very small;

2. Even if there are not many nodes updated, the performance will not affect;

Redis design and implementation-Chapter7 compression list