Live data from Hacker News

RethinkDB 2.1 is out: high availability

rethinkdb.com

41–50 of 108 posts

Re: RethinkDB 2.1 is out: high availability

#43

I 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!

We're still working on the full documentation for the Twisted and asyncio backends. We'll put it up in the next days. You can find the Tornado documentation under the link coffeemug mentioned.

Re: RethinkDB 2.1 is out: high availability

#45
post #33

Earlier 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…

Ah, I apologize 'oppressive' isn't the right word. I really meant 'outside of our budget', but I'll certainly be test-driving the CE this month. Thanks again.

Re: RethinkDB 2.1 is out: high availability

#46
post #40
post #30

Earlier 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…

Thank you for the detailed and fascinating response! I read and re-read it to make sure I didn't miss any details. I understand now why you chose to handle only metadata with Raft. I really appreciate the time you took to explain not only your reasoning, but your reasoning through the alternatives as well. Databases and distributed systems are both fascinating, and very challenging, problem domains. Combining them is even more challenging.

Re: RethinkDB 2.1 is out: high availability

#47
This looks awesome .. great job guys .. Just a question on licenses . Server is "GNU Affero General Public License v3.0" and drivers are "Apache License v2.0." , so in simple english does it means that can i use make commercial products with backend as RethinkDB? these things always confuses me so apologies if i ask something stupid here ..

Re: RethinkDB 2.1 is out: high availability

#49

Earlier 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.

Based on this pull request: https://github.com/aphyr/jepsen/pull/70

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

#50
post #30

Earlier 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…

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?

Post reply on HN