Like the ziplist for LISTs, HASHes, and ZSETs, there’s also a compact representation
for short SETs. If our SET members can all be interpreted as base-10 integers within
the range of our platform’s signed long integer, and our SET is short enough
(we’ll get to that in a moment), Redis will store our SET as a sorted array of integers,
By storing a SET as a sorted array, not only do we have low overhead, but all of the
standard SET operations can be performed quickly. But how big is too big? The next
listing shows the configuration option for defining an intset’s maximum size.
As long as we keep our SETs of integers smaller than our configured size, Redis will
use the intset representation to reduce data size. The following listing shows what happens
when an intset grows to the point of being too large.
Earlier, in the introduction to section 9.1, I mentioned that to read or update part of
an object that uses the compact ziplist representation, we may need to decode the
entire ziplist, and may need to move in-memory data around. For these reasons,
reading and writing large ziplist-encoded structures can reduce performance. Intsetencoded
SETs also have similar issues, not so much due to encoding and decoding
the data, but again because we need to move data around when performing insertions
and deletions. Next, we’ll examine some performance issues when operating
with long ziplists.
TRY REDIS ENTERPRISE CLOUD FREE
Redis Enterprise Cloud provides complete automation of day-to-day database operations. Start now with 30MB of free storage.