And*_*w J 8 database storage database-design data-paging mongodb
我正在开展一个项目,我们定期通过IMAP或POP收集大量电子邮件,对其进行分析(例如聚类到对话,提取重要句子等),然后通过网络呈现视图到最后用户.
主视图将是一个类似Facebook的个人资料页面,用于最近(大约20个)对话的每个联系人,每个对话都来自我们捕获的电子邮件.
对我们而言,能够经常快速地检索个人资料页面和最近20个项目非常重要.我们也可能经常在此Feed中插入最近的电子邮件.为此,文档存储和MongoDB的低成本原子写入看起来非常有吸引力.
然而,我们还会有大量的旧电子邮件会话,这些会话不会经常被访问(因为它们不会出现在最近的20个项目中,人们只会在他们搜索它们时看到它们,这将是相对罕见).此外,随着时间的推移,此数据的大小将比联系人存储的增长更快.
从我读过的内容来看,MongoDB似乎或多或少地要求整个数据集保留在RAM中,解决这个问题的唯一方法就是使用虚拟内存,这会带来很大的开销.特别是如果Mongo无法区分易失性数据(配置文件/提要)和非易失性数据(旧电子邮件),这可能最终会非常讨厌(因为它似乎将虚拟内存分配转移到操作系统,我不知道Mongo怎么可能这样做.
似乎唯一的选择是(a)购买足够的RAM来存储所有内容,这对于易失性数据来说很好,但是对于捕获TB的电子邮件几乎没有成本效益,或者(b)使用虚拟内存并且看到读取/写入我们的易失性数据慢慢爬行.
这是正确的,还是我错过了什么？MongoDB是否适合这个特殊问题？如果是这样,配置会是什么样的？
MongoDB 使用 mmap 将文档映射到虚拟内存（而不是物理 RAM）。Mongo 不要求整个数据集都位于 RAM 中，但您希望“工作集”位于内存中（工作集应该是整个数据集的子集）。
如果您想避免将大量电子邮件映射到虚拟内存中，您可以让您的配置文件文档包含一个 ObjectId 数组，该数组引用存储在单独集合中的电子邮件。