I really am liking Redis, and they've expanded beyond just snapshots for persistent storage. You can now append data, and there a different options for both when you snapshot or append (a time, for each set, etc).
I just started using MongoDB in a Python project; it shares a lot of the advantages (vs. SQL) mentioned in this presentation -- there's a natural mapping between the BSON in MongoDB and Python dicts.
What are the pros & cons of Redis compared to MongoDB?
The cool thing about redis is that it supports a bunch of different data structures: (ordered) sets, arrays, hashes, queues and more. There are a lot of db operations that are very natural with such support that are harder to force into the basic key/value paradigm exported by MongoDB. Also, redis is really simple to use which makes it useful for many cases where a full database might otherwise be overkill. For example, I've used it for storing results from experiments for further analysis. It's easier than a flat-file and much more performant.
Shenanigans. The author says that MySQL/Tokyo Tyrant don't work because of "death by I/O". Right, well, if your data set fits in memory, which I assume it does because you're relying on Redis, and the Redis VM feature is ghastly, then your problem isn't with "I/O", it's with MySQL not doing the right thing.
Buy some SSD drives, try out Postgres, but if you bet your business on something like Redis, you deserve whatever you get.
It is not possible to design something that is both optimized to be an in memory DB or on disk DB, there are tradeoffs. So Redis stresses the right tradeoffs to be good in memory. The VM evolution, called diskstore, will provide us a way to work on bigger datasets as well. But probably Redis will continue to be much better in memory compared to an on disk DB with dataset that happens to fit in memory, and on disk DBs will try to be better than Redis+diskstore.
A few operations that Redis supports are specifically designed to work well in memory and can't be made efficient on disk. See for instance sorted sets and all the commands that this data type supports.
I'm always suspicious when I see something that is known to be a limitation of a tool is held up as the reason it's better than all other tools, including those that don't have that same limitation. And, as I understand it, redis is specifically designed to work with data that fits in memory, which is definitely a limitation that will prevent its use in a lot of places.
It strikes me that redis has some cool concepts...but you can't just wave your arms around and say that because redis is a memory-based database it solves I/O and performance problems of databases that normally operate in larger than memory deployments. If redis falls apart when memory can't contain the entire data set, that's a limitation, not a feature.
Since I know Tokyo Tyrant (and its successor or sibling or whatever, Kyoto Tycoon) are blisteringly fast in memory only workloads using key-value datasets, I'm highly suspicious of claims that redis is naturally and obviously faster (or something...I can't tell if this is a claim of speed, or architectural superiority because redis somehow solves I/O in a different way, I can't tell from the slides what is claimed, really).
Personally, I'd like to see some more meat to the argument that redis is superior, or at least some clarity about when and why redis is superior. It's obviously not going to replace MySQL for my CMS or OpenLDAP for my directory services, but it might have a place in other types of deployments. I couldn't figure out what Plurk is, so I'm not sure I understand what it was developed for. (I'm old, though...Plurks purpose might be obvious to someone not afflicted with my particular malady.)
I don't see another obvious advantage of Redis over Tokyo Cabinet other than the nicer complex data structure support. I use Redis for several projects and for me it serves well. Particularly, I know the limit of Redis and can predict how much memory it will eventually eat up with respect to the growth of site. Besides, Redis has a small code base that I can tinker around (It is c!) which would be nearly impossible for me to tinker around MySQL with confidence. Tokyo Cabinet has a nice code base too, and I liked it a lot but the limitation is: Tokyo Cabinet provides either a simple key-value db (b-tree/hashtable) or a full flee of table-like db. The former one is too simple to actual usage and the latter one is too complex (from my point of view, it is just SQL without parser, I even programmed a SQL parser on top of its table db). For my usage, a document-based db (MongoDB) or Redis which has sorted set/set data structure is enough and since MongoDB is complex in terms of code base too, Redis becomes my first choice.
Although Redis is critiqued for its VM implementation, I found that it is good enough for my specific usage: I have around 2 million or so keys and the workset is about 25k keys average.
Yes, Redis is not a universal solution to everything, and I am a little worried about its current proposal of disk-based system (to me, Tokyo Cabinet's disk op implementation is more mature and antirez should do more analysis on the comparison to Tokyo Cabinet and Berkeley DB since these two are only known k-v based disk DBs that tested in battle field).
