Почему полнотекстовый поиск фрагментов MongoDB напрямую намного быстрее, чем прохождение экземпляра менеджера кластера (mongos)?

Question

Я был очень недоволен производительностью полнотекстового поиска в MongoDB, поэтому я искал нестандартные решения. С относительно небольшой коллекцией из 25 миллионов документов, отосланных на 8 мощных машинах (4 отрывка с избыточностью), я вижу, что некоторые запросы занимают 10 секунд. Это ужасно В общем, я попробовал 10-секундный запрос к шардам напрямую, и кажется, что монго посылает запросы шарду последовательно, а не параллельно. Через 4 осколка я видел время поиска 2,5 секунды для одного осколка, а для остальных 3 осколков - по 2 секунды каждый. Это всего менее 8,5 секунд, но это заняло 10 через монго. Facepalm.

Может ли кто-нибудь подтвердить, что эти запросы к шардам выполняются последовательно? Или предложить какое-то другое объяснение?

Каковы подводные камни при непосредственном обращении к осколкам?

Мы находимся на 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

Использование Robo 3T неправильно измеряет время запроса. По умолчанию Robo 3T возвращает первые 50 документов. Для реализаций драйверов, если число возвращаемых документов превышает размер пакета по умолчанию, для извлечения всех документов будет отправлено getmore запросов к базе данных. Robo 3T дает вам только первую партию, то есть набор результатов.

Чтобы оценить ваш запрос, добавьте explain('executionStats') к вашему запросу. Падение производительности - это, вероятно, передача данных между осколками Поскольку в запросе отсутствует ключ сегмента, результаты всех сегментов должны быть отправлены в сегмент до объединения. Общее время - это не только время запроса (нахождения документов) из механизма Монго, но и время поиска документов.

Выполните команду ниже, и вы увидите 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"}]}}
]
);