31–40 of 108 posts
Earlier quoted context omitted.
Fantastic news, this looks great! Just a quick question, can I update individual nodes one at a time in my running cluster, or do they all need to be on 2.1 at the same time?
Unfortunately 2.0 nodes cannot connect to 2.1 nodes and vice versa, so depending on your table configuration you might need to update all of them at the same time.
Earlier quoted context omitted.
Suppose you configure RethinkDB to store three copies of the data. When you do a write, RethinkDB will replicate the data to three nodes; that operation is roughly a matter of sending three messages to the appropriate nodes, getting the acks, and sending the ack back to the client. If we used Raft to replicate the document, in many cases it would be a lot more chatty. If you look at the Raft paper and track all the m…
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…
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/ 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.
Earlier quoted context omitted.
If you like the general style of CouchDB but want scale and availability that's been proven in mission critical user facing deployments for years, we just did a blog post about moving to Couchbase http://blog.couchbase.com/2015/august/moving-couch
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.
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 paying less per node and running fewer nodes than they used to.
Earlier quoted context omitted.
Yea of course. We're basically talking about 10/90 write/read on JSON documents ~100kb in size with very low load, probably no more than 10-20 ops/second at peak. Records now are at 200,000 projected to grow 250k/year.
Thanks! I'd definitely give RethinkDB a try, I think you'd be pleasantly surprised at how nice it can be for this. You'll also find that you might want to run ad-hoc queries on JSON documents (e.g. for analytics/exploratory analysis, etc.) and having ReQL at your disposal will be great for that. IMO picking a KV store makes the most sense if you have insane performance requirements (e.g. millions of ops/second) where…
Also, very much looking forward to trying this out!
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!
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!
If there's anything else you think is missing from the documentation that would be helpful, open an issue here: https://github.com/rethinkdb/docs
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.
Earlier quoted context omitted.
Suppose you configure RethinkDB to store three copies of the data. When you do a write, RethinkDB will replicate the data to three nodes; that operation is roughly a matter of sending three messages to the appropriate nodes, getting the acks, and sending the ack back to the client. If we used Raft to replicate the document, in many cases it would be a lot more chatty. If you look at the Raft paper and track all the m…
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…
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 leader sends another AppendEntries with a higher commit index; and then the follower applies the changes to the state machine. In RethinkDB's case, the "state machine" is the B-tree we store on disk. One of the guarantees we provide is that if the server acknowledges a write to the client, then all future reads should see that write; and we perform reads by querying the B-tree. So we can't acknowledge writes until they've been actually written to the B-tree, and we can't start writing to the B-tree until after the write has been committed via Raft. So that's where the latency would come from if we were using Raft to manage individual documents. We considered a couple of ways to work around this. One would be to make reads check both the B-tree and the Raft log; but that makes the read logic much more complicated. Another would be to start writing to the B-tree as soon as we put the write in the Raft log. The problem is that Raft expects to be able to roll back parts of its log at any time, and our storage engine's MVCC capabilities aren't good enough for that. The hybrid approach allows us to have good latency without major rewrites of the existing storage engine.
The other reason is that RethinkDB allows tables to be split into shards, and the number of shards can be changed while the databases is running and accepting queries. We considered having one Raft instance per shard, but we would have needed to modify the Raft algorithm to allow splitting and merging Raft instances while they are running and accepting queries. (This is approximately what CockroachDB is doing [1].) But the Raft algorithm is really tricky to get right even when you're not trying to modify it, and we wanted to stick as closely as possible to the official algorithm to minimize bugs. The approach we ended up going with allows us to have the performance and convenience of live resharding without having to modify the Raft algorithm.
In response to your question about consistency guarantees: RethinkDB gives users several options for trading off consistency and latency. The default is to acknowledge writes only once they're safely on disk on a majority of replicas, but to perform reads only on the primary replica (leader). This doesn't give perfect consistency; if the leader fails over, reads that hit the database around the time of the failover might see outdated data, or they might read writes that were rolled back as part of the failover. Unfortunately, the only way to get stronger consistency guarantees is to wait for a majority of replicas to acknowledge the read, which makes performance much worse. We offer a safe-but-slow mode for reads, but it's not the default because the performance is so bad. We also offer fast-but-unsafe modes for writes, for users that want better latency and are OK with losing the last few writes in the event of a failover. See the documentation [2] for more information.