Snappy Dashboards with Redis

This doesn't make any sense to me. Why store the values in Redis and use Ruby to do simple math? If you're using Postgres already, just store the stats in Postgres and use an aggregate or window function to grab the stats. (And collect those stats with triggers, in the first place.) If you're using Mongo already, just grab your stats with a map reduce query.

This is cool and, I believe, a good strategy for many things.<p>&#62; If Redis isn’t available, for whatever reason, we could rebuild the gaps from the canonical data in Mongo. We’ve never had to do this.<p>I'm not sure this is so straight-forward.<p>So, this is a guest post by Sqoot hosted by togo.io, who owns the redistogo.com. Can anyone explain redistogo.com's pricing? I understand the value in not running your own service dependencies, but the redistogo.com prices seem really high to me. I was under the impression redis is fairly easy to manage. What kinds of operational tasks does redistogo.com perform for a redis instance that would warrant such high prices?

This is a pretty standard way to handle counts and doesn't seem to have much to do with redis. In an SQL database you'd just do it with a trigger and your application wouldn't need to know a thing about it.

Sounds like the typical caching approach to me, "avoid making big queries by caching your data in a ram-based key-value store" .. so this is pretty much common knowledge amongst webdevs since LiveJournal introduced memcached back in 2007?, or am i missing something ?

This works great, one thing I've started doing is caching those mget's in memcached. Redis is fast, but it's also single threaded and depending on how you're using it can become cpu bound, causing timeout errors while busy redis instance handle lots of write/reads... so similar to mysql - i've started guarding multiple redis reads with single memcache get... feels crazy, but maybe correct?

I've been working on a dashboard that uses Redis as well. Just wondering, why not take advantage of sets/lists/zsets for your date-related keys. With lists you can do an easy LRANGE instead of that loop of GETs you're doing now.<p>Also, if you don't do this already, look into using bitsets to track users. As long as userID's are integers, it's real easy it saves a <i>lot</i> of space.

Nothing specific about redis or new here. Of course if you can easily cache a pre-calculated value, that'll save you time and CPU.

Why not store &#38; update count in database. Rather Redis. Also I could never appreciate the redistogo. I can get much powerful redis instance on EC2 for much lesser price.

nitpick: "The values are almost inconsequential since THEIR just numbers" should be either THEY ARE or THEY'RE

This is exactly what I'm building <a href="http://www.instahero.com" rel="nofollow">http://www.instahero.com</a> to solve. You don't have to build your own infrastructure, just write the relevant bit of code (or select a template) and you have a dashboard.

I use Fnordmetric - Ruby/Redis dashboard. Works great.