[erlang-questions] How would you architecture a ...

Paul Mineiro paul-trapexit@REDACTED
Tue May 12 06:51:18 CEST 2009


On Mon, 11 May 2009, Steve Davis wrote:

> Change of question to one of a more general nature :)
>
> Is there any reason to believe that Mnesia is not suitable for a LAMP-
> scale web application stack?
>
> I've seen concerns raised here about Mnesia's use for "real web apps",
> but AFAICS none appear to say *why* a disk based mnesia schema would
> be any less capable/suitable for a moderate sized web app than say
> MySQL or (choose your favorite). I've not seen any real issues -- on
> the contrary, mnesia seems to be more responsive, and easier to manage
> in general (especially if you *don't* reboot).

My 2c.

We use Mnesia alot.  If I was starting from scratch, I would not use it in
distributed mode; I was really inspired by the Kreditor talk at the recent
Erlang Factory, where Tobbie talked about using Mnesia but in
non-distributed mode with a custom replication and query routing layer.
Clearly the guys who started that company knew a thing or two about
Mnesia.

Our major pain point is when Mnesia gets confused by network partitions,
and these happen on EC2 occasionally.  We muddle our way through those
when they happen, typically by restarting some nodes.  We also had some
performance problems related to distributed functioning, see
http://dukesoferl.blogspot.com/2008/08/scaling-mnesia-with-localcontent.html
for some details.

In a remaining case where performance was an issue, we replaced an mnesia
table with a custom database in Erlang which was block oriented and very
efficient wrt I/O.  We expected to have to rewrite portions of that in C
with a linked-in driver but that has not been necessary, surprise.

So that's all the bad.  The good is, it's very nice to program, very
functional-y.  You can store arbitrary terms in Mnesia so it's not hard to
arrange for what amount to schema migrations without ever transforming
existing data.  You can use tuples as keys in ordered set tables and
select a bound prefix efficiently, which often comes in handy.

However it's not relational ... for the stuff we do, there's never enough
time to do anything relational while serving so data is denormalized
anyway, but for some (many?) applications a relational back-end surely
makes programming go faster.

Cheers,

-- p

>
> /s
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>

In an artificial world, only extremists live naturally.

        -- Paul Graham



More information about the erlang-questions mailing list