为什么直接搜索MongoDB碎片的全文要比查看集群管理器(mongos)实例快得多？

Question

我对MongoDB中的全文搜索性能非常不满意，所以我一直在寻找盒子外的解决方案。由于在8台强大的机器上共享了2500万个文档的相对较少的集合(4个带有冗余的碎片)，我看到一些查询耗时10秒。那太可怕了。在云雀上，我直接对碎片进行了10秒的查询，看起来芒戈斯正在向碎片发送查询，而不是并行的。在这4个碎片中，我看到一个碎片的搜索时间为2.5秒，另一个碎片的搜索时间为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的一位专家谈过，我了解了大部分事情(我认为)，但我很高兴看到其他人说了些什么，这样我才能支付赏金并使之正式化。

Answer 1

有人能确认这些对碎片的查询是连续运行的吗？或者提供其他解释？

在查询中没有碎片键的情况下，查询将发送到所有碎片，并在并行中并行处理。但是，来自所有碎片的结果将在主碎片处合并，因此它将等待最慢的碎片返回。

直接查询碎片的陷阱是什么？

您可能包括孤立的文档。通过mongos进行查询还会检查孤立的文档，以确保数据的一致性。因此，通过mongos查询比直接从每个碎片查询更多的开销。

使用Robo 3T的查询时间测量

使用Robo3T不能正确地测量查询时间。默认情况下，Robo3T返回前50个文档。对于驱动程序实现，如果返回的文档数量大于默认批处理大小，则要检索所有文档，将有getmore请求跟随到数据库。Robo 3T只给出第一批，即结果的子集。

若要计算查询，请向查询中添加explain('executionStats')。性能影响很可能是碎片之间的数据传输。由于查询中缺少一个碎片键，所以在合并之前，必须将所有碎片的结果发送到碎片。总时间不仅是mongo引擎的查询时间(定位文档)，也是文档检索的时间。

执行下面的命令，您将从每个碎片中看到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"}]}}
]
);