3 ms·

> Leader needs to send AppendEntries and slave needs to apply to persistent storage and ACK. Leader needs to wait for majority of ACKS before responding to the

> Leader needs to send AppendEntries and slave needs to apply to persistent storage and ACK. Leader needs to wait for majority of ACKS before responding to the client. That's the same as your three-node replication scenario, so what am I missing here? A couple of things -- the payload in Raft tends to be much higher (though it could probably be fixed with sufficient engineering effort), and in some scenarios this process would have to happen multiple times during netsplits (which may or may not be ok). RethinkDB doesn't relax consistency guarantees; we implement them in a different way. Check out http://rethinkdb.com/docs/consistency/ http://rethinkdb.com/docs/consistency/ for more details. I'm a bit busy today, but this is a really interesting question. I'll see if we can do a technical blog post on this and go into all the details in depth.

teraflop 11y ago
The parent comment asked: > 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?
- coffeemug 11y ago
  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.

teraflop 11y ago

The parent comment asked: > 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?

coffeemug 11y ago
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.