mnesia列可以存储多少数据。对它有任何限制，或者我们可以存储我们想要的任何数量。任何指针？（如果表是disc_only_copy）
答案 0 :(得分：3)
与任何可能较大的数据集一样（就总条目数而言，不是总字节数），真正的问题不在于您可以将多少数据塞入单个表中，而是如何对数据进行分区和这些分区应该如何统一或区别于系统。
例如，在聊天系统的上下文中，您可能希望能够永久保存聊天记录，这是一个合理的目标。但是你可能不希望所有聊天条目永远存在于同一个表中（10年？多长时间？谁知道！）就在昨天的聊天条目旁边。您可能还会发现，随着时间的推移，将每个聊天消息存储在一张表中是一个非常天真的决定，可以在以后的路上克服。
所以这就提出了分区的问题。你想怎么做？ （保持在聊天系统的环境中，但很容易转移到另一个问题......）按时间？通过渠道？用户？按时间和渠道？
您希望以后如何查找数据？这带来了与上述相同的明显答案：按时间？通过渠道？用户？按时间和渠道？
当您考虑存储批次条目时，无论您是在处理Mnesia还是与Postgres或任何数据库进行交易，都会出现此问题。因此，在您希望如何对数据进行分区的上下文中考虑您的问题。
第二个问题是以字节为单位的数据量，以及该数据的最自然表示。考虑到基本的聊天数据，简单地将所有内容插入数据库并不难想象。但是如果它的聊天系统可以在消息中附加大文件，我可能希望将这些文件存储为系统中的某些内容（文件）（就像文件系统一样！）并且只存储一个在数据库中引用它。如果我正在创建一个电影档案，我肯定会觉得使用Mnesia来存储电影中的标题，演员，年份和指针（URL或文件系统路径），但我不会梦想存储电影文件数据。我的数据库，即使我使用的是Postgres（它实际上可以经受住那种滥用......但想想以每个人的下载/上传速度的形式引入的数据库转储，备份和大量瓶颈的新尴尬无论核心服务对数据库后端的带宽是什么！）。
除了这些问题之外，您还要考虑数据后端如何与系统的其余部分进行交互。您希望使用的API是什么？现在写下来，仔细思考，看看它是否愚蠢。一旦看起来很完美，那就回头看看并删掉任何你没有立即需要实际使用的元素。
所以，这给了我们：
当您开始想知道可以将多少数据放入数据库时，您必须开始问自己这些问题。
现在已经编写了所有内容，这里有一个问题，就条目，字节和不同类型的条目可能代表的字节数来讨论Mnesia：What is the storage capacity of a Mnesia database?
答案 1 :(得分：2)
Mnesia最初是一个内存数据库。这意味着它不是为存储大量数据而设计的。当你问自己这个问题时，这意味着你应该看看另一个ejabberd后端。