Re:How we implemented replication in Memgraph DB – Our appro...
by codeulike on Wednesday February 10, 2021 @10:20AM
(#26090285)
Synchronisation/replication are such a common requirement I'm surprised there's not some well known checklists or patterns or best practices. e.g. merits of looking at times of changes vs keeping a log of changes, techniques to avoid and correct divergence over time, etc
Re:How we implemented replication in Memgraph DB – Our appro...
by antonio2368 on Wednesday February 10, 2021 @10:43AM
(#26090658)
I agree.
There is some basic knowledge on how to achieve the replication, but, in our case, a lot of it was improvised and we're not sure what is the best approach.
We tried to minimize the overhead (keep as little information as possible) and that was more or less the only guidance we used.
Re:How we implemented replication in Memgraph DB – Our appro...
by cpard on Wednesday February 10, 2021 @10:20AM
(#26090272)
"Because the concept is simple, achieving all three of the CAP properties at the same time is not possible."
I know that Paxos is considered hard to implement correct, but is there a reason to believe that in the general case, the more strict guarantees we need the more complex the algorithm has to be?
Re:How we implemented replication in Memgraph DB – Our appro...
by antonio2368 on Wednesday February 10, 2021 @10:37AM
(#26090554)
Well, consistency and availability are the problem here. While enforcing one of the property, you lose on the other. Not sure how would you achieve those opposing properties without introducing huge amount of complexity.
In this case, replication consists of communication between 2 instances, and when one them fails you need to pick consistency or the availability.
Paxos and Raft introduce consensus using multiple instances communicating with each other to mitigate those problems. Implementing correctly communication with 2 instances is hard enough, implementing it correctly for n instances is for sure harder.
In Memgraph, we actually tried to implement Raft and we did manage to some degree, but the effort was too much, especially when you look at the results we got (protocol that didn't work for many edge cases).
Re:How we implemented replication in Memgraph DB – Our appro...
by mbuda on Wednesday February 10, 2021 @02:08PM
(#26093386)
We'll probably put the replication feature in the Memgraph Community soon. At that point, we'll make a PR to the Jepsen repo with all our tests included + yea, additional testing will be possible. That's always good. As they say, once you wrote a bunch of tests for your code, please leave it to the others to test it as well :D
Re:How we implemented replication in Memgraph DB – Our appro...
by cpard on Wednesday February 10, 2021 @12:50PM
(#26092432)
thanks for the detailed response. Did you try to implement Raft yourself or use something like etcd for coordination? It would be great to write about this journey too in the future.
Re:How we implemented replication in Memgraph DB – Our appro...
by mbuda on Wednesday February 10, 2021 @01:59PM
(#26093293)
We implemented Raft as a C++ library from scratch. We can probably publish that as s standalone implementation (open-source it). The main problem was the write performance and network communication overhead, even for read queries. There are some known solutions for all that. None of the Memgraph users required Raft type of guarantees, so we decided to go with a more straightforward and faster solution. It doesn't mean we won't get back to Raft in the future if required :D
There is some basic knowledge on how to achieve the replication, but, in our case, a lot of it was improvised and we're not sure what is the best approach.
We tried to minimize the overhead (keep as little information as possible) and that was more or less the only guidance we used.
I know that Paxos is considered hard to implement correct, but is there a reason to believe that in the general case, the more strict guarantees we need the more complex the algorithm has to be?
In this case, replication consists of communication between 2 instances, and when one them fails you need to pick consistency or the availability.
Paxos and Raft introduce consensus using multiple instances communicating with each other to mitigate those problems. Implementing correctly communication with 2 instances is hard enough, implementing it correctly for n instances is for sure harder.
In Memgraph, we actually tried to implement Raft and we did manage to some degree, but the effort was too much, especially when you look at the results we got (protocol that didn't work for many edge cases).