Mnesia disk performance (was RE: multi-attribute mnesia indexes?)

Sean Hinde Sean.Hinde@REDACTED
Tue Jan 2 14:30:25 CET 2001


> One thing about mnesia is that it's not really prepared for
> applications that write constantly to disk-based tables.

It is not optimal I agree. There are some relatively simple things which
could be done to improve this though.

One simple idea would be to have independently specified paths to the
various log and dets files. Certainly having the log file on its own disk
could substantially increase performance of the dumper.

Files could also be striped across multiple disks using RAID type systems.

Another more complex enhancement would be to treat the log file as a simple
recovery log and use a memory based store as the actual source for data to
be propogated into the dets files. This could even just contain a list of
keys which have been updated in each transaction and the dumper could get
the data from the main memory table (with some extra stuff for detection of
multiple updates of the same record. Hmmm).

Or there could be a separate UNIX thread which runs through the log and does
the propogation into the main dets files.

I'm sure there are many things which can be done - though splitting out the
path of the different files could perhaps be the simplest and most effective
(allowing one to throw more hardware bandwidth at the problem).

- Sean



NOTICE AND DISCLAIMER:
This email (including attachments) is confidential.  If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents.  We cannot accept liability for any breaches of
confidence arising through use of email.  Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions.  We will not accept responsibility for any commitments
made by our employees outside the scope of our business.  We do not warrant
the accuracy or completeness of such information.





More information about the erlang-questions mailing list