生产中的超大型 Mnesia 表

Posted 2023-03-15

【中文标题】生产中的超大型 Mnesia 表

【英文标题】：Very Large Mnesia Tables in Production

【发布时间】：2011-10-28 17:53:12

【问题描述】：

我们使用 Mnesia 作为大型系统的主数据库。 Mnesia Fragmented Tables 在测试期间表现得非常好。系统有大约 15 个表，每个表在 2 个站点（节点）上复制，每个表都高度碎片化。在测试阶段（专注于可用性、效率和负载测试），我们接受了 Mnesia 及其复杂结构的许多优势，因为我们在服务之上运行的所有应用程序都是 Erlang/OTP 应用程序。我们正在运行 Yaws 1.91 作为主 WebServer。 为了有效地配置 Fragmented Tables，我们使用了许多在大型系统中使用过 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 的哪个幂：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 集群在两台服务器之间复制（每台服务器拥有两个 NDB 节点，一个 MySQL 服务器），管理节点位于不同的主机上。

【问题讨论】：

也许你可以尝试在 erlang-questions 邮件列表上提问。它有很多经验丰富的大佬，你更有可能在那里得到这样一个开放式问题的好答案.

谢谢@knutin，让我试试

嘿 @MuzaayaJoshua，如果您确实在 erlang-questions 上发过帖子，您介意分享链接吗？

【参考方案1】：

具有两个片段数的幂的提示与默认片段模块mnesia_frag 使用线性散列的事实简单相关，因此使用 2^n 片段可确保记录在之间平均分布（或多或少，显然）碎片。

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

谈到 Mnesia 碎片数缩放，请记住，通过使用 disc_only_copies，大部分时间都花在了两个操作上：

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

从对应的 dets 表中检索记录（Mnesia 后端）

第一个实际上并不依赖于默认情况下 Mnesia 使用线性散列的片段数量。 第二个与硬盘延迟有关，而不是其他因素。

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