为什么直接全文搜索MongoDB碎片要比通过cluster manager（mongos）实例快得多？

我对MongoDB的全文搜索性能非常不满意，所以我一直在寻找开箱即用的解决方案。在8台健壮的机器（4个冗余的碎片）上，有2500万个文档的相对较小的集合，我看到一些查询需要10秒钟。那太可怕了。在一个百灵鸟上，我尝试了一个10秒的直接碎片查询，看起来mongos是在串行而不是并行地向碎片发送查询。在4个碎片中，我看到一个碎片的搜索时间为2.5秒，另外3个碎片的搜索时间各不到2秒。这总共不到8.5秒，但通过mongos只花了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的一位专家谈过，了解了大部分情况（我想），但很高兴看到其他人说了些什么，这样我就可以支付赏金并将其正式公布

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

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

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

您可能会包含孤立文档。通过

mongos进行查询

还会检查孤立文档以确保数据一致性。因此，通过

mongos

进行查询比直接从每个shard进行查询具有更大的开销

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

使用Robo3T无法正确测量查询时间。默认情况下，Robo3T返回前50个文档。对于驱动程序实现，如果返回的文档数大于默认的批量大小，则要检索所有文档，将有

getmore

请求跟随到数据库。Robo 3T仅提供第一批结果，即结果的子集

要评估查询，请将

explain（'executionStats'）

添加到查询中。性能受到的影响可能是碎片之间的数据传输。由于查询中缺少切分键，因此在合并之前，必须将所有切分的结果发送到切分。总时间不仅是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"}]}}
]
);

---

你的mongo版本是什么？你的查询是什么样的？它是否使用了另一个条件而不是$search或其他排序？更新了描述。您能给我们一些关于如何创建文本索引的详细信息吗？你的碎片是如何组织的？您是否有副本集（有多少个）？如果知道哪些查询花费的时间更长，您应该使用db.collectionName.find（{Query}）.explain（）@ChrisSeline检查这些查询是否使用了btreeCursor，并使用db.collectionName.find（{Query}）.explain如何度量查询时间？我敢肯定，“分散-聚集”是并行运行的