Redis list different encoding types cause memory footprint and operational efficiency differences

1. Introduction

It is well known that the list in Redis has two coding structures, ziplist and LinkedList. The switching of the two encoding structures is determined by the following configuration information:

The two configurations above are the default configurations.

For the above configuration, when all string elements held by a list object are less than 64 bytes in length, and the list object holds fewer than 512 elements, lists use ziplist encoding, which is not sufficient for either case or LinkedList encoding.

Ziplist is characterized by memory savings, LinkedList is a two-way list, characterized by a fast insertion speed, but memory.

2. Measurement

The official beginning of the main thing I want to publish today, although not a great thing, but it is my serious test results, leave a souvenir.

Test method:

A. A key, respectively, the Rpush, Lrange, LTrim three kinds of operation;

B. The rpush data is 80W integer, and the average insertion rate is recorded at the time of each 10W entry;

C. Lrange every 10W record to see the elapsed time;

D. After all the data has been successfully updated, test the LTrim;

E. Two coding structures are tested for comparison;

Here are the test results:

( the table is not good to paste, directly )

About Ziplist and LinkedList memory consumption, 80W of data, ziplist occupy less than 5M of memory, and linked occupy memory for 37m+, memory consumption is 7 times times more than.

3. Test machine configuration (non-professional introduction, make a look at it):

Cpu:24 Core Intel (R) Xeon (r) CPU e5-2643 v2 @ 3.50GHz

Memory: 128G

System: CentOS Release 6.6 (Final)

Redis list different encoding types cause memory footprint and operational efficiency differences