Mnesia is an RDBMS. But it belongs to the NoSQL category of RDBMS. Reason being the query language is not SQL but Erlang. That makes it very easy to store and retrieve without having to go through Object Relational Mapping. So we can actually call Mnesia an object-relational database.Mnesia is a distributed, soft real-time database management system written in the Erlang programming language.

Why and where use mnesia?

Erlang, in general, is used to program highly distributed and fault-tolerant systems. Even though it has its roots in the telecommunication industry, it has proven useful in several other sites like ejabbered, Facebook chat etc. Mnesia is just a part of Erlang and is built with Erlang.Hence it gives you the configurable degree of Fault-tolerance (by means of replication).

Use Mnesia with the following types of applications:

Applications that need to replicate data.

Applications that perform complicated searches on data.

Applications that need to use atomic transactions to update several records simultaneously.

Applications that use soft real-time characteristics.

Mnesia contains the following features that combine to produce a fault-tolerant, distributed DBMS has written in Erlang:

Database schema can be dynamically reconfigured at runtime.

Tables can be declared to have properties such as location, replication, and persistence.

Tables can be moved or replicated to several nodes to improve fault tolerance. The rest of the system can still access the tables to read, write, and delete records.

Table locations are transparent to the programmer. Programs address table names and the system itself keeps track of table locations.

Database transactions can be distributed, and many functions can be called within one transaction.

Several transactions can run concurrently, and their execution is fully synchronized by the DBMS. Mnesia ensures that no two processes manipulate data simultaneously.

Transactions can be assigned the property of being executed on all nodes in the system, or on none. Transactions can also be bypassed in favor of running "dirty operations", which reduce overheads and run fast.

Mnesia is a layer built on top of ETS and DETS to add a lot of functionality to these two databases. It mostly contains things many developers might end up writing on their own if they were to use them intensively. Features include the ability to write to both ETS and DETS automatically, to both have DETS' persistence and ETS' performance, or having the possibility to replicate the database to many different Erlang nodes automatically.

Another feature we've seen to be useful is transactions. Transactions basically mean that you're going to be able to do multiple operations on one or more tables as if the process doing them were the only one to have access to the tables. This is going to prove vital as soon as we need to have concurrent operations that mix read and writes as part of a single unit. One example would be reading in the database to see if a username is taken, and then creating the user if it's free. Without transactions, looking inside the table for the value and then registering it counts as two distinct operations that can be messing with each other — given the right timing, more than one process at a time might believe it has the right to create the unique user, which will lead to a lot of confusion. Transactions solve this problem by allowing many operations to act as a single unit.

The nice thing about Mnesia is that it's pretty much the only full-featured database you'll have that will natively store and return any Erlang term out of the box (at the time of this writing). The downside of that is that it will inherit all the limitations of DETS tables in some modes, such as not being able to store more than 2GB of data for a single table on disk (this can, in fact, be bypassed with a feature called fragmentation.)

What is ets?

ETS tables are implemented as BIFs in the ets module. The main design objectives ETS had was to provide a way to store large amounts of data in Erlang with constant access time (functional data structures usually tend to flirt with logarithmic access time) and to have such storage look as if it were implemented as processes in order to keep their use simple and idiomatic.

Data in Mnesia is organized as a set of tables. Each table has a name that must be an atom. Each table is made up of Erlang records. The user is responsible for the record definitions. Each table also has a set of properties. The following are some of the properties that are associated with each table:

set

A set table will tell you that each key instance must be unique. There can be no duplicate e-mail in the database above. Sets are great when you need to use a standard key/value store with constant time access.

ordered_set

There can still only be one key instance per table, but ordered_set adds a few other interesting properties. The first is that elements in an ordered_set table will be ordered (who would have thought?!). The first element of the table is the smallest one, and the last element is the largest one. If you traverse a table iteratively (jumping to the next element over and over again), the values should be increasing, which is not necessarily true of set tables. Ordered set tables are great when you frequently need to operate on ranges (I want entries 12 to 50 !). They will, however, have the downside of being slower in their access time (O(log N) where N is the number of objects stored).

bag

A bag table can have multiple entries with the same key, as long as the tuples themselves are different. This means that the table can have {key, some, values} and {key, other, values} inside of it without a problem, which would be impossible with sets (they have the same key). However, you couldn't have {key, some, values} twice in the table as they would be entirely identical.

duplicate_bag

The tables of this type work like bag tables, with the exception that they do allow entirely identical tuples to be held multiple time within the same table.

record_name -All records stored in a table must have the same name. The records must be instances of the same record type.

ram_copies -A table can be replicated on a number of Erlang nodes. Property ram_copies specifies a list of Erlang nodes where RAM copies are kept. These copies can be dumped to disc at regular intervals. However, updates to these copies are not written to disc on a transaction basis.

disc_copies -This property specifies a list of Erlang nodes where the table is kept in RAM and on disc. All updates of the table are performed in the actual table and are also logged to disc. If a table is of type disc_copies at a certain node, the entire table is resident in RAM memory and on disc. Each transaction performed on the table is appended to a LOG file and written into the RAM table.

disc_only_copies-Some, or all, table replicas can be kept on disc only. These replicas are considerably slower than the RAM-based replicas.

Index-This is a list of attribute names, or integers, which specify the tuple positions on which Mnesia is to build and maintain an extra index table.

local_content- When an application requires tables whose contents are local to each node, local_content tables can be used. The table name is known to all Mnesia nodes, but its content is unique on each node. This means that access to such a table must be done locally. Set field local_content to true to enable the local_content behavior. Default is false.

Majority-This attribute is true or false; default is false. When true, a majority of the table replicas must be available for an update to succeed. Majority checking can be enabled on tables with mission-critical data, where it is vital to avoid inconsistencies because of network splits.

SNMP- Each (set-based) Mnesia table can be automatically turned into a Simple Network Management Protocol (SNMP) ordered table as well. This property specifies the types of the SNMP keys.

Attributes- The names of the attributes for the records that are inserted in the table.