[erlang-questions] "actor database" - architectural strategy question
Mon Feb 17 22:05:42 CET 2014
Ahh... thanks! Now I know what to look for as a start perusing the
riak_core architectural documents.
Re. a couple of your other points:
Michael Radford wrote:
> I was addressing exactly your second point: backing up and restoring actors.
> Since you brought up that point, it didn't sound like an "actor" in
> your model is 1-1 with an Erlang process for all time. So OK, you can
> checkpoint them and restart them. But what if you want the "actor" to
> continue to "respond to messages" when any single machine crashes?
> Maybe multiple Erlang processes on multiple machines can coordinate to
> provide a highly available representation of your per-document actor.
In some sense, I keep coming back to the model of paper documents - but
just a little bit "smarter."
- I have a copy of the same document at the office, at home, in my
briefcase, someone else has a copy
- updates can be distributed via copy machine and mail
- with paper, if one of them gets lost or stolen, there are other
copies, but you lose marginal notes
- add a little "intelligence" and now copies can be synced (a la what we
do with our smart phones and laptops) - with the sync logic embedded in
the document rather than the environment (which is makes the actor-like
rather than simply files or object-like)
- which does address one approach to backup - things are mirrored, if a
node crashes, there are other copies around, it's easy to restore state
(the only time things get lost is if one is running disconnected and
things crash) -- though it becomes pretty inefficient if the power
fails, or you want to reboot the machine, or what have you
> For the same reason, it sounds like you need reliable messaging, so
> that a locally-triggered change isn't lost if a machine crashes. So
> you may need to persist the update messages in multiple places.
I'm thinking that this is embedded in publish subscribe channels, with
logs/archives. I keep coming back to a USENET/NNTP model for both
messaging and replication.
> Finally, you also mentioned "copies of documents" with "local changes"
> triggering changes in other copies of the documents. What if the
> locally-triggered changes conflict?
For this, I'm thinking that each document has an embedded change control
system. Akin to having one's own copy of a git repository. (The Fossil
distributed version control system is a really nice model for this.)
> For example, a budget with a total, where any user can add or remove
> line items. To compute the current total, you need rules for resolving
> conflicting additions and removals of the same line item. Since you
> mentioned that these changes are "local" and you're sending messages
> among the document actors, it sounded like you had something like this
> in mind.
Exactly. Which is one of the things that leads me to the actor model -
embed the rules directly in each copy of the document, rather than in
> If any of these things are a concern for your application, I thought
> you might find the ideas behind riak-core helpful at least.
Thanks! I'm going off to look now!
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra
More information about the erlang-questions