<div dir="ltr"><div>The simple view of Mnesia is that it's a transaction layer on top of ETS tables, with some varying forms of backing storage. Transactions are pessimistic, based on locking. Some small optimizations have been done to the locking mechanism in recent years, but it's maybe more could be done in that area. It might also be possible to add built-in support for optimistic transactions based on timestamps or compare-and-swap, for certain usage patterns. The semantics of dirty reads/writes need to be better documented, and if possible cleaned up a bit, because the behaviour can depend on table type and whether or not the tables are local or remote. The table size problems can probably be considered to be solved by mnesia_ext with leveldb or other backends. None of this will make it less of a 90's database though. Adding eventual consistency (e.g. based on vector clocks) as alternative to transactions would make it more modern.<br><br>The big thing that would help, as Gordon mentioned, is a new distribution/replication layer. The existing one basically assumes that tables are not huge and the network between nodes is fast and reliable with netsplits being rare, like in a small cluster in a telecom base station. We use Mnesia, but not in distributed mode - we have a custom distribution layer (stable, but very limited) on top of local Mnesia instances that are not directly aware of each other.<br></div><div><br></div><div>    /Richard<br><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><br>        /Richard</div></div>
<br><div class="gmail_quote">On Wed, Oct 14, 2015 at 9:25 AM, Gordon Guthrie <span dir="ltr"><<a href="mailto:gguthrie@basho.com" target="_blank">gguthrie@basho.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Mnesia is also a pain when it partitions - you have to write your own reconciliation programmes.<div><br></div><div>There has been a lot of work done on eventual consistency in *the other* Erlang database - Riak (disclaimer I am working at Basho now)</div><div><br></div><div>Riak implements eventual consistency - and post-partition self-healing using Consistent Replicated Data Types (or CRDTs) and the canonical set of standalone CRDT libraries is written in Erlang:</div><div><a href="https://github.com/basho/riak_dt" target="_blank">https://github.com/basho/riak_dt</a></div><div><br></div><div>There is a comprehensive reading list here:</div><div><a href="https://christophermeiklejohn.com/crdt/2014/07/22/readings-in-crdts.html" target="_blank">https://christophermeiklejohn.com/crdt/2014/07/22/readings-in-crdts.html</a></div><div><br></div><div>The combination of using Klarna’s (forthcoming) leveldb backend and a CRDT eventual consistency layer on top would be an interesting start offering a distributed transactional database with eventual consistency</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Gordon</div></font></span><div><div class="h5"><div><br><div><blockquote type="cite"><div>On 14 Oct 2015, at 02:16, Richard A. O'Keefe <<a href="mailto:ok@cs.otago.ac.nz" target="_blank">ok@cs.otago.ac.nz</a>> wrote:</div><br><div><div><br>On 14/10/2015, at 6:46 am, <<a href="mailto:lloyd@writersglen.com" target="_blank">lloyd@writersglen.com</a>> <<a href="mailto:lloyd@writersglen.com" target="_blank">lloyd@writersglen.com</a>> wrote:<br><blockquote type="cite"><br>I asked Fred what it would it take to upgrade Mnesia for the 21st century (or, at least, for the next decade). He didn't know.<br></blockquote><br>There's one thing that strikes me.<br><br>I could go to a shop today and buy a 1 TB external drive for<br>NZD 75, including Goods and Services Tax of 15%.  (At least<br>that's what the ad I saw a couple of days ago said.)<br>That's almost exactly USD 50.  This is a drive that fits in<br>a shirt pocket, with room left over for all sorts of junk.<br><br>To make Mnesia a data base for the 2010s, it has to be able to<br>handle at least 1TB of data.  Heck, I've got enough goodies-for-<br>research money left that I could get the department to buy me<br>ten of these gadgets, so let's say Mnesia<br> - should be able to handle a single table in the low TB<br> - should be able to handle a collection of tables in the<br>   tens of TB<br> - where "handle" includes creating, populating, checking,<br>   recovering, and accessing in "a reasonable time".<br><br>That's a "single machine data base for the 2010s".<br>Of course there are multicore, cluster, and network issues as<br>well.<br><br><br><br>_______________________________________________<br>erlang-questions mailing list<br><a href="mailto:erlang-questions@erlang.org" target="_blank">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></div></div></blockquote></div><br></div></div></div></div><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" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>