Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
The motivation for this new commands is to be search in the usage of Redis for real time statistics. See the article "Fast real time metrics using Redis". http://blog.getspool.com/2011/11/29/fast-easy-realtime-metrics-using-redis-bitmaps/ In general Redis strings when used as bitmaps using the SETBIT/GETBIT command provide a very space-efficient and fast way to store statistics. For instance in a web application with users, every user can be associated with a key that shows every day in which the user visited the web service. This information can be really valuable to extract user behaviour information. With Redis bitmaps doing this is very simple just saying that a given day is 0 (the data the service was put online) and all the next days are 1, 2, 3, and so forth. So with SETBIT it is possible to set the bit corresponding to the current day every time the user visits the site. It is possible to take the count of the bit sets on the run, this is extremely easy using a Lua script. However a fast bit count native operation can be useful, especially if it can operate on ranges, or when the string is small like in the case of days (even if you consider many years it is still extremely little data). For this reason BITOP was introduced. The command counts the number of bits set to 1 in a string, with optional range: BITCOUNT key [start end] The start/end parameters are similar to GETRANGE. If omitted the whole string is tested. Population counting is more useful when bit-level operations like AND, OR and XOR are avaialble. For instance I can test multiple users to see the number of days three users visited the site at the same time. To do this we can take the AND of all the bitmaps, and then count the set bits. For this reason the BITOP command was introduced: BITOP [AND|OR|XOR|NOT] dest_key src_key1 src_key2 src_key3 ... src_keyN In the special case of NOT (that inverts the bits) only one source key can be passed. The judicious use of BITCOUNT and BITOP combined can lead to interesting use cases with very space efficient representation of data. The implementation provided is still not tested and optimized for speed, next commits will introduce unit tests. Later the implementation will be profiled to see if it is possible to gain an important amount of speed without making the code much more complex.
- Loading branch information
9ee55e8
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Imho there is inconsistence in handling and bitop. It's expected (and for XOR/OR it's true), that if one of arguments is shorted than the other ones, missing bytes are handled as bytes with 0x00 val (so they don't change operation). But that doesn't hold for AND. Example: Let have 3 variables in hexa: var1= 0x01; var2 = 0x0101; var3 0x0101. Currently answer to calling and over those 3 vars is 0x0101. But I will say that if we expect, that unset bytes have effect of zero byte, than answer should be 0x0100 (as the var1 is only one byte). Another possibility for AND would be to cut the resulting string to the length of the shortest argument of AND, that can be also expected. But I will prefer the solution where missing bytes are taken as 0 bytes (-> bytes between the length of shortest and longest argument are zeroed-out)
9ee55e8
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @anydot, I don't follow you on that:
The answer is 0100 as you would expect. I'm missing something? Admittedly read the message in a hurry.
9ee55e8
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I hadn't tried it myself and I managed to misinterpret part of code :-( -> everything is fine, AND works as expected.
9ee55e8
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No prob thank you for your comment, btw I just implemented tests (still to be committed) and indeed with fuzzing everything is working as expected. Commit soon.