[mantrax5]

Redis 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? Hell no. Can it help scale your app if carefully considered, with regards to its properties? Sure. Does it "scale SQL"? No.

[zeeg]

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 "conflicts" in a classical sense, but there are race conditions with the specific lock implementation. I definitely didn't suggest they were strong.

[nkozyra]

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

[patrickmay]

> ACID will never be performant and scalable

We manage this quite well at GigaSpaces (http://www.gigaspaces.com). I have some examples up at http://gigaspacesinanger.wordpress.com that show some use cases.

[diakritikal]

> ACID will never be performant and scalable

I think the chaps over at HyperDex.org may strongly disagree with you.

[mantrax5]

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 ACID, but it is durable.

They stumbled upon scalable durability because they had no other choice. As a trading platform, they were required to be durable by law, and required to scale by their clients.

A blanket all-or-nothing statement like "it will never scale" stops you before you even try to research the space of possible solutions.

[twic]

As an aside, i think the persistence approach used in Disruptor is taken from Prevayler:

http://prevayler.org/

Which perhaps got it from other even earlier efforts of which i am not aware.

[cdelsolar]

> it'll lose minutes of committed operations on unexpected stops.

Never noticed anything like this and I've been using Redis for 3+ years.