一列mnesia可以存储多少数据。它有限制吗？或者我们可以随心所欲地储存。有指针吗？（如果表为disc_only_copy）
与任何潜在的大数据集一样（就总条目而言，而不是总字节数而言），真正的问题不是你能在一个表中塞进多少，而是你想如何对数据进行分区，以及这些分区在系统中应该有多统一或不同。
例如，在聊天系统的上下文中，您可能希望能够永远保存聊天历史记录，这是一个合理的目标。但你可能不希望所有的聊天条目永远都在同一张表中（10年？多久？谁知道呢！），就在昨天的聊天条目旁边。随着时间的推移，你可能还会发现，将每一条聊天信息存储在一张表中是一个痛苦而天真的决定，以后要克服这个决定。
这就引出了分区的问题。你想怎么做？（停留在聊天系统的上下文中，但很容易转移到另一个问题…）时间到了？按频道？按用户？按时间和频道？
您希望以后如何查找数据？这带来了与上述相同的显而易见的答案：到时间了？按频道？按用户？按时间和频道？
当您考虑存储大量条目时，无论您是在处理Mnesia还是Postgres，或者任何数据库，都存在这个问题。因此，请在您希望如何对数据进行分区的上下文中思考您的问题。
第二个问题是以字节为单位的数据量，以及该数据最自然的表示形式。考虑到基本的聊天数据，简单地将所有内容插入数据库并不难想象。但是，如果它是一个聊天系统，可以在消息中附加大文件，我可能希望将这些文件按原样存储在为此而创建的系统中的某个位置（比如文件系统！），并在数据库中只存储对它的引用。如果我在创建一个电影档案，我肯定会觉得使用Mnesia来存储电影的标题、演员、年份和指针（URL或文件系统路径）很舒服，但我不会梦想将电影文件数据存储在我的数据库中，即使我使用的是Postgres（它实际上可以抵御这种滥用……但想想数据库转储、备份的新尴尬，以及以每个人下载/上传速度的形式引入的巨大瓶颈，无论核心服务到数据库后端的带宽是多少！）。
除了这些问题之外，您还需要考虑数据后端将如何与系统的其他部分进行接口。您希望使用的API是什么？现在就把它写出来，仔细想一想，看看它是否愚蠢。一旦它看起来很完美，就批判性地回去，扔掉任何你没有即时需要立即使用的元素。
因此，这给了我们：
- 分区方案
- 未来查询的上下文
- 数据量（字节）
- 要存储的不同数据元素的自然状态
- 与您希望使用的整个系统的接口
当你开始想知道你可以在数据库中放入多少数据时，这些都是你必须开始问自己的问题。
既然已经写好了，这里有一个问题，从条目、字节以及不同类型的条目可能代表多少字节的角度来讨论Mnesia：Mnesia数据库的存储容量是多少？
Mnesia作为内存数据库启动。这意味着它不是为存储大量数据而设计的。当你问自己这个问题时，意味着你应该看看另一个射精后端。