[erlang-questions] generic replication bahaviour

[Scott Lystig Fritchie]

Replying to a thead from last week....

Johan Montelius <johanmon@REDACTED> wrote:

jm> has anyone played around with a generic replication behaviour in the
jm> style of gen_server?

No, sorry.  But before doing such a thing, I think you need to put some
thought into what "replication" means vis a vis Brewer's CAP theorem.
Or more perhaps more usefully(*), the spectrum of consistency
vs. availability.

Then (perhaps?) deciding on an implementation that's based on a state
machine replication technique or a quorum-based technique.  The choice
of technique may help drive what kind of metadata you're going to
require for each thingie stored.  Are the thingie's key-value pairs, or
something else?  Do you require monotonically-increasing timestamps or
vector clocks or something else?  Does the behavior always resolve
consistency ambiguity or push those decisions to the client, and how the
client app inform the behavior of its choice?

If you're dealing with disk-based persistence, then any Erlang process
that's doing disk I/O can block at very inconvenient times for very
inconvenient lengths of time.  Syncronous replication across a network
(even a fast LAN) can result in similiar inconveniences, at least in
terms of Murphy's Law.  The sum of these inconveniences can easily tip
an implementation into the "Won't work for my app" category.

Just things off the top of the cuff of my head.  :-) I'll make a blind
guess and say that this is why key-value stores such as Dynomite,
Scalaris, Riak, Ringo, Scalien, and others are already "out there"(**)
and useful: they choose a path through the maze of choices above and
then do it well.

-Scott

(*) Reading Brewer's writings about CAP and then the Gilbert & Lynch
proof, the formal definition of "P" is a tricky thing.

(**) Sorry, Hibari hasn't been released yet, contrary to what my Erlang
Factory 2010 San Francisco talk had predicted.  Mid-July 2010 is my best
guess right now.