我对MongoDB的全文搜索性能非常不满意，所以我一直在寻找现成的解决方案。在8台Beefy机器（4个具有冗余的碎片）上，有2500万个文档被碎片相对较小的集合，我看到一些查询需要10秒钟。太糟糕了。在云雀上，我尝试了一个10秒的直接查询碎片，似乎蒙古人是在连续而不是并行地向碎片发送查询。在4个碎片中，我看到一个碎片的搜索时间为2.5秒，另外3个碎片的搜索时间不到2秒。总共不到8.5秒，但蒙古人花了10秒。掌心。
有人能确认这些对碎片的查询正在连续运行吗？或者提供其他解释？
直接查询碎片的陷阱是什么？
我们在4.0上，查询如下：
db.items.aggregate(
[
{ "$match" : {
"$text" : { "$search" : "search terms"}
}
},
{ "$project": { "type_id" : 1, "source_id": 1 } },
{ "$facet" : { "types" : [ { "$unwind" : "$type_id"} , { "$sortByCount" : "$type_id"}] , "sources" : [ { "$unwind" : "$source_id"} , { "$sortByCount" : "$source_id"}]}}
]
);
我以前犯过一个错误，这是发送的查询有问题。我和一个MongoDB专家谈过了，他把事情的大部分内容（我想）都包括进去了，但我很高兴看到别人说了些什么，这样我就可以支付赏金并使之正式化。
最佳答案
有人能确认这些对碎片的查询正在连续运行吗？或
提供其他解释？
如果查询中没有shard键，查询将发送到所有shard并并行处理。但是，所有碎片的结果将在主碎片处合并，因此它将等待最慢的碎片返回。
直接查询碎片的陷阱是什么？
您可能会包括孤立的文档。通过mongos查询还检查孤立文档以确保数据一致性。因此，通过mongos进行查询的开销比直接从每个碎片进行查询的开销要大。
使用Robo 3T的查询时间测量
使用robo 3t无法正确测量查询时间。默认情况下，robo 3t返回前50个文档。对于驱动程序实现，如果返回的文档数大于默认的批处理大小，为了检索所有文档，将有getmore请求跟随到数据库。Robo3T只提供第一批结果，即结果的子集。
若要评估查询，请将explain('executionStats')添加到查询中。性能下降可能是碎片之间的数据传输。因为查询中缺少shard键，所以在合并之前必须将所有shard的结果发送到shard。总时间不仅是Mongo引擎的查询时间（定位文档），也是文档检索时间。
执行下面的命令，您将看到每个shard的inputstages，以便更好地评估您的查询。
db.items.explain('executionStats').aggregate(
[
{ "$match" : {
"$text" : { "$search" : "search terms"}
}
},
{ "$project": { "type_id" : 1, "source_id": 1 } },
{ "$facet" : { "types" : [ { "$unwind" : "$type_id"} , { "$sortByCount" : "$type_id"}] , "sources" : [ { "$unwind" : "$source_id"} , { "$sortByCount" : "$source_id"}]}}
]
);