A Collection Of Redis Use Cases(paperplanes.de)
paperplanes.de
A Collection Of Redis Use Cases
http://www.paperplanes.de/2010/2/16/a_collection_of_redis_use_cases.html
12 comments
These are really useful. I've been telling anyone who will listen that Redis is a very different beast from the other NOSQL / Document stores out there - it scales down to small applications beautifully and makes a whole class of large-scale write problems (like real-time statistics) approachable for smaller projects.
it scales down to small applications beautifully
This is worth highlighting. In Rails, for example, the integration for Redis is seven lines of code (they're in my last blog post), and then the Rails cache you know and love is suddenly magic. It requires no significant amount of developer resources to integrate, minimal sysadmin skills to get running, and coexists beautiful with whatever you use for data persistence right now. In all of these respects it is a lot like memcached. (Or like memcachedb except without the periodic disk flush that gives your users 5 second response times.)
This is worth highlighting. In Rails, for example, the integration for Redis is seven lines of code (they're in my last blog post), and then the Rails cache you know and love is suddenly magic. It requires no significant amount of developer resources to integrate, minimal sysadmin skills to get running, and coexists beautiful with whatever you use for data persistence right now. In all of these respects it is a lot like memcached. (Or like memcachedb except without the periodic disk flush that gives your users 5 second response times.)
But wouldn't it require lots of RAM? My web server only has 512MB (or 256, not sure), therefore I have not seriously considered it yet. I'd love to use it, but it would cost me a lot to move to a better server.
Also, none of the root servers you can rent seem to have decent amounts of memory.
Also, none of the root servers you can rent seem to have decent amounts of memory.
The new virtual memory feature of Redis 2.0 allows you to swap data to disk and keep a minimal subset (the keyset, only values are swapped, never keys) in ram (1M keys would require 160mb of memory). You could keep only the most frequently used values in ram (and the keyset) to minimize memory usage.
http://antirez.com/post/redis-virtual-memory-story.html
http://antirez.com/post/redis-virtual-memory-story.html
After being clued in by Assaf (who wrote Vanity) I have been testing it out for adoption on my site.
A/B testing is practically tailor made for a NoSQL solution: you're storing lots of disconnected bits about individual user/test pairs but never querying over a set of them. The load is potentially very write heavy, very spiky, etc -- these sort of things spell trouble for scaling relational databases. However, key/value stores just slurp them up and ask for more. (Additionally, "eventually ACID" works totally fine for this problem: if one of your Redis machines suddenly dies, you might lose a minute's worth of A/B test assignments for a fraction of your userbase. That's just rounding error on your tests, though, and moreover it is evenly distributed rounding error, so you can just handwave it away.)
This is why I went with key/value stores for A/Bingo. (Granted, my site only has about 20,000 writes a week for A/B tests so I could have gotten away with doing it in MySQL/ActiveRecord -- heck, I could probably have gotten away doing it with opening a new flat file for every user -- but some of the larger deployments would probably never have happened if I did it that way. It would have had unacceptable performance implications for key pages on their sites.)
A/B testing is practically tailor made for a NoSQL solution: you're storing lots of disconnected bits about individual user/test pairs but never querying over a set of them. The load is potentially very write heavy, very spiky, etc -- these sort of things spell trouble for scaling relational databases. However, key/value stores just slurp them up and ask for more. (Additionally, "eventually ACID" works totally fine for this problem: if one of your Redis machines suddenly dies, you might lose a minute's worth of A/B test assignments for a fraction of your userbase. That's just rounding error on your tests, though, and moreover it is evenly distributed rounding error, so you can just handwave it away.)
This is why I went with key/value stores for A/Bingo. (Granted, my site only has about 20,000 writes a week for A/B tests so I could have gotten away with doing it in MySQL/ActiveRecord -- heck, I could probably have gotten away doing it with opening a new flat file for every user -- but some of the larger deployments would probably never have happened if I did it that way. It would have had unacceptable performance implications for key pages on their sites.)
Here's a use case of my own. I'm running a script that does sentence tokenization. Since the algorithm is using machine learning, I have a large dictionary of fragments corresponding to their probabilities. Instead of loading that dictionary off disk, as I had been, the script now accesses them out of Redis.
Hey, I know a guy who's doing something just like...oh, right, hi. Is that script up on the server at the moment?
I've been using Redis for data storage in a couple facebook apps. It's worked pretty well, and the speed is remarkable.
Thanks for this!
I'm planning replace most of MySQL on a web app with redis requests/responses for a faster experience. And this made my day (http://ozmm.org/posts/sort_in_redis.html). Tks!
I'm planning replace most of MySQL on a web app with redis requests/responses for a faster experience. And this made my day (http://ozmm.org/posts/sort_in_redis.html). Tks!
We're using redis, exclusively, to power http://pycon.djangodose.com/ (A live stream of everything going on at PyCon).
It's not just a database - it's also usable out of the box as a fast, language-independent tuple space. Its atomic lists and sets can be used like Erlang mailboxes, and the different components of your system don't need to be in the same language or on the same machine.
Another thing I like about Redis is that its features make it very complementary to RDBMSs, rather than a competitor in the same niche.
Another thing I like about Redis is that its features make it very complementary to RDBMSs, rather than a competitor in the same niche.
Fantastic, I've been looking for something like this.