2

Is there a storage system with these properties?

  • horizontally scalable - can handle arbitrary read and write throughput if you add enough nodes to the cluster
  • consistent, in the sense that all reads will reflect the latest successful writes
  • [edit] "safe" in the sense that if a write is reported successful, it is guaranteed that all subsequent successful reads will reflect that write
  • tolerant of individual node failures

In CAP terms, I'm interested in systems which guarantee consistency rather than availability in the event of network partitions. Or systems which at least can be configured to behave this way.

I'm not concerned with latency, as long as writes are guaranteed to terminate eventually.

I'm not asking which tool I "should use". I'm asking, out of academic interest, for a proof of concept of a CP storage system. It doesn't matter if it's modern, actively maintained, widely used or what not; I'm just seeking a reference implementation.

Improve this question
0
1

The image in this article is used quite a bit around the internet in various different forms but it highlights which systems fall in each category of CAP

So your are basically asking which horizontally scalable systems don't rely on eventual consistency. To which MongoDB, HBase and many more would be a good answer.

Improve this answer
3
  • Thanks, this is a helpful starting point. Sorry if I didn't make this clear, but I'm interested in systems which are "safe" in the sense that if a write operation returns success, it's guaranteed that the write will be reflected in all future successful reads. I don't think MongoDB can provide this - even with fsync writes, the master could explode before replicating the write in which case the data will be lost, right? I'm not very familiar with HBase but I believe it's also possible for a write to appear successful but actually be lost when a master dies? – Daniel May 18 '14 at 18:13
  • I'm basically looking for something where all write and read operations must achieve consensus before they're considered successful, so that it's impossible for a successful write to be lost unless half of the cluster explodes. (And if that happens, all reads should fail, so that consistency is still enforced.) – Daniel May 18 '14 at 18:17
  • when this is needed database replication generally achieves this by using synchronous replication. This means that the write does not return a success until the same write has been committed on the remote server. This causes some latency depending on the distance and hardware etc. – James Anderson May 18 '14 at 18:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.