Skip to content

Conversation

@msaffitz
Copy link
Contributor

If you use a bitop against a frequently changing bitmap, the multi can be cancelled because the underlying key tracked by watch will change and invalidate the transaction. The bitop will then return invalid results (0). This removes the transaction block. Unknown if this is dangerous if the bitmap is in the process of being copied. Causes bitops to not be strongly consistent.

This also pipelines bit operations to increase speed. In testing large bitmaps saw a ~50x increase in speed
by pipelining operations.

If you use a bitop against a frequently changing bitmap,
the multi can be cancelled because the underlying key tracked
by watch will change and invalidate the transaction.  The
biota will then return invalid results (0).  This removes the
transaction block.  Unknown if this is dangerous if the bitmap is
in the process of being copied.  Causes bitops to not be strongly
consistent.
In testing large bitmaps saw a ~50x increase in speed
by pipelining operations.
@onomated
Copy link

onomated commented Jul 29, 2016

@bilus I've also addressed conflicts in this PR in my fork. Can create a new PR addressing these conflicts once #6 is merged, as I included these changes on top of the chunk keys improvements.

Will personally start looking into using redis SCAN in lieu of KEYS to reduce latency in my current deployment

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants