<br>How can you upgrade the record schema when your fragment is large? The cocurrent r/w will be blocked for a long time without stopping service.
<div><span class="gmail_quote">2008/7/29, Paul Mineiro <<a href="mailto:paul-trapexit@mineiro.com">paul-trapexit@mineiro.com</a>>:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">As another opinion, arguing against a large number of fragments:<br><br>We have some large dbs as well, and we started with a large number of<br>
fragments (initially: 1260) but have actually dropped the number of<br>fragments over time (currently: 12). We're using EC2 as we found that<br>introducing a new node or removing an old one went faster with less<br>fragments. Also we have several dbs like this and it was more challenging<br>
to inspect mnesia's state when the total number of tables in the system<br>was circa 10000. Finally, with dets there is some memory overhead per<br>fragment that we never completely understood (the "buddy system"), but<br>
we found less fragments meant less memory usage.<br><br>One disadvantage of fewer fragments is that, since it is relatively cheap<br>to move fragments versus repartition, starting with a larger number of<br>fragments allows for relatively straightforward load balancing when<br>
introducing new nodes, until you get to the point where you have a<br>fragment for each node. However, lately we've been running the bigger EC2<br>instance types and using tcerl for the backend and so our node count has<br>
been reduced from 24 to 6, thus we could afford to reduce the number of<br>fragments.<br><br>-- p<br><br>On Mon, 28 Jul 2008, Valentin Micic wrote:<br><br>> We used to have up to 200 million records (+200 million for indices,<br>
> therefore 400 million) in a production system, spread over 896 fragments<br>> (768 for data and 128 for indices (*)) and that worked reasonably well (all<br>> of that on a single node) - the tested limit on that particular system was<br>
> more than 2*250 million records.<br>><br>><br>><br>> Eventually, due to an increase in performance requirements (750 million<br>> rows/records and significantly higher transaction rates) we decided to drop<br>
> MNESIA in subsequent releases of the system (and no, we did *not* replace it<br>> with any of commercially available RDBMSes). Mind you, the main reason was<br>> really considerable skepticism expressed in this forum regarding suitability<br>
> of MNESIA for large data volumes (**).<br>><br>><br>><br>> At any rate, I cannot tell you how big the largest fragment was (not in<br>> terms of bytes anyway), but we did not store more than 300,000 records per<br>
> fragment. Our performance requirement was to service 100 transactions per<br>> second with sub 100 ms response time. These criteria were compromised<br>> whenever we approached this load per fragment -- response time would<br>
> increase to 150-180 ms, or even more when we had lots of deletions).<br>><br>><br>><br>><br>><br>> V.<br>><br>><br>><br>> (*) Please note that standard MNESIA indexing is not recommended for<br>
> fragmented table. Rather, as Ulf suggested once, use another (first-class)<br>> mensia table to do indexing yourself.<br>><br>><br>><br>> (**) Truth be told, I do not think that we would have even consider MNESIA<br>
> if we were exposed to these kind of views before we actually developed the<br>> system. Fortunately, we did not, thus, we had two very successful system<br>> releases before we abandon the MNESIA, and by that time, we were quite<br>
> capable of developing a custom storage mechanism that would satisfy new<br>> requirements. What I'm trying to say is: even if it is not the best<br>> long-term choice, MNESIA can be used to buy you some valuable time while<br>
> you're still figuring out what (and how) you're trying to do (it).<br>><br>><br>><br>><br>><br>> _____<br>><br>> From: <a href="mailto:erlang-questions-bounces@erlang.org">erlang-questions-bounces@erlang.org</a><br>
> [mailto:<a href="mailto:erlang-questions-bounces@erlang.org">erlang-questions-bounces@erlang.org</a>] On Behalf Of devdoer bird<br>> Sent: 28 July 2008 12:28 PM<br>> To: Valentin Micic<br>> Cc: <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
> Subject: Re: [erlang-questions] How many fragments would be proper<br>> for1milions records in mensia?<br>><br>><br>><br>><br>><br>> 2008/7/28, Valentin Micic <<a href="mailto:valentin@pixie.co.za">valentin@pixie.co.za</a>>:<br>
><br>> I'd say that also depends on what storage method you're using. Thus, in a<br>> case you're planning to use DETS (disc_only_copy), you may want to consider<br>> fragmentation even for 1 million... In my experience, the performance<br>
> deteriorates(*) when table gets populated beyond, say, 250,000 entries (if<br>> entries are reasonably complex terms).<br>><br>><br>><br>> Oh,that will be a problem.Can I say mnesia is not proper for very large<br>
> data-set?<br>><br>> If I keep every fragment 250,000 records, then 100 million records will be<br>> distrubted in<br>><br>> 400 fragments,is it a problem for mnesia?<br>><br>> What's the size of your largest mnesia table in your application ?<br>
><br>><br>> In addition, if you increase a number of dets fragments, make sure that you<br>> also increase a number of I/O threads (+A) to some reasonable value(**).<br>><br>> V.<br>><br>> (*) Inserts and/or updates are affected, read seems to keep good performance<br>
> levels.<br>><br>> (**) If you are using 32-bit environment, try not to get carried away with a<br>> number of I/O threads, as the cost in memory may be substantial.<br>><br>> ----- Original Message ----- From: "Ulf Wiger" <<a href="mailto:ulf@wiger.net">ulf@wiger.net</a>><br>
> To: "devdoer bird" <<a href="mailto:devdoer2@gmail.com">devdoer2@gmail.com</a>>; <<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a>><br>> Sent: Sunday, July 27, 2008 10:12 AM<br>
> Subject: Re: [erlang-questions] How many fragments would be proper for<br>> 1milions records in mensia?<br>><br>><br>><br>> Depending on object size, you may well have just a single<br>> table/fragment. 1 million objects is not that much.<br>
><br>> BR,<br>> Ulf W<br>><br>> 2008/7/27, devdoer bird <<a href="mailto:devdoer2@gmail.com">devdoer2@gmail.com</a>>:<br>><br>> Hi:<br>><br>> Considering the access performance , easy mangement ,how many fragments<br>
> would be proper for 1 milions records in mensia? Are there any rules about<br>> the number of fragments and the number of total records?<br>><br>> Regards<br>><br>> _______________________________________________<br>
> erlang-questions mailing list<br>> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>> <a href="http://www.erlang.org/mailman/listinfo/erlang-questions">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br>
><br>><br>><br>><br>><br>><br><br>In an artificial world, only extremists live naturally.<br><br> -- Paul Graham<br>_______________________________________________<br>erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br><a href="http://www.erlang.org/mailman/listinfo/erlang-questions">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br></blockquote>
</div><br>