1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
|
Count the number of set bits (population counting) in a string.
By default all the bytes contained in the string are examined. It is possible to
specify the counting operation only in an interval passing the additional
arguments _start_ and _end_.
Like for the `GETRANGE` command start and end can contain negative values in
order to index bytes starting from the end of the string, where -1 is the last
byte, -2 is the penultimate, and so forth.
Non-existent keys are treated as empty strings, so the command will return zero.
@return
@integer-reply
The number of bits set to 1.
@examples
```cli
SET mykey "foobar"
BITCOUNT mykey
BITCOUNT mykey 0 0
BITCOUNT mykey 1 1
```
## Pattern: real-time metrics using bitmaps
Bitmaps are a very space-efficient representation of certain kinds of
information. One example is a Web application that needs the history of user
visits, so that for instance it is possible to determine what users are good
targets of beta features.
Using the `SETBIT` command this is trivial to accomplish, identifying every day
with a small progressive integer. For instance day 0 is the first day the
application was put online, day 1 the next day, and so forth.
Every time a user performs a page view, the application can register that in the
current day the user visited the web site using the `SETBIT` command setting the
bit corresponding to the current day.
Later it will be trivial to know the number of single days the user visited the
web site simply calling the `BITCOUNT` command against the bitmap.
A similar pattern where user IDs are used instead of days is described in the
article called "[Fast easy realtime metrics using Redis
bitmaps][hbgc212fermurb]".
[hbgc212fermurb]:
http://blog.getspool.com/2011/11/29/fast-easy-realtime-metrics-using-redis-bitmaps
## Performance considerations
In the above example of counting days, even after 10 years the application is
online we still have just `365*10` bits of data per user, that is just 456 bytes
per user. With this amount of data `BITCOUNT` is still as fast as any other O(1)
Redis command like `GET` or `INCR`.
When the bitmap is big, there are two alternatives:
- Taking a separated key that is incremented every time the bitmap is modified.
This can be very efficient and atomic using a small Redis Lua script.
- Running the bitmap incrementally using the `BITCOUNT` _start_ and _end_
optional parameters, accumulating the results client-side, and optionally
caching the result into a key.
|
