其实mnesia的文档以及写的很清楚它要解决的问题的目标 不是设计来用来做大规模存储器的 所以在容量上没有考虑。
分类：
2009-07-16 16:49:51
关于 Mnesia
因为工作关系，最近又有机会再来近距离审视 mnesia 这坨神奇的东西。Joe 老头在他的书中说：“关于 Mnesia 的更多内容，恐怕还要再写一本书才能讲得清楚”，现在我(部分地)知道这句话的分量了——我发现自己之前对于 Mnesia 的认识完全错了，而基于新的认识，好多东西都要推翻了重来(害我多做了那么多蹩脚的实现，写了那么多苍白的代码)。我的感觉(现在的)是—— mnesia 根本就不是什么数据库，这只是一个善意的谎言(以它出现的时代来说，太激进，会把人都吓跑了)。实际上，它根本就是一个 Erlang 的 hibernate 。换句话说，这个东西就不应该被拿来当作“数据库”用，而是应该拿来当作“数据层”用。一字之差，谬以千里，熟悉 Java/SSH 编程的同学们相信都能明白我在说什么。实际上，我私下里在怀疑这是 mnesia 最初的设计目的之一，但为了某种原因而故意不去点破这一层。但愿在这个问题上我只是个可耻的阴谋论者。
其实mnesia的文档以及写的很清楚它要解决的问题的目标 不是设计来用来做大规模存储器的 所以在容量上没有考虑。
，是，仔细看 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，让这些扩展变得更加容易。