Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CURP - fast replication nearly for free and without the current caveats #6175

Open
dumblob opened this issue Jun 20, 2019 · 3 comments
Open

Comments

@dumblob
Copy link

dumblob commented Jun 20, 2019

There is a "new" approach to very fast replication called CURP (Consistent Unordered Replication Protocol).

It shall not have the caveats the current replication scheme in Redis has and shall not be difficult to implement (actually it was already partially implemented for Redis to test it - don't know though where the source lies and what is the license).

Would you consider implementing such low hanging fruit?

@antirez
Copy link
Contributor

antirez commented Jun 21, 2019

Hello @dumblob, there are a few things that ring bells reading the blog post, but I'll look at the paper itself. Just to be sure we understand the matter here, CURP is actually an improved synchronous replication protocol, so would substitute more what WAIT is doing now (but without the real guarantees provided by CURP anyway), and not what we are doing right now with asynchronous replication and the best-effort consistency that we use. So anyway that would be a downgrade in performances compared to the normal way people use Redis, but would be an improvement in the case of users using WAIT. The way the durable Redis is benchmarked in the paper however is extremely odd, since they compare the AOF fsync "always" policy with the CURP replication protocol, not sure if it makes much sense.

@dumblob
Copy link
Author

dumblob commented Jun 21, 2019

The way the durable Redis is benchmarked in the paper however is extremely odd, since they compare the AOF fsync "always" policy with the CURP replication protocol, not sure if it makes much sense.

I would guess, that they were trying to accomplish "strict serializability" (long description) and therefore did this comparison which looks weird on the first sight.

@dumblob
Copy link
Author

dumblob commented Nov 24, 2019

@antirez did you have some time looking into that paper? Does your enterprise (Redis Labs if I'm not mistaken) offer commercially such functionality?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants