<div>Thanks for replies.</div><div>I just know why it takes so long time to start up mnesia.</div><div><br></div><div><br></div><div>It looks fine to work except long time mnesia startup.</div><div>But it's getting worse problem because the number of tables are increasing.</div>
<div><br></div><div><br></div><div>Most of tables have same personally.</div><div><br></div><div>The maximum size(whichever 2GB or 4GB) limit of dets was main problem to use single table.</div><div>I needed short response from mnesia but I wasn't sure that fragmentation is right choice.</div>
<div><br></div><div>so I used lots of tables instead of it.</div><div><br></div><div>Some of table's size are about 50M Bytes. (about 130k no_objects(same no_keys))</div><div>Some of table's size are about 30K Bytes. (about 100 no_objects(same no_keys))</div>
<div><br></div><div><br></div><div>Is the fragmentation only way to reduce mnesia startup time?</div><div><br></div><div>thanks</div><div><br></div><br><div class="gmail_quote">On Fri, Apr 13, 2012 at 2:53 PM, Ulf Wiger <span dir="ltr"><<a href="mailto:ulf@feuerlabs.com">ulf@feuerlabs.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
<br>
On 13 Apr 2012, at 00:31, Richard O'Keefe wrote:<br>
<br>
><br>
> On 12/04/2012, at 9:26 PM, Ulf Wiger wrote:<br>
><br>
>><br>
>> Hmm, the first thing that stands out is the inordinate number of tables.<br>
>><br>
>> Out of curiosity, I tried figuring out what is considered a reasonable number of tables for other database management systems:<br>
>><br>
>> - Oracle: over 10,000 tables considered insane<br>
>> (<a href="http://asktom.oracle.com/pls/asktom/f?p=100:11:::::P11_QUESTION_ID:26039880025641" target="_blank">http://asktom.oracle.com/pls/asktom/f?p=100:11:::::P11_QUESTION_ID:26039880025641</a>)<br>
><br>
> That page has no claim that *Oracle* cannot handle it.<br>
> The arguments given are<br>
> - that it seems extremely unlikely that people could "design,<br>
> implement, or maintain" a system with 10,000 distinct tables<br>
> "personally".<br>
</div>…<br>
<br>
Fair enough. My point was mainly that 60k tables is well beyond what most database management systems are optimized for. The question is obviously here what _nmesia_ is good at, but I just wanted to illustrate that if you want to build a database with 60k tables, you shouldn't _assume_ that any given dbms will handle it well.<br>
<br>
As far as mnesia is concerned, there are a number of commonly used functions that are reasonable as long as the number of tables is somewhere in the hundreds.<br>
<br>
Take, for example, mnesia:wait_for_tables/2. Let's assume that our application actually needs those 60k tables to be loaded before it starts doing things.<br>
<br>
wait_for_tables/2 is basically implemented like this (lots of code snipped):<br>
<br>
wait_for_tables_init(From, Tabs) -><br>
process_flag(trap_exit, true),<br>
...<br>
cast({sync_tabs, Tabs, self()}),<br>
rec_tabs(Tabs, Tabs, From, Init)<br>
end.<br>
<br>
rec_tabs([Tab | Tabs], AllTabs, From, Init) -><br>
receive<br>
{?SERVER_NAME, {tab_synced, Tab}} -><br>
rec_tabs(Tabs, AllTabs, From, Init);<br>
...<br>
end;<br>
rec_tabs([], _, _, Init) -><br>
unlink(Init),<br>
ok.<br>
<br>
To begin with, if the objective was to support tens of thousand tables, it would be better to provide functions to efficiently query the 'table of tables'. Currently, there is no table of tables, but a system_info(tables), which provides them all as a list (including 'schema', which you often must delete from the list, since you can't, for example, do wait_for tables on the schema).<br>
<br>
In the code above, mnesia sends the 60k list of tables in a single message. It then loops through the list and does selective receive on the replies belonging to each. This is a convenient way to do it when the list of Tabs is short, but pretty awful for a very large list, since each iteration may end up scanning a rather large message queue.<br>
<br>
This was just one example. Mnesia was not designed with this sort of thing in mind.<br>
<br>
BR,<br>
Ulf W<br>
<div class="HOEnZb"><div class="h5"><br>
Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.<br>
<a href="http://feuerlabs.com" target="_blank">http://feuerlabs.com</a><br>
<br>
<br>
<br>
</div></div></blockquote></div><br>