我测试了两个场景Single Huge collection vs Multiple Small Collections,并在查询时发现了巨大的性能差异.这就是我做的.
案例1:我创建了一个产品集合,其中包含10种不同类型产品的1000万条记录,并且每种产品类型的记录正好为100万条,我在ProductType上创建了索引.当我运行条件ProductType = 1和ProductPrice> 100并且限制(10)的示例查询返回ProductType = 1的10条记录并且其价格大于100时,当集合有很多产品价格时花了大约35毫秒当我们在ProductType = 1中的产品数量非常少而且价格大于100时,相同的查询大约需要8000毫秒(8秒).
案例2:我为每个ProductType创建了10个不同的Product表,每个ProductType包含100万条记录.在包含productType 1记录的集合1中,当我运行条件为ProductPrice> 100且limit(10)的相同样本查询返回10个价格大于100的产品记录时,当集合有很多时,它花了大约2.5毫秒价格超过100的产品,当价格大于100的产品数量非常少时,同样的查询大约需要1500毫秒(1.5秒).
那么为什么会有这么大的差异呢？案例一和案例二之间的唯一区别是一个巨大的集合与多个较小的集合,但我在第一个案例中创建了一个单一巨大集合的ProductType索引.我猜性能差异是由第一种情况下的索引引起的,我在第一种情况下需要该索引,否则性能会更差.我预计在第一种情况下由于指数会有一些表现缓慢但我没想到在第一种情况下差异大约10倍.
因此,对于一个巨大的集合与多个小集合相比,8000毫秒对1500毫秒.为什么？
我现在收集了TimeSheet几千条记录.这最终将在一年内增加到3亿条记录.在这个集合中,我嵌入了来自另一个集合的几个字段,Department其中大部分都不会获得任何更新,并且很少会更新某些记录.我很少说一年只有一次或两次,也不是所有记录,只有不到1%的记录.
一旦创建了一个部门,就不会有任何更新,即使有更新,也会在最初完成(当TimeSheet中的相关记录不多时)
现在如果有人在一年后更新一个部门,在最糟糕的情况下,收集的机会总共TimeSheet将有大约3亿条记录,并且该部门的大约500万条匹配记录会更新.更新查询条件将位于索引字段上.
由于这次更新非常耗时并且会产生锁定,我想知道有没有更好的方法呢？我正在考虑的一个选项是通过添加额外条件来批量运行更新查询UpdatedDateTime> somedate && UpdatedDateTime < somedate.
其他详情:
单个文档大小可以是大约3或4 KB我们有一个包含三个副本的副本集.
还有其他更好的方法吗？您如何看待这种设计？如果我给出的数字不像下面那么你觉得怎么样？
1)更新查询的1亿条记录和100,000条匹配记录
2)更新查询总计1000万条记录和10,000条匹配记录
3)更新查询总计100万条记录和1000条匹配记录
注意:集合名称department和timesheet它们的目的是虚构的,而不是真正的集合,但我给出的统计数据是真实的.