[erlang-questions] [ANN] ActorDB a distributed SQL database (Sergej Jurecko)
Fred Hebert
mononcqc@REDACTED
Fri Jan 24 17:33:32 CET 2014
I'm curious about a few things:
- You mention using ACID for transactions, but later mention "The master
does periodic rebroadcasts of state. Eventually it will correct
itself. But it had bad data for X seconds"
This points towards an eventually consistent solution, not a fully
consistent one.
- There is, during your leader election (picking local max) and many
times around the text: "A successful 2 phase commit means a majority
of nodes."
This sounds like a majority-based consensus, but the 2PC algorithm
usually waits for *all* participants to have agreed. Unless you're
adding majority-reads as a constraints, it sounds like you're going to
be breaking ACID in the first place, and that you're not actually
using 2PC, but a quorum-based consensus algorithm.
- It's unclear how 'majority' is determined. Is it a majority of all the
nodes *expected* in the cluster, or a majority of the nodes
*currently* in the cluster? How does this deal with netsplits?
- No mention of timeout. Do you have a threshold under which a master
gets de-elected for taking too long to respond? Is there an assumption
here about timeouts vs. failures and how to tell them apart? Under
such a scenario, how do two nodes who think of each other as masters
detect the case and resolve it?
- How do these mechanism keep working following a netsplit during a
multi-shard transaction?
- When you redirect requests, are you doing the redirection as a proxy,
or asking to retry directly? In the former case, what happens if the
proxy node dies, but not the master actually doing the request? Or
vice-versa, what if the client dies, but not the proxy node?
- What happens to requests being sent during a shard migration that
hasn't yet completed?
There's probably more to ask, but yeah. Distributed systems are fun and
hard!
Regards,
Fred.
On 01/24, Sergej Jurecko wrote:
> hello,
>
> We've put up a documentation page with more info.
>
> http://www.actordb.com/docs.html
>
> Hopefully it answers more questions than it raises. If not fire away.
>
>
> Sergej
>
> On Jan 22, 2014, at 10:19 PM, Valery Meleshkin wrote:
>
> > Hi Sergej,
> >
> > Which algorithms were used to build it? How its architecture looks like? How testing process looks like?
> > Specifically I’m interested in the details of replication, inter-actor transaction coordination, replica placement and membership service (e.g. raft/paxos/2pc/ 2pc over paxos ensembles/…).
> >
> > --
> > Sincerely,
> > (Mr.) Valery Meleshkin
> >
> >
> >
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://erlang.org/mailman/listinfo/erlang-questions
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
More information about the erlang-questions
mailing list