我们将Mnesia用作非常大型系统的主数据库。 Mnesia Fragmented Tables在测试期间表现良好。系统有大约15个表，每个表在2个站点（节点）上复制，每个表都是高度分散的。在测试阶段（主要关注可用性，效率和负载测试），我们接受了Mnesia的复杂结构的许多优点将为我们做，因为我们在服务之上运行的所有应用程序都是Erlang / OTP应用程序。我们运行Yaws 1.91作为主WebServer。
为了有效地配置碎片表，我们使用了许多在大型系统中使用过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写入失败的问题。同样在上面的博客中，他建议the number of fragments should be a power of 2，这句话（他说）是根据mnesia记录的方式进行调查的。然而，我们需要对此进行更多解释，以及在这里讨论两种权力：2,4,16,32,64,128，......？
该系统适用于HP Proliant G6，包含Intel处理器（2个处理器，每个4核，每个核心2.4 GHz速度，8 MB缓存大小），20 GB RAM大小，1.5 TB磁盘空间。现在，我们可以使用其中的两台高功率机器。应该在两者之间复制系统数据库。每个服务器运行Solaris 10,64位。
mnesia的表现会在什么样的片段开始降级？如果我们将给定表的片段数从64增加到128，这样可以吗？ 65536个片段（2 ^ 16）怎么样？我们如何通过使用碎片来扩展我们的mnesia以利用Terabyte空间？
请提供问题的答案，并且您可以提供有关可能增强系统的任何其他参数的建议。
注意：所有要保存数百万条记录的表都是以disc_only_copies类型创建的，因此没有RAM问题。对于我们运行的少数RAM表，RAM就足够了。其他DBMS如MySQL Cluster和CouchDB也将包含数据，并且与我们的Mnesia DBMS使用相同的硬件。 MySQL Cluster在两个服务器上复制（每个服务器包含两个NDB节点，一个MySQL服务器），管理节点位于不同的主机上。
答案 0 :(得分：14)
具有两个碎片数量的功能的提示与默认碎片模块mnesia_frag使用线性散列的事实简单相关，因此使用2 ^ n个碎片可确保记录均匀分布（或多或少，显然）片段之间。
关于可供使用的硬件，更多的是性能测试问题。 可以降低性能的因素很多，配置像Mnesia这样的数据库只是一般问题的一个部分。 我只是建议你对一台服务器进行压力测试，然后在两台服务器上测试算法，以了解它是否正确扩展。
谈论Mnesia片段数量缩放记住，通过使用disc_only_copies，大部分时间花在两个操作上：
决定哪个片段包含哪个记录
从相应的dets表（Mnesia后端）检索记录
第一个并不真正依赖于所考虑的片段数量，默认情况下Mnesia使用线性散列。 第二个与硬盘延迟相关，而不是与其他因素有关。
最后一个好的解决方案可能是每个片段有更多的片段和更少的记录，但同时尝试找到中间地带，而不是失去一些硬盘性能提升的优势，如缓冲区和缓存。