undefined | Better HN

0 pointsxfalcox6y ago0 comments

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.

0 comments

rakoo6y ago

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

jdsully6y ago

I run a fork called KeyDB with multithreading as well as a few optimizations directly around large values (redis does unnecessary copies).

It may work well for your use case. https://github.com/JohnSully/KeyDB

antirez6y ago

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

j / k navigate · click thread line to collapse