Good News — Mnesia Unlimited!
我们知道 mnesia 为很多人诟病的一个问题是——它有着诸多让人费解的限制。比如说，在 32 位的系统上，你最多只能存储 4G 的数据。又比如传说中磁盘表让人胆战心惊的修复过程。这些缺陷常常让人在试图推广 erlang 时，总觉得有些底气不足。虽然说，在实用的角度， 4G 其实也够用了，况且还可以分块。但无论怎么说，这种限制毕竟让人不爽。但其实，这些让人尴尬的限制其实并不是 mnesia 代码的问题（冤枉 mnesia 同学了），而是由它底层的存储机制 ets 和 dets 的特性所决定的(好比 mysql 之于 myisam / innodb 的关系)。现在好了，我们可以说，这些让人不快的限制已经可以被抛在脑后了。
Joel Reymont 就是那位在 05 年写出惊到大家的《Writing Low-Pain Massively Scalable Multiplayer Servers》一文的作者。(此文本站亦有中文翻译《轻松实现可伸缩性，容错性，和负载平衡的大规模多人在线系统》，感谢译者“神宗冥浩”)。他这次带给大家的是一个让人惊叹的大礼包——超乎想象的 mnesia 补丁包 mnesiaex 。这个东西解除了加在 mnesia 数据库系统上所有的限制(虽说上面已经提到，实际上 mnesia 代码本身没有什么真正的限制)——你现在可以用 SleepyCat/BerkeleyDB/MySQL/Amazon S3/Tokyo Cabinet/… 甚至是你自己喜欢的某种东西来当作 mnesia 的后端，就像 ets/dets 一样。而访问的接口仍保持不变——继续沿用 mnesia 的接口，一行也不用改。 DIY 这种扩展也变得相当容易，写一个 behavior 就成了。
感谢 Joel Reymont 将这些工作回馈到开源社区。让我们一起祈祷 OTP Team 将这堆 patch 合并到 Erlang 的下一个发布版本中去吧。
顺便 blah 一下：
关于 Erlang
Erlang 就好像是 Ericsson 的私生子，从出生之日起就一直不得宠。在 AXD301 中的耀眼光芒，还是逃脱不了被弃用的命运(Ericsson 又转回去用 C 写交换机了，别让我猜中是因为公司政治)。失败了的 Joe 一伙人被迫离开自组 BlueTail 公司，绝望之中以 Open Source 协议公布了 Erlang 的代码，这个挫折使得它在编程语言的坟场寂寞的躺了多年，但仍然保留着翻盘的火种。默默无闻的完善了多年(加入SMP支持之类)，一直不为人所知。直到碰上 CPU 多核变革的机遇，这才重新捡回半条命，并渐渐被人提起。但别忘了，Erlang 直到现在仍然都是由 Ericsson 所拥有(整个的 OTP Team 都是他的员工)和操纵的(你能看到 Erlang 的 souce code 但能访问 Erlang source code 的 SVN 么？)。而比 Sun 的 Java 更加糟糕的是老态龙钟的 Ericsson 从来也没有意识到 Erlang 这个私生子身上所蕴含的潜力。麻烦哪位消息人士请一定转告 Ericsson 的老爷爷们，现在连 Sun 都已经完全开源了 Java ，请抓紧赶上吧，把那些没用的遮遮掩掩全都扔掉。因为对于一个程序设计语言而言，只有 Open Source Community 的程序员们，只有这些人，才是它生命力的真正源泉。在此祈祷 Open Source Erlang 项目朝着更 Open Source Way 的方向前进。
关于 Mnesia
因为工作关系，最近又有机会再来近距离审视 mnesia 这坨神奇的东西。Joe 老头在他的书中说：“关于 Mnesia 的更多内容，恐怕还要再写一本书才能讲得清楚”，现在我(部分地)知道这句话的分量了——我发现自己之前对于 Mnesia 的认识完全错了，而基于新的认识，好多东西都要推翻了重来(害我多做了那么多蹩脚的实现，写了那么多苍白的代码)。我的感觉(现在的)是—— mnesia 根本就不是什么数据库，这只是一个善意的谎言(以它出现的时代来说，太激进，会把人都吓跑了)。实际上，它根本就是一个 Erlang 的 hibernate 。换句话说，这个东西就不应该被拿来当作“数据库”用，而是应该拿来当作“数据层”用。一字之差，谬以千里，熟悉 Java/SSH 编程的同学们相信都能明白我在说什么。实际上，我私下里在怀疑这是 mnesia 最初的设计目的之一，但为了某种原因而故意不去点破这一层。但愿在这个问题上我只是个可耻的阴谋论者。
jz同学，有空跟大家分享下mnesia的最佳实践心得把:)
mnesia对中文支持怎么样, 能存储,操作中文字符吗?
@马天一
对于 Erlang 来说，如果只是存储和读取(不做分隔和解析的话)字符集问题其实并无大碍，因为对于 mnesia 来说它存的只是一个 list 它原样存，原样取，在外面你想怎么用就怎么用，爱怎么转换就怎么转换(这就好比，在 java 里面，用 gbk 的 mysql 一样可以处理 utf-8 的字符串)。并无妨碍。
这个，好像不支持最新的R12,(mnesia 4.4)
就是啊，要全部开源，也许erlang就是下一个java了
第一段话有点问题，mnesia数据库的每个表是一个dets文件，而dets文件的大小不能超过2GB，所以每张表的大小超不过2GB，但是如果数据库有100张表，那么mnesia数据库的容量就是200GB了。dets文档中原文是
The size of Dets files cannot exceed 2 GB. If larger tables are needed, Mnesia’s table fragmentation can be used.
看这篇文章 http://mryufeng.javaeye.com/blog/352508
这个问题可以很好的绕过去的 比较这个patch靠不靠谱 而且不能被官方接受的patch使用起来很大麻烦！
@mryufeng
本来就是一个很无厘头的 4G 限制(看见过官方解释，忘了)，偏偏要让使用者去想法子来绕过去，它自己解决好不就结了么。况且官方的方案让人觉得很不完美：
local_content table 需要自己对数据进行分区
fragmented table 用起来则实在是有那么一点…… tricky…
问题是——凭什么啊？作为使用者，选择一个存储机制，当然是希望它越透明越好，如若不然，自然就会考虑其他的选择，比如，自己去架个 couchdb/kai/scalaris 来用。而这些项目的蓬勃发展，正好证明了 mnesia 的这个限制是多么的让人不爽。对于这个问题 otp team 确实需要加以重视，并好好的解决一下。
其实mnesia的文档以及写的很清楚它要解决的问题的目标 不是设计来用来做大规模存储器的 所以在容量上没有考虑。
@mryufeng，是，仔细看 mnesia 的文档，就会发现，它的确是提到了这一点。实际上，更确切地说(原始意义上的) mnesia 是 Erlang 这个 FP (无共享内存语言)的一个 “共享内存” 方案。而且，比起 ETS ，它具有分布式和高可用性的特性。
但，在另一方面，对很多 “头一次听说 Erlang 的人” 来说，这个 mnesia 又是被当作 “Erlang 内置的一个数据库” 来介绍的。所以，在他们在探索和学习的路上，必然地发现这个 4G 限制的时候，自然也会产生想象与现实的 “落差” 感。
要解决这种落差，要么是再明确地提供一个真正意义上的 DataBase ，比如说，象 CounchDB 这样的东西。要么是在介绍 mnesia 的时候，就在更显著的地方明确的指出它和数据库之间的差异，提供清晰的信息，以供作出判断。
对于前者，我觉得必要性其实并不高，相反地，像这篇文章中 mnesia unlimit 的做法，我觉得是可取的。因为 mnesia 的 api 设计得相当精巧，尤其是它 qlc 的部分，非常符合 FP 的习惯风格。我在这篇文章后面的 blah 中也提到，某种意义上，不妨将 mnesia 看作是一个类似于 ODBC/JDO/Hibernate 这样的 api 层面的东西。具体要怎样去接驳后端的存储实现，是 DETS/ETS ，又或者是 Memcached/Tokoyo Carbinet，提供选项，让你照自己的喜欢去配置就好。实际上 mnesia 本身在代码之中就留有替换 “存储实现” 的空间(比如，在 ETS 和 DETS 之间选择“存储实现”)，因而这并非不可能完成的任务。Joel Reymont 就是通过 Hack mnesia 自身的代码(其实只能算是少量的 Hack)来做到这一点。倒是 mnesia team 应该考虑如何增加可配置的 API，让这些扩展变得更加容易。
“…Ericsson 又转回去用 C 写交换机了，别让我猜中是因为公司政治…”
我看重要的一点还是因为C是工业标准,E3不想惹起太多纠纷,它只是卖产品的,不是卖软件的.
erlang产品还有秘密吗,估计产品很容易被逆向工程出来吧,这恰恰不符合”工业标准”,呵呵~~乱弹一番
真的是“乱弹一番”，～此言差亦。
如果说“工业标准”和“程序员数量”或者“应用规模”、“教学语言”之类的因素挂上钩，那还算靠点谱。但如果认为“工业标准”和“逆向工程”之类的因素相关，那么，我个人实在无法认同。
作为“工业标准”的 C (包括ASM)的程序被反向工程的例子实在太多，已经举不胜举。就算是“相对独立的软硬件一体化系统”，比如 iPhone 和 XBox 360 之类，还不是一样被破掉了么？只是多费了一些时间而已。
这个世界上从来就没有过密不透风的墙(将来恐怕也不会有)。有差别的只是突破这堵墙所花的代价会有多高，是否合算而已。只要是被认为具有“破解的价值”，那么无论采用什么技术来做，区别其实不大。以此作为“工业标准”的考量因素，又是从何说起？
虽如此，但在“反逆向工程”上 Erlang 还是有经过精心设计的源代码保护机制，你可以对外发布加密过调试信息的字节码(RSA)(对此，本站另有文章介绍，感兴趣请自行搜索)。虽说这个机制并不一定意味着彻底避免被逆向工程，但无疑是增加了难度——至少不会出现“装个软件源代码就全部被还原”的尴尬情况。单就这一点而言，已经比同样是 ByteCode 的 Java 和 .NET 要强上很多了。
话又说回来，对于我们程序员而言，如果程序真的达到“极具破解价值”的水准，那又何尝不是一种荣誉。