我们有 2700 万份文档分布在 3 个分片中,每个分片包含大约 900 万份文档。每个文档都有约 15 个索引字段。要求是我们应该能够使用索引字段的组合来过滤这些文档。对于复杂查询,count() 最多花费不到 20 秒。
我们还需要使用 find() 提取与过滤器匹配的文档的特定字段。但是,有时这需要几分钟才能完成,尤其是在结果超过 100 万个文档时。这是通过 Web 服务调用执行的,因此有时会发生超时。
我想知道添加更多分片是否可以解决问题,或者我们可以应用其他优化。
谢谢!
我们有 2700 万份文档分布在 3 个分片中,每个分片包含大约 900 万份文档。每个文档都有约 15 个索引字段。要求是我们应该能够使用索引字段的组合来过滤这些文档。对于复杂查询,count() 最多花费不到 20 秒。
我们还需要使用 find() 提取与过滤器匹配的文档的特定字段。但是,有时这需要几分钟才能完成,尤其是在结果超过 100 万个文档时。这是通过 Web 服务调用执行的,因此有时会发生超时。
我想知道添加更多分片是否可以解决问题,或者我们可以应用其他优化。
谢谢!
添加更多分片对您没有帮助,但您可以进行分页,这可以返回有限的文档,因为您必须进行多个 API 调用
你可以这样做
db.users.find(/*condition*/).limit (10000)
db.users.find(/*condition*/).skip(10000).limit(10000)
db.users.find(/*condition*/).skip(20000).limit(10000)
我在一个有数千万条记录的项目中遇到了同样的问题,过滤查询很复杂。
我不知道您是否有足够的资源或者您的项目是否有可能,但我解决了该项目正在创建包含报告结果的新集合。
系统在空闲时间提供和更新报告,并且大多数报告已准备好使用或仅针对新字段需要更新。
也正如其他人所说,分页是这种查询的必要条件。
如果你解决了查询执行的问题并且它足够快,那么处理这么多数据的 HTTP 请求就没有足够快的速度来提供良好的用户体验。