Mnesia：优点和差异

Question

Mnesia 与主要的 SQL 数据库实现相比有哪些优势？它与它们有何不同？

我可以使用数据库来保存大量数据而不会明显降低性能吗？

Answer 1

很抱歉在聚会上迟到了。:) 这是我的答案，基于自 1996 年以来使用 Mnesia 和自 1988 年以来使用各种其他数据库技术。

Mnesia 和 MySQL 确实是不同的野兽，哪一个最好在很大程度上取决于您打算如何使用它。

如果您的应用程序是用 Erlang 编写的，Mnesia 允许您将数据存储在与应用程序相同的内存空间中，这意味着您可以在几微秒内快速获取单个数据对象。这在 MySQL 中是不可能的，因为您的应用程序和数据库将在内存中分开。Mnesia 能够做到这一点并且仍然健壮的原因是 Erlang 在语言级别实现了内存“保护”。

总体而言，SQL 数据库倾向于吞吐量而不是延迟，并且在延迟方面，Mnesia+Erlang 总体上表现出色。你需要决定哪一个对你最重要。正如文档（上）中所说，Mnesia 的目标应用程序是电信交换应用程序，其中对例如呼叫建立的响应时间要求约为 20 毫秒。这实质上意味着您只能在数据位于共享内存中时从数据库中读取数据，但会避免在每次调用设置的基础上写入持久存储。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 也更胜一筹，如果您需要分析，毫无疑问您应该选择哪一个（即不是 Mnesia）。

将 Mnesia 视为 Erlang 语言的扩展是最好的方式。它让数据触手可及，非常适合数据结构和访问模式众所周知的小型数据集。为此，使用 MySQL 与使用 Mnesia 来处理 MySQL 最有效的事情一样不舒服。

大多数应用程序介于两者之间，这就是它成为判断调用的地方。你很可能最终会同时使用两者......

Answer 2

从文档：

Mnesia 是一个分布式数据库管理系统，适用于电信应用和其他需要连续运行和软实时特性的 Erlang 应用。它是开放电信平台 (OTP) 的一部分，该平台是用于构建电信应用的控制系统平台。

特别是许多不间断系统所需的非常高水平的容错能力，再加上对 DBMS 与应用程序在同一地址空间中运行的要求，促使我们实施了全新的 DBMS。称为 Mnesia。Mnesia 是在 Erlang 编程语言中实现的，并且非常紧密地连接在一起，它提供了实现容错电信系统所必需的功能。Mnesia 是一个多用户分布式 DBMS，专门为工业电信应用程序使用符号编程语言 Erlang 编写，Erlang 也是预期的目标语言。Mnesia 试图解决典型电信系统所需的所有数据管理问题，它具有许多传统数据库中通常没有的功能。

在电信应用中，有不同于传统 DBMS 提供的功能的需求。现在用 Erlang 语言实现的应用程序需要广泛的特性的混合，传统的 DBMS 通常不能满足这些特性。Mnesia 的设计考虑了以下要求：

快速实时键/值查找

以运维为主的复杂非实时查询

分布式应用导致的分布式数据

高容错

动态重新配置

复杂对象

Mnesia 与大多数其他 DBMS 的不同之处在于它的设计考虑了电信应用程序的典型数据管理问题。因此，Mnesia 将传统数据库中的许多概念（例如事务和查询）与电信应用数据管理系统中的概念相结合，例如非常快速的实时操作、可配置的容错程度（通过复制）和能够无需停止或暂停系统即可重新配置系统。Mnesia 也很有趣，因为它与编程语言 Erlang 紧密耦合，从而几乎将 Erlang 变成了一种数据库编程语言。这有很多好处，首先是 DBMS 使用的数据格式和编程语言使用的数据格式之间的阻抗不匹配，

Mnesia 与 MySQL，性能：

与使用内部 Mnesia 相比，ejabberd 在使用某些 *SQL 数据库时消耗的计算资源更少。当您有很多并发用户（例如超过 1000）时，您可能对该主题感兴趣。由于并发用户很少，ejabberd 的 CPU 消耗可以忽略不计，因此小型服务器的管理员不关心设置外部 SQL 服务器和数据库。

CouchDB 诉 Mnesia、诉 MySQL和其他 Mnesia 主题：

我立即想到的一个见解是，虽然如何为 MySQL 构建数据对我来说是显而易见的，但对于 Mnesia 和 CouchDB 而言则不然，我仍然不完全确定最佳方法。现在，这里有几个更明显的点：

'record' 有一个 'numplays' 字段，它显然表明它已经播放了多少次。这在 MySQL 中很好，但是如果我只是将这个字段合并到 CouchDB 的文档中，每次这个数字发生变化时，我都会在数据库中得到一个完整的文档副本，这看起来效率很低。

MySQL 中记录、标签和它们之间的链接表的三表布局（如果不清楚，请参阅脚本）显然是（至少对我而言）正确的解决方案，但有很多可能的方法来做到这一点在 Mnesia 和 CouchDB 中，我发现我没有直觉上的答案。

简而言之，它是为非常特定的目的而设计的，并且似乎经过精心设计以适合该目的。没有一个数据库可以抽象地与另一个数据库进行比较。只有通过使用需求，才能引入可公度的要素。

Answer 3

不，我不会说 Mnesia 适合处理大量数据。您可以选择使用Ets 或 Dets作为后端。如果您选择 Ets，您的数据库将仅位于内存中并且速度非常快，但数据不是持久的。如果您希望数据持久化（保存在磁盘上），您需要使用 Dets，它有2GB 的限制，因此您的数据库不能容纳超过 2GB 的数据。

您可以使用自定义后端，例如Riak NoSQL 数据库中使用的innostore。

Mnesia 的优点是它是一个分布式数据库，因此如果您有多于一台计算机，则很容易实现容错系统。它在 Erlang 中非常容易使用，因为它是一个语言内数据库并且行为“就像一个函数”。如果您只需要一个内存数据库（例如缓存），它也非常快。