Binary State Statistics with Redis Bitmap: Efficient User Login and Sign‑In Tracking

In mobile application scenarios we often need to store a key associated with a collection of data, such as determining a user’s login status, showing a user’s monthly sign‑in count and first sign‑in time, or counting users who have signed in continuously over the past seven days.

Because the number of users and access volume can reach millions or even hundreds of millions, we must choose a collection type that can efficiently handle such massive data.

Understanding common statistical patterns and applying appropriate data types is the first step to solving these problems.

Four statistical types are introduced: binary state statistics, aggregate statistics, sorted statistics, and cardinality statistics.

The article focuses on the binary state statistics as the first practical example, using Redis Bitmap instead of the usual String , Set , Zset , List , or hash types.

All commands can be tested via the online Redis client at https://try.redis.io/.

Binary State Statistics

Binary state statistics mean that each element in a collection can only be 0 or 1, which is ideal for login status (online/offline) or sign‑in (signed/not signed) scenarios.

Using a Redis String to store one million users’ login status would require one million separate strings, consuming excessive memory.

Redis String objects use the SDS (Simple Dynamic String) structure, which adds extra overhead for length, allocation, and a terminating byte.

Additionally, each Redis object carries a RedisObject header that stores metadata such as last access time and reference count.

For binary state scenarios, a Bitmap can represent each user with a single bit, so 100 million users only need about 12 MB of memory.

Space ≈ ($offset / 8 / 1024 / 1024) MB

A Bitmap is stored internally as an SDS string where each byte’s 8 bits are used to represent individual elements. The offset (index) identifies the bit position.

Bitmap operations include GETBIT and SETBIT , which read or write a bit at a given offset (starting from 0).

Determining User Login State

Use a single key, e.g., login_status , where the user ID is the offset; set the bit to 1 for online and 0 for offline. For 500 million users this only requires about 6 MB.

SETBIT command

SETBIT

GETBIT command

GETBIT

Example: mark user 10086 as logged in and then check the status.

SETBIT login_status 10086 1
GETBIT login_status 10086
SETBIT login_status 10086 0

User Monthly Sign‑In Tracking

Each day’s sign‑in is stored as one bit; a month needs at most 31 bits. Use a key pattern like uid:sign:{userId}:{yyyyMM} where offset = day‑1 .

SETBIT uid:sign:89757:202105 15 1   // record sign‑in on May 16
GETBIT uid:sign:89757:202105 15   // check sign‑in
BITCOUNT uid:sign:89757:202105    // count total sign‑ins in May

To find the first sign‑in day, use BITPOS :

BITPOS uid:sign:89757:202105 1

Add 1 to the returned offset because offsets start at 0.

Counting Users with Continuous Sign‑Ins

Store each day’s sign‑in bitmap with the date as the key and user ID as the offset. Perform a bitwise AND across the seven daily bitmaps using BITOP AND to produce a bitmap of users who signed in all seven days, then count the set bits with BITCOUNT .

// AND operation
BITOP AND destmap bitmap:01 bitmap:02 bitmap:03
// Count bits set to 1
BITCOUNT destmap

A 100 million‑bit bitmap occupies roughly 12 MB; seven such bitmaps need about 84 MB. Setting an expiration on these keys helps reclaim memory.

Summary

When the statistical scenario only requires binary states (e.g., user existence, IP blacklist, sign‑in tracking), using a Redis Bitmap can dramatically reduce memory consumption, as a single bit can represent each element.

Thus, binary state statistics with Bitmap are a powerful technique for handling massive data efficiently.