Fragmented tables in Mnesia

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Fragmented tables in Mnesia

Michał Ptaszek
Hi, everyone.

Does someone know if it implies lose of performance using mnesia:activity to execute reads and writes in a fragmented table?

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.

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.

Thanks in advance, Carlos.-
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20030709/e9027d92/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Fragmented tables in Mnesia

Ulf Wiger-4
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


Reply | Threaded
Open this post in threaded view
|

Fragmented tables in Mnesia

Håkan Mattsson-6
On Thu, 10 Jul 2003, Ulf Wiger wrote:

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

As alternative to insert tons of calls to your own activity function
myDbLib:activity(Kind, Fun), you could start by using the normal
Mnesia API. Later when you feel a need of it, you can change the
Mnesia access_module configuration parameter to some customized
access callback module (mnesia_frag, rdbms, my_own_callback...)
without doing any changes to your old code.

/H?kan

---
H?kan Mattsson
Ericsson
High Availability Software, DBMS Internals
http://www.ericsson.com/cslab/~hakan/



Reply | Threaded
Open this post in threaded view
|

Fragmented tables in Mnesia

Ulf Wiger (AL/EAB)
From: "Hakan Mattsson" <hakan>
>
> As alternative to insert tons of calls to your own activity function
> myDbLib:activity(Kind, Fun), you could start by using the normal
> Mnesia API. Later when you feel a need of it, you can change the
> Mnesia access_module configuration parameter to some customized
> access callback module (mnesia_frag, rdbms, my_own_callback...)
> without doing any changes to your old code.

True. I'd still opt for the access library approach, but most likely not
just one, but one per (loosely put) category. It still leaves some
additional options, e.g. that you can easily change semantics from
transaction to synch_transaction, if stress test indicate that you get
better characteristics that way. This of course assumes that the
access library function wraps the "activity kind" parameter, and
doesn't let that leak out of the access API. For a given category
of data, you'd probably not want to mix different activity kinds anyway.
There are other tricks one can pull with a private access API, for
example during tricky upgrades, but that's a whole different story.

A matter of programming preferences, perhaps.

/Uffe