生产中的非常大的Mnesia表

Question

我们使用Mnesia作为非常大的系统的主数据库.Mnesia Fragmented Tables在测试期间表现良好.系统有大约15个表,每个表在2个站点(节点)上复制,每个表都是高度分散的.在测试阶段(主要关注可用性,效率和负载测试),我们接受了Mnesia的复杂结构的许多优点将为我们做,因为我们在服务之上运行的所有应用程序都是Erlang/OTP应用程序.我们运行Yaws 1.91作为主WebServer.

为了有效地配置分段表中,我们使用了一些谁已经在大型系统中使用Mnesia的引用:
它们是:Mnesia的一年后博客,博客的第2部分,其次是即使在这里,关于散列.这些博客文章帮助我们在这里和那里进行了微调,以获得更好的性能.

现在,问题.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服务器),管理节点位于不同的主机上.

Answer 1

具有两个碎片数量的能力的暗示与默认碎片模块mnesia_frag使用线性散列的事实简单相关,因此使用2 ^ n个碎片确保记录在碎片之间平均分布(或多或少).

关于可以使用的硬件,更多的是性能测试问题.可以降低性能的因素很多,配置像Mnesia这样的数据库只是一般问题的一个部分.我只是建议你对一台服务器进行压力测试,然后在两台服务器上测试算法,以了解它是否正确扩展.

谈论Mnesia片段数量缩放记住,通过使用disc_only_copies大部分时间花在两个操作上:

• 决定哪个片段保存哪个记录

• 从相应的dets表中检索记录(Mnesia后端)

第一个并不真正依赖于所考虑的片段数量,默认情况下Mnesia使用线性散列.第二个与硬盘延迟相关,而不是与其他因素相关.

最后一个好的解决方案可能是每个片段有更多的片段和更少的记录,但同时尝试找到中间地带,而不是失去一些硬盘性能提升的优势,如缓冲区和缓存.