volunteer wanted to write a few FAQ entries about Mnesia
Fri Feb 21 05:59:53 CET 2003
On Thu, 20 Feb 2003 16:35:06 -0600
Chris Pressey <> wrote:
> On Thu, 20 Feb 2003 11:26:13 +0100
> Matthias Lang <> wrote:
> > Hi,
> > The Mnesia section of the FAQ has been embarassingly barren for far
> > too long.
> > I know zilch about mnesia, so I need a volunteer to write that chapter
> > (or help me write it, I'm happy to take care of the formatting and
> > editing). Mail me if you can help.
> > The alternative is to remove the chapter entirely. Which seems a shame
> > because there are some interesting mnesia-based applications around.
> I can try to make it a bit less barren. I'll post it to the list in
> case anyone wants to review it and perhaps catch my mistakes (I haven't
> used Mnesia for a while now.)
(As usual I have no idea what I'm talking about... I use Mnesia all the
time, but I've written wrapper functions around mnesia calls, and I don't
tinker with mnesia directly that much, so I rarely think of it that way.)
> What is Mnesia good at?
> Locking and Transactions - if you need to keep a database that will be
> used by multiple processes and/or nodes, using Mnesia means you don't
> have to write your own access controls.
> Distribution - tables can be replicated at many nodes, both for
> efficiency(database lookup is a local activity) and robustness
> (redundancy means if one node goes down, other nodes still have copies
> of the data.)
> Non-fully-normalized data - unlike most database systems, records can
> contain data of arbitrary size and structure.
even funs and pids.
> Monitoring - processes can subscribe to events which are sent when
> various operations on the data take place (update, delete, etc) The
> RDBMS package allows even more fine-grained control.
It's nice and simple (relatively speaking) as well, and written in Erlang.
> What is Mnesia not so good at?
> It's not as quick as ETS for when you don't need locking, etc.
Mnesia is based on ETS, so it has the same limitations of being primarily
a memory-resident database.
Records are accessed by a single key (which may be unique or duplicate)
and there is no concept of a secondary key. Typically one can use a tuple
for the primary key instead, perhaps at the small cost of duplicating some
information in the record.
Mnesia itself can't intercept a request to update or delete a record, but
the RDBMS module can do that for it.
Really large tables must be stored in a fragmented manner.
More information about the erlang-questions