为了有效地配置分片表,我们使用了许多在大型系统中使用mnesia的引用：
这些是：Mnesia One Year Later Blog,Part 2 of the Blog,Followed it even here,About Hashing.这些博客文章帮助我们在这里进行了微调,以获得更好的表现.
现在的问题. Mnesia具有桌面大小限制,是的,我们同意.然而,对碎片数量的限制在任何地方都没有提到.出于性能原因,为了满足大量数据,有多少个片段会保留mnesia“okay”？
在我们的一些表中,我们有64个片段.将n_disc_only_copies设置为集群中的节点数,以使每个节点具有每个片段的副本.这有助于我们解决如果某个节点在一瞬间不能达到的情况下,就会发生错误写入失败的问题.另外在上面的博客中,他建议片段的数量应该是2的幂,这个声明(他说)是从mnesia做记录的方式调查的.然而,我们需要更多的解释,两个在这里谈论的是哪些权力：2,4,16,32,64,128,…？
该系统旨在运行在包含Intel处理器(2个处理器,每个4个内核,每个2.4GHz核心,8 MB高速缓存大小),20 GB RAM大小,1.5 TB磁盘空间的HP Proliant G6上.现在,这些大功率机器中有2台可供我们使用.系统数据库应该在两者之间复制.每个服务器运行Solaris 10,64位.
什么数量的片段可能会使神秘的表现开始降级？如果将给定表格的片段数从64个增加到128个,可以吗？ 65536个片段(2 ^ 16)？我们如何通过使用碎片来扩展我们的遗体以利用太字节空间？
请提供问题的答案,您可以提供任何可能增强系统的其他参数的建议.
注意：所有保存数百万条记录的表都是以disc_only_copies类型创建的,因此没有RAM问题. RAM将足够用于我们运行的几个RAM表.像MysqL Cluster和CouchDB这样的其他DBMS也将包含数据,并且与我们的Mnesia DBMS使用相同的硬件. MysqL群集在两台服务器之间进行复制(每个服务器都有两个NDB节点,一个是MysqL服务器),管理节点位于不同的HOST上.
解决方法
关于处理的硬件,您可以认为这不是一个答案,但欢迎在性能测试的糟糕世界.
我在工作中做了很多次,因为可以降低性能的因素是如此之多,因为配置mnesia数据库只不过是问题之一.
我只是建议你在一个服务器上进行压力测试,然后在两个服务器上测试算法,以了解它是否正确扩展.
而对于mnesia片段编号,请记住,disc_only_copies大部分时间花在两个操作中：
>决定哪个片段有哪个记录
>从dets表中检索记录(mnesia后端)
第一个不是真正依赖于片段的数量,考虑到默认情况下,mnesia使用线性散列.
第二个更多的依赖于硬盘延迟比其他因素.
最后的结论是：我的两美分是每个片段更多的碎片和更少的记录.
而且,BTW,测试测试！
