<div dir="ltr">Also, Mnesia focuses on the CA in CAP, and doesn't behave very nicely when you get a split cluster that you then have to bring back into line. The pain of changing the records can be mitigated somewhat by having a single base record type that you store that's basically just a key/value pair (-record(document, {doc_id, doc}) for example) with your changing data held in the value part...but that makes a lot of operations just a bit more complicated than they otherwise would be and you have to do a lot more work yourself.<div>
<br></div><div style>If you have a system design which isn't going to change and is going to remain on a single server Mnesia might just work for you, but if you're looking at any sort of distributed or changing application architecture you might want to consider another solution. </div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jun 2, 2013 at 1:19 AM, Yash Ganthe <span dir="ltr"><<a href="mailto:yashgt@gmail.com" target="_blank">yashgt@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The Mnesia documentation says:<br>largest possible mnesia table (for now) is 4Gb<br><br>A table can be distributed across nodes so that part of it remains on one node and part on another. In a distributed sense, does this mean 4GB per table per node, or 4GB per table across nodes?<br>

<br>Is there a way by which Mnesia can be used in a system that will store about 100GB of data in some tables and support ACID properties just like popular RDBMS's like MySQL/Oracle?<br><br>Thanks,<br>Yash<br>
<br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>