> Does Rethink db relax consistency guarantees in some cases to achieve better latency?
You responded:
> RethinkDB doesn't relax consistency guarantees; we implement them in a different way.
But the page you linked says:
> `single` returns values that are in memory (but not necessarily written to disk) on the primary replica. This is the default.
> `majority` will only return values that are safely committed on disk on a majority of replicas. This requires sending a message to every replica on each read, so it is the slowest but most consistent.
which seems to imply that the default settings sacrifice consistency for better latency. Can you (or someone else, if you're busy) clarify?
Sorry, this is a bit nuanced and my comment was unclear.
We implement a variety of modes for reading and writing that allow the user to select different trade-offs for consistency and performance. By default: writes are always safe; reads are safe when the cluster is healthy, but can sometimes have anomalies in failure scenarios. You can also do `majority` reads which are completely safe even during failure scenarios, but are slower.
However note, that the default read mode isn't an "anything can happen" implementation. The guarantees are precisely defined, and 2.1 passes all tests in a large variety of failure scenarios with respect to these guarantees.
My comment about not relaxing consistency guarantees was meant in a slightly different context. The OP was talking write transactions (and implementing individual writes with Raft vs. using a different way), and I pointed out that we don't relax consistency guarantees for writes despite not using Raft.
I realize my comment was confusing -- sorry about that; I didn't mean to mislead.
> Does Rethink db relax consistency guarantees in some cases to achieve better latency?
You responded:
> RethinkDB doesn't relax consistency guarantees; we implement them in a different way.
But the page you linked says:
> `single` returns values that are in memory (but not necessarily written to disk) on the primary replica. This is the default.
> `majority` will only return values that are safely committed on disk on a majority of replicas. This requires sending a message to every replica on each read, so it is the slowest but most consistent.
which seems to imply that the default settings sacrifice consistency for better latency. Can you (or someone else, if you're busy) clarify?