[erlang-questions] Support for newcomers and the popularity of Erlang

[Wojciech Knapik]

On Mon, Mar 19, 2012 at 05:38:37PM +0100, Ulf Wiger wrote:

> I much prefer to have a slightly more strict setup, where you e.g.
> designate one or two "master" machines that keep a persistent copy of
> the database. The other machines can start up with the env variable:
> extra_db_nodes : MasterNodes, and access the database without even
> having their own copy.
 
Let's assume for a moment, that full replication is indeed unnecessary.
We still want to run identical nodes. Or at least the static code
delivered to all nodes should be the same and runtime decisions should
designate a master node. That is not trivial. Would we have to
"manually" implement an election algorithm, or are there any Erlang
mechanisms that would make this simpler ? If "manual" is the answer,
then would you suggest any specific algorithm ?

> Why does the data need to be fully replicated? Nodes starting with
> extra_db_nodes as above enjoy full distribution transparency. If very
> rapid read response is required, you can add a ram-based replica on
> the fly with the function mnesia:add_table_copy_type(Table, Node,
> CopyType). 
> 
> Update cost will increase noticeably with every replica you add, so in
> many cases, it may be counter-productive to use full replication. For
> fault tolerance, having two persistent copies of the data goes a long
> way.

The project's domain is completely dominated by client-server solutions
where the central server is a weak point in terms of fault tolerance,
performance and scalability. A completely explicit configuration on the
server is also very rigid - it doesn't allow the system to adapt to
changing conditions and forbids a number of features that could exist in
a fully distributed setup.

So we aim to push the distribution aspect as far, as it makes sense, to
fix these issues. 

>From what everyone here is saying, full mnesia replication will give us
fault tolerance, but at a severe cost to scalability and performance.
On the other hand we want to avoid the necessity for the user to
explicitly specify nodes that would be special in any way. In fact the
user can't know that in advance, because nodes can go offline, or become
overloaded, or whatever. And last, but not least, in the spirit of
declarativeness - the user shouldn't be bothered with these details -
it's up to the system to figure it out.

As far as what the database would be used for - it would hold the state
of the system as a whole and provide persistence even if all nodes go
down (with disc_copies). It's hard to predict a lot of details at this
point.

I know I'm being a bit cryptic, but I can't really talk about the
project without the blessing of the other team members...

So anyway - I'm guessing the problems I described are not uncommon among
Erlang programmers. How do you usually handle them ? Any feedback would
be very much appreciated.

br,
WK