Live data from Hacker News

Redis 6 RC1 is out today

antirez.com

1–10 of 12 posts

Re: Redis 6 RC1 is out today

#5
post #3
post #2

Can't wait for Threaded I/O as our app main bottleneck in some deployments was Redis.

Threading can help up to a given point but sharing is the way to go.

One of our bottlenecks was really big keys (>1MB) being written and read too often and effectively stealing all the CPU time. That was fixed in the app by reducing the number of operations + compression. Threaded IO will give us a little more room.

Other use case involves LUA scripts that operate on 5 different keys, so cluster/proxy is out of question.

Re: Redis 6 RC1 is out today

#6
post #4

This got me thinking about using Redis and I needed a review of what is open source and what isn't: https://redislabs.com/legal/licenses/

All Redis 6 is BSD licensed. The Disque module and the Cluster Proxy are AGPL. The link you posted is only relevant for the Redis Labs commercial modules that are not part of this release.

Re: Redis 6 RC1 is out today

#7
post #5
post #3

Earlier quoted context omitted.

Threading can help up to a given point but sharing is the way to go.

One of our bottlenecks was really big keys (>1MB) being written and read too often and effectively stealing all the CPU time. That was fixed in the app by reducing the number of operations + compression. Threaded IO will give us a little more room. Other use case involves LUA scripts that operate on 5 different keys, so cluster/proxy is out of question.

Oh I saw a wonderful (private) fork about this, sending very large keys using threads.

Re: Redis 6 RC1 is out today

#9
Really appreciate that @antirez takes the time to add features in a way that doesn’t negatively impact old features where possible, for example if I don’t want to use ACL, I don’t have to jump through hoops or assign universal high level access that I have to undo later. Thanks!

Re: Redis 6 RC1 is out today

#10
post #5
post #3

Earlier quoted context omitted.

Threading can help up to a given point but sharing is the way to go.

One of our bottlenecks was really big keys (>1MB) being written and read too often and effectively stealing all the CPU time. That was fixed in the app by reducing the number of operations + compression. Threaded IO will give us a little more room. Other use case involves LUA scripts that operate on 5 different keys, so cluster/proxy is out of question.

Genuinely curious, why do you need such big keys ? Can't you hash them so you get nice short SHA-X strings for instance ?
Post reply on HN