-
Notifications
You must be signed in to change notification settings - Fork 12
/
Copy pathmnesia.xml
163 lines (127 loc) · 4.42 KB
/
mnesia.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
<?xml version="1.0" encoding="iso-8859-1" ?>
<!DOCTYPE chapter SYSTEM "chapter.dtd">
<chapter>
<header>
<title>Mnesia Database Questions</title>
<prepared>Matthias Lang</prepared>
<docno></docno>
<date>2007-09-12</date>
<rev>1.0</rev>
<file>mnesia.xml</file>
</header>
<p>
Mnesia is the somewhat odd name for the real-time, distributed database which
comes with Erlang.
</p>
<section><title>What is Mnesia good at?</title>
<section> <title>Locking and Transactions</title>
<p>
If you need to keep a database that will be used by multiple
processes and/or nodes, using Mnesia means you don't have
to write your own access controls.
</p></section>
<section> <title>Distribution</title>
<p>
Tables can be replicated at many nodes, both for efficiency
(database lookup is a local activity) and robustness
(redundancy means if one node goes down, other nodes still
have copies of the data.)
</p></section>
<section> <title>Non-fully-normalised data</title>
<p>
Unlike most database systems, records can contain data
of arbitrary size and structure.
</p></section>
<section><title>Monitoring</title>
<p>
Monitoring - processes can subscribe to events which are
sent when various operations on the data take place
(update, delete, etc) The RDBMS package allows even
more fine-grained control.
</p></section>
</section>
<section><title>What is Mnesia not so good at?</title>
<p>
Mnesia is primarily intended to be a memory-resident database.
Some of its design tradeoffs reflect this.
</p><p>
Really large tables must be stored in a fragmented manner.
</p></section>
<section><title>Is Mnesia good for storing blobs?</title>
<p>
It depends. Erlang has no problem storing Erlang binary data
types of arbitrary size, however due to the in-memory-database
design emphasis of mnesia, storing lots of binary
data will eventually hit one of a number of limitations.
These are driven by:
</p>
<list>
<item><p>
Storage type - Both <c>ram_copies</c> and
<c>disc_copies</c> tables
rely on storing a full copy of the whole table and data
in main memory. This will limit total blob storage to
the size of available memory.
</p><p>
On the other hand <c>disc_only_copies</c>
tables do not suffer
from this limitation but they are slow (from disk) and
the data is stored in dets tables which if not closed
properly (e.g. after system crash) can take a long time
to repair (this was improved in recent versions but is
still not quick).
</p></item>
<item><p>
Replication - if the table has a replica then updating
an entry and rebuilding after a restart will copy the
data over the network between the two machines. Depending
on available bandwidth and the uptime requirements
this may or may not be acceptable.
</p></item>
</list>
<p>
As always, measurement of the different mechanisms for your
specific application is recommended.
</p><p>
A more colourful discussion of the these topics can be found
in this <url href="http://erlang.org/pipermail/erlang-questions/1999-October/000618.html">
post to the mailing list.</url>
</p></section>
<section><title>Is there an SQL interface for mnesia?</title>
<p>
A partial one was built as a masters project, it's
of limited use and not widely used.
</p><p>
QLC is the query engine for Mnesia and ETS. It is
a much better fit to Erlang than SQL.
</p></section>
<section><title>How much data can be stored in Mnesia?</title>
<p>
It depends on the storage type of your tables.
</p>
<list>
<item><p>
For <c>ram_copies</c> and <c>disc_copies</c>, the entire table
is kept in memory, so data size is limited by available RAM.
</p><p>
Note that for <c>disc_copies</c> tables, the entire table
needs to be read from disk to memory on node startup, which
can take a long time for large tables.
</p></item>
<item><p>
<c>disc_only_copies</c> tables are limited to 2 GB each. If
your table is fragmented, each fragment counts as a separate
table, and the combined size can thus exceed 2 GB.
</p><p>
The reason for this limit is that <c>disc_only_copies</c>
tables are backed by Dets tables, and the Dets file format
uses signed 32-bit integers for file offsets.
</p></item>
</list>
<p>
An earlier version of this FAQ entry claimed that all tables
are limited by the Dets limit. This was the case until R7B-4
(released on 30th September 2001), when <c>disc_copies</c>
tables were moved from Dets to <c>disk_log</c>.
</p></section>
</chapter>