[erlang-questions] Desing of MVC models

[Garrett Smith]

On Mon, Sep 16, 2013 at 6:24 AM, Jesper Louis Andersen
<jesper.louis.andersen@REDACTED> wrote:
>
> On Sun, Sep 15, 2013 at 10:44 PM, Ludovic Demblans <ludovic@REDACTED>
> wrote:
>>
>> Hi Jesper, i don't really understand why you advise me to use a very
>> fast DB, (like voltDB) because your previous point was that if things
>> are kept in state, storing it to the database should only be done from
>> time to time (like just after killing a big boss).
>>
>> I want my models transient (even implemented as regular gen_servers),
>> but i don't want to brutal-kill them : I just ask them gently to
>> terminate and to store their data before. So they have time to do so.

It's hard to guarantee a graceful shutdown of processes, servers, etc.
so if you can avoid relying on a shutdown message, it's a good idea.
E.g. Jesper's suggestion of write backs on idle (or interval) is the
right thinking IMO.

> I am just trying to say that this model will scale quite well. Since you
> will have relatively few write-backs to stable storage. Also note you will
> have very few reads compared to writes in this model. So write-centric
> database systems can also do well in this scheme. Cassandra comes to mind,
> but I don't like it too much.

One of the nice things about the process oriented approach that Erlang
encourages is you can start thinking about federating data storage --
something that's closer to 1:1 with your process state. E.g. if a
process is managing a few MB of state (a lot for a single user in most
applications) it's trivial to push this data around a network. I've
used something as simple as writing to a local dets file and then
pushing that over a network for backup / restore. Heck, gziping
term_to_binary(State) is probably enough in many cases.

Smart people will probably criticize this as "rolling your own
distributed database" -- which is fair. But I like the idea of making
each process responsible for its state, both in loading and persisting
[1]. Whether you use something naive like a local file and push to a
remote location or something like Riak - it's the same idea.

Garrett

[1] The actual responsibility of loading/saving might be best
implemented by *another* process -- but the idea here is that each
process is responsible for its own state, whether it does so itself or
uses a helper.