上一篇文章我们从总体介绍了Mnesia的应用场景，我们应该如何操作Mnesia呢？请诸君停下你的步伐，听我慢慢道来：
数据在Mnesia中被组织成一组表，每个表名都是atom类型。每个表都是由Erlang的record组成，用户需要自定义record，每个表也有一组属性：
type:每个表都可以是'set'、'ordered_set' 或者 'bag' （在当前版本OTP17 'disc_only_copies'还不支持'ordered_set'）。
如果表的类型为set，意味着每个key会导致单一或者空记录。如果有新记录插入到已经存在的key值，记录将会被覆盖。
如果类型位bag，一个key可以有多条记录。但是所有的记录是唯一标志的，只是key可能会重复。
核心：set 1:1， bag：1:n （Key-Value对应关系）
record_name:所有的record在表中必须有相同的名称，也就是说所有的记录都是同一个类型的记录的实例。
ram_copies:一个表可以在多个erlang节点中复制，ram_copies指定了那些在RAM中保留副本信息的节点列表，这些副本可以定期转存到磁盘，但是这些保存不是基于事务的？？怎么解释？？难道有更能造成数据不一致性？需要进一步细化。
disc_copies:disc_copies指定呢那些在RAM中保留副本信息的节点列表，并且也需要保存到磁盘上（与ram_copies重要区别）。所有的在表上的执行实际的更新操作，同步记录到磁盘，每个在表上进行操作的事务均会追加到LOG文件和写入RAM表中。
disc_only_copies:只是进行磁盘操作，不进行RAM保存（明显慢于RAM拷贝）
index:是个list，包含属性名称，或者整形（指定了index在tuple中的位置），Mnesia需要基于它来创建和维护额外的索引，这通过这个建立多个索引。
local_conten:当应用程序需要读取的数据位于本地节点上时，可以使用cocal_content属性，该表名在所有节点上都是可知的，但是每个节点的内容是唯一的。这就代表访问这些表需要在本地化完成（默认值为false）
majority:true表明副本必须能够成功更新，主要用于系统关键数据一致性保证，特别是在网络拆分表的情况下，默认为false。
snmp:每个表（基于set）的Mnesia表可以自动转化为一个SNMP有序表，该属性指定SNMP key的类型。
attributes: record中需要插入到Mnesia表中的名称。
具体详情请查看mnesia:create_table/2.
看了表的属性，我们再来看看锁吧：
Mnesia包含读锁和写锁，
写锁需要在表存放所有副本的节点（激活）获取。读锁需要在一个节点上获取（如果在本地节点有表的副本，则在本地节点）。若果在事务的上下文中调用，大多数上下文敏感的访问函数都会获取一个隐式锁，锁的粒度可以是针对记录或者整个表的。
参考：
1063
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
