我们正在使用 Mnesia 作为一个非常大的系统的主数据库。 Mnesia Fragmented Tables 在测试期间表现非常好。系统有大约 15 个表，每个表都跨 2 个站点(节点)复制，并且每个表都是高度碎片化的。在测试阶段(侧重于可用性、效率和负载测试)，我们接受了 Mnesia，它复杂结构的许多优点将为我们提供帮助，因为我们在服务之上运行的所有应用程序都是 Erlang/OTP 应用程序。我们正在运行 Yaws 1.91 作为主要的网络服务器。
为了有效地配置碎片表，我们使用了许多在大型系统中使用过 mnesia 的引用资料:
它们是: Mnesia One Year Later Blog , Part 2 of the Blog , Followed it even here , About Hashing 。这些博文帮助我们在各个方面进行微调以获得更好的性能。
现在，问题来了。 Mnesia 有表大小限制，是的，我们同意。但是，任何地方都没有提到对片段数量的限制。出于性能原因，并为了满足大数据的需要，大约有多少片段可以使 mnesia “正常”？。
在我们的一些表中，我们有 64 个片段。 n_disc_only_copies 设置为集群中的节点数，以便每个节点的每个片段都有一个副本。如果给定节点瞬间无法访问，这帮助我们解决了 mnesia 写入失败的问题。同样在上面的博客中，他建议片段的数量应该是 2 的幂，这个声明(他说)是根据 mnesia 对记录进行哈希处理的方式进行调查的。然而，我们需要对此进行更多解释，这里讨论的是 2 的哪个幂:2,4,16,32,64,128,...？
该系统旨在运行在 HP Proliant G6 上，包含 Intel 处理器(2 个处理器，每个处理器 4 个内核，每个内核 2.4 GHz 速度，8 MB 缓存大小)，20 GB RAM 大小，1.5 TB 磁盘空间。现在，我们可以使用这些大功率机器中的 2 台。系统数据库应该在两者之间进行复制。每台服务器都运行 64 位 Solaris 10。
mnesia 的性能可能会在多少片段时开始下降？如果我们将给定表的片段数从 64 增加到 128 可以吗？ 65536 个片段 (2 ^ 16) 怎么样？我们如何通过使用碎片来扩展我们的 mnesia 以利用 TB 空间？
请务必提供问题的答案，并且您可以就可以增强系统的任何其他参数提供建议。
注意:所有要保存数百万条记录的表都是以 disc_only_copies 类型创建的，因此没有 RAM 问题。 RAM 将足够我们运行的几个 RAM 表。其他 DBMS，如 MySQL Cluster 和 CouchDB 也将包含数据，并与我们的 Mnesia DBMS 使用相同的硬件。 MySQL Cluster 在两台服务器之间进行复制(每台服务器拥有两个 NDB 节点，一个 MySQL 服务器)，管理节点位于不同的主机上。
最佳答案
片段数量为 2 次幂的提示与默认片段模块 mnesia_frag 使用线性散列的事实简单相关，因此使用 2^n 片段可确保记录均匀分布(更多或更多)更少，显然)片段之间。
关于可用的硬件，更多的是性能测试。 可以降低性能的因素有很多，配置像 Mnesia 这样的数据库只是一般问题的一部分。 我只是建议您对一台服务器进行压力测试，然后在两台服务器上测试算法以了解它是否可以正确缩放。
谈论 Mnesia 片段数量缩放请记住，通过使用 disc_only_copies 大部分时间花在两个操作上:
决定哪个片段保存哪个记录
从相应的 dets 表中检索记录(Mnesia 后端)
第一个并不真正依赖于默认情况下 Mnesia 使用线性哈希的片段数量。 第二个与硬盘延迟的关系比其他因素更多。
最终，一个好的解决方案可能是拥有更多的片段和更少的每个片段的记录，但同时尝试找到中间立场，并且不会失去一些硬盘性能提升的优势，如缓冲区和高速缓存。
关于database - 生产中的超大型 Mnesia 表，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/7090193/