

Presentation: Redis, The Hacker's Database - zeynel1
http://amix.dk/blog/post/19593#Presentation-Redis-The-Hackers-Database

======
btipling
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).

------
smokestack
The video is up on GoogleTechTalks:
<http://www.youtube.com/watch?v=1BS3UVSLX-I>

------
akavlie
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?

~~~
necubi
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.

------
dizz
Another excellent redis preso - <http://simonwillison.net/static/2010/redis-
tutorial/>

------
tedjdziuba
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.

~~~
SwellJoe
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.)

~~~
liuliu
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).

