Hacker News Reader

Comment by thelinuxl1ch | Hacker News Reader

Are there any performance issues we should know after the Raft implementation?

The Raft protocol only touches the metadata (table information, location of tables on physical nodes, etc). The query engine works the way it always did, so Raft shouldn't affect query performance in a measurable way.

There might be difference in performance for administrative operations (e.g. resharding), but they should all be positive changes!

EDIT: Daniel beat me to it.

General query performance should be the same, if not better in this release (the improvements are not due to Raft, but due to other changes). We use Raft only to determine a consistent configuration. The queries themselves are executed in the same efficient way as before.

Note that in the beta, reconfiguring tables over servers on rotational disks can be slow https://github.com/rethinkdb/rethinkdb/issues/4279 . If you store large documents, you might also see some increases in memory usage during backfills https://github.com/rethinkdb/rethinkdb/issues/4474 . We're going to address both of these issues before the final release.

> We use Raft only to determine a consistent configuration. The queries themselves are executed in the same efficient way as before.

So, you've made the noob mistake in using Raft, where only configuration goes in the log and actual changes to data aren't replicated in the same manner.

We have carefully designed the way data is versioned and replicated in RethinkDB 2.1 to result in a correct and consistent system in combination with the Raft-supported configuration management. For example we make sure that both components use consistent quorum definitions and the same membership information at any point.

This allows us to provide different degrees of consistency guarantees for the data, depending on the user's need. Our default is already pretty conservative, but allows uncommitted data to be visible by reads. In the strongest consistency mode, RethinkDB 2.1 provides full linearizability (see http://docs.rethinkdb.com/2.1/docs/consistency/ for details). We have confirmed this both theoretically as well as by testing the overall system using the Jepsen test framework.

What do you gain? Let's say that you're right and you've managed actually managed to provide the guarantees that you say you have. By adding things to Raft, you haven't made it simpler and, having implemented Raft myself recently, I can attest that it's not the simplest of things to start with.

If you're looking for different degrees of consistency, I'm fairly sure you can do that without protocol level changes to Raft.

Reply on news.ycombinator.com