Hacker News Reader

Comment by bmer | Hacker News Reader

What's the difference between "reliable" and "accurate"?

In any case, I have seen enough of these "A, B, C : pick N" (where 0 < N < 3) mantras shot down (usually by re-examining whether the constraints/assumptions of the original mantra apply in a specific situation, or just through plain algorithmic engineering) that whenever someone drops something like this, I mostly tune it out.

In the case of distributed network <anything>, implementing programs in languages that help you manage important invariants automatically (and preferably not at run-time, but at compile-time) is key in creating robust systems that are both reliable, and fast.

But if you have such tools, and you are trying to also meet a set of standards that were designed without any care for distributed computing, then...yeah.

View on HN

I think they probably are misremembering consistency, partition-tolerance, availability; pick 2.

No, I'm familiar with CAP. My theorem is different.

Reliable: A system can be available but not reliable; if a machine is down 6 minutes every hour, it's 90% availabile but less than 1 hour reliable. A networked distributed system can be reliable but not accurate if you keep it online while it slowly accrues errors, such as the mentioned link/unlink race condition. The machine still works, it just has occasional corruption. It tends not to be very fast if it's reliable.

Fast: You can do whatever you want quickly. Think UDP, or filesystems that don't commit their log journal frequently. Tends not to be reliable or accurate.

Accurate: Whatever you do has no corrupted state. Think ACID. Most systems don't do this because it's expensive/complicated.

Apologies - fair enough. I can't quite tell if that is a genuine set of three alternatives or not[0], but I sort of see your point. Couple of unsure places:

> Think ACID. Most systems don't do this because it's expensive/complicated.

Is this true? A lot of systems are built on databases.

> Accurate: Whatever you do has no corrupted state

How does accuracy work if the system is distributed and there's a partition, and two node get different data? Presumably it's reliable if they're different, as accuracy is a different item?

> Fast: You can do whatever you want quickly. Think UDP, or filesystems that don't commit their log journal frequently. Tends not to be reliable or accurate.

Why wouldn't this be reliable?

Most databases aren't ACID compliant, and even if they can be, they're often used in a non-ACID way.

> How does accuracy work if the system is distributed and there's a partition, and two node get different data?

You don't allow writes during a partition. All nodes (or a quorum) must confirm on each write, and if that fails then a partition is detected. Everything that was accidentally written before you detected partition is thrown away. Usually you just have one writer node for simplicity.

> Fast: > Why wouldn't this be reliable?

If you prioritize reliability you will need a slower method to ensure reliability. TCP is slower than UDP so it can be reliable.

> You don't allow writes during a partition. All nodes (or a quorum) must confirm on each write, and if that fails then a partition is detected. Everything that was accidentally written before you detected partition is thrown away. Usually you just have one writer node for simplicity.

Wouldn't this be done better with a majority/minority approach, where if enough nodes are still communicating then they still work?

> If you prioritize reliability you will need a slower method to ensure reliability. TCP is slower than UDP so it can be reliable.

Agree - that is true in the TCP sense of the word reliable. But in your sense of the word, as I understood it, the TCP/UDP difference is more like "accuracy", is it not? Reliability is more like availability, as I read it in your previous comment.

maybe helpful

https://en.wikipedia.org/wiki/CAP_theorem

Is this a theorem, or a rule of thumb? I can't quite tell, because I thought theorems had proofs to go along with them?

You can prove it, if you pick some assumptions.

Reply on news.ycombinator.com