非常大的Mnesia生产表 [英] Very Large Mnesia Tables in Production

问题描述

我们使用Mnesia作为一个非常大的系统的主数据库。 Mnesia碎片表在测试期间表现良好。系统有大约15个表，每个表复制在2个站点（节点），每个表是高度分散的。在测试阶段（专注于可用性，效率和负载测试），我们接受了Mnesia以及其复杂结构的许多优势，因为我们所有运行在服务上的应用程序都是Erlang / OTP应用程序。我们运行Yaws 1.91作为主WebServer。


为了有效地配置分段表，我们使用了大量系统中使用mnesia的引用：


这些是： Mnesia一年后的博客 ， 第2部分的博客 ， ， 关于散列 。这些博客文章帮助我们在这里和那里更好的表现。

现在，问题。 Mnesia有表大小限制，是的，我们同意。然而，对片段数目的限制在任何地方都没有提及。出于性能原因，并且为了满足大数据，关于有多少碎片将保持mnesia好？

在我们的一些表中，我们有64个碎片。其中 n_disc_only_copies 设置为集群中的节点数，以便每个节点都有一个每个片段的副本。这有助于我们解决mnesia写入失败的问题，如果给定的节点在一瞬间不能达到。在上面的博客中，他建议片段的数量应该是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磁盘空间。现在，这些大功率机器中的2个在我们的处置。系统数据库应在两者之间复制。每个服务器运行Solaris 10,64位。

mnesia的性能开始降级的碎片数量是多少？如果我们将片段数从64增加到128，对于给定的表是否可以吗？怎么样65536个片段（2 ^ 16）？我们如何扩展我们的mnesia以通过使用碎片来利用Terabyte空间？

请提供问题的答案，您可以提供有关可能会增强系统的任何其他参数的建议。

注意：保存数百万条记录的所有表都创建在 disc_only_copies 类型中，因此没有RAM问题。 RAM将足够用于我们运行的几个RAM表。其他DBMS如MySQL Cluster和CouchDB也将包含数据，并使用与我们的Mnesia DBMS相同的硬件。 MySQL簇被跨越两个服务器（每个包含两个NDB节点，一个MySQL服务器）复制，管理节点在不同的HOST上。

解决方案

关于片段的数量问题：具有两个片段数的幂的提示与默认片段化模块（mnesia_frag）使用线性哈希的事实简单相关，因此使用2 ^ n个片段确保记录均匀分布（或多或少，显然）在片段之间。

关于硬件处置，你可以认为它不是一个答案，但欢迎在性能测试的坏的世界。
我在工作中做了很多次，因为可以降低性能的因素是如此之多，以至于配置mnesia数据库只是其中的一个问题。
我只是建议你在一个服务器上进行压力测试，然后测试服务器上的算法，以了解它是否正确缩放。

对于mnesia碎片请记住，大多数时间都有disc_only_copies用于两个操作：

• 决定哪个片段有哪个记录

第一个不是真正依赖于片段的数量，考虑到默认情况下mnesia使用线性哈希。
第二个更多的依赖于硬盘等待时间比其他因素。





最后结论：我的两分钱是更多的碎片，每个碎片少记录。





而且，BTW，测试测试测试!!!




We are using Mnesia as a primary Database for a very large system. Mnesia Fragmented Tables have behaved so well over the testing period. System has got about 15 tables, each replicated across 2 sites (nodes), and each table is highly fragmented. During the testing phase, (which focused on availability, efficiency and load tests), we accepted the Mnesia with its many advantages of complex structures will do for us, given that all our applications running on top of the service are Erlang/OTP apps. We are running Yaws 1.91 as the main WebServer.

For efficiently configuring Fragmented Tables, we used a number of references who have used mnesia in large systems:
These are: Mnesia One Year Later Blog, Part 2 of the Blog, Followed it even here, About Hashing. These blog posts have helped us fine tune here and there to a better performance.

Now, the problem. Mnesia has table size limits, yes we agree. However, limits on number of fragments have not been mentioned anywhere. For performance reasons, and to cater for large data, about how many fragments would keep mnesia "okay" ?.

In some of our tables, we have 64 fragments. with n_disc_only_copies set to the number of nodes in the cluster so that each node has a copy per fragment. This has helped us solve issues of mnesia write failure if a given node is out of reach at an instant. Also in the blog above, he suggests that the number of fragments should be a power of 2, this statement (he says) was investigated from the way mnesia does its hashing of records. We however need more explanation on this, and which power of two are being talked about here: 2,4,16,32,64,128,...?

The system is intended to run on HP Proliant G6, containing Intel processors (2 processors, each 4 cores, 2.4 GHz speed each core, 8 MB Cache size), 20 GB RAM size, 1.5 Terabytes disk space. Now, 2 of these high power machines are in our disposal. System Database should be replicated across the two. Each server runs Solaris 10, 64 bit.

At what number of fragments may mnesia's performance start to de-grade? Is it okay if we increase the number of fragments from 64 to 128 for a given table? how about 65536 fragments (2 ^ 16) ? How do we scale out our mnesia to make use of the Terabyte space by using fragmentation?

Please do provide the answers to the questions and you may provide advice on any other parameters that may enhance the System.

NOTE: All tables that are to hold millions of records are created in disc_only_copies type, so no RAM problems. The RAM will be enough for the few RAM Tables we run. Other DBMS like MySQL Cluster and CouchDB will also contain data and are using the same hardware with our Mnesia DBMS. MySQL Cluster is replicated across the two servers (each holding two NDB Nodes, a MySQL server), the Management Node being on a different HOST.

解决方案

about the number of fragments question: the hint of having a power of two number of fragments is simply related to the fact the default fragmentation module (mnesia_frag) uses linear hashing so using 2^n fragments assures that records are equally distributed (more or less, obviously) between fragments.

About the hardware at disposal, well you can think it's not an answer but welcome in the bad world of performance testing. I do it many times at work 'cause the factors that can reduce performance are so many that configuring mnesia database is nothing but one of the problems. I simply advice you of doing a stress test on one server and then test the algorithm on both server to understand if it scales correctly.

And for mnesia fragments number, remember that having disc_only_copies most of the time is spent in two operations:

• decide which fragment has which record

• retrieve the record from the dets table (mnesia backend)

The first one is not really dependent from the number of fragments, considering that by default mnesia uses linear hashing. The second one depends more on hard disk latency than other factors.

Final conclusion: my two cents are more fragments and less records per fragment.

And, BTW, test test test!!!

这篇关于非常大的Mnesia生产表的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！