ets vs. mnesia ram_copies

Shawn Pearce <>
Tue Mar 11 21:27:08 CET 2003

Thanks, that was basically what I was looking for, I guess.  :)

My intent is to do writes through a normal transaction, as right
now all writes are serialized anyway through a server process.  I
would rather to have the transaction semantic of being able to rollback
and have it be slower, then not have it.  The writes aren't my problem.
Its the reads. :)  If I went with Mnesia, I'd pretty much have to use
a dirty read of some sort.

As it is, I really need a couple of indexes defined on my data, so
writes aren't that fast to begin with, and won't be that fast with
Mnesia.  I'm all about read speed.  :)

Wiger Ulf <> wrote:
> I guess we're comparing dirty_read() to ets:lookup() and
> dirty_write() to ets:insert()? Transactions will of course be much
> slower, but it's not really fair to compare that to ets, since the
> semantics differ.
> First of all, you can get *almost* ets performance by writing
> like this:
> mnesia:activity(
>    Type = ets,
>    fun() ->
>       [#obj{value = Val} = Obj] = mnesia:read({obj, Key}),
>       mnesia:write(Obj#obj{val = foo(Val)})
>    end).
> where Type can be ets | dirty | sync_dirty | transaction | sync_transaction
> When Type == ets, the mnesia:read() and mnesia:write() functions are
> translated to ets:lookup() and ets:insert(), with minimal overhead
> (basically
> a get() and a couple of external function calls for each and a get_env()
> (an ets:lookup() to determine the access module for mnesia -- can be avoided
> if you provide it explicitly.)
> If you're doing dirty_write (e.g. with Type=dirty), mnesia will have to
> perform some checks, each being basically an ets:lookup():
> 1) record validation (proper record name and attributes)
> 2) where_to_read (finding out where the physical table is)
> 3) sending the request to mnesia_tm process and awaiting the result
> 4) a number of other meta-data lookups (indeces, storage_type, replication)


  Your reasoning powers are good, and you are a fairly good planner.

More information about the erlang-questions mailing list