与主要的SQL数据库实现相比，Mnesia有何优势？它们之间有何不同？
我可以使用数据库保存大量数据而不会导致性能显着下降吗？
Answers:
很抱歉参加晚会。:)这是我的答案，基于自1996年以来使用Mnesia和1988年以来使用的其他各种数据库技术。
Mnesia和MySQL确实是不同的野兽，哪一个是最好的，很大程度上取决于您打算如何使用它。
如果您的应用程序是用Erlang编写的，则Mnesia允许您将数据存储在与应用程序相同的内存空间中，这意味着您可以以几微秒的速度获取单个数据对象。在MySQL中这是不可能的，因为您的应用程序和数据库将在内存中分开。Mnesia之所以能够做到这一点并且仍然很健壮，是因为Erlang在语言级别实现了内存“保护”。
总体而言，SQL数据库倾向于优先于吞吐量而不是延迟，在延迟方面，Mnesia + Erlang通常非常出色。您需要确定哪个对您最重要。就像在文档中（上面）说的那样，Mnesia的目标应用是电信交换应用，例如呼叫建立的响应时间要求约为20 ms。从本质上讲，这意味着您仅可以在数据位于共享内存中的情况下从数据库中读取数据，但可以避免在每次调用设置的基础上写入持久性存储。OTOH，这些应用程序实际上不需要临时查询支持，并且不使用非常大的数据集。已经做了一些工作来扩展Mnesia在其他领域的适用性，但是对于Erlang / OTP开发团队而言，这并不是优先事项。Mnesia就是这样，并且可能会保持这种状态。
在上面的链接中，比较了Mnesia和MySQL的速度，需要记住它在eJabberd中，如果是MySQL，它可以在单个服务器上运行，如果是Mnesia，则可以在一个完全复制的数据库上运行-大型eJabberd集群可以拥有多达10个或更多的erlang节点（因此，有10个或更多的Mnesia副本）。从冗余的角度来看，这是相当荒谬和昂贵的，Mnesia绝不强迫您这样做。显然，它可以在每个节点上提供快速读取，但是写入将非常昂贵。我已经阅读了几次比较，最终将分布式Mnesia与单节点MySQL进行了比较。如果MySQL不需要冗余，那么Mnesia也不需要冗余。Mnesia在选择复制模式方面非常灵活，并且数据位置对于应用程序是透明的。
Mnesia也不限于每个表2 GB（尽管有特定的存储选项）。我知道的最大的Mnesia数据库在（64位）RAM +磁盘中大约有600 GB的数据-尽管我不建议这样做。最高10-20 GB的存储空间对于现代硬件来说应该是完全可以的，但是请完全跳过disc_only_copies并使用disc_copies-如果需要，请购买更多的RAM。在使用分片支持（mnesia_frag）之前，我会三思而后行-它可以工作，但很少值得为此烦恼。
Mnesia和MySQL之间的最大区别也许是SQL本身：Mnesia确实没有可比的功能；它具有可比性。QLC为即席查询提供了一些支持，但是它与SQL不在同一个联盟中，查询优化的级别也没有。在工具和供应方面，MySQL也很出色，如果您需要分析，那么毫无疑问应该选择哪一个（即NOT Mnesia）。
查看Mnesia的最佳方法是对Erlang语言的扩展。它使数据触手可及，非常适合数据结构和访问模式众所周知的小型数据集。为此，在MySQL最有效的地方，使用MySQL与使用Mnesia一样不舒服。
大多数应用程序介于两者之间，在这里它成为一个判断调用。您可能最终会同时使用两者...
从文档中：
Mnesia是一个分布式数据库管理系统，适用于需要连续操作和软实时属性的电信应用程序和其他Erlang应用程序。它是开放电信平台（OTP）的一部分，该平台是用于构建电信应用程序的控制系统平台。
尤其是许多不间断系统所要求的极高的容错能力，再加上对DBMS的要求，使其在与应用程序相同的地址空间中运行，这导致我们实现了全新的DBMS。叫做Mnesia。Mnesia在编程语言Erlang中实现并与之紧密相连，它提供了实现容错电信系统所必需的功能。Mnesia是一种多用户分布式DBMS，专门为使用符号编程语言Erlang（也是目标语言）编写的工业电信应用程序而设计。Mnesia试图解决典型电信系统所需的所有数据管理问题，并且具有许多传统数据库通常不具备的功能。
在电信应用中，与传统DBMS提供的功能有不同的需求。现在以Erlang语言实现的应用程序需要多种功能的混合，而传统DBMS通常无法满足这些功能。Mnesia在设计时考虑了以下要求：
快速的实时键/值查找
复杂的非实时查询，主要用于操作和维护
分布式数据归因于分布式应用程序
高容错能力
动态重新配置
复杂物体
Mnesia与大多数其他DBMS的不同之处在于，它的设计考虑了电信应用程序的典型数据管理问题。因此，Mnesia将传统数据库中的许多概念（例如事务和查询）与电信应用程序的数据管理系统中的概念相结合，例如非常快速的实时操作，可配置的容错度（通过复制）以及重新配置系统而不停止或挂起它。Mnesia也很有趣，因为它与Erlang编程语言紧密耦合，因此几乎将Erlang变成了数据库编程语言。这有很多好处，最重要的是，DBMS使用的数据格式与编程语言使用的数据格式之间的阻抗不匹配，
与使用内部Mnesia相比，使用某些* SQL数据库时，ejabberd消耗的计算资源更少。当有多个并发用户（例如，超过1000个）时，您可能对该主题感兴趣。在并发用户很少的情况下，ejabberd的CPU消耗可以忽略不计，因此小型服务器的管理员不必理会设置外部SQL服务器和数据库。
CouchDB诉Mnesia，V.MySQL和其他Mnesia主题：
我马上想到的一个见解是，虽然我对如何为MySQL构造数据一目了然，但对Mnesia而言却并非如此，对于CouchDB而言，我仍不确定是否最好的方法。现在，这里有几个比较明显的要点：
“记录”具有“ numplays”字段，该字段显然指示已播放了多少次。在MySQL中这很好，但是如果我将此字段合并到CouchDB的文档中，则每次此数字更改时，我都会在数据库中获得该文档的完整重复版本，这似乎效率很低。
MySQL中记录，标签和它们之间的链接表的三表布局（如果不清楚，请参见脚本）（至少对我而言）显然是正确的解决方案，但是有许多可行的方法在Mnesia和CouchDB中，我发现我没有直观的答案。
简而言之，它是为非常特定的目的而设计的，并且经过精心设计以适合该目的。没有一个数据库可以与另一个数据库进行抽象比较。只有通过使用需求，才能引起可相称性的要素。