[erlang-questions] Mnesia: Whether it is good for my application! help?

[aman mangal]

Hi,

Thank you so much for your response!
On one side I tend to use mnesia because it is free and can be used on
distributive nodes, on the other hand I am not very much aware of the
shortcoming of mnesia. So there is always a question in front of me whether
to what extend can mneisa handle things easily. I tried reading some
article on internet like learnyousomeerlang.com, looked at erlang
documentation but couldn't understand the limitations of mnesia. It will be
very nice if you can give me some pointers where I can understand the
internals of mnesia properly and use it accordingly.

About my back up node, the process group has some specific name or id. I'll
prefix the table names with the unique id. Each process group serves a
specific group of people(say). I am using back up node for failover case so
that I don't lose data. It is important not to lose data. Are you saying
that saving it on the disk on the same node is enough? No need to store on
the other node? disk failure is rare and in that case I've data in
RAM(mnesia). The capacity of servers like RAM, disk space can be assumed as
much as we want.

Aman Mangal
3rd year Undergraduate
Department of Computer Science & Engineering
IIT Bombay
www.cse.iitb.ac.in/~amanmangal


On Tue, Apr 2, 2013 at 9:23 PM, Magnus Henoch
<magnus@REDACTED>wrote:

> aman mangal <mangalaman93@REDACTED> writes:
>
> > Hi everyone,
> >
> > This is my first post on this forum! I am new to erlang, just started
> using
> > it a month ago or so. Since I have come across erlang, I have become
> such a
> > big fan of it that I have started working on a product in erlang for a
> > company.
> >
> > Coming to the point, here is my question. I want to make
> > a distributive application. There are multiple processes running on a
> node.
> > The processes are divided in logical groups. Each group serves a specific
> > purpose. Each group has some data(few tables) shared among the processes
> > inside the group but not outside the group. Now my question is that
> whether
> > to use mnesia or not to store the data? If I don't use mnesia, I'll store
> > the data as state in a gen server processes running in the group. In that
> > case I don't know how will I will keep back up of the data for the case
> > when any node goes down.
>
> It sounds like Mnesia would be a good fit.  You would get persistence
> for free by creating your tables with disc_copies.  The only potential
> issue I see is table names: each Mnesia table must be named by an atom.
> Are your process groups created dynamically?  If so, you'd need to come
> up with a scheme to get the correct table names from within the
> processes that need to access the tables.  You'll also need to use the
> record_name option when creating the tables, as by default Mnesia
> requires you to use records with the same name as the table.
>
> > Also my database can grow as large as thousand tables each having hudred
> > entries on a node. Is mnesia a good idea to use for such a large (I'm not
> > sure whether it is large :P ) database? Is there any free alternative to
> > mnesia? Please note that there is no inter node communication in order to
> > get data except with the back up node!
>
> Assuming each entry takes no more than a kilobyte, you're looking at
> roughly 100 megabytes of data in total.  When using the disc_copies
> table storage type, Mnesia will store the entire database in memory as
> well as on disk, but I presume that you have enough RAM that 100
> megabytes isn't a big problem.
>
> Could you elaborate on your backup node setup?  If you want your data to
> be distributed to protect against disk failure on the main node, then
> Mnesia distribution is probably the way to go, but depending on your
> requirements you might be able to get away with a simpler solution.
>
> Hope this helps,
> Magnus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130404/b38924eb/attachment.htm>