Mnesia

from Wikipedia, the free encyclopedia
Mnesia
Basic data

Maintainer Ericsson / The Erlang Project
developer Ericsson
Current  version 4.16.1
(September 17, 2019)
operating system Unixe ( Linux ,  FreeBSD ,  macOS ), Windows (all platforms on which Erlang runs)
programming language Erlang
category Database management system
License EPL (Erlang Public License; similar to Mozilla Public License )
German speaking No
erlang.org , mnesia (3erl)

Mnesia is a database system written in Erlang . It is used exclusively in direct association with Erlang, there is no connection to other languages. Mnesia has soft real-time capabilities, can be easily configured in a distributed manner and is also optimized for speed.

Surname

Joe Armstrong , one of the main developers of Erlang, answers the question about the name Mnesia in his book Programming Erlang as follows:

"The original name was Amnesia . One of our bosses didn't like the name. He said, 'You can't possibly call it Amnesia - you can't have a database that forgets things!'. So we dropped the A and the name stuck. "

“The original name was Amnesia . But one of our bosses didn't like that name. He said, 'You can't call this thing amnesia - you can't develop a database that forgets things!' So we left out the A and the name stayed. "

- Joe Armstrong

commitment

Like Erlang, Mnesia was developed for use in telecom environments where low latency and very high availability as well as parallelism are important. Mnesia was not designed to replace traditional SQL -based databases, but rather as a language-embedded database, much like the Berkeley DB .

Integration in Erlang

Mnesia is heavily specialized in Erlang, so it supports storing any Erlang terms. Erlang terms are the data structures / types used in the language itself:

  • Lists: [1,2,3]
  • Scalars: 42
  • Atoms: helloworld,xyz
  • Tuple:, {hello,1,3.4,[1,2,3],{5,abc}}Records:R = #recordname{a=1,b=2}
  • Funs: fun() -> doSomething() end.

There is therefore no need to convert data types.

It is not possible to use languages ​​other than Erlang. The module is mnesiaused within Erlang to communicate with the database server, which works with various Erlang processes.

Memory model

Mnesia stores Erlang tuples in tables. The tuples are structured according to the following pattern: 

{Tabellenname,Key,Feld1,Feld2,...}

Table name is used by Mnesia to put the data record in the correct table, while Key is a key that is unique in the respective table (typical for relational database systems), for example a sequential number. The rest of the tuple are other data fields.

Because of this structure, records are mostly used to work with Mnesia. The record -record(table1,{field1,field2=defaultvalue}).is converted into a tuple {table1,Wert1,Wert2}and is therefore well suited to be stored in Mnesia.

Transactions

Reading, writing and queries should only be in so-called transactions ( transactions take place). Transactions are Erlang- Funs (in Erlang, fun is synonymous with anonymous function ), in which the mnesia commands for reading, writing and querying are executed. Such fun is then passed on to the Mnesia transaction manager.

The purpose of transactions is to achieve atomicity (indivisibility) and thereby consistency. Either the entire transaction succeeds or the entire transaction fails. The database always remains consistent. Example: Two related data records are to be written into the database. The writing of the first data record is successful, that of the second fails (for example because of a forgotten field in the data record to be inserted). Now the first write process is undone in order to achieve consistency again. After that, the program will be informed that something went wrong.

In addition to transactions, there are dirty operations , i.e. dirty operations that are many times faster than transactions, but do not guarantee consistency or atomicity.

Working with mnesia - a few small examples

Scheme

Before the database can be used, a so-called schema must be created. A schema is actually just a folder in the current directory that is named after the pattern Mnesia.node () , in the case of an unnamed Erlang instance, Mnesia.nonode@nohost . The scheme is used to save data on the hard drive depending on the mode and to manage the links with other Mnesia instances. 

mnesia:create_schema(['node1@host.example.org','node2@host.example.org',node()]).

This command creates the necessary files for the two named nodes (Erlang VMs that are able to be addressed via the network) and the current node ( node () ). table1 is currently the only table in the database. The entire structure takes up about 28 kB with 20 entries  , an empty database needs about 20 kB. 

Mnesia.node1@host.example.org/
├── DECISION_TAB.LOG
├── LATEST.LOG
├── schema.DAT
├── table1.DCD
└── table1.DCL

The schema thus stores the meta information for working with a database. Linking to a running Mnesia server happens automatically, i. H. if a mnesia server is started in a node and it finds a scheme with a name that matches the node name, this is used.

After a scheme has been created, Mnesia must be started on all nodes involved: 

mnesia:start().

Tables

Tables are an important basic element of relational databases. In Mnesia, a table consists of a series of Erlang tuples that all start with the same name, namely that of the table. An Erlang record is best suited for this: 

-record(table1,{field1,field2=defaultvalue}).

mnesia:create_table(table1,[{attributes,record_info(fields,table1)},{disc_copies,['node1@host.example.org','node2@host.example.org']}]).

table1 is the name of the table, which must match the record name. The second argument is a list of option tuples. Used here:

  • {attributes,[field1,field2]}- List of fields. record_info()returns the list of fields of the given record.
  • {disc_copies,['node1@host.example.org','node2@host.example.org']}- storage method. In addition to disc_copies (location: RAM; backup on hard disk), there are only RAM ( ram_copies or no argument) and only hard disk ( disc_only_copies ). The node list always only contains nodes that were specified when the schema was created, since a special cookie must match between the schemas. This node list configures the table in such a way that copies of the table are stored on two nodes, but not on the main node on which the application that is currently executing this function is running. A typical scenario would be a front-end-back-end application in which the application server primarily has computing power and the other two nodes provide the storage space.

Write

First, a function object with the desired behavior is generated and then transferred to the transaction manager. The Mnesia functions used in transactions only run in the transaction context, i. H. it is not possible with these functions to change the database outside of a transaction. 

Transaction_Fun = fun() ->
    Data = #table1{field1=1337,field2=42},
    mnesia:write(Data)
    end.

mnesia:transaction(Transaction_Fun).

Interrogate

The query is done using the list compre- hens often used in Erlang. In order to extract all values ​​of field1 in data records where field2 is greater than 100, the following query is formulated: 

Transaction_Fun = fun() ->
    Query = qlc:q([X#table1.field1 || X <- mnesia:table(table1), X#table1.field2 > 100 ]),
    qlc:e(Query)
    end.

mnesia:transaction(Transaction_Fun).

QLC is a module for querying different tables, for example ETS or Mnesia. qlc: q () compiles a list compilation, qlc: e () executes it and returns the values. Joins are also possible with these list dimensions.

The SQL equivalent for this query would be: 

SELECT field1 FROM table1 WHERE field2 > 100

Individual evidence

  1. ^ Mnesia Release Notes. Release Notes. In: erlang.org. Ericsson AB, accessed September 21, 2019 .
  2. ^ Joe Armstrong: Programming Erlang: Software For A Concurrent World. In: Pragmatic Bookshelf. Raleigh (North Carolina) 2007, ISBN 1-934356-00-X , p. 316 (English).