Mnesia dB size limits

[Yariv Sadan]

AFAIK the problems with Mnesia isn't that you can't insert a lot of
data into it, but the following:

1) in the event of a crash, a very large dets table takes a long time to repair.
2) there are no join optimizations (yet), so some queries can take a
long time to process
3) as the dets freelist gets fragmented it consumes more and more memory.

None of these items means you can't put a lot of data in Mnesia --
they just mean that you may run into problems if you do.

With ets tables, issues 1) and 3) go away.

Yariv

On 8/30/06, Joel Reymont <joelr1@REDACTED> wrote:
> I have a suspicion that when people mention that Mnesia is great with
> huge data sets they unintentionally forget to mention important
> details. My understanding is that call record databases are insert/
> retrieve only or for the most part.
>
> When people outside of the telco world ask about Mnesia they usually
> have MySQL, etc. in mind and wonder about insert/delete/update
> performance. My understanding at the moment is that Mnesia is not the
> best database for insert/update/delete, much less with huge databases.
>
> Please correct me if I'm wrong!
>
> On Aug 30, 2006, at 4:10 PM, Philip Robinson wrote:
>
> > I was once writing a program that needed to retrieve events
> > within a date/time range from an mnesia table, and found that it
> > did not seem to be hitting the index.  It would scan the entire
> > 1-million-plus records every query... dead slow.
> >
> > When I wanted to retrieve a specific event there was no noticable
> > delay, but most of my queries were for a date/time range.
> >
> > I think the mnesia issues being mentioned on this list were to do
> > with database recovery across nodes after a node failure...?
>
> --
> http://wagerlabs.com/
>
>
>
>
>
>