Snappy Dashboards with Redis
blog.togo.io
Snappy Dashboards with Redis
1–10 of 46 posts
Re: Snappy Dashboards with Redis
#2This is cool and, I believe, a good strategy for many things.
> 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.
I'm not sure this is so straight-forward.
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?
Re: Snappy Dashboards with Redis
#3This 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?
Re: Snappy Dashboards with Redis
#4This 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.
Re: Snappy Dashboards with Redis
#5This 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.
Re: Snappy Dashboards with Redis
#6This 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.
I completely agree, I worry how everyone is introducing all these new technologies into their stack when their existing tools work fine.
Introducing new services/technologies just complicates things on both the application and ops layer (even though the author did say he was using RedisToGo).
Re: Snappy Dashboards with Redis
#7Nothing specific about redis or new here. Of course if you can easily cache a pre-calculated value, that'll save you time and CPU.
Re: Snappy Dashboards with Redis
#8This 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'm surprised that Redis cannot handle your traffic. What are you throwing at it? Or are you on EC2, with frequent BGSAVEs or AOF enabled on an EBS volume?
Re: Snappy Dashboards with Redis
#9This 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.
Agreed, this seems to fall into the bucket of "rediscovering" something that was solved decades ago.
Re: Snappy Dashboards with Redis
#10This 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.
It's the blog of a hosted Redis service.
Make sense?