数据库 – 生产中非常大的Mnesia表

前端之家收集整理的这篇文章主要介绍了数据库 – 生产中非常大的Mnesia表前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我们使用Mnesia作为一个非常大的系统的主数据库. Mnesia碎片表在测试期间表现良好.系统已经有大约15个表,每个表都复制到两个站点(节点),每个表都是高度分段的.在测试阶段(其重点是可用性,效率和负载测试),我们接受了Mnesia,其复杂结构的许多优点将为我们做好准备,因为在服务之上运行的所有应用程序都是Erlang / OTP应用程序.我们正在运行Yaws 1.91作为主要的WebServer.
为了有效地配置分片表,我们使用了许多在大型系统中使用mnesia的引用:

这些是:Mnesia One Year Later Blog,@L_301_1@,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_frag)使用线性散列的事实有关,因此使用2 ^ n个片段可以确保记录的分布均匀(或多或少),显然)片段之间.

关于处理的硬件,您可以认为这不是一个答案,但欢迎在性能测试的糟糕世界.
我在工作中做了很多次,因为可以降低性能的因素是如此之多,因为配置mnesia数据库只不过是问题之一.
我只是建议你在一个服务器上进行压力测试,然后在两个服务器上测试算法,以了解它是否正确扩展.

而对于mnesia片段编号,请记住,disc_only_copies大部分时间花在两个操作中:

>决定哪个片段有哪个记录
>从dets表中检索记录(mnesia后端)

第一个不是真正依赖于片段的数量,考虑到默认情况下,mnesia使用线性散列.
第二个更多的依赖于硬盘延迟比其他因素.

最后的结论是:我的两美分是每个片段更多的碎片和更少的记录.

而且,BTW,测试测试!

猜你在找的MsSQL相关文章