[erlang-questions] "actor database" - architectural strategy question

[Sergej Jurecko]

Each actor is isolated and independent. This is why using sqlite is completely scalable. I thought it would be quite clear that it fits your ideas well. So let me expand more on your questions.


>>> 
>>> 
>>> 1. So far, I haven't seen anything that actually looks like an "actor-oriented database."  Document databases implemented in Erlang, yes (e.g., CouchDB), but every example I find ultimately pushes persistent data into files or a more conventional database of some sort.  Can anybody point to an example of something that looks more like "storing actors in a database?"
>>> - It strikes me that the core issues with doing so have to do with maintaining "aliveness" - i.e., dealing with addressability, routing messages to a stored actor, waking up after a timeout (i.e., the equivalent of triggers)
>>> 

Storing the actor state in an sql database gives you the most flexible data model. All the issues you listed are something actordb deals with.

>>> 2. One obvious (if simplistic) thought: Does one really need to think in terms of a "database" at all - or might this problem be approached simply by creating each document as an Erlang process, and keeping it around forever?  Most of what I've seen built in Erlang focuses on relatively short-lived actors - I'd be really interested in comments on:
>>> - limitations/issues in persisting 100s of 1000s, or maybe millions of actors, for extended periods of time (years, or decades)
>>> - are there any tools/models for migrating (swapping?) inactive processes dynamically to/from disk storage
>>> 

ActorDB will keep an actor open while it is doing something. Once it stops doing stuff it is closed and remains untouched on disk until it is used again.

>>> 3. What about backup for the state of a process?  'Let it crash' is great for servers supporting a reliable protocol, not so great for an actor that has  internal state that has to be preserved (like a simulated tank, or a "smart document"). Pushing into a database is obvious, but...
>>> - are there any good models for saving/restoring state within a tree of supervised processes?
>>> - what about models for synchronizing state across replicated copies of processes running on different nodes?
>>> - what about backup/restore of entire Erlang VMs (including anything that might be swapped out onto disk)
>>> 

ActorDB will replicate state to multiple servers.

>>> 4. For communications between/among actors:  Erlang is obviously excellent for writing pub-sub engines (RabbitMQ and ejabberd come to mind), but what about pub-sub or multicast/broadcast models or messaging between Erlang processes?  Are there any good libraries for defining/managing process groups, and doing multicast or broadcast messaging to/among a group of processes.
>>> 

This is where a separation of code and data comes in. A use case that ActorDB could easily be expanded to do (without a lot of work). ActorDB handles the storage and persistence of state. The application programer implements his program logic in his own code.

ActorDB could provide "triggers". For instance you have an actor (some gen_server) running on a node:
- When it wants to store the result of some work, it stores it in his actor in ActorDB. 
- If it wants to send a message to one or many actors, he would create a write transaction to multiple actors. The transaction would do an insert to their "events" table. ActorDB would then callback your own code for every one of those actors and tell them there is work for them to do. This way no event is ever lost.
- If you just want to send non-persistent messages to erlang processes you can use pg or pg2 modules and sidestep ActorDB. Or maybe it makes sense to support sending non-persistent messages through ActorDB and rely on it to route those messages to the right processes on the right nodes.

Callbacks could be directly within erlang or externally connected with http or zeromq. So your app logic can be implemented in anything.


Sergej

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140217/8572f187/attachment.htm>