SearchYC.com

Bullshit, and I will elaborate.

Oracle has two "scalable offerings:"

RAC relies on a single large san to "scale."

Exadata relies on super-fast interconnects to get multiple machines to look more like a single huge one, which has the obvious speed-of-light limitations as well as the price one.

Neither approach is the kind of scale out with commodity hardware that something like Cassandra gives you.

Here's the core misunderstanding:

"It is hinted that by setting the number of reads (R) and number of writes (W) to be more than the total number of replicas (N) (ie. R+W>N) - one gets consistent data back on reads. This is flat out misleading. On close analysis one observes that there are no barriers to joining a quorum group (for a set of keys). Nodes may fail, miss out on many many updates and then rejoin the cluster - but are admitted back to the quorum group without any resynchronization barrier."

That's because adding a barrier (a) isn't necessary for the consistency guarantee, (b) doesn't add any extra safety in the worst case, and (c) adds complexity (always be suspicious of complexity!)

Consider the simple case of a 3-node cluster (A, B, C) with N=3.

For quorum reads and writes, R = W = 2.

Then reads will be consistent if any two nodes are up. It doesn't matter if nodes A and B are up for the write, then B and C are up for the read -- the reader will still always see the latest write.

Of course you will have to block writes and reads if more than one node is down for either operation. This is what the dynamo paper means when it talks about allowing clients to decide how much availability to trade for consistency.

Reddit was originally on L instances.