我需要存储数十亿个小的数据结构(每个约200字节)。到目前为止,将每个元素作为单独的文档存储效果很好,Mongo每秒提供大约10,000个结果。我使用20字节的哈希作为每个文档的_id,并在_id字段上使用单个索引。经过测试,对于500万个文档的数据集,这种方式是可行的。
在操作中,我们将每秒进行大约10,000次请求,每秒更新现有文档约1,000次,并且可能每秒或更少地插入新文档100次。
当我们无法将整个索引存储在RAM中时,如何管理更大的数据集?如果我们将几个元素合并到每个文档中,MongoDB是否会表现得更好--用于更快速地搜索索引,但在每个查询中返回更多的数据?
与SO上的其他问题不同,我不仅对我们可以将多少数据塞入Mongo感兴趣。它显然可以管理我们所看到的数据量。我的担忧在于,如何在受限制的RAM条件下最大程度地提高对巨大集合的find
操作的速度。
我们的搜索往往是聚集的;约50,000个元素将满足约50%的查询,但剩余50%将在所有数据上随机分布。通过将这50%移动到自己的集合中,以便始终将最常用的数据的较小索引保留在RAM中,我们可以期望获得性能提升吗?
将_id字段的大小从20字节减少到8字节,是否会对MnogoDB的索引速度产生重大影响?