Interesting use case and a great writeup - thanks for sharing :)
Scaling SQL with Redis
11–20 of 37 posts
Re: Scaling SQL with Redis
#12Redis is great... except for the fact it's (publicly) not ACID, so adding Redis in the mix and calling it "scaling SQL" is outright misleading, because it loses the very properties SQL exists to provide. Redis will enter into conflicts (where in this article's example, those locks won't "lock" the thing you're locking), and it'll lose minutes of committed operations on unexpected stops. Does that make Redis useless?…
Almost the entire post assumes you're not using it for durability. It's about making tradeoffs so the use of SQL can scale. If you want to be semantic, ACID will never be performant and scalable. The use of SQL on getsentry.com is already pushing Postgres to the limit's of what a locking/transactional database can do. The locks are a minor bullet point in a much larger picture. Redis is never going to generate "confl…
> ACID will never be performant and scalable
I think the chaps over at HyperDex.org may strongly disagree with you.
Re: Scaling SQL with Redis
#13Redis really is a fundamental building block for designing distributed systems these days. I was kind of surprised, but all these examples exist independently in the Zapier codebase as well (all backed by Redis). I've been meaning to open source our timeseries implementation for a while now, it is very similar to the linked article but uses a "{key}:YYYY:MM:DD:hh:mm:ss" pattern on hashes where you pick your stored gr…
Hey Bryan, just curious, are you guys not already using statsd/graphite? I think that at least you used to, since you contributed to my small script[0] to automate the installation of graphite... So I'm curious if/why it wasn't good enough, or whether this has different requirements that graphite wasn't suitable for? [0] https://github.com/gingerlime/graphite-fabric
(Jumping in for Bryan; also @Zapier)
We installed statsd/graphite early on to experiment around with visualizing our task and request logs for Zaps. We've since settled into Elasticsearch and Graylog which is phenomenal for debugging and support -- but has it's growing pains.
The timeseries stuff is used more at the application layer, rather than the pure logging layer. For example, I believe we're using it to track how many tasks an account has done over the last 30 days for pricing/plans.
Re: Scaling SQL with Redis
#14Redis really is a fundamental building block for designing distributed systems these days. I was kind of surprised, but all these examples exist independently in the Zapier codebase as well (all backed by Redis). I've been meaning to open source our timeseries implementation for a while now, it is very similar to the linked article but uses a "{key}:YYYY:MM:DD:hh:mm:ss" pattern on hashes where you pick your stored gr…
And also https://github.com/antirez/redis-timeseries https://github.com/o/simmetrica https://www.npmjs.org/package/redis-timeseries
You just solved some of my problems. Thank you very much!
Btw is there any nodejs module for voting? I've done it myself for one app but it would be nice to see other solutions.
Re: Scaling SQL with Redis
#15Interesting, but why not use redis pub-sub for the job queues instead of forwarding to RabbitMQ?
Re: Scaling SQL with Redis
#16Interesting, but why not use redis pub-sub for the job queues instead of forwarding to RabbitMQ?
Durability & high availability?
Re: Scaling SQL with Redis
#17Earlier quoted context omitted.
Almost the entire post assumes you're not using it for durability. It's about making tradeoffs so the use of SQL can scale. If you want to be semantic, ACID will never be performant and scalable. The use of SQL on getsentry.com is already pushing Postgres to the limit's of what a locking/transactional database can do. The locks are a minor bullet point in a much larger picture. Redis is never going to generate "confl…
I don't understand what's so hard to say the thing being scaled up is "the application domain model" and not "SQL". Not hard, is it? A "scaling SQL" article that suggests adding Redis is like a "make more beer" article that suggests adding water. There are performant algorithms for durable operations (as seen in frameworks like LMAX's Disruptor) which are simply not explored by Redis. The Disruptor is not canonical A…
As an aside, i think the persistence approach used in Disruptor is taken from Prevayler:
Which perhaps got it from other even earlier efforts of which i am not aware.
Re: Scaling SQL with Redis
#18Interesting, but why not use redis pub-sub for the job queues instead of forwarding to RabbitMQ?
Durability & high availability?
Rabbit is durable and highly available as well. It can be clustered and it's confirmable queues allow for a high volume of writes while remaining durable.
Re: Scaling SQL with Redis
#19Redis is great... except for the fact it's (publicly) not ACID, so adding Redis in the mix and calling it "scaling SQL" is outright misleading, because it loses the very properties SQL exists to provide. Redis will enter into conflicts (where in this article's example, those locks won't "lock" the thing you're locking), and it'll lose minutes of committed operations on unexpected stops. Does that make Redis useless?…
Almost the entire post assumes you're not using it for durability. It's about making tradeoffs so the use of SQL can scale. If you want to be semantic, ACID will never be performant and scalable. The use of SQL on getsentry.com is already pushing Postgres to the limit's of what a locking/transactional database can do. The locks are a minor bullet point in a much larger picture. Redis is never going to generate "confl…
> If you want to be semantic, ACID will never be performant and scalable.
I disagree with this part. We may not have great options for it now but we're largely stuck with the requirement of a hard lock for data consistency - someday someone will figure out how to mitigate the effect here.
Re: Scaling SQL with Redis
#20Earlier quoted context omitted.
Durability & high availability?
Rabbit is durable and highly available as well. It can be clustered and it's confirmable queues allow for a high volume of writes while remaining durable.
This was my take away question. Redis can be used extremely effectively as a pool of job queues with failover. Perhaps RabbitMQ provides robust bidirectional messaging? While pooling Redis works well for one-way job submission (with each Redis instance being backed by some set of work consumers), making the process synchronous (whereby the consuming worker communicates back to the producer) is not so clearly handled in a robust way unless the producer is listening on some set of Redis instances for the single reply message. RabbitMQ seems heavy weight just to solve that single problem, though.