[joe_the_user]

Redis' internal design typically trades off memory for speed. For some workloads, there can be an order of magnitude difference between the raw number of bytes handed off to Redis to store, and the amount of memory that Redis uses.

What are the circumstances that make this kind of tradeoff worthwhile?

A generic Key-Value store, say Kyoto Cabinet, is pretty fast and you can configure its cache to be huge if you need it. Does reconstructing and using a list/set/hash take that much time?

Edit: Is the "order of magnitude" here greater or less than the extra space that keeping a b-tree index in memory would take? Is it doing something akin to that or a completely different thing?

[antirez]

The tradeoff is especially worthwhile because we export complex data structures (I wrote a great deal of articles about this, please check the latest at antirez.com), but this time I'll try to provide a proof by paradox: what you are saying here is that memcached may be replaced with TC from the point of view of performances, if you add an LRU expiry, that I think it's not true.

[joe_the_user]

I hope this didn't come off as a criticism. I was simply trying to understand what Redis does.

I'm using Kyoto cabinet to serialize various hashlist-based-classes and I'm wondering what bottlenecks etc. I might encounter are. I'll take a look at your site.