Mongodb Explain for Aggregation framework

Есть ли в MongoDB функция объяснения для фреймворка агрегации? Я не вижу этого в документации.

Если нет, есть ли другой способ проверить, как запрос выполняется в структуре агрегирования?

Я знаю, что ты просто найди

db.collection.find().explain()

Но с фреймворком агрегации я получаю ошибку

db.collection.aggregate(
    { $project : { "Tags._id" : 1 }},
    { $unwind : "$Tags" },
    { $match: {$or: [{"Tags._id":"tag1"},{"Tags._id":"tag2"}]}},
    { 
        $group: 
        { 
            _id : { id: "$_id"},
            "count": { $sum:1 } 
        }
    },
    { $sort: {"count":-1}}
).explain()

Начиная с MongoDB версии 3.0, просто изменив порядок с

collection.aggregate(...).explain()

в

collection.explain().aggregate(...)

даст вам желаемый результат (документация здесь ).

Для более старых версий> = 2.6 вам нужно будет использовать explainопцию для операций конвейера агрегации

explain:true

db.collection.aggregate([
    { $project : { "Tags._id" : 1 }},
    { $unwind : "$Tags" },
    { $match: {$or: [{"Tags._id":"tag1"},{"Tags._id":"tag2"}]}},
    { $group: { 
        _id : "$_id",
        count: { $sum:1 } 
    }},
    {$sort: {"count":-1}}
  ],
  {
    explain:true
  }
)

Важные с Aggregation Framework является то , что индекс может быть использован только для извлечения исходных данных для трубопровода (например , использование $match, $sort, $geonearв начале трубопровода), а также последующий $lookupи $graphLookupэтапах. После того, как данные были загружены в конвейер агрегации для обработки (например, проходя через такие этапы, как $project, $unwindи $group), дальнейшие манипуляции будут производиться в памяти (возможно, с использованием временных файлов, если allowDiskUseопция установлена).

Оптимизация трубопроводов

В целом конвейеры агрегации можно оптимизировать с помощью:

• Запуск конвейера с $matchэтапом, чтобы ограничить обработку соответствующими документами.
• Обеспечение поддержки начальных $match/ $sortэтапов с помощью эффективного индекса .
• Фильтрация данных в начале использования $match, $limitи $skip.
• Минимизация ненужных этапов и манипуляций с документами (возможно, пересмотр вашей схемы, если требуется сложная гимнастика агрегирования).
• Воспользуйтесь преимуществами новых операторов агрегирования, если вы обновили свой сервер MongoDB. Например, в MongoDB 3.4 добавлено много новых этапов и выражений агрегирования, включая поддержку работы с массивами, строками и фасетами.

Существует также ряд оптимизаций конвейера агрегирования, которые автоматически выполняются в зависимости от версии вашего сервера MongoDB. Например, смежные этапы могут быть объединены и / или переупорядочены, чтобы улучшить выполнение, не влияя на выходные результаты.

Ограничения

Как и в MongoDB 3.4, explainопция Aggregation Framework предоставляет информацию о том, как обрабатывается конвейер, но не поддерживает такой же уровень детализации, как executionStatsрежим для find()запроса. Если вы сосредоточены на оптимизации начального выполнения запроса, вам, вероятно, будет полезно просмотреть эквивалентный find().explain()запрос с помощью executionStatsили allPlansExecutionмногословностью .

Есть несколько соответствующих запросов функций для просмотра / голосования в трекере проблем MongoDB относительно более подробной статистики выполнения, чтобы помочь оптимизировать / профилировать конвейеры агрегирования:

• СЕРВЕР-19758: добавьте режимы объяснения «executionStats» и «allPlansExecution» в объяснение агрегирования
• СЕРВЕР-21784: отслеживайте статистику выполнения для каждого этапа конвейера агрегации и предоставляйте через объяснение
• СЕРВЕР-22622: улучшено объяснение $ lookup, чтобы указать план запроса для коллекции "от"

Начиная с версии 2.6.x mongodb позволяет пользователям выполнять объяснения с помощью фреймворка агрегации .

Все, что вам нужно сделать, это добавить объяснение: правда

db.records.aggregate(
  [ ...your pipeline...],
  { explain: true }
)

Благодаря Рафе я знаю, что можно было сделать и в 2.4, но только через runCommand(). Но теперь вы можете использовать и агрегат.

Платформа агрегации - это набор аналитических инструментов, MongoDBкоторые позволяют нам запускать различные типы отчетов или анализа документов в одной или нескольких коллекциях. На основе идеи трубопровода. Мы берем входные данные из MongoDBколлекции и передаем документы из этой коллекции через один или несколько этапов, каждый из которых выполняет свою операцию над входными данными. Каждый этап принимает в качестве входных данных все, что было до его создания в качестве выходных. А входы и выходы для всех этапов - это поток документов. У каждого этапа есть определенная работа, которую он выполняет. Он ожидает конкретную форму документа и производит определенный вывод, который сам по себе является потоком документов. В конце конвейера мы получаем доступ к выходу.

Индивидуальный этап - это блок обработки данных. Каждый этап принимает в качестве входных данных поток документов по одному, обрабатывает каждый документ по одному и создает выходной поток документов. Опять же, по одному. Каждый этап предоставляет набор регуляторов или настраиваемых параметров, которыми мы можем управлять, чтобы параметризовать этап для выполнения любой интересующей нас задачи. Таким образом, этап выполняет общую задачу - задачу общего назначения и параметризует этап для конкретного набора документов, с которым мы работаем. И что именно мы хотели бы сделать с этими документами на этом этапе. Эти настраиваемые параметры обычно имеют форму операторов, которые мы можем предоставить, которые будут изменять поля, выполнять арифметические операции, изменять форму документов или выполнять какую-либо задачу накопления, а также множество других вещей. Часто бывает так, что мы

например, мы можем захотеть выполнить начальный фильтр, чтобы нам не приходилось передавать всю коллекцию в наш конвейер. Но позже, после некоторой дополнительной обработки, вы хотите снова отфильтровать, используя другой набор критериев. Итак, напомним, конвейер работает с MongoDBколлекцией. Они состоят из этапов, каждый из которых выполняет различные задачи обработки данных на входе и создает документы в качестве выходных данных, которые передаются на следующий этап. И, наконец, в конце конвейера создается вывод, который мы можем затем сделать в нашем приложении. Во многих случаях необходимо включать один и тот же тип этапа несколько раз в отдельный конвейер.