RethinkDB 2.1 is out: high availability
41–50 of 108 posts
Re: RethinkDB 2.1 is out: high availability
#42As a heavy Heroku user - I'm wondering - is there some hosted RethinkDB solution?
Re: RethinkDB 2.1 is out: high availability
#43I couldn't really find any good docs on how to use the various async Python drivers...? All I found was some references to Tornado under `set_loop_type`. Also, very much looking forward to trying this out!
Re: RethinkDB 2.1 is out: high availability
#44Re: RethinkDB 2.1 is out: high availability
#45Earlier quoted context omitted.
That's funny, I just installed that over the weekend and was testing it out. It's really good but what sort of through me off was the high $/node licensing fee if you want the Enterprise edition. It basically starts at $5k/year/node and that's just too oppressive. Do you use the Community Edition and if so is it generally stable / suits your needs? I didn't read your article but I'll check it out tonight.
I'm a cofounder of Couchbase. Almost all our code is Apache 2.0, and we make the Community builds available for everyone. Enterprise builds are free to use for a small test cluster. Unless you are a business where $5k/node looks reasonable to pay for peace of mind, you are probably fine with the Community Edition. A lot of the customers paying for Enterprise Edition are moving to Couchbase from Oracle, so they are pa…
Re: RethinkDB 2.1 is out: high availability
#46Earlier quoted context omitted.
OK, so it's a latency concern, which makes perfect sense. > If we used Raft to replicate the document, in many cases it would be a lot more chatty. I'm out of my depth here. 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 he…
tim@rethinkdb here. coffeemug's earlier comment is not quite right. There were two reasons why we went for this hybrid approach where Raft handles metadata but not documents: because of how Raft interacts with the storage system, and because of sharding. In the Raft protocol, the leader sends AppendEntries; the follower writes the log entries to persistent storage, but doesn't apply them to the state machine yet; the…
Re: RethinkDB 2.1 is out: high availability
#47Re: RethinkDB 2.1 is out: high availability
#48...Doesn't seem available on homebrew yet though.
Re: RethinkDB 2.1 is out: high availability
#49Earlier quoted context omitted.
Have you Jepsen-tested the new 2.1 release? If so, what were its results?
Yes. We did months of internal tests, and 2.1 passes Jepsen tests. We'd love for Kyle to do his own analysis once he gets some free time. In the meantime there is a bit more info on this in the blog post under "testing" headline.
Am I correct in understanding that the tests only pass in the "safe-but-slow" configuration that timmaxw described (https://news.ycombinator.com/item?id=10043746) and not in the default "fast-but-unsafe" configuration?
Re: RethinkDB 2.1 is out: high availability
#50Earlier quoted context omitted.
OK, so it's a latency concern, which makes perfect sense. > If we used Raft to replicate the document, in many cases it would be a lot more chatty. I'm out of my depth here. 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 he…
> 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 pro…
> 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?