Fragmented tables in Mnesia
Ulf Wiger
etxuwig@REDACTED
Thu Jul 10 00:12:52 CEST 2003
On Wed, 9 Jul 2003, Erlang Questions wrote:
>Hi, everyone.
>
>Does someone know if it implies lose of performance using
>mnesia:activity to execute reads and writes in a fragmented
>table?
There is an overhead of one ets:lookup() per read or write
operation when you use the mnesia_frag callback for
non-fragmented tables. This should be regarded as
negligible.
>My question goes to indiscriminately use mnesia:activity
>even in those cases where the table is not fragmanted
>(yet). This way, the final user could make its own
>fragmentations whenever he wants without having to change
>any code line. It will be a good option if there is no
>significative overhead in using such function.
You could also make sure that you always use your own
function, myDbLib:activity(Kind, Fun), which could start by
calling mnesia:activity(Kind, Fun), and later perhaps call
mnesia:activity(Kind, Fun, mnesia_frag).
>Or maybe there is some other way to prevent code of
>writting or reading from a table that could be fragmented
>in the future. I am new in the "Mnesia Table Fragmenters
>Club" and my experience is based on the examples found in
>the documentation.
I would not recommend that. My recommentation is to use your
own wrapper to mnesia:activity() right from the start. It
gives you the most flexibility and "no" overhead. To
reiterate, the overhead when using mnesia_frag for
non-fragmented tables is minimal, but there is no reason to
lock yourself into forever using the mnesia_frag callback
either. There are other custom callback modules, e.g. rdbms,
and your future requirements may cause you to outgrow
mnesia_frag as well. You may even end up wanting to write
your own callback module (it's not that difficult). The
trick then is not to have mnesia_frag hard-coded in 4711
different places.
/Uffe
--
Ulf Wiger, Senior Specialist,
/ / / Architecture & Design of Carrier-Class Software
/ / / Strategic Product & System Management
/ / / Ericsson AB, Connectivity and Control Nodes
More information about the erlang-questions
mailing list