I was alerted to mnesiaex by archaelus (I think) in #erlang, and this is another nice addition. It’s very exciting to see alternate storage schemes popping up for the unadulterated awesomeness that is Mnesia, as my first really erlang app is targeting webservices and mnesia users.

Thanks for the update, and info!

http://dukesoferl.blogspot.com/2008/06/tokyocabinet-and-mnesia.html

This allows you to move beyond the ‘2GB’ file limit. These guys wrote a C driver to link directly into the high performance tokyo cabinet, and have a wrapper for a storage api using mnesia. this makes it transparent when using mensia.

Thanks very much, I’ve enjoyed reading your articles.

1. Thank you for clarifying on the 2gb limit, that’s actually really good news for some the projects I have in mind :)

2. Also very important information to have when considering it for a cloud app, I’ll add this as an update to the article when I get a chance.

3. Not sure, I’ll make sure to correct that.

4. Thanks for taking the time to comment!

I’d like to add two things:
1) Mnesia has a limit of 2GB for one fragment of disc_only_copies table (i.e. tables stored only on a hard drive, not in the ram). There is no limit for RAM and RAM+disc tables, except for memory limit of 4GB on 32bit systems. But even if the limit is reached you can fragment your data between many nodes started on one machine (or use 64bit system).

2) Mnesia does not scale for more then 8-10 nodes, since Erlang VM creates a fully connected graph of connections in a cluster and with this amount of nodes network is quickly saturated.

3) Why do you write Mnesia as “MNesia”? :)

Best regards,
Gleb Peregud