【发布时间】：2015-05-05 02:42:17
【问题描述】：
mnesia的一列可以存储多少数据。有没有限制或者我们可以存储多少我们想要的。任何指针？（如果表是disc_only_copy）
【问题讨论】：
【发布时间】：2015-05-05 02:42:17
【问题描述】：
Mnesia 最初是一个内存数据库。这意味着它不是为存储大量数据而设计的。当你问自己这个问题时，这意味着你应该看看另一个 ejabberd 后端。
【讨论】：
-
这忽略了规模问题。 “很多”的含义在字节数方面已经发生了显着变化，但是对于 单个分区来说，一百万个条目仍然相当多，无论是在 Postgres 还是 Mnesia 中。
-
我一直在 ejabberd 的上下文中回复，当被问到这个问题时相信我，我从经验中知道用户需要从 Mnesia 切换到另一个后端。这确实是一个很实用的回复，不过应该也够用了；）
与任何潜在的大型数据集（就总条目而言，而不是总字节数而言）一样，真正的问题不是您可以在单个表中塞进多少数据，而是您希望如何对数据进行分区以及如何统一或区分这些分区应该出现在系统中。
例如，在聊天系统的上下文中，您可能希望能够永久保存聊天记录，这是一个合理的目标。但是您可能不希望所有聊天条目永远都在同一个表中（10 年？多长时间？谁知道！）就在昨天创建的聊天条目旁边。随着时间的推移，您可能还会发现，将每条聊天消息存储在一个表格中是一个非常幼稚的决定，以后需要克服。
所以这带来了分区的问题。你想怎么做？ （停留在聊天系统的上下文中，但很容易转移到另一个问题......）按时间？按渠道？按用户？按时间和渠道？
您想以后如何定位数据？这带来了与上面相同的明显答案：按时间？按渠道？按用户？按时间和渠道？
无论您是使用 Mnesia 还是使用 Postgres（或任何数据库），当您考虑存储 lots 条目时，都会存在此问题。因此，请在您希望如何对数据进行分区的背景下考虑您的问题。
第二个问题是以字节为单位的数据量，以及该数据的最自然表示。考虑到基本的聊天数据，不难想象简单地将所有内容都插入数据库。但是，如果它是一个可以在消息中附加大文件的聊天系统，我可能希望将这些文件按原样（文件）存储在为此而制作的系统（如文件系统！）中的某个位置，并且只存储一个在数据库中引用它。如果我正在创建电影档案，我肯定会觉得使用 Mnesia 来存储电影的标题、演员、年份和指针（URL 或文件系统路径）很舒服，但我不会梦想将电影文件数据存储在我的数据库中，即使我使用的是 Postgres（它实际上可以经受住这种滥用......但想想数据库转储、备份和以每个人的下载/上传速度的形式引入的巨大瓶颈的新尴尬，无论核心服务的带宽如何到数据库后端是！）。
除了这些问题之外，您还需要考虑数据后端将如何与系统的其余部分进行交互。您希望可以使用的 API 是什么？现在写下来，仔细考虑一下，看看它是否愚蠢。一旦它看起来很完美，就批判性地回顾并丢弃任何你没有立即需要实际使用现在的元素。
所以，这给了我们：
- 分区方案
- 未来查询的上下文
- 以字节为单位的数据量
- 您要存储的数据的不同元素的自然状态
- 您希望使用的整个系统的接口
当您开始想知道可以将多少数据放入数据库时，您必须开始问自己这些问题。
既然已经写完所有内容，这里有一个问题，它根据条目、字节以及不同类型的条目可能代表多少字节来讨论 Mnesia：What is the storage capacity of a Mnesia database?
【讨论】：