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

David Gould dg@REDACTED
Wed Jan 3 21:07:21 CET 2001

On Tue, Jan 02, 2001 at 10:05:56PM +0100, Andi Kleen wrote:
> On Tue, Jan 02, 2001 at 03:49:16PM -0500, Shawn Pearce wrote:
> > Oracle does this with their database and it is a big performance
> > booster.  The other thing they do is allow a table to be striped
> > across multiple disks by making a table exist in multiple file system
> > files at once.  (They stripe disk allocations across the files.)  This
> > does help to manage larger tables as well.
> Near all modern OS can do that themselves using volume managers and software
> RAID -- it would probably be a waste of time to implement it in Mnesia too.
> -Andi

(Psst, Andi, what are you doing on this list? ;-) )

Anyway, it is still very worthwhile to be able to place tables and indexes
by name from the DB or application and not rely on raid or lvm systems to
do this automagically. The DBA or app designer can know quite a lot about
access patterns and paths and use this to assign table fragments and indexes
that are used at the same time to separate spindles or even controllers/buses.
And one almost always wants to place transaction (undo/redo) logs on separate
spindles/paths from data spaces.

It is useful to have an lvm or raid system to make manageing storage easier
and safer and more flexible, but in the end, you need to be able to place
specific chunks'o'stuff (technical database term) onto specific logical
volumes or raid sets anyway to be able to control parallism of
spindles/actuators and not overload controllers or buses.

How hard would it be to add the capability of specifying a path of some
kind to mnesia/dets tables/indexes/logs ets?


David Gould                                                 dg@REDACTED
SuSE, Inc.,  580 2cd St. #210,  Oakland, CA 94607          510.628.3380
why would you want to own /dev/null? "ooo! ooo! look! i stole nothing!
i'm the thief of nihilism! i'm the new god of zen monks."

More information about the erlang-questions mailing list